Community
Participate
Working Groups
This is an issue I could observe while working on Bug 306641. I'll attach screenshots.
Created attachment 166321 [details] Screenshot 1
I run Eclipse using these arguments -nl iw -nlExtensions "@calendar=hebrew". However the Hebrew lang pack is not installed. On Screenshot 1, you can see the result of comparing revisions. I marked the confusing label.
Created attachment 166324 [details] The string that is set on the label
For me the fact that the date was swapped around looks wrong. I would expect to see the String in the label as it is, or something like [hebrew date] a.txt :Local history When I install the language pack, the label looks ok.
Created attachment 166328 [details] The label when the Hebrew lang pack is installed
Szymon, any idea who I should direct this defect to? It might be either the compare or BiDi related.
Sorry, Eric, this is for BiDi. TextProcessor scrambles the date as returned from the ICU calendar. We worked around that by only applying TextProcessor to the file name. Now in the actual widget, if we only have English NL packs with a Hebrew date it looks incorrect. If we're using the Hebrew NL packs with the Hebrew date it looks fine. It might just be that the property in English includes "Local History: ${0}" but in Hebrew the property includes "${0} :<HebrewCharacters>" PW
The behavior described in screen shot 1 is expected when using mixed English and Hebrew text. You can verify this by doing the following:- open a text file with notepad on windows OS and write the following (with the same order from left) Local history : a.txt <hebrew date or any hebrew characters> after doing that press right ctrl+shift to mirror the notepad , now you will notice the same display seen in screen shot 1 This didn't happen when using the hebrew translated version which is understood as reading order won't change for LTR or RTL screen (because the whole text is in hebrew) so to reach the desired order (which is <hebrew date> a.txt : local history) i suggest inserting control character "RLM" after the colon for only the case where eclipse is mirrored in RTL
A similar issue was reported in bug 307161 and a general approach was discussed in bug 306751. Instead of patching the PII for ALL languages in the properties files or/and adding control characters for specific scenarios in endless list of contexts in the code (in which problematic PII is loaded), the suggestion is to enforce the structure of PII with a placeholder for given message "on the fly" in one location (where all PII are loaded). The problem is in fact that the structure of message (PII) with placeholder(s ) replaced by end user originated data (which might but not necessarily matches the language of the message), is not enforced. Thus the message appears differently based on the data replacing the placholder(s). The general approach is as follows: 1. The support is invoked only when Bidi is turned on for end user originated data (via -bidi flag). For more details please see bug 307307 2. For each specific loaded message with placeholders (i.e. "hello {0} world: {1}) we identify the language of the message (PII). 3. Based on the language we derive the natural base text direction of the PII (on how to do that programatically please see comment #8 in bug 306751). 4. We parse out the message and inject Unicode control character(s) around the placeholders based on the identified language of PII. The key idea is that PII should be always displayed with natural to it base text direction regardless of GUI orientation. This means that for ALL LTR languages (i.e. English, Russian, etc.) the expected display is: local history: a.txt [hebrew date] independently from GUI orientation. It does not seem naturally to read English sentence from Right To Left: [hebrew date] a.txt :local history For all RTL languages (i.e. Arabic / Hebrew) we should expect to see: [hebrew date] a.txt :YROTSIH LACOL Again, independently from GUI orientation. By the way, having mirrored GUI with English PII or not mirrored GUI with Hebrew PII is not a valid scenario. So, the originally reported problem in this bug is not valid assuming we are using the same data pattern. Namely, In NOT mirrored GUI following text should be properly displayed: local history: a.txt [hebrew date] In the mirrored GUI following text should also be properly displayed: LOCAL HISTORY: a.text [hebrew date] However, assuming Bidi characters are used for file name we might get the following problem: local history: FILENAME.EXT [hebrew date] In NOT mirrored GUI we will get: local history: [hebrew date] TXE.EMANELIF In mirrored GUI we will get: [hebrew date] TXE.EMANELIF :local history Bottom line is that I believe a general solution should be provided as part of fixing bug 306751
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
