**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 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 o
request.get_fulL_path as the next parameter to the POST.
--
Ticket URL: <https://code.djangoproject.com/ticket/28070>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Old description:
> 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 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 o request.get_fulL_path as the next parameter to the POST.
New description:
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/28070#comment:1>
Comment (by Claude Paroz):
This should have been fixed by #24122 / [aa5ab114e34645]. Isn't it the
same issue? Did we miss something?
--
Ticket URL: <https://code.djangoproject.com/ticket/28070#comment:2>
* status: new => closed
* resolution: => needsinfo
--
Ticket URL: <https://code.djangoproject.com/ticket/28070#comment:3>