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:
parent
e7383f16b4
commit
8bc350b385
|
@ -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
|
||||||
|
|
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue