This document is missing a discussion about the KDE-specific handling of plural, which differs from the standard Gettext way of handling plurals. For information on the latter you still have to refer to the respective threads in the translators mailing list, mainly plural handling and plural handling again.
We already mentioned that the characters "#" and "~" have special meaning. A few other things to watch out for are the following:
The "&" character in one of the examples above is used to mark an "accelerator key", ie a letter which in combination with Alt (on PC keyboards) will execute the command; i.e. Alt + S for "Show &Status Bar". You have to make sure that the same letter is not marked twice within one menu. See Compilation, Context and Accelerator Checks.
Some PO files contain so-called "context information" to let translators know whether, for instance, "home" means the user directory, a key on the keyboard or the beginning of a line. Such context information always begins with the letter combination "_:". The important thing is: These strings must not show up in the translations. In other words: Do not translate or copy this stuff into the "msgstr" part of the PO file. If you do, your whole file will not work anymore.
The same as above applies to "_n:", which denotes strings handling plural cases. You do not need to translate "_n:".
For the correct handling see the following example:
#: kdeui/kstdaction.cpp:669 msgid "" "_: beginning (of line)\n" "&Home" msgstr "&Dateianfang" #: src/kernel/qaccel.cpp:562 msgid "" "_: QAccel\n" "Home" msgstr "Pos1"
Special characters such as quotes must be "escaped" (i.e. preceded with a backslash), if you want to use them as part of the text (see example below).
Unescaped quotes will be interpreted by the programs which read the file as the end of the "msgstr". The test routine msgfmt --statistics --check-header, described below, would terminate at this point with an error. The syntax highlighting and the check routines in KBabel will help you with the handling of these special characters.
#: cardmaps.cpp:105 #, c-format msgid "kpat: PANIC, cannot load card pixmap \"%1\"\n" msgstr "KPat: schwerer Fehler, kann Kartenbild \"%1\" nicht laden\n"
One problem which languages with longer than average words (German, for example, is notorious here) sometimes encounter is dialog boxes which are too small, cutting off or cramming together translated text. This is one of the things that can only be determined for sure by checking the translations in the compiled program. The obvious, but always temporary, solution is to "keep it short." You would basically do this if there were no more time to pursue the proper solution, namely contacting the author of the program so that he/she can adjust the geometry of the offending boxes. In any case, an email describing the problem should be sent to the author or even better create a new bug report in KDE Bugs.
Sometimes English text appears in the program interface even though the PO file has been completely translated, and the text in question cannot even be found there.
One way this can happen is when the text comes from "somewhere else" (often from kdelibs which can be found throughout the KDE interface, sometimes from separate modules of the same program that have extra POs). Another possibility is that this particular text has not been made "i18n conform" by the author.
Any strings which should be seen by the user are supposed to be passed to the C++ function QString i18n(const char *text)
. This ensures that the properly localized version of a string is shown (assuming there is a translation). Thus, it is only possible to translate texts which have been prepared in this manner. In cases where the untranslated text cannot be found in the PO file the author may have forgotten to do this. If you want to know for sure, you need to look in the source to the program; for example, you can find out the filename and line number by using grep -n "text in question" *.cpp in the source code folder.
Anyway, if you discover such a case, please file a bug at bugs.kde.org or write the author of the program. Do not just leave the problem unmentioned.