Django language selection workflow

The first step in the process to support multiple languages and countries in a Django project, is to understand how a Django application determines whether to present itself in English, Spanish, German or some other language variation.

The entry point: LANGUAGE_CODE value

Let's start with a Django project with the settings.py values described in listing 13-1 -- which are the default and should be there if you didn't tweak settings.py. Next, ensure you have the Django admin set up and change the LANGUAGE_CODE value in settings.py to one of the following: fr (for French), de (for German) or es (for Spanish).

Next, go to the Django admin main page -- by default at http://localhost:8000/admin/ -- and what do you see ? The login page which previously showed the field "Username" – with the LANGUAGE_CODE set to en-us – will now show either "Nom d'utilisateur", "Benutzername" or "Nombre de usuario", depending on the LANGUAGE_CODE value you configured.

With the LANGUAGE_CODE variable set to a different value, Django uses the locale corresponding to this new LANGUAGE_CODE value, which in turns makes the Django admin use the locale message bundles for the given language. For example, with LANGUAGE_CODE='fr', Django sets it locale to fr, which in turn loads the French localized message files (a.k.a. locale message bundles) included in the Django distribution (e.g. django/contrib/auth/locale/fr/LC_MESSAGES/django.po). Future sections describe how to use and create your own locale message bundles.

The good news is you just localized the Django admin -- as well as a series of other internal Django internal messages -- to use another language by simply modifying the LANGUAGE_CODE values. The bad news is you've now forced all users accessing the Django admin into what's probably not their native language.

A better approach is to let users have a say into which language pipeline they want and leave the LANGUAGE_CODE to your primary audience's language, whatever that may be.