GNOME Bugzilla – Bug 169117
Phonetic alphabet strings should be marked with Q_() to help translators
Last modified: 2005-04-25 12:47:25 UTC
Phonetic alphabet is "A for Alpha, B for Bravo, C for Charlie...". The translation tools (translation memory tools) see the strings as "Alpha", "Bravo", ... and it causes confusion. In addition, translators should not translate them unless they use the 24-letter english alphabet. Using the Q() notation, the messages would appear as "Phonetic|Alpha" "Phonetic|Bravo" "Phonetic|Charlie" A. "Alpha" could be alpha as in transparency B. "Delta" from diffing C. "Echo" in sound applications D. "India" from country list (gnome-applets-locations) E. "November", the month ...
Created attachment 38514 [details] [review] Proposed patch
Christian, what is your opinion about the patch above?
This would break string freeze (since the added context would alter the strings), so this change should probably only be applied to HEAD after gnopernicus has branched for gnome-2-10. Second, it would probably help the situation much if there was translator comments as well, explaining for translators how these messages are used and how they should be translated. For more information about translator comments, please see http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#use-comments. Third, regarding the patch 38514 and this specific change: - /*To translators: X = X Window System server */ - port_text = _("X display's _terminal number:"); + port_text = _("X Window server|X display's _terminal number:"); Context should only be added where there is a danger for a specific string to be used in multiple meanings. In such cases, the context is there to differentiate between the meanings. Since context adds overhead, it should not be used unless necessary, and specifically, it should *not* be used as a general replacement for translator comments. Regarding the change mentioned above, it seems very unlikely that the specific string "X display's _terminal number:" would appear in multiple situations with different meanings. Can you think of any such situation? If not, it should not have context added, so the above change seems pointless.
Created attachment 38687 [details] [review] proposed patch Thank you for your suggestions.
Comment on attachment 38687 [details] [review] proposed patch commit after we've branched - unless we come up with a better way of implementing the 'military mode' spelling in the first place/
Note that there's a fundamental problem here, in that we're only able to spell things that correspond to the 'a-z' latin alphabet. What we'd really like to do is be able to spell any UTF-8 string, and the existing implementation doesn't allow that. So for instance, there's no way to spell even a Latin-character set word containing an accented character, using the current implementation.
Patch committed to CVS head.