Code

Opened 5 years ago

Closed 4 years ago

#10078 closed (fixed)

Document use of locales in management commands

Reported by: gregoire Owned by: nobody
Component: Documentation Version: master
Severity: Keywords: LANCGUAGE_CODE management basecommand en-us
Cc: gregoire@…, django@…, vzima Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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.

Attachments (1)

10078.diff (2.4 KB) - added by ramiro 4 years ago.
Patch for this documentation ticket, ready for trview by documentation experts

Download all attachments as: .zip

Change History (12)

comment:1 Changed 5 years ago by Jonas

  • Cc django@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

comment:2 Changed 5 years ago by Jonas

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)

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by mtredinnick

  • Triage Stage changed from Unreviewed to Accepted

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.

comment:5 Changed 5 years ago by Jonas

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.

comment:6 Changed 5 years ago by mtredinnick

  • Component changed from Internationalization to Documentation
  • Summary changed from Management commands should honor LANGUAGE_CODE settings to Document use of locales in management commands

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.

comment:7 Changed 4 years ago by ramiro

  • Keywords LANCGUAGE_CODE management basecommand en-us added

#13859 was a duplicate.

comment:8 Changed 4 years ago by vzima

  • Cc vzima added

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.

Changed 4 years ago by ramiro

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

comment:9 Changed 4 years ago by ramiro

  • Has patch set

comment:10 Changed 4 years ago by jezdez

  • Triage Stage changed from Accepted to Ready for checkin

comment:11 Changed 4 years ago by timo

  • Resolution set to fixed
  • Status changed from new to closed

(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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.