← Back to branch summary

~ubuntu-branches/ubuntu/quantal/python-django/quantal-security

« back to all changes in this revision

Viewing changes to docs/topics/i18n/deployment.txt

  • Committer: Bazaar Package Importer
  • Author(s): Chris Lamb
  • Date: 2010-05-21 07:52:55 UTC
  • mfrom: (1.3.6 upstream)
  • mto: This revision was merged to the branch mainline in revision 28.
  • Revision ID: james.westby@ubuntu.com-20100521075255-ii78v1dyfmyu3uzx
Tags: upstream-1.2
Import upstream version 1.2

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/topics/i18n/deployment.txt
 
1
.. _topics-i18n-deployment:
 
2
 
 
3
==========================
 
4
Deployment of translations
 
5
==========================
 
6
 
 
7
If you don't need internationalization
 
8
======================================
 
9
 
 
10
Django's internationalization hooks are on by default, and that means there's a
 
11
bit of i18n-related overhead in certain places of the framework. If you don't
 
12
use internationalization, you should take the two seconds to set
 
13
:setting:`USE_I18N = False <USE_I18N>` in your settings file. If
 
14
:setting:`USE_I18N` is set to ``False``, then Django will make some
 
15
optimizations so as not to load the internationalization machinery.
 
16
 
 
17
You'll probably also want to remove ``'django.core.context_processors.i18n'``
 
18
from your ``TEMPLATE_CONTEXT_PROCESSORS`` setting.
 
19
 
 
20
.. note::
 
21
 
 
22
    There is also an independent but related :setting:`USE_L10N` setting that
 
23
    controls if Django should implement format localization.
 
24
 
 
25
    If :setting:`USE_L10N` is set to ``True``, Django will handle numbers times,
 
26
    and dates in the format of the current locale. That includes representation
 
27
    of these field types on templates and allowed input formats for dates,
 
28
    times on model forms.
 
29
 
 
30
    See :ref:`format-localization` for more details.
 
31
 
 
32
If you do need internationalization
 
33
===================================
 
34
 
 
35
.. _how-django-discovers-language-preference:
 
36
 
 
37
How Django discovers language preference
 
38
----------------------------------------
 
39
 
 
40
Once you've prepared your translations -- or, if you just want to use the
 
41
translations that come with Django -- you'll just need to activate translation
 
42
for your app.
 
43
 
 
44
Behind the scenes, Django has a very flexible model of deciding which language
 
45
should be used -- installation-wide, for a particular user, or both.
 
46
 
 
47
To set an installation-wide language preference, set :setting:`LANGUAGE_CODE`.
 
48
Django uses this language as the default translation -- the final attempt if no
 
49
other translator finds a translation.
 
50
 
 
51
If all you want to do is run Django with your native language, and a language
 
52
file is available for it, all you need to do is set ``LANGUAGE_CODE``.
 
53
 
 
54
If you want to let each individual user specify which language he or she
 
55
prefers, use ``LocaleMiddleware``. ``LocaleMiddleware`` enables language
 
56
selection based on data from the request. It customizes content for each user.
 
57
 
 
58
To use ``LocaleMiddleware``, add ``'django.middleware.locale.LocaleMiddleware'``
 
59
to your ``MIDDLEWARE_CLASSES`` setting. Because middleware order matters, you
 
60
should follow these guidelines:
 
61
 
 
62
    * Make sure it's one of the first middlewares installed.
 
63
    * It should come after ``SessionMiddleware``, because ``LocaleMiddleware``
 
64
      makes use of session data.
 
65
    * If you use ``CacheMiddleware``, put ``LocaleMiddleware`` after it.
 
66
 
 
67
For example, your ``MIDDLEWARE_CLASSES`` might look like this::
 
68
 
 
69
    MIDDLEWARE_CLASSES = (
 
70
       'django.contrib.sessions.middleware.SessionMiddleware',
 
71
       'django.middleware.locale.LocaleMiddleware',
 
72
       'django.middleware.common.CommonMiddleware',
 
73
    )
 
74
 
 
75
(For more on middleware, see the :ref:`middleware documentation
 
76
<topics-http-middleware>`.)
 
77
 
 
78
``LocaleMiddleware`` tries to determine the user's language preference by
 
79
following this algorithm:
 
80
 
 
81
    * First, it looks for a ``django_language`` key in the current user's
 
82
      session.
 
83
 
 
84
    * Failing that, it looks for a cookie.
 
85
 
 
86
      .. versionchanged:: 1.0
 
87
 
 
88
      In Django version 0.96 and before, the cookie's name is hard-coded to
 
89
      ``django_language``. In Django 1,0, The cookie name is set by the
 
90
      ``LANGUAGE_COOKIE_NAME`` setting. (The default name is
 
91
      ``django_language``.)
 
92
 
 
93
    * Failing that, it looks at the ``Accept-Language`` HTTP header. This
 
94
      header is sent by your browser and tells the server which language(s) you
 
95
      prefer, in order by priority. Django tries each language in the header
 
96
      until it finds one with available translations.
 
97
 
 
98
    * Failing that, it uses the global ``LANGUAGE_CODE`` setting.
 
99
 
 
100
.. _locale-middleware-notes:
 
101
 
 
102
Notes:
 
103
 
 
104
    * In each of these places, the language preference is expected to be in the
 
105
      standard :term:`language format<language code>`, as a string. For example,
 
106
      Brazilian Portuguese is ``pt-br``.
 
107
 
 
108
    * If a base language is available but the sublanguage specified is not,
 
109
      Django uses the base language. For example, if a user specifies ``de-at``
 
110
      (Austrian German) but Django only has ``de`` available, Django uses
 
111
      ``de``.
 
112
 
 
113
    * Only languages listed in the :setting:`LANGUAGES` setting can be selected.
 
114
      If you want to restrict the language selection to a subset of provided
 
115
      languages (because your application doesn't provide all those languages),
 
116
      set ``LANGUAGES`` to a list of languages. For example::
 
117
 
 
118
          LANGUAGES = (
 
119
            ('de', _('German')),
 
120
            ('en', _('English')),
 
121
          )
 
122
 
 
123
      This example restricts languages that are available for automatic
 
124
      selection to German and English (and any sublanguage, like de-ch or
 
125
      en-us).
 
126
 
 
127
    * If you define a custom ``LANGUAGES`` setting, as explained in the
 
128
      previous bullet, it's OK to mark the languages as translation strings
 
129
      -- but use a "dummy" ``ugettext()`` function, not the one in
 
130
      ``django.utils.translation``. You should *never* import
 
131
      ``django.utils.translation`` from within your settings file, because that
 
132
      module in itself depends on the settings, and that would cause a circular
 
133
      import.
 
134
 
 
135
      The solution is to use a "dummy" ``ugettext()`` function. Here's a sample
 
136
      settings file::
 
137
 
 
138
          ugettext = lambda s: s
 
139
 
 
140
          LANGUAGES = (
 
141
              ('de', ugettext('German')),
 
142
              ('en', ugettext('English')),
 
143
          )
 
144
 
 
145
      With this arrangement, ``django-admin.py makemessages`` will still find
 
146
      and mark these strings for translation, but the translation won't happen
 
147
      at runtime -- so you'll have to remember to wrap the languages in the
 
148
      *real* ``ugettext()`` in any code that uses ``LANGUAGES`` at runtime.
 
149
 
 
150
    * The ``LocaleMiddleware`` can only select languages for which there is a
 
151
      Django-provided base translation. If you want to provide translations
 
152
      for your application that aren't already in the set of translations
 
153
      in Django's source tree, you'll want to provide at least a basic
 
154
      one as described in the :ref:`Locale restrictions<locale-restrictions>`
 
155
      note.
 
156
 
 
157
Once ``LocaleMiddleware`` determines the user's preference, it makes this
 
158
preference available as ``request.LANGUAGE_CODE`` for each
 
159
:class:`~django.http.HttpRequest`. Feel free to read this value in your view
 
160
code. Here's a simple example::
 
161
 
 
162
    def hello_world(request, count):
 
163
        if request.LANGUAGE_CODE == 'de-at':
 
164
            return HttpResponse("You prefer to read Austrian German.")
 
165
        else:
 
166
            return HttpResponse("You prefer to read another language.")
 
167
 
 
168
Note that, with static (middleware-less) translation, the language is in
 
169
``settings.LANGUAGE_CODE``, while with dynamic (middleware) translation, it's
 
170
in ``request.LANGUAGE_CODE``.
 
171
 
 
172
.. _settings file: ../settings/
 
173
.. _middleware documentation: ../middleware/
 
174
.. _session: ../sessions/
 
175
.. _request object: ../request_response/#httprequest-objects
 
176
 
 
177
How Django discovers translations
 
178
---------------------------------
 
179
 
 
180
As described in :ref:`using-translations-in-your-own-projects`,
 
181
at runtime, Django looks for translations by following this algorithm:
 
182
 
 
183
    * First, it looks for a ``locale`` directory in the application directory
 
184
      of the view that's being called. If it finds a translation for the
 
185
      selected language, the translation will be installed.
 
186
    * Next, it looks for a ``locale`` directory in the project directory. If it
 
187
      finds a translation, the translation will be installed.
 
188
    * Finally, it checks the Django-provided base translation in
 
189
      ``django/conf/locale``.
 
190
 
 
191
In all cases the name of the directory containing the translation is expected to
 
192
be named using :term:`locale name` notation. E.g. ``de``, ``pt_BR``, ``es_AR``,
 
193
etc.