GNU gettext package

This chapter is full of references to GNU gettext package. GNU gettext is a “must have” for nearly all steps of internationalizing any program, and it’s manual is definetely a recommended reading for people involved in I18N.

There are GNU gettext ports to all major OS platforms. Windows binaries are available from GNU mirror sites.

Roundup does not use GNU gettext at runtime, but it’s tools are used for extracting translatable messages, compiling message catalogs and, optionally, for translating messages.

Note that gettext package in some OS distributions means just runtime tools and libraries. In such cases gettext development tools are usually distributed in separate package named gettext-devel.

Marking Strings for Translation

Strings that need translation must be marked in the source code. Following subsections explain how this is done in different cases.

If translatable string is used as a format string, it is recommended to always use named format specifiers:

_('Index of %(classname)s') % locals()

This helps translators to better understand the context of the message and, with Python formatting, remove format specifier altogether (which is sometimes useful, especially in singular cases of Plural Forms).

When there is more than one format specifier in the translatable format string, named format specifiers must be used almost always, because translation may require different order of items.

It is better to not mark for translation strings that are not locale-dependent, as this makes it more difficult to keep track of translation completeness. For example, string </ol></body></html> (in index() method of the request handler in roundup_server script) has no human readable parts at all, and needs no translations. Such strings are left untranslated in PO files, and are reported as such by PO status checkers (e.g. msgfmt --statistics).

from i18n import _, ngettext

print _("This message is translated")

print ngettext("Nuked %i file", "Nuked %i files", number_of_files_nuked)

for meal in ("spam", "egg", "beacon"):
    print _(meal)

strings_to_translate = (
    ''"This string will be translated",
    ""'me too',
    ''r"\raw string",
    ''"""
    multiline string"""
)

Extracting Translatable Messages

The most common tool for message extraction is xgettext utility from GNU gettext package. Unfortunately, this utility has no means of Deferred Translations in Python sources. There is xpot tool from Francois Pinard free PO utilities that allows to mark strings for deferred translations, but it does not handle plural forms.

Roundup overcomes these limitations by using both of these utilities. This means that you need both GNU gettext tools and PO utilities to build the Message Template File yourself.

Latest Message Template File is kept in the source code repository and distributed with Roundup Source. If you wish to rebuild the template yourself, make sure that you have both xpot and xgettext installed and just run gmake (or make, if you are on a GNU system like linux or cygwin) in the locale directory.

For on-site i18n, Roundup provides command-line utility:

roundup-gettext <tracker_home>

extracting translatable messages from tracker’s html templates. This utility creates message template file messages.pot in locale subdirectory of the tracker home directory. Translated messages may be put in locale.po files (where locale is selected locale name) in the same directory, e.g.: locale/ru.po. These message catalogs are searched prior to system-wide translations kept in the share directory.

Translating Messages

Gettext Message File (PO file) is a plain text file, that can be created by simple copying roundup.pot to new .po file, like this:

$ cp roundup.pot ru.po

The name of PO file is target locale name, usually just 2-letter language code (ru for Russian in the above example). Alternatively, PO file may be initialized by msginit utility from GNU gettext tools:

$ msginit -i roundup.pot

msginit will check your current locale, and initialize the header entry, setting language name, rules for plural forms and, if available, translator’s name and email address. The name for PO file is also chosen based on current locale.

Next, you will need to edit this file, filling all msgstr lines with translations of the above msgid entries. PO file is a plain text file that can be edited with any text editor. However, there are several tools that may help you with this process:

• poEdit by Vaclav Slavik. Very nice cross-platform GUI editor.

• KBabel. Being part of KDE, it works in X windows only.

  At the first glance looks pretty hairy, with all bells and whistles. Haven’t had much experience with it, though.

• po-mode for emacs. One of GNU gettext tools. Very handy, definitely recommended if you are comfortable with emacs. Cannot handle plural forms per se, but allows to edit them in simple text mode.

• po filetype plugin for vim. Does not do as much as po-mode, but helps in finding untranslated and fuzzy strings, and checking code references. Please contact alexander smishlajev if you prefer this, as i have patched this plugin a bit. I have also informed the original plugin author about these changes, but got no reply so far.

Compiling Message Catalogs

Message catalogs (PO files) must be compiled into binary form (MO files) before they can be used in the application. This compilation is handled by msgfmt utility from GNU gettext tools. GNUmakefile in the locale directory automatically compiles all existing message catalogs after updating them from Roundup source files. If you wish to rebuild an individual MO file without making everything else, you may, for example:

$ msgfmt --statistics -o ru.mo ru.po

This way, message translators can check their PO files without extracting strings from source. (Note: String extraction requires additional utility that is not part of GNU gettext. See Extracting Translatable Messages.)

At run time, Roundup automatically compiles message catalogs whenever PO file is changed.