.mofiles; they need to be delivered by the server.
The main solution to these problems is the
gettext interface, plus an array of translation strings.
Those translation strings are taken from applications or Django core, according to what you specify in either the
info_dict or the URL. Paths listed in
LOCALE_PATHS are also included.
Each string in
packages should be in Python dotted-package syntax (the same format as the strings in
INSTALLED_APPS) and should refer to a package that contains a
The precedence of translations is such that the packages appearing later in the
packages argument have higher precedence than the ones appearing at the beginning, this is important in the case of clashing translations for the same literal.
By default, the view uses the
gettext domain. This can be changed by altering the
You can make the view dynamic by putting the packages into the URL pattern:
With this, you specify the packages as a list of package names delimited by ‘+’ signs in the URL. This is especially useful if your pages use code from different apps and this changes often and you don’t want to pull in one big catalog file. As a security measure, these values can only be either
django.conf or any package from the
LOCALE_PATHS setting are also always included. To keep consistency with the translations lookup order algorithm used for Python and templates, the directories listed in
LOCALE_PATHS have the highest precedence with the ones appearing first having higher precedence than the ones appearing later.
To use the catalog, just pull in the dynamically generated script like this:
gettext interface to access it:
and even a string interpolation function:
The interpolation syntax is borrowed from Python, so the
interpolate function supports both positional and named interpolation:
- Positional interpolation:
fmtplaceholders in the same order they appear. For example:
- Named interpolation: This mode is selected by passing the optional boolean named parameter as true.
ngettext to produce proper pluralization).
Note On Performance
.mo files on every request. Since its output is constant – at least for a given version of a site – it’s a good candidate for caching.
Server-side caching will reduce CPU load. It’s easily implemented with the
cache_page() decorator. To trigger cache invalidation when your translations change, provide a version-dependent key prefix, as shown in the example below, or map the view at a version-dependent URL.
Client-side caching will save bandwidth and make your site load faster. If you’re using ETags (
USE_ETAGS = True), you’re already covered. Otherwise, you can apply conditional decorators. In the following example, the cache is invalidated whenever you restart your application server.