#26556: set_language with i18n_patterns doesn't work all the time
--------------------------------------+--------------------
Reporter: hchargois | Owner: nobody
Type: Bug | Status: new
Component: Internationalization | Version: 1.9
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------
Using both i18n_patterns and the set_language view should work since
#24122, and it mostly does, but one use-case is not covered.
The problem is when the default language for a user (either when the user
has no session or cookie-base preference and the website-default is used,
or when the user preference is used) is not the same as the language
encoded in the url from which the user is switching.
For example, let's say that we have a website that has English as its
default language, and is also translated in French.
Some user that has never visited this website (and thus has no session or
language cookie) stumbles upon a link to a French URL to this website. He
clicks it and finds a page in French. He would prefer the English version,
so he clicks on "English" in the language selector, and this doesn't work.
Why this doesn't work is that the documentation says that the
`set_language` view should be outside of `i18n_patterns`. When the user
POSTs to the `set_language` view, the view is called with the default
language, English. The view calls `translate_url` [1] on the `next` URL
that in turn calls `resolve`, but this only resolves correctly if the
language-prefix in the URL is the same as the current active one. This is
not the case since, as we said, we come from a French page, thus the
`next` URL has a `fr` prefix, but the view is called in the default `en`
context.
This also happens if the user has the English language explicitly set as a
preference, of course.
I have made a simple Django app for you to test easily [2] (the Django it
includes in the environment is the current dev version from a git checkout
of yesterday). It includes a very rough fix that is definitely not well-
tested but solves the problem in this very simple test app [3], so you
will have to checkout before this fix to reproduce. I first found the
problem on Django 1.9.
Another way to fix (I will probably be using this as a workaround for the
time being) is to simply put the `set_language` view in `i18n_patterns`. I
wonder why this is forbidden by the documentation [4], this seems to work
like a charm.
[1]
https://github.com/django/django/blob/86573861a95e5a47dc7ff906443117d75b73dca1/django/views/i18n.py#L51
[2] https://github.com/hchargois/django_bug_language_select
[3]
https://github.com/hchargois/django_bug_language_select/commit/b46e89b41fdd20c73386bb937ec75bd0906976c4
[4] https://docs.djangoproject.com/en/dev/topics/i18n/translation/#the-
set-language-redirect-view (first warning note)
--
Ticket URL: <https://code.djangoproject.com/ticket/26556>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/052.0cc6a1597f8ad4b5975823d70f5df260%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
