The standard translation method involves using the django.utils.translation.gettext() function. The gettext() function accepts a Python string as its only argument. The string that is specified in the gettext() function is added to the message file.

For example, the following code enables a direct string and a string variable for translation:

from django.utils.translation import gettext
def myView(request):
    rawText = 'Welcome to iFriends'
    transText = gettext(rawText)
    loginText = gettext('Please Login')
    . . .

from django.utils.translation import gettext as _
. . .
    transText = _('Please Login')

You should be mindful when adding variable placeholders to localized strings that you may need to use named-string syntax. That way, when the strings are translated, the variable placeholder can move position in the translation as necessary. For example, the string Tim is my name. would be translated to Ich heisse Tim. The following code shows an example of using a named variable placeholder:

text = gettext('%(name)s is my name.') % {'name': name}

The lazy translation method involves using the django.utils.translation.gettext_lazy() function. The gettext_lazy() function accepts a Python string as its only argument. The gettext_lazy() function stores a lazy reference to the string and translates the string only if it is used in a string context.

For example, the following model definition uses the gettext_lazy() function:

from django.utils.translation import gettext_lazy as _
class Contact(models.Model):
    name = models.CharField(_('Name'), max_length=80)
    location = models.CharField(_('Location', help_text=_('Your city.'))

from django.utils.translation import gettext_lazy as _
. . .
    title = models.CharField(_('Title'), help_text=_('Enter a Title Here.'))

Django provides the django.utils.translation.gettext_no-op() function to identify strings as translation strings. However, they are not actually translated yet. They are translated later as a variable at the last possible point before they are rendered to the user.

You can use no-op strings for things such as constant strings, or strings stored in the database. Django will not translate a no-op strings until the last possible moment.

The simplest way to localize a string in a template is to use the trans template tag. The trans template tag works the same way that the gettext() function does; it accepts a string and identifies that string as localized. The following is an example of using the trans template tag:

{% trans "Web Search Results" %}

{% trans "title" noop %}

The trans tag accepts only constant strings; it cannot accept variables. To localize string variables, you need to use the blocktrans tag. It identifies a block of text, including variables, as localized. The following example shows how to use the blocktrans tag:

{% blocktrans %}Title: {{ title }} {% endblocktrans %}

If you need to use some kind of template expression on a variable, such as a template filter, you need to bind the expression to a local variable to be used in the block. For example:

{% blocktrans with title|CAPFIRST as ctitle %}
    Title: {{ ctitle }}
{% endblocktrans %}

The i18n template file also provides translation hooks within any template that accepts constant strings. To use those template hooks, use the _() syntax, as shown in the following example:

{% CustomTag _("Translation String") %}

When you use these translation hooks, the tag sees the translated string and is unaware of the translation.

RequestContext has access to the following translation-specific variables that you can use when designing your templates:

For example, the following template code uses the LANGUAGE_CODE variable to display English-only code if the user’s language is English:

{% ifequal LANGUAGE_CODE 'en' %}
    English Elements
    . . .
{% endifequal %}

If you are not using the RequestContext extension in the view, you can also assign the translation-specific variables using the following template tag code:

{% get_available_languages as LANGUAGES %}
{% get_current_language as LANGUAGE_CODE %}
{% get_current_language_bidi as LANGUAGE_BIDI %}

{% load i18n %}
. . .
<td bgcolor="white"><font size="3">
    {% if user.is_authenticated %}
        {% trans "Welcome" %} {{ user.username }}.
    {% else %}
        <a href="/Login">Login</a>
    {% endif %}
</font></td>
. . .

The first step in creating language files is to build the message files. A message file is a text file that contains entries that include a message ID and translation string for that particular language. Each language has one message file.

Django provides the django/bin/make-messages.py utility to create and update message files. You can also build the message file for a specific language using the -l language-code parameter. The following example shows how to build the German message file:

message-make.py -l de

You need to run the message-make.py utility for each language you want to add to your project. However, after you have added the language files, you can use the -a parameter to update all the existing message files:

message-make.py -a

Message files can be built at three different levels—the Django installation, the project, and the application.

Django already comes with its own message files built and compiled. You would need to build the message file at the Django installation level only if you modified a string in the Django code or if you wanted to add a language that Django currently doesn’t support. To build the message files for the Django installation, run the make-messages.py utility at the root of the Django installation. The messages are stored in the following file in the Django installation path:

django/confg/locale/language-code/LC_MESSAGES/django.po

Typically you will want to build message files for just your project. To do so, create a locale directory in the root of your project in which to store the message files. The message-make.py utility stores the message files in the following location in the project directory. However, it does not create the locale directory if it doesn’t exist:

locale/language-code/LC_MESSAGES/django.po

The message-make.py utility then searches through the .py and .html files in your project and builds the message files.

You can also build message files for only one application by creating a locale directory in the application directory and then running the messages-make.py application from the application directory.

The django.po files store localized messages using the following entries for each string:

Initially the translated strings are blank. You need to add translated strings to each message file you create. To do so, open the django.po file in an editor, and add the strings.

After your have added the translated strings to the message files, you need to compile the message files into a binary file that can be consumed by gettext. Django provides the django/bin/compile-messages.py utility to compile the message files. The compile-messages.py file parses the django.po files and creates django.mo language files.

The compile-messages.py file must be run from the same location that the make-messages.py utility was run. After you have compiled the message file, you are ready to implement languages in your project.