Opened 6 years ago

Last modified 6 years ago

#26556 new Bug

set_language with i18n_patterns doesn't work all the time

Reported by: Hugo Chargois Owned by: nobody
Component: Internationalization Version: 1.9
Severity: Normal Keywords:
Cc: greyzmeem@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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.

[4] (first warning note)

Change History (3)

comment:1 Changed 6 years ago by Aymeric Augustin

The description makes sense. (I didn't attempt to reproduce.)

The reason why set_language shouldn't be in i18n_patterns is discussed in #18472:

I've seen people get confused by including the set_language URL within their i18n_patterns and wondering why it doesn't work (the form POST turns into a redirected GET request which fails); we should probably add a warning to ensure that this URL is locale-independent

(There's nothing else about this issue in that ticket.)

comment:2 Changed 6 years ago by Aymeric Augustin

Triage Stage: UnreviewedAccepted

comment:3 Changed 6 years ago by Andrey Maslov

Cc: greyzmeem@… added
Note: See TracTickets for help on using tickets.
Back to Top