Community
Participate
Working Groups
<response_by> Mostafa Ali at 2008.06.02.17.52.48 </response_by> OS: Linux Build date: 0601 Component/Function name: CDT Language: Arabic Tester Name: Mostafa Ali Steps to recreate the problem: In the C/C++ Projects view, right click on project xlc and select Properties. Select C/C++ Build -> Settings. On the Tool settings tab, select Input Control under XL C++ Compiler. Verify the highlighted areas are translated (scroll down to verify all strings). Problem description: There are several reversed parentheses, plus, the drop down menu items are not translated <response_by> John Ryding at 2008.06.03.08.06.17 </response_by> This article was reassigned from Category:''TVT/Testing,Inbox''.
Created attachment 103300 [details] 05.001930.jpg
<cde:tctdetail> Testcase: 05.001930 Project: WSW34 Component: Xfer - CDT/cdt-build Priority: 2 Subject: The parentheses are reversed, and the menu items are not translated Article ID: 704 Originator: mali@eg.ibm.com </cde:tctdetail>
The untranslated strings are fixed in bug 234946 *** This bug has been marked as a duplicate of bug 235318 ***
<response_by> Mostafa Ali at 2008.06.09.08.34.46 </response_by> Hi, The closing parenthesis problem is fixed, but the strings are missed up. What I want is to keep the order of the strings as they were and just correct the closing parenthesis direction. Attached is an example of the missed up strings. Thanks Mostafa
Created attachment 104148 [details] 05.001930_b.jpg
This might be related to bug 234742. https://bugs.eclipse.org/bugs/show_bug.cgi?id=234742#c6
<response_by> John Ryding at 2008.06.12.11.29.26 </response_by> This has been deferred. It will be considered for the 3.4.1 service pack.
*** This bug has been marked as a duplicate of bug 236513 ***
reopen. this is the reserved paratheses problem.
The status of the article and the state of the corresponding problem may be out of sync.]
(In reply to comment #9) > reopen. this is the reserved paratheses problem. > Hi Felipe, I'm already using the TextProcessor API to process the string as seen in 05.001930_b.jpg but I'm still not getting the correct ordering. Do you have other suggestions for me? Kit mentioned that this might be occurring because there is an English string in the middle of the BIDI string.
Sorry, I didn't read the whole report last time around. This can be a dup of bug 236513. What is the String ? Does it start with an English word ?
This is the string and it does not start with any English word: Option.cinc=\u0627\u062F\u0631\u0627\u062C "C" {} \u062E\u0627\u0631\u062C\u064A \u0641\u064A \u0645\u0644\u0641\u0627\u062A \u0627\u0644\u062A\u0636\u0645\u064A\u0646 \u0627\u0644\u0645\u062D\u062F\u062F\u0629 (-qcinc)
works for me. I set this string as it is in a Label, Text, and StyledText and it works fine. Are you sure this string is set exactly like that ? Doesn't the TextProcessor change the string ?
In the case of this string the bidi algorithm needs help. But, IMO, TextProcessor API is not what you want, see my comments in Bug 146220 comment #10. IMO this string should be fixed the the catalog file, the right form should be: "\u0627\u062F\u0631\u0627\u062C \"C\" {} \u062E\u0627\u0631\u062C\u064A \u0641\u064A \u0645\u0644\u0641\u0627\u062A \u0627\u0644\u062A\u0636\u0645\u064A\u0646 \u0627\u0644\u0645\u062D\u062F\u062F\u0629 (\u202A-qcinc\u202C)"; -> the english text in this case needs to be surrounded with a left-to-right embeding mard and a pdf. Please, have a hebrew/arabic translator to confirm this.
In another words: this is a bug in the translation not in the code.
Hello, if you mean left-to-right marker, I already tried this during the TVT and it didn't work. It is written in your response (left-to-right embeding mard), but I guess this means marker. I don't understand what you mean by (a pdf) in the text? Does it mean to convert the string to pdf or what? I am not sure what you are pointing to here. Finally, I don't think this is a translation problem because there are a lot of similar cases in other components and they are displayed correctly. Thanks
I really meant: U+202A: LEFT-TO-RIGHT EMBEDDING (LRE) U+202C: POP DIRECTIONAL FORMATTING (PDF) I think the mark you are talking about is something different: U+200E: LEFT-TO-RIGHT MARK Try the string I paste in comment 15, doesn't that work good in LTR and RTL ? Can that string be store in the catalog ? Please, ask somebody else with lots of experience with the bidi algorithm if what we are doing here is the right thing. The smartest guy I know in this area is probably Matitiahu Allouche. Tomer Mahlin is also pretty good.
Strictly speaking the problem discussed here does not belong to "Message with placeholder" type of complex expression since the message does not include any placeholder replaced by run time data. In other words the entire message is coming from resource file. From this perspective I agree with Felipe (see comment 16) that the problem should be resolved in translateion, not in the code. In other words using of TextProcessor is not going to resolve anything in this case. Having said that I do see the issue closely related to the problem of complex expressions of type "Message with placeholder". This is for a very simple reason - all messages mentioned in this defect have translated and not translated portions. All pieces of text which are not translated can be viewed as placeholders replaced with Latin data. For those pieces of data LTR direction should be enforced. This method (enforcing direction for placeholder in a text message) is described in following defects: * Design articulated by Bidi architect - Mati can be found in section 3.8 "Message with placeholders" at: https://bugs.eclipse.org/bugs/attachment.cgi?id=96407 * The implementation and best practices (aka algorithm) for using this implementation for resolution of similar issues were suggested in bug 229010 Some basics: ------------- To enforce direction of a piece of text regardless direction of possibly present surrounding text use following method: a. To enforce LTR direction: myText = LRE + LRM + myText + LRM + PDF b. To enforce RTL direction: myText = RLE + RLM + myText + RLM + PDF How this method should be applied to the examples discussed in this thread ? ---------------------------------------------------------------------------- Example 1: Please see attachement in comment 5 for illustration. One of the messages in this case is as follows: Compile any file as a c++ file (-+) I believe that in the translated form it should look as follows: (-+) ELIF c++ A SA ELIF YNA ELIPMOC To achive this display you need to enforce the direction of "(-+)" and "c++" to LTR. This means that using mentioned above method you should have in the resources something like this: COMPILE ANY FILE AS A <LRE><LRM> c++ <LRM><PDF> FILE <LRE><LRM> (-+) <LRM><PDF> Example 2: Please see attachement in comment 5 for illustration. Another message in this case is as follows: Insert extern "C" {} in the specified include files (-qcinc) In my humble opinion in the translated form it should look as follows: (-qcinc) SELIF EDULCNI DEIFICEPS EHT NI extern "C" {} TRESNI Please notice that the word "extern" should not be translated since it is part of the directive which is suggested for insertion. Using mentioned above method you should have in the resources something like this: INSERT <LRE><LRM> extern "C" {} <LRM><PDF> IN THE SPECIFIED INCLUDE FILES <LRE><LRM> (-qcinc) <LRM><PDF> Example 3: Please see attachement in comment 1 for illustration. The message in this case is as follows: Specify an additional search path for #include s(-I) I believe that in the translated form it should look as follows: #include s(-I) ROF HTAP HCRAES LANOITIDDA NA YFICEPS Using mentioned above method you should have in the resources something like this: SPECIFY AN ADDITIONAL SEARCH PATH FOR <LRE><LRM> #include s(-I) <LRM><PDF> Example 3: Please see attachement in comment 1 for illustration. The message in this case is as follows: Control the interopertaion of and subsequent generation of code for asm statement (-qasm) I believe that in the translated form it should look as follows: (-qasm) TNEMETATS asm ROF EDOC FO NOITARENEG TNEUQESBUS DNA FO NOITAREPORETNI EHT LORTNOC Using mentioned above method you should have in the resources something like this: CONTROL THE INTEROPERATION OF AND SUBSEQUENT GENERATION OF CODE FOR asm STATEMENT <LRE><LRM> (-qasm) <LRM><PDF> PS. <LRE> = U+202A <LRM> = U+200E <PDF> = U+202C If you wonder why you need to use both LRE/LRM (or RLE/RLM) for enforcing a direction of text token (according to UBA using of LRE (or RLE) is sufficient), please notice that this is due to known limitation of presentation engine used by OS.
> If you wonder why you need to use both LRE/LRM (or RLE/RLM) for enforcing a > direction of text token (according to UBA using of LRE (or RLE) is sufficient), > please notice that this is due to known limitation of presentation engine used > by OS. Which OS/version ? can you give me an example where the OS fails without the extra LRM (or RLM) ? Thank you
Tomer, I feel that this problem can't benefit from proposed enhacements for TextProcessor (bug 229010). The solution here, in my opnion, is to fix the translation. Do you agree ? I'd say that is not only the simplest solution but also the only one possible. Would you also recommend to them to fix the translation ?
In response to comment 21. Yes, I agree that the problem can be resolved only on the resources level. TextProcessor works in the code and is useless here. Resolving the problem in the code is possible but much more expensive (since it involves analyzing the translated message, parsing it and isolating the tokens for which direction should be enforced to LTR) and by all means is not justified in the discussed here cases.
In response to comment 20. I personally discovered the problem for the first time on Windows OS. Please notice that when the string (direction of which you want to enforce) is not surrounded by any additional text usage of LRE + PDF (or RLE + PDF) is sufficient. The sample using which I discovered the issue was as follows: " (*.java) " This string has LTR direction. I wanted the *.java to be displayed the same way when the direction of the whole string is changed from LTR to RTL. If I follow UBA and use: " (<LRE>*.java<PDF>) " I get: " (.*java) " Please notice the relative position of dot and star. Following the method described in bug 229010: " (<LRE><LRM>*.java<LRM><PDF>) " I get correct display. You can try this example using Notepad. Please also notice that in input fields in IE adding LRE/PDF is sufficient since in that case a slightly different implementation of presentation engine is used.
*** Bug 287080 has been marked as a duplicate of this bug. ***
