test0908
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/ref/settings.txt
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
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
languages as translation strings (as in the default value referred to above)
-- but use a "dummy" ``gettext()`` function, not the one in
``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.
If you define a custom :setting:`LANGUAGES` setting, you can mark the
language names as translation strings using the
:func:`~django.utils.translation.ugettext_lazy` function.
The solution is to use a "dummy" ``gettext()`` function. Here's a sample
settings file::
Here's a sample settings file::
gettext = lambda s: s
from django.utils.translation import ugettext_lazy as _
LANGUAGES = (
('de', gettext('German')),
('en', gettext('English')),
('de', _('German')),
('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
LOCALE_PATHS

24
docs/topics/i18n/translation.txt
View File

@ -1651,29 +1651,19 @@ Notes:
en-us).
* If you define a custom :setting:`LANGUAGES` setting, as explained in the
previous bullet, it's OK to mark the languages as translation strings
-- but use a "dummy" ``ugettext()`` function, not the one in
``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.
previous bullet, you can mark the language names as translation strings
-- but use :func:`~django.utils.translation.ugettext_lazy` instead of
:func:`~django.utils.translation.ugettext` to avoid a circular import.
The solution is to use a "dummy" ``ugettext()`` function. Here's a sample
settings file::
Here's a sample settings file::
ugettext = lambda s: s
from django.utils.translation import ugettext_lazy as _
LANGUAGES = (
('de', ugettext('German')),
('en', ugettext('English')),
('de', _('German')),
('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
preference available as ``request.LANGUAGE_CODE`` for each
:class:`~django.http.HttpRequest`. Feel free to read this value in your view