id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
21473	Cookie based language detection no longer practical	Ludwik Trammer	nobody	"I use cookies to save user's custom language preference (and that's not just a matter of personal taste - I use Varnish, so it's important for me to defer putting a session cookie on user's computer as long as possible, because it is unique per user, so does not work good with caching).

Up until Django 1.6 I successfully used the following method:

1. Use Django's `LocaleMiddleware` so the correct locale is detected and used.
2. When user switches languages set a cookie with her new preference, with name based on `settings.LANGUAGE_COOKIE_NAME`.

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 `LocaleMiddleware`'s `process_response()` method:

{{{
# 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:

1. 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_language` cookie instead of using sessions.

2. 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_CODE` settings. From now on `django_language` cookie 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.

My code broke after upgrading to Django 1.6, just because I used a cookie-based method, that is part of documented Django futures. The '''only''' way to use cookies for setting language now, is to disable sessions completely in your project (not an option for me). That's a really big change, and there is literally nothing about it in ""backwards incompatible changes"" section of Django 1.6 release notes. I also don't see an easy work around this problem for me."	Bug	closed	Internationalization	dev	Release blocker	fixed		Sergey Kolosov	Accepted	1	0	0	0	0	0