Community
Participate
Working Groups
Created attachment 92655 [details] incorrect layout of search result Build ID: I20080395-1100 Steps To Reproduce: 1. Install: - Eclipse Base Platform Runtime eclipse-RCP-3.4M5-linux-gtk.tar.gz - NLpackBidi-eclipse-RCP-3.4M5-linux-gtk.zip - Eclipse IDE Platform Runtime eclipse-platform-3.4M5-linux-gtk.tar.gz - NLpackBidi-eclipse-platform-3.4M5-linux-gtk.zip - JDT Runtime eclipse-JDT-3.4M5.zip - NLpackBidi-eclipse-JDT-3.4M5.zip 2. Set default locale to Hebrew 3. Run Eclipse with command line including following argument -nl iw 4. Open search dialog: Search->File 5. Choose *.html as File Name pattern. 6. Run search. 7. Inspect the search result in Search view. Expected result: text containing search result (like "0 file names matching….") is right aligned and displayed correct. See correct display in attached file "english version". Actual result: text containing search result (in Hebrew) is left aligned and displayed incorrect: the number of file names (0) is displayed after the text. More information:
Created attachment 92656 [details] correct english version
released fix > 20080414
*** Bug 181300 has been marked as a duplicate of this bug. ***
Created attachment 97776 [details] screen shot from I20080427-2000 (In reply to comment #2) > released fix > 20080414 Martin, I'm not sure if this is really fixed in I20080427-2000, at least the dup bug seams not to be fixed.
Created attachment 97965 [details] I20080428
Still reproducible in build I20080428, see attachment Resolution of this issue depends on bug 229010
The positioning of the parentheses is really strange. They are not part of a technical name, but part of a normal Hebrew sentence and should therefor be correctly positioned without any special treatment or processing on our side. I'll bring up this issue in bug 229010.
oops, sorry, this bug is not about the positioning of the parentheses. I'll bring that up in an other bug. Please ignore here.
I understand that comment 7 relates to the screen capture added in comment 4. Please notice that the message template in problem illustrated in comment 4 and original problem are different. Case 1 ------- The template of message in the original problem is something like this: {P0} names of files matching {P1} in workspace where P0 = number of matches (i.e. 5) P1 = search pattern (i.e. "*.html") Case 2 ------- The template of message in the problem illustrated in comment 4 is probably something like: {P0} - {P1} match in workspace {P2} where P0 = name of matching file P1 = number of matches (i.e. 6) P2 = search pattern (i.e. "*.txt") Here is the analysis of both cases. Case 1: ------- The only placeholder which requires special attention is P1. It is supposed to have LTR direction since search pattern has LTR direction. Consequently you simply have to use a new function from bug 229010 to enforce LTR direction for the text replacing P1 placeholder. Case 2: -------- The only placeholder which requires special attention is P2. It is supposed to have LTR direction since search pattern has LTR direction.Consequently you simply have to use a new function from bug 229010 to enforce LTR direction for the text replacing P2 placeholder. Finally, let me explain what you see on the screen capture added in comment 4. You have two issues: 1. The message is not translated to Arabic / Hebrew. It is not a valid scenario to use mirrored Eclipse with not translated messages. You can of course still use Latin custom data (i.e. search pattern can include Latin chars - *.txt). However the message (in our case 'match in workspace ') must be translated. Please notice that if you translate the message you will get something similar to the following: (txt.*) ECAPSKROW NI HCTAM 1 - 'TXET CIBARA' instead of what you see on the screen capture in comment 4 (match in workspace (*.txt 1 - 'TXET CIBARA' This is almost perfect except for search pattern. 2. The direction of search pattern must be enforced to LTR. When you enforce LTR direction to search pattern you will get: (*.txt) ECAPSKROW NI HCTAM 1 - 'TXET CIBARA'
Thanks, Tomer, for the detailed explanation. So we should really start to us the new function from bug 229010.
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
