Document use of locales in management commands

[gregoire]

Locale en-us is forced in management commands.

My application does not support en-us and should run its commands as fr, as specified in the settings.

In BaseCommand.execute(), the comment says:

# Switch to English, because django-admin.py creates database content
# like permissions, and those shouldn't contain any translations.

I guess that commands requiring en-us should activate it themselves and let everything else working in the expected locale.

[Jonas von Poser]

I second this. I use transdb in my models to store translations and my management commands return unexpected values because of this. I was hoping to be able to set the locale another way but it doesn't seem to work. I have to find a fix ASAP, hope I can come up with something.

[Jonas von Poser]

Ok, quick fix in case someone runs across this. Start your management command like this:

  from django.core.management.base import NoArgsCommand
  from django.utils import translation
  from django.conf import settings

   class Command(NoArgsCommand):
       def handle_noargs(self, **options):
           translation.activate(settings.LANGUAGE_CODE)

[gregoire]

I'm in the exact same case, except that I use a personal application instead of transdb.

I use another temporary fix in my application, but the main is problem is that reusable application developers are not necessarily aware of internationalization principles, and some of their management commands are broken because they are defaulted to en-us.

[Malcolm Tredinnick]

It's not necessarily a given that the solution presented here is correct. The Django management tools do a lot more behind the scenes that really require a system-neutral string language (for which we use en-us) than user-visible content. The comment reference in the description is quite possibly only the tip of the iceberg gere.

The alternative solution is that management commands requiring localised content should call translation.activate() beforehand and restore the state with deactivate() afterwards.

System management commands (on any kind of "system") typically have to be very careful about running in non-uniform locales, so "respecting LANGUAGE_CODE" is reasonably intrusive in that respect.

All that being said, we do need a recommended course of behaviour here (at a minimum, in the documentation). Jonas' solution looks quite neat, for example. Bears thinking about.

[Jonas von Poser]

Good point about the translation deactivation. I can live with wrapping my management commands in translation.active() and translation.deactivate() but maybe a sentence in ​http://docs.djangoproject.com/en/dev/howto/custom-management-commands/ would keep others from falling into the same trap.

[Malcolm Tredinnick]

Changing the title to reflect how this should be resolved. It's a documentation issue. The solution in comment:4 is really the best one so as to avoid unintended side-effects.

[Ramiro Morales]

#13859 was a duplicate.

[Vlastimil Zíma]

There is yet another problem with this I encountered.
Function django.utils.translation.get_language in this case does not return language from your settings.LANGUAGES in this case which is not expected. At least I expected that django prevents activation of languages that are not defined in settings.

It would be at least worth a comment in code when your are trying to trace why get_language return language code you have not set. I took me a while before I found out where 'en-us' comes from.

[Ramiro Morales]

Patch for this documentation ticket, ready for trview by documentation experts

[Tim Graham]

(In [15142]) [1.2.X] Fixed #10078 - Document use of locales in management commands. Thanks gregoire for the suggestion and ramiro for the patch.

Backport of r15141 from trunk.