id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
9340	`translation.get_language()` should process `settings.LANGUAGE_CODE`	Joost Cassee	nobody	"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

 1. `translation.get_language()` is always in `LANGUAGES`, or
 1. `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()`."	Bug	closed	Internationalization	1.0	Normal	fixed			Design decision needed	0	0	0	0	0	0