translation.get_language() should remove sublanguage code if it is not in settings.LANGUAGES
|Reported by:||mrts||Owned by:||nobody|
|Cc:||Triage Stage:||Design decision needed|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
When translation.get_language_from_request() processes the Accept-Language HTTP header it makes sure to remove the sublanguage code if it is not in settings.LANGUAGES, so that translation.get_language() subsequently returns only the "main" language code.
However, the behaviour is different in shell:
$ grep -2 LANGUAGES settings.py ugettext = lambda s: s LANGUAGES = ( ('et', ugettext('Estonian')), ('en', ugettext('English')), $ grep LANGUAGE_CODE settings.py LANGUAGE_CODE = 'et' $ locale LANG=en_US.UTF-8 $ ./manage.py shell --plain Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from django.utils.translation import get_language >>> get_language() 'en-us'
I.e. the shell locale is used unchanged.
That breaks code that assumes translation.get_language_from_request() behaviour, e.g. auto-translated model fields (properties that return getattr(self, fieldname + langcode) where langcode comes from get_language()).
This is a minor inconsistency easily fixable with translation.activate() in the shell, so feel free to wontfix this. However, if #9340 gets fixed, perhaps this could be something that can be looked into while at it.
Change History (2)
comment:1 Changed 7 years ago by mrts
- Component changed from Uncategorized to Internationalization
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
- Triage Stage changed from Unreviewed to Design decision needed
- Version changed from 1.1 to SVN