GNOME Bugzilla – Bug 659588
Orca presenting partialy untranslated the CONTROL+Plus and the CONTROL+Minus accelerator combinations
Last modified: 2012-05-22 14:24:00 UTC
Created attachment 197059 [details] Debug file with shows perhaps why happening this problem Dear Developers, When a menu item accelerator key containing plus or minus key names, Orca spokening translated form the CONTROL part, but spokening untranslated the minus or plus part. Reproducation steps for non english locales: 1. Open a terminal. 2. Listen for example the view menu menu items. I attached the required debug.out file. Now only this bug producing problems for speech output, but future if for example Orca awailable my other bug attached braille mnemonic presenting related patch, producing problem this bug both speech and braille output presenting with non english locales. I see this problem with orca-xdesktop branch, but absolute sure I think Orca 3.2Pre version producing same test result. Attila
Ok, I wrote wrong information. The accelerator key information is Orca spokening and presenting braille. Attila
Created attachment 197062 [details] [review] A full working patch with resolving this bug both orca master and Orca-xdesktop branches I tested this patch for Orca-xdesktop branch, but absolute sure the patch are compatible with Orca master branch too. If this is possible, please commit this patch. If now already have string freeze, please commit this full good working patch with next Orca developing cicle. Attila
Hey Attila. We're at string freeze, so, yeah, I'll have to wait until we branch 3.2. Although I probably am not going to wait very long to branch. We've got stuff to do. <smiles> In the meantime, looking at your patch, something occurs to me: We didn't provide context for the other strings there. Back when those old strings were added, I'm pretty sure we didn't know anything about providing qualified strings. Anyhoo.... Now I am wondering if it would be worth it to add context/qualifiers for the existing key names? On the one hand it would be more strings (or do they just become "fuzzy"?). On the other hand, in the long run, it ensures string uniqueness for keynames. I honestly do not know what the right thing is to do. I'm asking you as a translator what you and the others who do your job think. When you consider your answer, please also consider users whose localization team doesn't work as hard as you and some of the others do. In other words, will the change I am proposing break things for locales whose translators don't do frequent -- or even regular -- updates? Thanks!
Joanie, I using context style, because for example the Control key is use similar form with src/orca/keynames.py. You are full right, this style generating a fuzzy string. Just a moment, I try looking an another solution with doesn't generate new string, because in translations already have a plus and a minus string, look for example hungarian strings: #. Translators: this is the spoken word for the character '+' (U+002b) #. #: ../src/orca/chnames.py:91 msgid "plus" msgstr "plusz" #. Translators: this is to be sent to a speech synthesis #. engine to prefix a negative number (e.g., "-56" turns #. into "minus 56". We cannot always be sure of the type #. of the number (floating point, integer, mixed with other #. odd characters, etc.), so we need to unfortunately #. build up the utterance in this manner. #. #: ../src/orca/gnomespeechfactory.py:903 msgid "minus" msgstr "mínusz" If my second ydea working, translators doesn't need doing extra work. Attila
Created attachment 197081 [details] [review] Final revision Ok, my ydea is working without translators need doing anything with existing translations,. I simple remove the context markup for two new strings in src/orca/keynames.py file. This method are good for you and possible commit for master and orca-xdesktop branch? Attila
That will work, but we're also under hard code freeze at the moment. Once that is lifted.... Thanks again!
Joanie, many thanks the promise with commit. Your openion what style patch are better when you doing commit after hard code freeze lift of? The second patch doesn't resulting new string, this is the big adwantage this patch, and translators doesn't need doing later extra work after the patch is committed. But I don't no prewious why choosed for example the context style for CTRL, ALT, SHIFT strings related with src/orca/keynames.py file? This strings are need spokening different pronounce for other situations? For example, in hungarian language we always pronounce CTRL with "kontrol" word, pronounce minus with minusz, plus with plusz, etc. Attila
Joanie, possible committing my any attached patch to fix this bug both master and GNOME 3.2 branch, or only this is later possible? If you not would like add new string to translators doesn't need translating this extra informations, the second patch is better, because the 3.2 branch is freezed. If not have other possibility, I full accept if you committing my any fix way patch only with master version. Attila
Joanie, master version possible committing any fix patch this bug related? I think this patches not producing risks the master or GNOME 3.2 branch, but if need, I welcome testing any you choosed patch with my Precise system. If purpose fixing this bug with Orca-xdesktop branch, need choosing I think the second patch with not associated new localizable string the "plus" string. Attila
The reason I have not committed this is because, in general, I think that these sorts of strings should not be in Orca but should instead be handled by the speech provider (either speech-dispatcher or the synthesizers). In other words, these strings (and those already in Orca like them) should be removed IMHO. Before this wasn't doable because we have many different possible speech providers we were supporting (like hardware, gnome-speech, speech-dispatcher). Whether or not this is doable now is something I have yet to investigate.
Now, lot of translatable marked strings are have with src/orca/chnames.py file. This strings prewious added because I think for GNOME Speech possible doing this way this characters and simbols localization. For Speech-dispatcher I think direct way not possible adding this simbols and other strings depending the used language, but this localization way is working and fast, because realtime happening the update if translator coordinators committed the translation update for Orca source code tree. For example with Espeak if a language need adding a simbol or a string part with future possible removing, the sintax is relative hard, and the update only presenting only when next Espeak stable version is publicated. If the target distribution not always following Espeak stable releases, Orca user experiencing partialy untranslated strings the target language with another distribution are translated, because for example the another distribution is containing latest Espeak release. Have a disadvantage if hardcoded speech sinths this strings: If for example a hungarian Orca user changing only the system language, but not changing speech person, he will be hear hungarian pronounce the "plus" keyname. :-):-) An another problem, some textual strings presenting too with braille. For example, the "minus" or "plus" text presenting braille if an accelerator containing this simbol, this strings for example key names with need translating too the target language right output. Attila
Comment on attachment 197081 [details] [review] Final revision I still want this (and related things) moved over to the synthesizer. But what I want even more is to get old bugs with patches off my todo list. ;) This is harmless and I'm making a bunch of string changes anyway, so I've committed this.