Opened 8 years ago
Closed 8 years ago
#28070 closed Bug (needsinfo)
set_language (i18n) without next does not change language if called from a language prefixed URL
Reported by: | Monsieur Cellophane | Owned by: | nobody |
---|---|---|---|
Component: | Internationalization | Version: | 1.11 |
Severity: | Normal | Keywords: | set_language, url translation |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Greetings.
Preamble:
Switching language by posting to set_language with an empty next parameter causes a redirection to the REFERER url, as per the documentation.
Description:
What this means is that if language selection is made from a language-neutral URL (say /about/), selecting english as language the redirection in set_language will land the user to /en/about.
If - however - a new language selection (say de) is now made from /en/about/, the landing spot will be (again) /en/about, rather than the expected /de/about. The new language (de) is now, however, memorised in the user's session.
What should happen:
Invoking set_language from a language prefixed page with an empty next parameter should redirect to the language-neutral URL, allowing the session based url selection to kick in.
What would help:
Of course, being able to reference the current language-neutral url as the next parameter to set_language would achieve the result. However, language-neutral urls aren't availble in templates (or anywhere I looked); so one's best hope is writing a custom template filter that strips the language prefix from a URL and hen use the stripped request.path (or request.get_fulL_path) as the next parameter to the POST.
Change History (3)
comment:1 by , 8 years ago
Description: | modified (diff) |
---|
comment:2 by , 8 years ago
comment:3 by , 8 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
This should have been fixed by #24122 / [aa5ab114e34645]. Isn't it the same issue? Did we miss something?