Bug 58647

Created attachment 1605 [details]
Edit Contact Dialog in Chinese

The text in Green circle means correct accelerators have been specified, red
circle wrong.

It seems that KAcceleratorManager cannot deal DBCS well, maybe in Arabic or
Hebrew. Hardcode the Accelerators, please.

can you name what character are ok and which are not? And shall KAcceleratorManager 
create a character on it's own or would you prefer it to leave off the asian translations? 
 
Note that you can still put the (&L) in the translation. Those will be prefered by KAM 

It is very easy to distinguish which characters can be used as accelerators. 
Only ASCII characters, or more generally speaking, keys that appears in 
keyboard, can be used as accelerators.

Of course I could put "&L"s in translation , but the strings maybe used in 
elsewhere of the program, how can program do? Translators cannot tell exact 
accelerators which will be used in actual UI just from a msgid "Name:".

Furthermore, think about following:

   msgid "Name:"
   msgstr "XXXX(&N):"

those items will not pass the msgfmt -C check.

KAM is good, only that it should not set accelerators to characters other than 
ASCII letters, for these characters cannot be PRESSed but INPUTed.

For the better support for Japanese, Chinese, Korean, Arabic, and other 
languages that do not use Latin letter as their alphabet, KAM should not be 
used, unless it can deal such languages perfectly.

what I was thinking about: what do you think about a (&$) macro that you add to your 
translations where KAM will replace the &$ with a latin character? &$ is just an example. 
You're right that we should still use the & to mark msgids where an accel will be used 
even if KAM is in use. 

"Name:" will be used elsewhere within the program, maybe tooltips(Example, 
please). If we translate it as "XXXX(&$):", what will be displayed in the 
tooltip? Maybe "XXXX(A):", which was too bad.

I think the only way to solve it is to modifying the KAM itself. It will 
automaticlly insert "(&A)"s to the msgstr if no ASCII characters could be 
found. Furthermore, it would be better that it can recognize : and ... at the 
end of the string. That is:

msgstr      Expected result
XXXX        XXXX(&A)
XXXX:       XXXX(&A):
XXXX...     XXXX(&A)...

Subject: kdelibs/kdecore

CVS commit by tokoe: 

KAccelManager uses now only ASCII characters for accels, so the asian translators can put stuff like

msgid "Foobar"
msgstr "XXXXXXX (A)"

into the po file (with X = non-latin1 character) and KAM will automatically
use 'A' as accel.
CCMAIL:58647-done@bugs.kde.org


  M +1 -1      kaccelmanager.cpp   1.28


--- kdelibs/kdecore/kaccelmanager.cpp  #1.27:1.28
@@ -581,5 +581,5 @@ int KAccelString::maxWeight(int &index, 
 
   for (uint pos=0; pos<m_pureText.length(); ++pos)
-    if (!used.contains(m_pureText[pos].lower()))
+    if (used.find(m_pureText[pos], 0, FALSE) == -1 && m_pureText[pos].latin1() != 0)
       if (m_weight[pos] > max)
       {

No, such an result isn't what I have expected. Following arithmetic might help.

accelerators_pool="a..z"
.....
If '&' was found
then
   use the character after '&' as the accelerate key
   remove the character from accelerators_pool
else if no Latin characters was found
then
   append "(&%c)", where %c is the first avaliable character in accelerators_pool

See comment #5, "Foobar" will be used in elsewhere in the program, "XXXX (A)" is difficult for the user to understand.

but that won't happen for 3.2. At least you don't get wrong accels anymore

OK. Pend it to 3.3 or 4.0. 

Although the original bug is 17 years old, it is still relevant. The bug seems to be at least fixed in the QWidgets based applications, but QML based applications seems to have the bug. Attached here is configuration dialog of Dolphin and update dialog of Discover, using QWidgets and QML respectively. In Dolphin's dialog, only the translated message of "Switch between split views panes with tab key" has its accelerator key assigned, as only that item of the configuration dialog has alphabet. All other texts are using 100% Hangul, so no accelerator keys were added. That actually hurts usability but I think this should be discussed in another bug.

On the other hand, in Discover's update dialog, accelerator keys are allocated to composed Hangul which could not be used as an accelerator key. Only the translated message of "Plasma Addons" has alphabets in this case. All others are using 100% Hangul, but accelerator keys are nevertheless allocated. This is clearly a bug.

Created attachment 126655 [details]
Discover's Korean screenshot, where accelerator keys are misallocated

Created attachment 126656 [details]
Dolphin's Korean screenshot, only one accelerator key is allocated but there is no incorrect accelerator keys.

Given that the kdelibs is discontinued, I am going to report a new bug.