| An Internationalized Software Project With Auto Tools |
| Prev |
gettext Overview |
Next |
gettext Overview
gettext is a library, which allows to write multi-lingual software. The main idea is to mark strings in the source code for
translation. A special tool extracts all these strings and merges them into so called .po files. For each language
the project should be translated into, one .po file exists. These .po files are then translated by a translator. Technically
the translations are placed below to the original strings in the .po file. During the compilation of the .po files, they are converted
into binary .gmo files. These are installed with the project (and for some reason renamed during the installion into *.mo).
On runtime the libtool libraries seek the corresponding .mo file. If it does not exist, the english strings are used. If it
exists, each string is looked up in the .mo file and replaced by its translation. As the result, the program now displays
strings in a different language.
The workflow in more detail is the following:
- The software is written in english. Other "start languages" are possible as well, but they have to use ascii characters only.
- Translatable strings are marked in the source code by a special (user defined) function.
- A special tool (xgettext) extracts all translatable strings and collects them in one file (testproj.pot).
- If a new language (translation target) is added, this file is copied to LANG.po, where LANG denotes the language. The msginit tool might help here.
- The LANG.po files are translated by a human translator. Various tools (like KBabel) exist, which might help here. The target language
might use any character set, although unicode is recommended (as long as the rest of the program can work with unicode).
Translated strings are added into the LANG.po file below the english original.
- Whenever the source code has changed, xgettext should recreate the testproj.pot file. This must be merged with the LANG.po's with
the tool msgmerge. The merged LANG.po's have to be checked by the translator to bring it up to date.
- With the software, the LANG.po's have to be compiled into LANG.gmo's by msgfmt, which are just binary equivalents.
- During the installation, these LANG.gmo files are copied into /usr/local/share/locale/LANG/LC_MESSAGES/testproj.mo, where LANG is the language code.
The actual installation directory may vary.
- On run time, the gettext library tries to find the correct .mo file, e.g. by environment variable settings. Each string to be displayed
is passed through a function (see first point), which now looks for the translation. If no translation exists (no .mo file or string not translated), the english
string is taken.
This is an important part of the internationalization, but just a part. It is also important, that the program supports the character
sets, required for all target languages. Character set struggle can be avoided by makling the application unicode aware. Furthermore it should be localized, i.e. displaying dates, numbers etc. in the local way. Locale handling is part of the standard c
library.
So gettext is mainly a toolkit, a library and a workflow. But gettext integration into the gnu auto tools might simplify the
.po, .pot, .gmo and .mo file handling. Unfortunately it requires several steps, which are described in the next chapter.
| Prev |
Home |
Next |
| Adding libtool Support |
|
Adding gettext support |