`translation.get_language()` should process `settings.LANGUAGE_CODE`
|Reported by:||jcassee||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' (territory) code if it is not in settings.LANGUAGES. So for example, if the HTTP headers contain Accept-Language: en_US and LANGUAGES = ('en', ...), then get_language_from_request() returns 'en'. However, if language negotiation fails then get_language_from_request() returns settings.LANGUAGE_CODE without checking LANGUAGES. Using default settings, get_language_from_request() would return 'en-us' while LANGUAGES only contains 'en'.
This behaviour is inconsistent. Either get_language_from_request() should not remove the sublanguage code from the negotiated language or it should also do so for the default language. In other words, either
- translation.get_language() is always in LANGUAGES, or
- translation.get_language() or its root language is always in LANGUAGES.
In the first case, 'en-us' should not be the default LANGUAGE_CODE (at least not as returned from get_language()). In the second case Django should not strip the sublanguage from the negotiated language code.
Because installations that do not use content negotiation will never call get_language_from_request() any stripping of the sublanguage code might need to be moved to translation.get_language().
Change History (9)
comment:1 Changed 8 years ago by jacob
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
- Triage Stage changed from Unreviewed to Design decision needed