There are a few common mistakes that you would discover eventually yourself. But this section might help you to avoid them.
Sometimes two English strings are identical but have different meanings in different contexts, so they would probably not be identical when translated. Since the English strings are used as look-up keys, this causes problems.
In these cases, you should add extra characters to the strings. For instance,
use "jumps[noun]"
and "jumps[verb]"
instead of just "jumps"
and strip them again outside the
gettext
call. If you add extra characters you should also
add a comment for the translators before the gettext
call.
Such comments will be shown in the .po
files. For
instance:
// note to translators: don't translate the "[noun]" part - it is
// just here to distinguish the string from another "jumps" string
text = strip(gettext("jumps[noun]"), "[noun]");
If you use Glib's support macros, it's easier. Use
C_()
instead of _()
. For instance:
GLib::ustring text(C_("noun", "jumps"));
C programmers use sprintf()
to compose and concatenate
strings. C++ favors streams, but unfortunately, this approach makes
translation difficult, because each fragment of text is translated separately,
without allowing the translators to rearrange them according to the grammar of
the language.
For instance, this code would be problematic:
std::cout << _("Current amount: ") << amount
<< _(" Future: ") << future << std::endl;
label.set_text(_("Really delete ") + filename + _(" now?"));
So you should either avoid this situation or use
Glib::ustring::compose()
which supports syntax such as:
std::cout << Glib::ustring::compose(
_("Current amount: %1 Future: %2"), amount, future) << std::endl;
label.set_text(Glib::ustring::compose(_("Really delete %1 now?"), filename));
You never know how much space a string will take on screen when translated. It might very possibly be twice the size of the original English string. Luckily, most gtkmm widgets will expand at runtime to the required size.
You should avoid cryptic abbreviations, slang, or jargon. They are usually difficult to translate, and are often difficult for even native speakers to understand. For instance, prefer "application" to "app"
Currently, gettext does not support non-ASCII characters (i.e. any characters with a code above 127) in source code. For instance, you cannot use the copyright sign (©).
To work around this, you could write a comment in the
source code just before the string, telling the translators to
use the special character if it is available in their languages. For English, you could then make an American English
en_US.po
translation which used that special character.