Community
Participate
Working Groups
Build ID: 20080314_1059 Steps To Reproduce: 1.On a Windows plaftorm with Hebrew locale launch Eclipse with the arguments: -nl iw 2.Choose Run->External Tools-> External Tools Configuration 3.Look at the last sentence: .preference page Perspectives Configure launch perspective settings from the The right display should be : .Configure launch perspective settings from the Perspectives preference page More information:
Do you get the same thing in the run/debug dialogs as well? You may need to deselect the default selection if there is one.
Please pardon me but I don't understand your last sentence: "You may need to deselect the default selection if there is one." The problem I describe is not specific to the Run dialogs. You have the same behavior in the Help->Sofware Updates dialog Look at the bottom of the screen: You see: Update Preferences Specify the update schedule and other The right display should be: Specify the update schedule and other Update Preferences
I don't see the problem described. The sentence in question is properly NLS'd on our our end (for the launch dialog part anyway). Could it be that there is a problem setting an NLS'd message in the link widget?
Created attachment 94181 [details] Capscreen for the Run Dialog
Created attachment 94182 [details] Capscreen for the Help->Software Updates Dialog
There was a minor mistake in the expected results definition. The expected result is: Configure launch perspective settings from the Perspectives preference page. The dot should appear on the right side of the sentence. This is simply becasue this is an English sentence and consequently it must have LTR direction.
>The dot should appear on the right side of the sentence. This is simply becasue >this is an English sentence and consequently it must have LTR direction. Tomer, if you look at the picture (https://bugs.eclipse.org/bugs/attachment.cgi?id=94181) then all other sentences have the '.' on the left as well (actually everywhere in the UI). Isn't that OK i.e. should we not touch/mask those sentences since otherwise we might tweak the translated string, which we expect to have in place when starting with -nl iw. I'm treating this bug as being for the wrong placement of the link, which is caused by the Link widget.
Most likely a dub of bug 102584.
There is a simple rule which usually should be followed: Application GUI must be mirrored if and only if it is translated to Bidi language. In other words, running GUI application in the mirrored mode when it does not have translated to Bidi language resources is not a valid scenario. If you do run an application in the mirrored mode but your resources are not translated and appear in English they should have LTR direction since this direction is a natural direction for English text. If English sentence has LTR direction the dot will appear on the right side of the sentence. If English sentence has RTL direction the dot will appear on the left side of the sentence. I believe that the correct way to handle this deffect is to complete the translation. If all part of sentence (including links) are translated the problem will not occur.
Right, that's what I assumed. The only remaining thing will then be bug 102584.
We have two different behaviours to bidi reordering in Link: 1) syslink based, native to win32, used by windows xp and vista 2) textlayout based, used by win2k, gtk, carbon, etc The problem you have here only happens in syslink. syslink divides the text in runs and handle each run independently, this causes a problem here but fixes the problem in bug 102584. The patch in bug 102584 is a hack to force textlayout based link to behave like syslink. It would in fact introduce this problem on windows 2000. Personally I don't know what is the right behaviour: syslink or textlayout. Developer from IBM Israel think syslink is right way to go, see bug 102584. I found no way to override how syslink reorders the bidi text. I'm closing this bug as won't fix, platform behaviour. For discussion about textlayout based link versus syslink please refer to bug 102584.
