Opened 16 years ago
Closed 14 years ago
#10078 closed (fixed)
Document use of locales in management commands
Reported by: | gregoire | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Keywords: | LANCGUAGE_CODE management basecommand en-us | |
Cc: | gregoire@…, django@…, Vlastimil Zíma | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
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)
Change History (12)
comment:1 by , 16 years ago
Cc: | added |
---|
comment:2 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
Triage Stage: | Unreviewed → 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 by , 16 years ago
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 by , 16 years ago
Component: | Internationalization → Documentation |
---|---|
Summary: | Management commands should honor LANGUAGE_CODE settings → 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 by , 14 years ago
Keywords: | LANCGUAGE_CODE management basecommand en-us added |
---|
#13859 was a duplicate.
comment:8 by , 14 years ago
Cc: | 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.
by , 14 years ago
Attachment: | 10078.diff added |
---|
Patch for this documentation ticket, ready for trview by documentation experts
comment:9 by , 14 years ago
Has patch: | set |
---|
comment:10 by , 14 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:11 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.