set_language not changing language in certain cases (django) - django

Question

I have the following menu to change languages in my site:
<div class="btn-group navbar-right language menu">
<button class="btn btn-secondary btn-sm dropdown-toggle language-btn" type="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
{% get_language_info for LANGUAGE_CODE as lang %}
{{ lang.name_local }} ({{ lang.code }})
</button>
<div class="dropdown-menu" aria-labelledby="dropdownMenu2">
{% get_current_language as LANGUAGE_CODE %}
{% get_available_languages as LANGUAGES %}
{% get_language_info_list for LANGUAGES as languages %}
{% for language in languages %}
<ul class="language-item">
<form action="{% url 'set_language' %}" method="post">
{% csrf_token %}
<input name="next" type="hidden" value="{{ request.get_full_path }}" />
<input name="language" type="hidden" value="{{ language.code }}" />
<input type="submit" value="{{ language.name_local }} ({{ language.code }})" /> <span>{% if language.code == LANGUAGE_CODE %}✓{% endif %}</span>
</form>
</ul>
{% endfor %}
</div>
</div>
Being shown like
This works the same than the form suggested by Django docs but avoiding the "Go" button to switch languages.
It usually switches languages properly, except in certain cases, as I found out after a user reported the problem.
If the user gets to my site via www.mydomain.com, it will be redirected to www.mydomain.com/en/ (or /es/ or /de/) and as far as I know, changing languages works as expected.
However, if the user gets to my site via www.mydomain.com/es/, then when trying to change the language through the menu, www.mydomain.com/es/ is loaded again. The same behavior occurs with www.mydomain.com/de/.
Strange enough, when entering my site via www.mydomain.com/en/, changing languages works properly. Maybe because it is the default language?
I am able to replicate the issue consistently if entering the site through an incognito window. If I do it through a normal window, it is a similar behavior, but not always consistent. For instance, sometimes entering via www.mydomain.com/en/ will not let me change the language either. This makes me think it might have something to do with cookies. But this is as far as I got.
I checked for similar problems during hours and the only similar thing I found is the Django ticket In some cases i18n set_language does not change url language. Its conclusion is:
...I recreated the issue: we set a language (once) then try to reverse
a URL from the old language when setting the language again.
This obviously fails.
Workarounds:
keeping track of the old language and falling back to try that if the lookup with the current language fails.
Signalling across browser tabs that we already changed the language and adjusting accordingly (???).
Both of these are out of scope for the in-built i18n. (The first would
be possible on a project level — reimplementing e.g. set_language — if
it was deemed cost effective.)
I'm going to close this on that basis.
I am not sure if it is the same case, as I don't understand why it "obviously fails". As I see it, the obvious behavior should be to change the language.
I am surprised that such a basic feature does not work, so probably I am missing something.
Why is it not working in the cases described?
Any help would be appreciated.
Edit 1:
Previously I was using translated URLs instead of the form, as suggested here. However, this was taking 1 second to render due to the translation of the slug. This is why I decided to change

Answer 1

I experienced the same problem. It is still an existing issue, where django seemingly does not translate the HTTP referer header.
See Django source code of set_language
A way to workaround this is to send a hidden input field named next that you set to the same url you are at (request.get_full_path), but replace the current language part with the language you intend to switch to.
Here is a snippet of a language switcher solving this issue:
<li {% if current_language|slice:":2" == 'en' %} class="active"{% endif %}>
<form method="POST" action="{% url 'set_language' %}" autocomplete="off">
{% csrf_token %}
<span class="language-code">en</span>
<input type="submit" name="language" value="en">
<input type="hidden" name="next" value="{{ request.get_full_path|replace_language:"en" }}">
</form>
</li>
<li{% if current_language|slice:":2" == 'da' %} class="active"{% endif %}>
<form method="POST" action="{% url 'set_language' %}" autocomplete="off">
{% csrf_token %}
<span class="language-code">dk</span>
<input type="submit" name="language" value="da">
<input type="hidden" name="next" value="{{ request.get_full_path|replace_language:"da" }}">
</form>
</li>
Then you can implement a custom template tag called replace_language that runs through your configured languages and replaces it with the argument.
Hope this helps :-)

Answer 2

For further reference, I just went back to using translated URLs as suggested here, instead of the form.
I found out that what was making it so slow.
It turned out it was something that could be optimized, so now the translated URLs load very fast as well.

Answer 3

Solved the issue by removing the language code from the "next" input (slice the current language code from the url)
Next input:
<input name="next" type="hidden" value="{{ request.get_full_path|slice:"3:" }}">
Whole dropdown:
<form action="{% url 'set_language' %}" method="post">
{% csrf_token %}
<div class="row g-2">
<div class="col col-sm-12 col-lg-3 col-md-4">
<div class="form-floating">
<input name="next" type="hidden" value="{{ request.get_full_path|slice:"3:" }}">
<select class="form-select" name="language" onchange="this.form.submit()" id="language">
{% get_current_language as LANGUAGE_CODE %}
{% get_available_languages as LANGUAGES %}
{% get_language_info_list for LANGUAGES as languages %}
{% for language in languages %}
<option value="{{ language.code }}"{% if language.code == LANGUAGE_CODE %} selected{% endif %}>
{{ language.name_local }} ({{ language.code }})
</option>
{% endfor %}
</select>
<label for="language">Language</label>
</div>
</div>
</div>
</form>