Cookie based language detection no longer practical
|Reported by:||Ludwik Trammer||Owned by:||nobody|
|Cc:||Sergey Kolosov||Triage Stage:||Accepted|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Up until Django 1.6 I successfully used the following method:
- Use Django's
LocaleMiddlewareso the correct locale is detected and used.
- When user switches languages set a cookie with her new preference, with name based on
I think that sounds pretty responsible and in line with what's in documentation. And it worked as expected.
LocaleMiddleware used the cookie's value during language detection.
Unfortunately it all break after upgrading to Django 1.6. In Django 1.6 the following code was added to
# Store language back into session if it is not present if hasattr(request, 'session'): request.session.setdefault('django_language', language)
It has two unfortunate consequences for me. The former more obvious, the latter more important:
- Session cookie is now always present on user's computer. A session is created as soon a she opens the site for the first time. That's defeats the whole purpose of using
django_languagecookie instead of using sessions.
- When a user opens the site for the first time her current language is saved to her session. She haven't had a chance to manually set her preference yet, so the value set to session in based on request headers or
LANGUAGE_CODEsettings. From now on
django_languagecookie value is ignored (and for that matter her changing language preferences in her browser is ignored also), because the value from session has the highest priority.
So, to summarise: cookie value is ignored if session value is present, but starting from Django 1.6 session value is always present.
Change History (19)
comment:3 Changed 3 years ago by
|Severity:||Normal → Release blocker|
|Triage Stage:||Unreviewed → Accepted|
comment:13 Changed 3 years ago by
|Status:||closed → new|
|Triage Stage:||Ready for checkin → Accepted|
|Version:||1.6 → master|