From: Temlakos <tem...@gm...> - 2009-10-01 22:20:02
|
Gentlemen: I might be asking something that I should already know, but I don't think so. Is SMW even ready to support a RTL language as effectively as it does with LTR? I've just visited the SMW Community Wiki. I have found /two/ wikis thus far that are even /announced/ with Hebrew support (one ancient, one modern). I saw /one other/ that had Arabic support. Now here's the question: Do any of those wikis handle custom linear data types? Has anyone even /attempted/ to declare a custom linear data type in Hebrew or Arabic? It just occurred to me as I sought to complete the internationalization for Hebrew, to handle dates--and note that as of SMW 1.4.3, the Hebrew file did not even have a date formats file or a months or "monthsshort" array. I have a version ready to test--but then it hit me: SMW_DV_Time.php has routines that are supposed to put the "BC" or "BCE" symbol to the /right/ of the date on output. For an RTL language, that symbol belongs on the /left/. So now I'm asking: what /is/ the current status of RTL support in SMW? How does one annotate a linear value in Hebrew or Arabic? Does one put the unit to the right, or the left? It seems to me that the unit belongs on the left. The wiki that I co-administer, has a Hebrew subdirectory. A week or so ago, I started working on it, to get it ready to announce. And that included installing SMW on it and running its installation routine. So if any of you have any suggestions, or any requests for testing, I stand ready to test anything part of SMW's core, or Semantic Result Formats, or Semantic Compound Queries. (Those are the extensions that I have in place.) As I said, if someone has already thought of this, I'd be glad to hear about it. But right now, I strongly suspect that the SMW code will need extensive reworking, even to having a new global code, either in SMW_Settings.php (to be overridden in LocalSettings.php) or, better yet, in SMW_LanguageXx.php. Say, $smwgWriteDirection. The default, perhaps set in SMW_Language.php, would be "ltr", but the Hebrew, Arabic, and Urdu (when we ever write that) value would be "rtl." I suspect that SMW_DV_Time.php and SMW_DV_Linear.php (and maybe SMW_GeoCoords.php as well) would be dependent on this value, and would have to use it to govern where to find a unit or calendar-preference symbol during parsing (which might not be necessary), and where to /put/ the symbol during /printing/ (which we can't get around). I've thought of another problem specific to annotating dates in Hebrew, but I'll address that separately. Temlakos |
From: Markus K. <ma...@se...> - 2009-10-03 13:51:10
|
On Freitag, 2. Oktober 2009, Temlakos wrote: > Gentlemen: > > I might be asking something that I should already know, but I don't > think so. > > Is SMW even ready to support a RTL language as effectively as it does > with LTR? > > I've just visited the SMW Community Wiki. I have found /two/ wikis thus > far that are even /announced/ with Hebrew support (one ancient, one > modern). I saw /one other/ that had Arabic support. > > Now here's the question: Do any of those wikis handle custom linear data > types? Has anyone even /attempted/ to declare a custom linear data type > in Hebrew or Arabic? Well, I haven't. I don't speak either. If nobody tried it yet, my conclusion would be that there is no pressing demand for it. > > It just occurred to me as I sought to complete the internationalization > for Hebrew, to handle dates--and note that as of SMW 1.4.3, the Hebrew > file did not even have a date formats file or a months or "monthsshort" > array. I have a version ready to test--but then it hit me: > SMW_DV_Time.php has routines that are supposed to put the "BC" or "BCE" > symbol to the /right/ of the date on output. For an RTL language, that > symbol belongs on the /left/. That could be one point that is relevant. I have no idea where "BC" is supposed to go in Hebrew. Maybe someone who speaks the language can help. > > So now I'm asking: what /is/ the current status of RTL support in SMW? > How does one annotate a linear value in Hebrew or Arabic? Does one put > the unit to the right, or the left? It seems to me that the unit belongs > on the left. We have usually taken RTL into account when designing UIs. For example, the Factbox and Special:Browse UIs change directions in RTL languages. For strings, we usually keep the order: when processing strings internally, there is no question of "left" or "right" but only of "beginning of the string" and "end of the string". Units of measurement are expected after the end, i.e. on the left in RTL languages. As far as I see, most of the support you ask for below is already built into SMW and MediaWiki, and I do not see any reworking of code being required here. Whether or not a language is RTL is already defined in MediaWiki and SMW respects this setting. So we do not need new configuration settings. If there are particular features for which RTL needs some updates, please let us know and we will have a look. Cheers, Markus > > The wiki that I co-administer, has a Hebrew subdirectory. A week or so > ago, I started working on it, to get it ready to announce. And that > included installing SMW on it and running its installation routine. So > if any of you have any suggestions, or any requests for testing, I stand > ready to test anything part of SMW's core, or Semantic Result Formats, > or Semantic Compound Queries. (Those are the extensions that I have in > place.) > > As I said, if someone has already thought of this, I'd be glad to hear > about it. But right now, I strongly suspect that the SMW code will need > extensive reworking, even to having a new global code, either in > SMW_Settings.php (to be overridden in LocalSettings.php) or, better yet, > in SMW_LanguageXx.php. Say, $smwgWriteDirection. The default, perhaps > set in SMW_Language.php, would be "ltr", but the Hebrew, Arabic, and > Urdu (when we ever write that) value would be "rtl." I suspect that > SMW_DV_Time.php and SMW_DV_Linear.php (and maybe SMW_GeoCoords.php as > well) would be dependent on this value, and would have to use it to > govern where to find a unit or calendar-preference symbol during parsing > (which might not be necessary), and where to /put/ the symbol during > /printing/ (which we can't get around). > > I've thought of another problem specific to annotating dates in Hebrew, > but I'll address that separately. > > Temlakos > > --------------------------------------------------------------------------- >--- Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch <ma...@se...> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- |
From: Temlakos <tem...@gm...> - 2009-10-03 13:46:48
|
Markus: I've seen a Browse page on my Hebrew site. Yes, it does reverse direction. Of course, that's not a complete test, because thus far I haven't even defined a property in it, much less annotated any value for a property. Very well, then: I feel confident now that I should be able to test certain property definitions within a week. Shall I report my findings to this list? Or to you in private? Or shall I open a Bug in MediaZilla if anything goes wrong? Temlakos Markus Krötzsch wrote: > On Freitag, 2. Oktober 2009, Temlakos wrote: > >> Gentlemen: >> >> I might be asking something that I should already know, but I don't >> think so. >> >> Is SMW even ready to support a RTL language as effectively as it does >> with LTR? >> >> I've just visited the SMW Community Wiki. I have found /two/ wikis thus >> far that are even /announced/ with Hebrew support (one ancient, one >> modern). I saw /one other/ that had Arabic support. >> >> Now here's the question: Do any of those wikis handle custom linear data >> types? Has anyone even /attempted/ to declare a custom linear data type >> in Hebrew or Arabic? >> > > Well, I haven't. I don't speak either. If nobody tried it yet, my conclusion > would be that there is no pressing demand for it. > > >> It just occurred to me as I sought to complete the internationalization >> for Hebrew, to handle dates--and note that as of SMW 1.4.3, the Hebrew >> file did not even have a date formats file or a months or "monthsshort" >> array. I have a version ready to test--but then it hit me: >> SMW_DV_Time.php has routines that are supposed to put the "BC" or "BCE" >> symbol to the /right/ of the date on output. For an RTL language, that >> symbol belongs on the /left/. >> > > That could be one point that is relevant. I have no idea where "BC" is > supposed to go in Hebrew. Maybe someone who speaks the language can help. > > >> So now I'm asking: what /is/ the current status of RTL support in SMW? >> How does one annotate a linear value in Hebrew or Arabic? Does one put >> the unit to the right, or the left? It seems to me that the unit belongs >> on the left. >> > > We have usually taken RTL into account when designing UIs. For example, the > Factbox and Special:Browse UIs change directions in RTL languages. For > strings, we usually keep the order: when processing strings internally, there > is no question of "left" or "right" but only of "beginning of the string" and > "end of the string". Units of measurement are expected after the end, i.e. on > the left in RTL languages. > > As far as I see, most of the support you ask for below is already built into > SMW and MediaWiki, and I do not see any reworking of code being required here. > Whether or not a language is RTL is already defined in MediaWiki and SMW > respects this setting. So we do not need new configuration settings. If there > are particular features for which RTL needs some updates, please let us know > and we will have a look. > > Cheers, > > Markus > > > >> The wiki that I co-administer, has a Hebrew subdirectory. A week or so >> ago, I started working on it, to get it ready to announce. And that >> included installing SMW on it and running its installation routine. So >> if any of you have any suggestions, or any requests for testing, I stand >> ready to test anything part of SMW's core, or Semantic Result Formats, >> or Semantic Compound Queries. (Those are the extensions that I have in >> place.) >> >> As I said, if someone has already thought of this, I'd be glad to hear >> about it. But right now, I strongly suspect that the SMW code will need >> extensive reworking, even to having a new global code, either in >> SMW_Settings.php (to be overridden in LocalSettings.php) or, better yet, >> in SMW_LanguageXx.php. Say, $smwgWriteDirection. The default, perhaps >> set in SMW_Language.php, would be "ltr", but the Hebrew, Arabic, and >> Urdu (when we ever write that) value would be "rtl." I suspect that >> SMW_DV_Time.php and SMW_DV_Linear.php (and maybe SMW_GeoCoords.php as >> well) would be dependent on this value, and would have to use it to >> govern where to find a unit or calendar-preference symbol during parsing >> (which might not be necessary), and where to /put/ the symbol during >> /printing/ (which we can't get around). >> >> I've thought of another problem specific to annotating dates in Hebrew, >> but I'll address that separately. >> >> Temlakos >> >> --------------------------------------------------------------------------- >> --- Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> > > > |