Community
Participate
Working Groups
Created attachment 159424 [details] Screen shot with the wrong display of Date on Windows XP Steps to reproduce 1-Download and Extract Eclipse Galileo SR1 on an Arabic locale Windows XP PC 2-Connect to a CVS repository and download a file or project 3-Switch to Java perspective and right click on a file downloaded from CVS and select "compare with ", "Another Branch or Version" 4-A Dialog will appear, press the "Add Date" button then add any date 5-Expand the available dates and view the date entered in the previous step The Expected result : The date is displayed correctly The Actual result : Te date is displayed in a scrambled format when Arabic numerals are used Starting from right to left, it is the Month, then the year, then the time selected then the Day of the month please refer to screen shots
Created attachment 159426 [details] Screen shot showing correct display on Linux
Created attachment 159427 [details] Screen shot of correct display on Windows XP when Eclipse is launched in RTL mode Most probably the bug reason is due to text reading direction, it is contextual on Linux so the display is correct, on Windows, it follows the Eclipse direction so it appears in this way
This can be solved by inserting control character (RLE or RLM ) at the buffer start for the date to be displayed, however the same incorrect display occurs in other different views for example in property dialog of a certain project (see screen shot). Therefore I would suggest centralizing this support by adding it in ICU SimpleDateFormat.java and replacing the use of java.text.SimpleDateFormat. Since it will take some time for this support to be added in ICU, as a temporary solution we may concatenate the control character to the date for displaying purpose and remove it later after the shipment of ICU new date support What do you think?
Created attachment 161715 [details] Wrong Date display in Property dialog Screen shot for wrong date display in property dialog
Haven't had a chance to look at it in M7, removing the target.
Created attachment 184118 [details] Suggested patch Suggested patch to the bug
(In reply to comment #3) > Since it will take some time for this support to be added in ICU, [...] Have you field a bug against ICU for that issue?
So if eclipse is run with -nl ar the dates show up incorrectly? Would calling org.eclipse.osgi.util.TextProcessor.process(String) on the string insert the correct character, or is LRE the wrong thing (normally used for fixing paths)? PW
The dates show incorrectly on Arabic locale with the eclipse opens in ltr mode, So yes if the parameters are -nl ar -dir ltr the dates will be shown incorrectly. org.eclipse.osgi.util.TextProcessor.process(String) process text with semantic meaning like file paths and it is always Left To Right , in this case we need the orientation of the text to be Right To Left using RLE. (In reply to comment #8) > So if eclipse is run with -nl ar the dates show up incorrectly? > > Would calling org.eclipse.osgi.util.TextProcessor.process(String) on the string > insert the correct character, or is LRE the wrong thing (normally used for > fixing paths)? > > PW
(In reply to comment #9) > The dates show incorrectly on Arabic locale with the eclipse opens in ltr mode, > So yes if the parameters are -nl ar -dir ltr the dates will be shown > incorrectly. AFAIK we fundamentally don't support this. It seems to me that this should be addressed for eclipse as a whole through the work items intended to provide pluggable BiDi processing. Spot fixes will only make the entire system inconsistent. As Dina mentioned, this would effect every date that's supplied currently through com.ibm.icu.text.SimpleDateFormat. At the very least, this should be addressed with a utility method in TextProcessor, which already has the IS_PROCESSING_NEEDED flag set. PW
(In reply to comment #10) > It seems to me that this should be > addressed for eclipse as a whole through the work items intended to provide > pluggable BiDi processing. Do we have such work items already? If not, where they should be opened, in the UI?
(In reply to comment #11) > (In reply to comment #10) > > It seems to me that this should be > > addressed for eclipse as a whole through the work items intended to provide > > pluggable BiDi processing. > > Do we have such work items already? If not, where they should be opened, in the > UI? There is an open bug 183164 and there is its "dynamic" counterpart in SWT land.
Removing the target milestone since we depend on a different bug. Once the blocking bug is fixed we'll retarget this bug.
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.
