[Django] #20125: get_language_from_request() - inconsistent use of fallback language
Django
--------------------------------------+--------------------
Reporter: lwarx | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Internationalization | Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------
To set language code
django.utils.translation.trans_real.get_language_from_request() consults
four places in the following order:
1. url - get_language_from_path()
2. session - request.session.get('django_language', None)
3. cookie - request.COOKIES.get(settings.LANGUAGE_COOKIE_NAME)
4. 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:
* /fr-ca/
* /en-ca/
* /en-us/
* /en-gb/
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'.
Is it worth to unify fallback language handling to allow full locale in
url and session? There is also two recently closed related tickets: #19811
and #19763
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/20125>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: lwarx | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Internationalization | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by akaariai):
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
At the least the docstring is false.
--
Ticket URL: <https://code.djangoproject.com/ticket/20125#comment:1>
Django
Reporter: lwarx | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Internationalization | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by lwarx):
I do not have free time to work on this right now, but I have rough
concept (not tested at all) of how locale selector could be implemented.
It allows subclassing and some steps can be easily disabled. The missing
part is the way to inject custom class into LocaleMiddleware.
--
Ticket URL: <https://code.djangoproject.com/ticket/20125#comment:2>
Django
Reporter: lwarx | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Internationalization | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by bouke):
In
[[https://github.com/django/django/blob/9b7455e918a437c3db91e88dcbf6d9c93fef96f8/django/utils/translation/trans_real.py#L453|get_language_from_path:453]]
there is already a call to `get_supported_language_variant` and the
session will only contain languages that were previously available. Is
there still a problem with this? Apart from that, I like the locale
selector you're working on. The locale selection could do with some
cleaning up.
--
Ticket URL: <https://code.djangoproject.com/ticket/20125#comment:3>
Django
Reporter: lwarx | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Internationalization | Version: 1.5
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by lwarx):
* status: new => closed
* resolution: => fixed
Comment:
I haven't switched my projects to 1.6 yet, but after looking at the code
(#11915 #19763 #19811 #19919) I think it will do the trick.
Regarding locale selection class, I still do not have much time to work on
this, but hope to do it in the future.
If you do not have any objections, I'm closing this ticket for now
(refactoring can be moved to separate ticket).
--
Ticket URL: <https://code.djangoproject.com/ticket/20125#comment:4>