Navigation

The gettext module provides internationalization (I18N) and localization
(L10N) services for your Python modules and applications. It supports both the
GNU gettext message catalog API and a higher level, class-based API that may
be more appropriate for Python files. The interface described below allows you
to write your module and application messages in one natural language, and
provide a catalog of translated messages for running under different natural
languages.

Some hints on localizing your Python modules and applications are also given.

The gettext module defines the following API, which is very similar to
the GNU gettext API. If you use this API you will affect the
translation of your entire application globally. Often this is what you want if
your application is monolingual, with the choice of language dependent on the
locale of your user. If you are localizing a Python module, or if your
application needs to switch languages on the fly, you probably want to use the
class-based API instead.

Bind the domain to the locale directory localedir. More concretely,
gettext will look for binary .mo files for the given domain using
the path (on Unix): localedir/language/LC_MESSAGES/domain.mo, where
languages is searched for in the environment variables LANGUAGE,
LC_ALL, LC_MESSAGES, and LANG respectively.

If localedir is omitted or None, then the current binding for domain is
returned. [1]

Like gettext(), but consider plural forms. If a translation is found,
apply the plural formula to n, and return the resulting message (some
languages have more than two plural forms). If no translation is found, return
singular if n is 1; return plural otherwise.

The Plural formula is taken from the catalog header. It is a C or Python
expression that has a free variable n; the expression evaluates to the index
of the plural in the catalog. See
the GNU gettext documentation
for the precise syntax to be used in .po files and the
formulas for a variety of languages.

The class-based API of the gettext module gives you more flexibility and
greater convenience than the GNU gettext API. It is the recommended
way of localizing your Python applications and modules. gettext defines
a “translations” class which implements the parsing of GNU .mo format
files, and has methods for returning strings. Instances of this “translations”
class can also install themselves in the built-in namespace as the function
_().

This function implements the standard .mo file search algorithm. It
takes a domain, identical to what textdomain() takes. Optional
localedir is as in bindtextdomain() Optional languages is a list of
strings, where each string is a language code.

If localedir is not given, then the default system locale directory is used.
[2] If languages is not given, then the following environment variables are
searched: LANGUAGE, LC_ALL, LC_MESSAGES, and
LANG. The first one returning a non-empty value is used for the
languages variable. The environment variables should contain a colon separated
list of languages, which will be split on the colon to produce the expected list
of language code strings.

find() then expands and normalizes the languages, and then iterates
through them, searching for an existing file built of these components:

localedir/language/LC_MESSAGES/domain.mo

The first such file name that exists is returned by find(). If no such
file is found, then None is returned. If all is given, it returns a list
of all file names, in the order in which they appear in the languages list or
the environment variables.

Return a Translations instance based on the domain, localedir,
and languages, which are first passed to find() to get a list of the
associated .mo file paths. Instances with identical .mo file
names are cached. The actual class instantiated is either class_ if
provided, otherwise GNUTranslations. The class’s constructor must
take a single file object argument. If provided, codeset will change
the charset used to encode translated strings in the lgettext() and
lngettext() methods.

If multiple files are found, later files are used as fallbacks for earlier ones.
To allow setting the fallback, copy.copy() is used to clone each
translation object from the cache; the actual instance data is still shared with
the cache.

If no .mo file is found, this function raises OSError if
fallback is false (which is the default), and returns a
NullTranslations instance if fallback is true.

Translation classes are what actually implement the translation of original
source file message strings to translated message strings. The base class used
by all translation classes is NullTranslations; this provides the basic
interface you can use to write your own specialized translation classes. Here
are the methods of NullTranslations:

Takes an optional file objectfp, which is ignored by the base class.
Initializes “protected” instance variables _info and _charset which are set
by derived classes, as well as _fallback, which is set through
add_fallback(). It then calls self._parse(fp) if fp is not
None.

No-op’d in the base class, this method takes file object fp, and reads
the data from the file, initializing its message catalog. If you have an
unsupported message catalog file format, you should override this method
to parse your format.

This method installs self.gettext() into the built-in namespace,
binding it to _.

If the names parameter is given, it must be a sequence containing the
names of functions you want to install in the builtins namespace in
addition to _(). Supported names are 'gettext' (bound to
self.gettext()), 'ngettext' (bound to self.ngettext()),
'lgettext' and 'lngettext'.

Note that this is only one way, albeit the most convenient way, to make
the _() function available to your application. Because it affects
the entire application globally, and specifically the built-in namespace,
localized modules should never install _(). Instead, they should use
this code to make _() available to their module:

importgettextt=gettext.translation('mymodule',...)_=t.gettext

This puts _() only in the module’s global namespace and so only
affects calls within this module.

GNUTranslations parses optional meta-data out of the translation
catalog. It is convention with GNU gettext to include meta-data as
the translation for the empty string. This meta-data is in RFC 822-style
key:value pairs, and should contain the Project-Id-Version key. If the
key Content-Type is found, then the charset property is used to
initialize the “protected” _charset instance variable, defaulting to
None if not found. If the charset encoding is specified, then all message
ids and message strings read from the catalog are converted to Unicode using
this encoding, else ASCII encoding is assumed.

Since message ids are read as Unicode strings too, all *gettext() methods
will assume message ids as Unicode strings, not byte strings.

The entire set of key/value pairs are placed into a dictionary and set as the
“protected” _info instance variable.

If the .mo file’s magic number is invalid, the major version number is
unexpected, or if other problems occur while reading the file, instantiating a
GNUTranslations class can raise OSError.

The following methods are overridden from the base class implementation:

Look up the message id in the catalog and return the corresponding message
string, as a Unicode string. If there is no entry in the catalog for the
message id, and a fallback has been set, the look up is forwarded to the
fallback’s gettext() method. Otherwise, the message id is returned.

Equivalent to gettext(), but the translation is returned as a
bytestring encoded in the selected output charset, or in the preferred system
encoding if no encoding was explicitly set with set_output_charset().

Do a plural-forms lookup of a message id. singular is used as the message id
for purposes of lookup in the catalog, while n is used to determine which
plural form to use. The returned message string is a Unicode string.

If the message id is not found in the catalog, and a fallback is specified, the
request is forwarded to the fallback’s ngettext() method. Otherwise, when
n is 1 singular is returned, and plural is returned in all other cases.

Here is an example:

n=len(os.listdir('.'))cat=GNUTranslations(somefile)message=cat.ngettext('There is %(num)d file in this directory','There are %(num)d files in this directory',n)%{'num':n}

Equivalent to gettext(), but the translation is returned as a
bytestring encoded in the selected output charset, or in the preferred system
encoding if no encoding was explicitly set with set_output_charset().

Internationalization (I18N) refers to the operation by which a program is made
aware of multiple languages. Localization (L10N) refers to the adaptation of
your program, once internationalized, to the local language and cultural habits.
In order to provide multilingual messages for your Python programs, you need to
take the following steps:

prepare your program or module by specially marking translatable strings

run a suite of tools over your marked files to generate raw messages catalogs

create language specific translations of the message catalogs

use the gettext module so that message strings are properly translated

In order to prepare your code for I18N, you need to look at all the strings in
your files. Any string that needs to be translated should be marked by wrapping
it in _('...') — that is, a call to the function _(). For example:

In this example, the string 'writingalogmessage' is marked as a candidate
for translation, while the strings 'mylog.txt' and 'w' are not.

There are a few tools to extract the strings meant for translation.
The original GNU gettext only supported C or C++ source
code but its extended version xgettext scans code written
in a number of languages, including Python, to find strings marked as
translatable. Babel is a Python
internationalization library that includes a pybabel script to
extract and compile message catalogs. François Pinard’s program
called xpot does a similar job and is available as part of
his po-utils package.

(Python also includes pure-Python versions of these programs, called
pygettext.py and msgfmt.py; some Python distributions
will install them for you. pygettext.py is similar to
xgettext, but only understands Python source code and
cannot handle other programming languages such as C or C++.
pygettext.py supports a command-line interface similar to
xgettext; for details on its use, run pygettext.py--help. msgfmt.py is binary compatible with GNU
msgfmt. With these two programs, you may not need the GNU
gettext package to internationalize your Python
applications.)

xgettext, pygettext, and similar tools generate
.po files that are message catalogs. They are structured
human-readable files that contain every marked string in the source
code, along with a placeholder for the translated versions of these
strings.

Copies of these .po files are then handed over to the
individual human translators who write translations for every
supported natural language. They send back the completed
language-specific versions as a <language-name>.po file that’s
compiled into a machine-readable .mo binary catalog file using
the msgfmt program. The .mo files are used by the
gettext module for the actual translation processing at
run-time.

How you use the gettext module in your code depends on whether you are
internationalizing a single module or your entire application. The next two
sections will discuss each case.

If you are localizing your module, you must take care not to make global
changes, e.g. to the built-in namespace. You should not use the GNU gettext
API but instead the class-based API.

Let’s say your module is called “spam” and the module’s various natural language
translation .mo files reside in /usr/share/locale in GNU
gettext format. Here’s what you would put at the top of your
module:

If you are localizing your application, you can install the _() function
globally into the built-in namespace, usually in the main driver file of your
application. This will let all your application-specific files just use
_('...') without having to explicitly install it in each file.

In the simple case then, you need only add the following bit of code to the main
driver file of your application:

importgettextgettext.install('myapplication')

If you need to set the locale directory, you can pass it into the
install() function:

This works because the dummy definition of _() simply returns the string
unchanged. And this dummy definition will temporarily override any definition
of _() in the built-in namespace (until the del command). Take
care, though if you have a previous definition of _() in the local
namespace.

Note that the second use of _() will not identify “a” as being
translatable to the gettext program, because the parameter
is not a string literal.

In this case, you are marking translatable strings with the function
N_(), which won’t conflict with any definition of _().
However, you will need to teach your message extraction program to
look for translatable strings marked with N_(). xgettext,
pygettext, pybabelextract, and xpot all
support this through the use of the -k command-line switch.
The choice of N_() here is totally arbitrary; it could have just
as easily been MarkThisStringForTranslation().

The default locale directory is system dependent; for example, on RedHat Linux
it is /usr/share/locale, but on Solaris it is /usr/lib/locale.
The gettext module does not try to support these system dependent
defaults; instead its default is sys.prefix/share/locale. For this
reason, it is always best to call bindtextdomain() with an explicit
absolute path at the start of your application.