Fixed #21372 -- Corrected docs regarding translating LANGUAGES.

Corrected LANGUAGES documentation on how to translate language
names. Now using django.utils.translation.ugettext_lazy instead
of a dummy gettext() function.

Thanks to Salvatore for the report.
This commit is contained in:
Bernardo Pires 2013-11-09 11:32:19 +01:00 committed by Baptiste Mispelon
parent e7383f16b4
commit 8bc350b385
2 changed files with 14 additions and 34 deletions

View File

@ -1366,29 +1366,19 @@ This specifies which languages are available for language selection. See
Generally, the default value should suffice. Only set this setting if you want Generally, the default value should suffice. Only set this setting if you want
to restrict language selection to a subset of the Django-provided languages. to restrict language selection to a subset of the Django-provided languages.
If you define a custom :setting:`LANGUAGES` setting, it's OK to mark the If you define a custom :setting:`LANGUAGES` setting, you can mark the
languages as translation strings (as in the default value referred to above) language names as translation strings using the
-- but use a "dummy" ``gettext()`` function, not the one in :func:`~django.utils.translation.ugettext_lazy` function.
``django.utils.translation``. You should *never* import
``django.utils.translation`` from within your settings file, because that
module in itself depends on the settings, and that would cause a circular
import.
The solution is to use a "dummy" ``gettext()`` function. Here's a sample Here's a sample settings file::
settings file::
gettext = lambda s: s from django.utils.translation import ugettext_lazy as _
LANGUAGES = ( LANGUAGES = (
('de', gettext('German')), ('de', _('German')),
('en', gettext('English')), ('en', _('English')),
) )
With this arrangement, ``django-admin.py makemessages`` will still find and
mark these strings for translation, but the translation won't happen at
runtime -- so you'll have to remember to wrap the languages in the *real*
``gettext()`` in any code that uses :setting:`LANGUAGES` at runtime.
.. setting:: LOCALE_PATHS .. setting:: LOCALE_PATHS
LOCALE_PATHS LOCALE_PATHS

View File

@ -1651,29 +1651,19 @@ Notes:
en-us). en-us).
* If you define a custom :setting:`LANGUAGES` setting, as explained in the * If you define a custom :setting:`LANGUAGES` setting, as explained in the
previous bullet, it's OK to mark the languages as translation strings previous bullet, you can mark the language names as translation strings
-- but use a "dummy" ``ugettext()`` function, not the one in -- but use :func:`~django.utils.translation.ugettext_lazy` instead of
``django.utils.translation``. You should *never* import :func:`~django.utils.translation.ugettext` to avoid a circular import.
``django.utils.translation`` from within your settings file, because that
module in itself depends on the settings, and that would cause a circular
import.
The solution is to use a "dummy" ``ugettext()`` function. Here's a sample Here's a sample settings file::
settings file::
ugettext = lambda s: s from django.utils.translation import ugettext_lazy as _
LANGUAGES = ( LANGUAGES = (
('de', ugettext('German')), ('de', _('German')),
('en', ugettext('English')), ('en', _('English')),
) )
With this arrangement, :djadmin:`django-admin.py makemessages <makemessages>`
will still find and mark these strings for translation, but the translation
won't happen at runtime -- so you'll have to remember to wrap the languages in
the *real* ``ugettext()`` in any code that uses :setting:`LANGUAGES` at
runtime.
Once ``LocaleMiddleware`` determines the user's preference, it makes this Once ``LocaleMiddleware`` determines the user's preference, it makes this
preference available as ``request.LANGUAGE_CODE`` for each preference available as ``request.LANGUAGE_CODE`` for each
:class:`~django.http.HttpRequest`. Feel free to read this value in your view :class:`~django.http.HttpRequest`. Feel free to read this value in your view