Fixed #24073 -- Deactivated translations when leave_locale_alone is False

Thanks Tim Graham and Markus Holtermann for the reviews.

2 files changed, 20 insertions, 8 deletions

diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt
index c9695003a1..cab7ea47ac 100644
--- a/docs/howto/custom-management-commands.txt
+++ b/docs/howto/custom-management-commands.txt
@@ -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
diff --git a/docs/releases/1.8.txt b/docs/releases/1.8.txt
index 1e0203bdc3..0147b8b67b 100644
--- a/docs/releases/1.8.txt
+++ b/docs/releases/1.8.txt
@@ -1014,6 +1014,13 @@ Miscellaneous
   that Django includes) will no longer convert null values back to an empty
   string. This is consistent with other backends.
 
+* When the :attr:`~django.core.management.BaseCommand.leave_locale_alone`
+  attribute is ``False``, translations are now deactivated instead of forcing
+  the "en-us" locale. In the case your models contained non-English strings and
+  you counted on English translations to be activated in management commands,
+  this will not happen any longer. It might be that new database migrations are
+  generated (once) after migrating to 1.8.
+
 .. _deprecated-features-1.8:
 
 Features deprecated in 1.8