The goal of internationalization and localization is to allow a single Web application to offer its content in languages and formats tailored to the audience.
Essentially, Django does two things:
It allows developers and template authors to specify which parts of their apps should be translated or formatted for local languages and cultures.
It uses these hooks to localize Web apps for particular users according to their preferences.
Obviously, translation depends on the target language, and formatting usually
depends on the target country. This information is provided by browsers in
Accept-Language header. However, the time zone isn’t readily available.
The words “internationalization” and “localization” often cause confusion; here’s a simplified definition:
Preparing the software for localization. Usually done by developers.
Writing the translations and local formats. Usually done by translators.
Translation and formatting are controlled by
USE_L10N settings respectively. However, both features involve
internationalization and localization. The names of the settings are an
unfortunate result of Django’s history.
Here are some other terms that will help us to handle a common language:
A locale name, either a language specification of the form
ll or a
combined language and country specification of the form
pt_BR. The language part is
always in lowercase and the country part in upper case. The separator is
Represents the name of a language. Browsers send the names of the
languages they accept in the
Accept-Language HTTP header using this
pt-br. Language codes
are generally represented in lowercase, but the HTTP
header is case-insensitive. The separator is a dash.
A message file is a plain-text file, representing a single language,
that contains all available translation strings and how they should be represented in the given
language. Message files have a
.po file extension.
A literal that can be translated.
A format file is a Python module that defines the data formats for a given locale.