Table of Contents
gtkmm applications can easily support multiple languages, including non-ASCII languages such as Chinese and right-to-left languages such as Arabic. An appropriately-written gtkmm application will use the appropriate language at runtime based on the user's environment.
You might not anticipate the need to support additional languages, but you can never rule it out. And it's easier to develop the application properly in the first place rather than retrofitting later.
The process of writing source code that allows for translation is called internationalization, often abbreviated to i18n. The translation process provides translated text for other languages, based on that source code.
String literals should be typed in the source code in english as normal, but they should be surrounded by a call to the gettext() function. These strings will be extracted for translation and the translations may be used at runtime instead of the original english strings.
The GNU gettext package allows you to mark strings in source code, extract those strings for translation, and use the translated strings in your application.
Call gettext() with the string literals that should be translated. For example:
window.set_title(gettext("My application")); label.set_text(gettext("This is some text"));
Using gettext() throughout your source code can make it harder to read, so many projects, such as GNOME define the shorter _() macro that does the same thing. For instance,
window.set_title(_("My application")); label.set_text(_("This is some text"));
Question is, how do the marked strings end up translated? It is actually a bit complicated, but once it is set up, the programmer part of it is completely transparent.
A script from the gettext package extract the strings and put them in a mypackage.pot file. The translators of your application first use this as a base for their translations. These are kept in languagename.po files. Later the mypackage.pot is used updating the languagename.po files with other tools from gettext package.
At install time, the .po files are converted to a binary format (with the extension .mo) and put in a system-wide directory for locale files.
So what happens when your program is run is that the gettext library checks the system-wide directory to see if there is a .mo file for the locale environment that the user is running the program in (you can set the locale with e.g. "export LANG=mylanguage" in Bash). Later, when the program reaches a gettext call, the string is searched for. If it is found, it is used as a key to retrieve the translated string. If it is not found, the original string is simply returned.
Thus the handling of translations is almost completely transparent. Of course, the fact that the string itself is used as the key means that it is impossible to return different translations for two strings with the same contents. Once in a while this causes problems with words that happen to be similar in English, but are different in most other languages, e.g. nouns and verbs. More about that in the section called “Pitfalls”.
Of course, the whole .po system requires some help from the build system. However, this is simply a matter of copying and customizing one of the "Hello, World!" examples from the GNOME CVS. This can also help you make translated versions of auxiliary files, e.g. .desktop files. Note that this requires the so-called intltools which are distributed together with GNOME.