Odp: Re: Odp: Re: Storing language in session/cookie

I don't see any good reason to store the language in session rather than cookie. And storing it in cookie has major advantage, that is avoiding creating unnnecessary sessions. I say if LocaleMiddleware is in our way to better behavior, let's just change it. But I understand that revolution is

Odp: Re: Storing language in session/cookie

As lukeplant commented on a ticket: This is proposing the same thing as #12794, but for a different reason. #13217 is related, but the solution proposed here was not proposed there, and doesn't have the

Odp: Re: Storing language in session/cookie

I've created a ticket: http://code.djangoproject.com/ticket/15902 I agree with Madis. Having a setting to choose where the current language is stored would be convenient and also backwards compatible. How do you think the setting should look like? I propose: LANGUAGE_FORCE_COOKIE ...which

FOR template tag improvement

Hi, I've came up with an idea of improving default FOR template tag: {% for ... in ... %} By adding something similar to list comprehension syntax: {% for ... in ... if ... %} Filtering through looping is so common task that I'm sure many people would find this syntax quite handy. I'll be

Allow TestRunners to define their own command-line options

This idea clearly needs a design decision. The idea is to allow custom test runners do define and process their own command-line options, apart from default ones like verbose. Here's the ticket: http://code.djangoproject.com/ticket/15675 Attached patch is one of possible solutions. Management

Re: Storing language in session/cookie

Sorry for bumping the thread, but could somebody familiar with session subsystem anwer it? It is critical for my work to know if this issue is my problem or Django's. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,

Re: Storing language in session/cookie

If I understand the middleware correctly, session cookie is created only when the session itself is modified, unless SESSION_SAVE_EVERY_REQUEST is True. So, after user language is set but before user authentication there could be only one, language cookie. I think that

Re: Storing language in session/cookie

I know, but it just seems so obvious to me that I can't believe no one have ever encountered this problem before - I felt like I should ask ;) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Storing language in session/cookie

Hi, I'd like to make a proposal of changing the way that current language is stored, at least, making this changeable by settings. The problem is that even for non-logged users their language is stored in session (if it's supported or in the cookie otherwise). That creates a session for every