Community
Participate
Working Groups
Build Identifier: What constitutes Bidi support ? --------------------------------- Bidi support is divided into 2 major categories: #1 Enablement for translation to Arabic / Hebrew. Usually this means mirroring of product GUI #2 Support for typing, presenting, processing and transforming of Bidi text. How support for Arabic / Hebrew translation is different from the rest of Bidi support ? ----------------------------------------------------------------------------------------- One of the major difference lies in the distinction between following two types of text in which Bidi : * Program Integrated Information (PII) text - translatable resources packaged with the application * End user originated text which does not come with the application Support for translation to Arabic / Hebrew assumes presence of PII. While support for typing, presenting etc. of Bidi text assumes presence of Bidi characters in the end user originated text. From end user perspective: * support for translation is realized only when Eclipse appears translated to Arabic / Hebrew. * as opposed to that, support for typing, presenting etc. of Bidi text is realized in any version of the product. For example: a. in not translated English version when Bidi chars are used as part of end user originated text b. in translated into non-Bidi (i.e. French, Russian) language version when Bidi chars are used as part of end user originated text c. in translated into Bidi (i.e. Arabic, Hebrew) language version when Bidi chars are used as part of end user originated text It worth mentioning that a mixture of PII and end user originated text also occurs in Eclipse (see bug 306751 for more details). Issues with display of Bidi text usually occur in the context of presence of Bidi characters in stand alone end user originated text or in the mixture of PII and end user originated text. There usually no problems with proper display of pure PII text including Bidi chars. How Eclipse invokes support for various aspects of Bidi support ? ------------------------------------------------------------------ Support for translation into Arabic / Hebrew is invoked: - explicitly via command line option -dir (i.e. -dir ltr => not mirrored GUI, -dir rtl => mirrored GUI) - implicitly via nl command line option specifying default locale (i.e. -nl he / -nl ar will cause Eclipse GUI to appear mirrored) There is no any way to invoke Bidi support for proper typing, display etc. of Bidi data. Several attempts were made to connect/condition invocation of this support to default locale (i.e. TextProcessor is invoked only for Bidi locales - see bug 179724 for more details). Why current approach is not sufficient ? ---------------------------------------- Default locale is tightly connected to language of PII which is loaded into Eclipse and thus can be used as a trigger for invocation of support for translation. However, it has very little to do with end user originated data. Please notice that at least in Israel, most commonly used platform is Bidi enabled English platform (i.e. not translated English OS + ability to type and display Bidi text). Thus in this case the locale is 'en' while the end user originated data mostly in Hebrew. Consequently, in this case, connecting invocation of Bidi support for typing, presenting etc. of Bidi text to locale misses the point. What is missing ? ------------------ A new property / command line parameter which controls invocation of Eclipse specific aspects of Bidi support in the context of end user originated data. The suggestion is to call property "bidi". It will assume following values: y - invoke Bidi support. n (default) - don't invoke Bidi support. -bidi y => invoke Bidi support -bidi n => don't invoke Bidi support Who will leverage new parameter or What aspects of Bidi support should be conditioned on it ? ---------------------------------------------------------------------------------------------- There is no attempt to condition/control Bidi support inherited by Eclipse from OS. The goal is to condition/control only Eclipse specific newly developed aspects of Bidi support. Here are several examples: 1. Support for complex expressions: TextProcessor ( see bug 119517 , bug 126402 and bug 139806 for more details), Next generation of TextProcessor (see bug 183164 for more details), Dynamic types of complex expressions (see bug 230854 for more details) 2. Support for messages with placeholders (replaced by end user originated text): see bug 306751 for more details 3. Control over base text direction independently from GUI orientation: see bug 273198 for more details The general criteria for cases which should leverage new property is defined as follows: a. Support must be Eclipse specific (in other words, we don't affect what OS provides, we only affect when to provide what Eclipse has on top of what OS provides). b. Support must be related (directly or indirectly) to end user originated data. Reproducible: Always
Good suggestion ! Introducing of -bidi option would allow us to distinguish clearly between 'bidi functions enablement' and 'enablement for translation' On the other side, seemly doing that will make one of options (-dir or -nl) absolutely obsolete: I don"t know if -nl options is used for other languages or not. If it is used currently only for BIDI , than it can be removed If it is used also for purposes other than BIDI support, than -dir option can be removed, but having 3 options for eclipse invocations in a bidi environment seems to be overdone.
Dear Adir, I believe this is a misunderstanding. Please notice that: -nl - is a general flag used for ALL languages and is mainly associated with =>PII data<= (loading PII matching specified language) and cultural related functionality (i.e. translation of calendar months' names to specified language). -dir is used for Bidi languages only but it is mainly associated with =>GUI layout<= not with end user data or PII. -bidi flag is used for Bidi languages only and is mainly associated with =>end user originated data<=. You are correct that -nl and -dir flags are connected. Following the rule: " GUI must be mirrored IF AND ONLY IF it is translated to Bidi language (Arabic / Hebrew) " , only if Arabic / Hebrew PII is loaded, the GUI should be mirrored. The problem is that in Eclipse, it is not trivial to figure out (even in the context of a single plug-in) which PII is de-facto loaded (you can run Eclipse with -nl he, but if Hebrew PII is missing, English will be loaded). This was one of the reasons for introducing additional parameter controlling GUI direction independently from language / locale (-dir). Thus now, end user can specify his preferable GUI language (aka PII) via -nl and control GUI orientation via -dir independently. Please also notice that none of those (nl / dir) parameters control Bidi support in the context of =>end user originated data<=. Theoretically we don't need any additional parameter, since potentially every end user can use Arabic/Hebrew data for interacting with Eclipse (even if Eclipse itself is in English / Russian, Chinese etc.). However, due to cost (specifically computation time)which invocation of Bidi support entails in this context, Eclipse community tend to limit it for Bidi users only. So far, it was mainly done based on -nl parameter. However, as I explained earlier, this is not adequate for majority of customer scenarios. Thus a separate parameter is required.
Since we need to control both structured text display and enforcement of base text direction (for more details on API please see bug 383185) the suggested syntax is as follows: -bidi on=y textDir=ltr on =[y/n] - will be used for structured text handling (e.g. handleSText(Text, String)) and possibly for BTD enforcement. y - means bidi support is invoked. n - means bidi support is turned off. textDir = [ltr,rtl,auto] - will be used for BTD enforcement ltr - Left To Right rtl - Right To Left auto - Contextual (the word / term auto is borrowed from HTML 5 spec. it looks like it is shorter than contextual and thus less error prone from specification/typing perspective. Both auto and Contextual refer to the same concept of course). If textDir is not specified or on=n the API enforcing it does not do anything. Only if on=y and textDir has a valid value the API will do actual work. The syntax for this parameter is very similar to the one added via bug 243270 .
Even more so: -bidi on=y textDir=ltr dir=rtl The dir under -bidi will initialize the same parameter in the code as -dir currently does. If both -dir rtl and -bidi dir=ltr are specified -dir will take precedence (for backward compatibility reasons). The advantage of adding dir under -bidi is in fact that all Bidi processing related parameters are grouped together and appears under the same flag (-bidi): dir - controls GUI direction on - controls invocation of Bidi support in the context of text processing textDir - controls base text direction for end user supplied text.
Following the same syntax convention as in bug 243270 we should have: -bidi "on=y;textDir=ltr;dir=rtl" The order of parameters (which are all optional) is not important: -bidi "dir=rtl;on=y;textDir=ltr" Invalid parameters or values are ignored: -bidi "dirsss=rtl;on=fffy;textDir=ltr" is equivalent to: -bidi "textDir=ltr"
Created attachment 219477 [details] Patch for the new -bidi command line option
Hi Paul, Can you please take a look at the submitted patch ? Thanks a lot.
Created attachment 219561 [details] I only attached a few comments to the first patch Hello Paul, Could you please look into this patch ? Thank you very much
Created attachment 219623 [details] BTD and STT listeners + APIs Hello Paul, Could you please review this patch ? This is for BTD and STT segment listeners and also for the APIs enforceBTD and handleStructuredText Thank you very much for your review
Hi Moshe, I believe the patch from comment #9 actually belongs to bug 383185 :-)))
Hi Tomer, yes you are right. I put the new patch in bug 383185
(In reply to comment #8) > Created attachment 219561 [details] > I only attached a few comments to the first patch Comments: 1) setBidiSystemProperties should be called parseBidiArguments 2) Don't use system properties. Why doesn't that method set the appropriate information on the jface BidiUtils class? PW
Paul, I think following your last advise we already addressed second point in your comments (we will change the name as you suggest in first point as well in the next patch) in the latest patch attached to bug 383185 . Also I believe starting from that patch, we should continue the conversation in bug 383185 since patches attached to that bug address now issues reported in bug 383185 and bug 307307 Moshe, please check also comments added to bug 383185 . Thanks.
Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2e5fe234b6d1f9c3439e253a68861444332d0a82
The command line parameters are properly passed to the Eclipse, but it seems to be ignored by Eclipse (the several Bidi related bugs is still in the "new" state) Verified in the build: I20130311-2000-win32-x86_64
