#21473: Cookie based language detection no longer practical
--------------------------------------+------------------------------------
Reporter: ludwik | Owner: nobody
Type: Bug | Status: new
Component: Internationalization | Version: 1.6
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Changes (by akaariai):
* severity: Normal => Release blocker
* stage: Unreviewed => Accepted
Comment:
The solution in #14825 seems a bit over-aggressive. The implementation in
there is "force-assign language back to session for each response". For
example this means it is impossible to force-clear the session language if
you actually want that. And it also means that the language is stored in
the session no matter if you actually want to use session to store the
language. As session language overrides cookie language this essentially
breaks cookie based language selection. This will also break a view that
does this:
{{{
def change_language(request, lang):
request.session['django_language'] = lang
return HttpResponseRedirect(somepage)
}}}
Some proposals for fix:
1. Assign the language back to session in contrib.auth.logout() right
after session.flush(). Revert the change to localemiddleware
2. In LocaleMiddleware, store the language back only if it came from
session. This can be done by setting request._language_was_from_session =
True in process_request and checking against that in process_response.
3. Just revert the change.
I don't particularly like the idea that you can't flush the language code
from session, and with option 2 above it will be force-restored on
process_response. So, I vote for approach 1. This means that
session.flush() will remove the language for next request. But if you
store the language in a session and then flush it, isn't that what is
supposed to happen?
I haven't actually ran any tests to verify this issue but the analysis in
the description are convincing enough for me. Marking this as release
blocker as this is a regression in 1.6.
--
Ticket URL: <https://code.djangoproject.com/ticket/21473#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.fdfc80656b32690fe84e1eb56955155e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
