Community
Participate
Working Groups
In the Keys preference panel, key sequences ending with neutral characters such as \ in ctrl+Shift+\ are displayed incorrectly because of the RTL reading order. This is similar to TCT 232, need to be fixed with LRM markers. This article was reassigned from Category:''Legacy Project,TVT,Uncategorized''.
Created attachment 31395 [details] key_sequences_rtl_09.001120.jpg
<cde:tctdetail> Testcase: 09.001120 Project: WSW3A Component: Platform Priority: 2 Subject: Reading order in key sequences containing neutral chars Article ID: 241 Originator: gpelleg@il.ibm.com </cde:tctdetail>
When you find more examples of a problem that already has been reported, please add the examples to the original bug. *** This bug has been marked as a duplicate of 119685 ***
re-opening as key bindings are a special case of the referenced duplicate that may require more than just adding some LRM markers to traslated files.
Neutral characters (e.g. punctuation characters) are causing this problem. Key bindings with strings that are translated (like up arrow or down arrow) appear to display correctly. Note: LRM marker is \u200e.
So, how should the string be composed? "Ctrl+Shift+\u200e\" "Ctrl+Shift+\u200e\\u200e" "Ctrl+Shift+\\u200e"
"Ctrl+Shift+\\u200e" The LRM marker goes after the character you want to be oriented LTR.
Okay, I've fixed it so that the translations for AbstractKeyFormatter.properties can add LRM markers wherever they see fit. The English version will have no such markers. So, for example, let's take '\'. In the English AbstractKeyFormatter.properties file, there will be no entry for '\'. This means '\' doesn't need to be translated and will appear as is. In the Arabic AbstractKeyFormatter.properties file, the translators will need to add an entry for '\'. It might look like this # Neutral characters need LRM markers \=\\u200e The big catch here is that translator will need to *add* keys to this property file. I'm not sure if this is something you guys normally do.
NL issues should transparent to the platform so I think this is the right solution.
Okay, the fix is in for 3.2 M5. If this fix is needed for 3.1.2, then please let me know. It's low risk, but would require new translation files.
I don't think translations are being done for this point release. Kit, is that correct?
>The big catch here is that translator will need to *add* keys to this property file. I'm not sure if this is something you guys normally do. We don't do this normally. We should add this key to English AbstractKeyFormatter.properties file, with a comment saying only RTL languages (Arabic and Hebrew) should append the LRM. Other languages should not touch this key. >I don't think translations are being done for this point release. Kit, is that correct? Translations are NOT being done for this point release.
(In reply to comment #12) > We don't do this normally. We should add this key to English > AbstractKeyFormatter.properties file, with a comment saying only RTL > languages (Arabic and Hebrew) should append the LRM. Other languages should > not touch this key. In that case, I will need an exhaustive list of all characters that might possibly need an LRM marker in RTL languages.
The status of the article and the state of the corresponding problem may be out of sync.]
Bug was inadventantly closed because CDE cannot reopen the associated translation article.
The neutrals are spaces, punctuation marks and special chars including: . , ; ! ? ~ @ # $ % ^ & * ( ) { } [ ] < > \ / " ' ` | i.e. everything except letters of the English or Hebrew/Arabic alphabet (those are either strong LTR or strong RTL), and digits (which have "weak" directionality). Also see http://www.unicode.org/reports/tr9/ For the benefit of the translators, we should add a comment to the properties file for the strings that are there only because RTL locales need them to add LRM markers. Why was this bug re-opened? From the platform ui's perspective it is resolved. Either a new bug should be opened against releng to add the LRM markers to the translations or this bug should be transferred to releng.
I re-opened it because of comment #12. We need to add the translation keys to AbstractKeyFormatter.properties so the translation team knows that LRM markers need to be added in some places.
I've also come to realize that this problem is Windows-specific. GTK+ handles the neutral characters correctly. Does Microsoft have an open bug about its handling of neutral characters?
Moving Dougs bugs
Karice, Can we have this bug fixed in the service pack 3.2.1. Thank you.
Paul, do you think you will have a solution for this bug for 3.2.1?
*** Bug 147053 has been marked as a duplicate of this bug. ***
*** Bug 119685 has been marked as a duplicate of 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.
