get_language_from_request() - inconsistent use of fallback language
|Reported by:||Max Arnold||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
To set language code django.utils.translation.trans_real.get_language_from_request() consults four places in the following order:
- url - get_language_from_path()
- session - request.session.get('django_language', None)
- cookie - request.COOKIES.get(settings.LANGUAGE_COOKIE_NAME)
- accept-language header - request.META.get('HTTP_ACCEPT_LANGUAGE', )
Its docsting says:
Analyzes the request to find what language the user wants the system to
show. Only languages listed in settings.LANGUAGES are taken into account.
If the user requests a sublanguage where we have a main language, we send
out the main language.
(1) and (2) do not use get_supported_language_variant() function (which uses available main language when there is no sublanguage), making it impossible to always have full locale in url or session. Consider this use-case:
I want to build a site which will be available in several countries, and some of them have more than one official language. To do that, I allocate several url prefixes (locales) to always contain both language and country:
Using this scheme there is no need to have separate country selector in the url, and I can have only generic translations like 'en' and 'fr' with the possibility to add specific ones like 'en-gb'.
Also this logic is not very easy to override - I can subclass LocaleMiddleware.process_request(), but get_language_from_request() is still monolithic. I think it is better to move accept-language normalization to separate function.
Change History (5)
comment:1 Changed 3 years ago by
|Patch needs improvement:||unset|
|Triage Stage:||Unreviewed → Accepted|