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 26556,set_language with i18n_patterns doesn't work all the time,Hugo Chargois,nobody,"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)",Bug,new,Internationalization,1.9,Normal,,,greyzmeem@…,Accepted,0,0,0,0,0,0