Fixed #19730 -- Don't validate importability of settings by using i18n in management commands.

They are handled independently now and the latter can be influenced by
the new BaseCommand.leave_locale_alone internal option.

Thanks chrischambers for the report, Claude, lpiatek, neaf and gabooo for
their work on a patch, originally on refs. #17379.

2 files changed, 73 insertions, 35 deletions

diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt
index 6a7f644218..eba187bb37 100644
--- a/docs/howto/custom-management-commands.txt
+++ b/docs/howto/custom-management-commands.txt
@@ -112,54 +112,61 @@ In addition to being able to add custom command line options, all
 :doc:`management commands</ref/django-admin>` can accept some
 default options such as :djadminopt:`--verbosity` and :djadminopt:`--traceback`.
 
-.. admonition:: Management commands and locales
+.. _management-commands-and-locales:
 
-    The :meth:`BaseCommand.execute` method sets the hardcoded ``en-us`` locale
-    because the 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``).
+Management commands and locales
+===============================
 
-    If your custom management command uses another locale, you should manually
-    activate and deactivate it in your :meth:`~BaseCommand.handle` or
-    :meth:`~NoArgsCommand.handle_noargs` method using the functions provided by
-    the I18N support code:
+By default, the :meth:`BaseCommand.execute` method sets the hardcoded 'en-us'
+locale because most of the 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').
 
-    .. code-block:: python
+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
+:meth:`~BaseCommand.handle` or :meth:`~NoArgsCommand.handle_noargs` method using
+the functions provided by the I18N support code:
 
-        from django.core.management.base import BaseCommand, CommandError
-        from django.utils import translation
+.. code-block:: python
 
-        class Command(BaseCommand):
-            ...
-            can_import_settings = True
+    from django.core.management.base import BaseCommand, CommandError
+    from django.utils import translation
 
-            def handle(self, *args, **options):
+    class Command(BaseCommand):
+        ...
+        can_import_settings = True
 
-                # Activate a fixed locale, e.g. Russian
-                translation.activate('ru')
+        def handle(self, *args, **options):
 
-                # Or you can activate the LANGUAGE_CODE
-                # chosen in the settings:
-                #
-                #from django.conf import settings
-                #translation.activate(settings.LANGUAGE_CODE)
+            # Activate a fixed locale, e.g. Russian
+            translation.activate('ru')
+
+            # Or you can activate the LANGUAGE_CODE # chosen in the settings:
+            #
+            #from django.conf import settings
+            #translation.activate(settings.LANGUAGE_CODE)
+
+            # Your command logic here
+            # ...
 
-                # Your command logic here
-                # ...
+            translation.deactivate()
 
-                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
+it by using the :data:`BaseCommand.leave_locale_alone` option.
 
-    Take into account though, that system management commands typically have to
-    be very careful about running in non-uniform locales, so:
+When working on the scenarios described above though, take into account that
+system management commands typically have to be very careful about running in
+non-uniform locales, so you might need to:
 
-    * Make sure the :setting:`USE_I18N` setting is always ``True`` when running
-      the command (this is one good example of the potential problems stemming
-      from a dynamic runtime environment that Django commands avoid offhand by
-      always using a fixed locale).
+* 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).
 
-    * Review the code of your command and the code it calls for behavioral
-      differences when locales are changed and evaluate its impact on
-      predictable behavior of your command.
+* Review the code of your command and the code it calls for behavioral
+  differences when locales are changed and evaluate its impact on
+  predictable behavior of your command.
 
 Command objects
 ===============
@@ -222,6 +229,29 @@ All attributes can be set in your derived class and can be used in
   rather than all applications' models, call
   :meth:`~BaseCommand.validate` from :meth:`~BaseCommand.handle`.
 
+.. attribute:: BaseCommand.leave_locale_alone
+
+  A boolean indicating whether the locale set in settings should be preserved
+  during the execution of the command instead of being forcibly set to 'en-us'.
+
+  Default value is ``False``.
+
+  Make sure you know what you are doing if you decide to change the value of
+  this option in your custom command because many of them create database
+  content that is locale-sensitive (like permissions) and that content
+  shouldn't contain any translations so making the locale differ from the de
+  facto default 'en-us' can cause unintended effects. See the `Management
+  commands and locales`_ section above for further details.
+
+  This option can't be ``False`` when the
+  :data:`~BaseCommand.can_import_settings` option is set to ``False`` too
+  because attempting to set the locale needs access to settings. This condition
+  will generate a :class:`CommandError`.
+
+.. versionadded:: 1.6
+
+    The ``leave_locale_alone`` option was added in Django 1.6.
+
 Methods
 -------
 
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 5e1d959f60..acc273cef4 100644
--- a/docs/releases/1.6.txt
+++ b/docs/releases/1.6.txt
@@ -39,6 +39,14 @@ Minor features
   <lazy-plural-translations>` can be provided at translation time rather than
   at definition time.
 
+* For custom managemente commands: Validation of the presence of valid settings
+  in managements commands that ask for it by using the
+  :attr:`~django.core.management.BaseCommand.can_import_settings` internal
+  option is now performed independently from handling of the locale that should
+  active during the execution of the command. The latter can now be influenced
+  by the new :attr:`~django.core.management.BaseCommand.leave_locale_alone`
+  internal option. See :ref:`management-commands-and-locales` for more details.
+
 Backwards incompatible changes in 1.6
 =====================================