Opened 3 years ago

Last modified 2 years ago

#33668 assigned Bug

i18n set_language not working in Safari

Reported by: yopiti Owned by: Eknath Baravkar
Component: Internationalization Version: 4.0
Severity: Normal Keywords:
Cc: Carlton Gibson Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no
Pull Requests:How to create a pull request

Description (last modified by yopiti)

Trying to implement a session / cookie based translation selector.

This code correctly sets the language in Chrome (100) & Firefox (99.0.1), but not in Safari (15.4).

{% load i18n %}

<form action="{% url 'set_language' %}" method="post">{% csrf_token %}
    <input name="next" type="hidden" value="{{ redirect_to }}" />
    <select name="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="selected"{% endif %}>
                {{ language.name_local }} ({{ language.code }})
            </option>
        {% endfor %}
    </select>
    <input type="submit" value="Go" />
</form>

Request is made, its redirected to /i18n/setlang/ and back to the original page, but not switching language.

According to the ticket's flags, the next step(s) to move this issue forward are:

  • To provide a patch by sending a pull request. Claim the ticket when you start working so that someone else doesn't duplicate effort. Before sending a pull request, review your work against the patch review checklist. Check the "Has patch" flag on the ticket after sending a pull request and include a link to the pull request in the ticket comment when making that update. The usual format is: [https://github.com/django/django/pull/#### PR].

Change History (4)

comment:1 by yopiti, 3 years ago

Description: modified (diff)

comment:2 by Carlton Gibson, 3 years ago

This might be the intelligent tracking protection — it doesn't send the cookies after a-certain-number of redirects. 🤔

Can I ask: if you refresh, is the language then-set? This sometimes happens with logins, but when I've seen it, the login has worked, it's just that the cookie wasn't sent for the final redirect request, and so refreshing then sends it.

Was this working previously? Or are you only implementing it now? (Not sure if this is something we'd be able to work around... — short of Use less internal redirects... 🤔)

comment:3 by Carlton Gibson, 3 years ago

Cc: Carlton Gibson added
Triage Stage: UnreviewedAccepted

I'm going to Accept as The set_language redirect view docs have this exact form, so we'll need to review if a note or such is needed even if we can't suggest a different flow.

comment:4 by Eknath Baravkar, 2 years ago

Owner: changed from nobody to Eknath Baravkar
Status: newassigned
Note: See TracTickets for help on using tickets.
Back to Top