Fixed #24073 -- Deactivated translations when leave_locale_alone is False

Thanks Tim Graham and Markus Holtermann for the reviews.
This commit is contained in:
Claude Paroz 2015-01-03 20:27:18 +01:00
parent 2c0f64b5f6
commit f7c287fca9
4 changed files with 31 additions and 18 deletions

View file

@ -145,13 +145,18 @@ default options such as :djadminopt:`--verbosity` and :djadminopt:`--traceback`.
Management commands and locales
===============================
By default, the :meth:`BaseCommand.execute` method sets the hardcoded 'en-us'
locale because some commands shipped with Django perform several tasks
(for example, user-facing content rendering and database population) that
require a system-neutral string language (for which we use 'en-us').
By default, the :meth:`BaseCommand.execute` method deactivates translations
because some commands shipped with Django perform several tasks (for example,
user-facing content rendering and database population) that require a
project-neutral string language.
If, for some reason, your custom management command needs to use a fixed locale
different from 'en-us', you should manually activate and deactivate it in your
.. versionchanged:: 1.8
In previous versions, Django forced the "en-us" locale instead of
deactivating translations.
If, for some reason, your custom management command needs to use a fixed locale,
you should manually activate and deactivate it in your
:meth:`~BaseCommand.handle` method using the functions provided by the I18N
support code::
@ -177,7 +182,7 @@ support code::
translation.deactivate()
Another need might be that your command simply should use the locale set in
settings and Django should be kept from forcing it to 'en-us'. You can achieve
settings and Django should be kept from deactivating it. You can achieve
it by using the :data:`BaseCommand.leave_locale_alone` option.
When working on the scenarios described above though, take into account that
@ -187,7 +192,7 @@ non-uniform locales, so you might need to:
* Make sure the :setting:`USE_I18N` setting is always ``True`` when running
the command (this is a good example of the potential problems stemming
from a dynamic runtime environment that Django commands avoid offhand by
always using a fixed locale).
deactivating translations).
* Review the code of your command and the code it calls for behavioral
differences when locales are changed and evaluate its impact on