Community
Participate
Working Groups
OS: Windows Build date: 05232007 Component Name: EMFT-QVT Blocking: No Tester Name: Noha Steps to recreate the problem: Right click the Library item in the ".extlibrary" file editor. Select OCL Interpreter -> Show Console. In the bottom pane of the console type the text: ecore::EClass.allInstances()->closure(eSuperTypes->at(0).oclAsType(ecore::EClassifier)) Press <Enter>. Problem description: The Arabic string which appears is not RTL enabled. It has incorrect reading order and it is left aligned. Forwarding to development... This article was reassigned from Category:''TVT Testcases''.
Created attachment 69111 [details] 08.001120.jpg
<cde:tctdetail> Testcase: 08.001120 Project: WSW33 Component: CDE - MDT/OCL Priority: 2 Subject: ar: Arabic string not RTL enabled Article ID: 404 Originator: husseinn@eg.ibm.com </cde:tctdetail>
The string in question is produced by the ReflectiveItemProvider in the EMF run-time. However, in this particular occurrence, I don't think that this is even a bug, as the OCL Console is an example, and this display is not intended as production code. The OCL console is only used to test the translations of error messages, which are the only strings from the OCL run-time that users see. The example, itself, is not in the scope of TVT testing.
Sorry ... I didn't understand that what I was seeing in the screenshot was an error message. Thanks to Bryan for providing more information.
I would have thought it should only be necessary for the translation of the message pattern in the *.properties file to reverse the {0} and {1} placeholders in order to accomplish a right-to-left reading.
Updating screen shot.
[Added by CDE: Completed by the CDE Bridge]
I'm confused ... I just reopened this bug, then "CDE Admin" (is that a bot of some kind) closed it. Please reopen if this is a problem.
Created attachment 69160 [details] updated screen capture Christian, cdeadmin is a bridging bot between Bugzilla and the reporting system that the testers use. There must be a collision. Please reopen again. In Eclipse Platform, we should process the string with OSGi TextProcessor API (see http://wiki.eclipse.org/index.php/New_Bidi_APIs). However, not sure if OCL have access to the API.
Thanks, Kit, for the indication of what the result should look like. It seems to me, though, that this simply requires re-ordering of the text in the Arabic translation of the the string in the properties file. Why is that not sufficient? You are right that requiring TextProcessor is a problem for OCL, as it needs to work in non-Eclipse/non-OSGi environments, the same as EMF and UML2. I thought TextProcessor was only required to process structured text, such as file paths and URIs? We have no structured text in this case.
Arabic is a Bidirectional language. For pure Arabic characters, they read from right to left. However, when English chars (like "EClass") and neutral chars (like "()\/.:" etc) are encountered, the reading changes to left to right. (This is just a quick summary. I will need days to give you more details :-) Whenever there are a mixture of Bidi chars (Arabic and Hebrew) and English chars in a string, we have to process the string with the TextProcessor API is order to display that correctly. This happens very often in path names with \, /, and Bidi folder name in the middle, but not limited to that. Did you say the string was generated? If the string is from a properties file, please let me know the path and file name. Sometimes the translator can add some LRM and RLM (left-to-right and right-to-left markers) in the translation to fix the problem.
Thanks, Kit. I think I understand, now. No need to gather more details. Yes, the string is a MessageFormat pattern stored in the OCLMessages.properties file in the org/eclipse/ocl/internal/l10n folder of the org.eclipse.ocl plug-in (along with several dozen other error messages that would undoubtedly need the same treatment). If it would be too costly to insert these BiDi markers into the translation of this file (several dozen messages), I'll be happy to use an EMF-provided Eclipse/OSGi-independent text processor utility when it should become available (I understand that this is unlikely in the Europa timeframe).
Converting to an enhancement for the next release, to consider how to make the console easier to read in BiDi locales. The original problem of error messages appearing to be malformed has been resolved. It was caused by the results panel of the console forcing an LTR orientation because it echoes the OCL expression entered by the user, which requires LTR for correct rendering. Unfortunately, an error message requires RTL orientation, but the text widget cannot be both. This was demonstrated by testing the scenario again with a patched console that uses RTL orientation in the results panel, in which the error message was observed to read correctly. So, for the next release, we should find a different/better way to report errors in the console. It is unlikely that TextProcessor would be the solution, because its purpose is to insert BiDi markers into text, which is independent of LTR vs. RTL display.
I believe there is a key combination that the user can exploit to flip the orientation of a widget dynamically, but I could be wrong about that...
The OCL team do not have the skills or resources to resolve let alone test RTL issues. Feel free to reopen if you are able to contribute to a solution or can identify standard Eclipse UI tooling that would resolve this problem automatically.
*** Bug 234759 has been marked as a duplicate of this bug. ***
Closing after over 18 months in resolved state.
