Chapter 4. i18n/l10n tools in Debian

4.1. Generic tools: gettext

In order to be able to internationalise the user environment the GNU project developed a set of tools which are known as gettext. These tools make use of the locale definition that is a part of the POSIX.2 standard and is implemented in the GNU libc. These definitions include the basic tasks of representing currency formats, date or numbers. But they also include the definitions of sorting tasks and the classification of codes based on the user's culture (such as the order of the letters in the alphabet). This aspect of a user's environment only needs to be defined once since these definitions, once covered, do not typically vary throughout time (except when fixing bugs or introducing new languages).

The translation of messages according to the user's language in any given interface is, however, a more variable aspect of internationalisation of software. Not only messages that are shown to the user are translated usually, error messages, help of the options that the program use and any other message that a user might see at any point in time is suitable of translation.

The Gettext tool was developed within the GNU project between 1994 and 1995 by a diverse group of programmers. This tool helps the creation of programs that can be distributed with multiple message catalogs in different languages. In localised environments the programs will choose the message catalog most suited to the environment as defined by the user and present messages in a given language.

This tool is almost transparent to the programmer. The programmer just has to mark in a special way messages that need to be translated. It is also transparent to the translator since the precise location of messages in the source code and the relocation of messages. Translators just have to keep the translation of a list of messages current. The gettext tools handle the creation of catalogues and their regeneration when the sources change but, at the same time, preserving translations already done.

This way, the work of translating messages within a program is reduced to the task of doing an initial translation of all the messages and then the maintenance of the small (or big) changes introduced in the code that might have as a consequence the apparition (or change) of messages. The programmer has just to prepare the sources to use gettext through the use of the tools both in the program itself and in the tools that compile and build it (a process known as software internationalisation). Once this is done, the work of both groups can be done independently, which helps development both ways. That is, a translator does not have to depend on the programmer to introduce a new language and a programmer does not have to wait for the translators to do their job in order to publish a new release.

More information is available in the official gettext project pages. If gettext is already installed, online documentation is available that can be read executing info gettext.

Translation of messages using gettext is very simple. A translator just needs to pick up a PO file either partially translated or completely untranslated and fill in the missing "gaps". Having many people with many different capabilities willing to cooperate makes it possible to collaborate without the need of in depth knowledge of the translation mechanism. This is how translation teams born. Several front-end interfaces to gettext are available, such as gtranslator, kbabel, poedit or emacs'po-mode. One of consequences of the availability of the gettext tools is that it is not necessary to have programming knowledge to work on translation. The only requirements for working in translations are the knowledge of the original language, the language it will be translated to and the ability to edit .po files (with multiples tools being available to ease the task as described above).

The GNU project supports different groups of internationalisation. These groups are coordinated by a person in charge of the translation team. There is no requirements, however, to provide constant dedication within a translation group. Translation can be a discrete effort. The existence of these groups, however, guarantees the revision of these discrete efforts from anonymous contributors (many time users). These groups are also in charge of developing glossaries to make translation of programs uniform and to maintain and update translations whenever new programs are published.

This work is coordinated through the Free Translation Project at http://translation.sourceforge.net/. The state of translations can be reviewed through a database of translations and translators at http://translation.sourceforge.net/cgi-bin/registry.cgi?team=index.