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

[Vlastimil Zíma]

I just find out ticket #15902 while searching for completely different thing 
:)

I support storing language into cookie only (as final state) for reasons we 
encountered in our applications:

 - Language is not forgotten when user logs out / is logged out.
   - When this happens with languge in session, whole session is dumped 
including language and any further response is displayed with default 
language. This problem is described in #14825.

 - Language can be changed by GET request.
   - If language is stored in cookie, this avoids #3651 as cookies are only 
part of response and does not change state of session on server.

 - Language can be shared without necessity to share session
   - Language cookie can be not secure, thus shared between `https://` and 
`http://` URL even when session is secured. Also language cookie can be 
shared between subdomains without necesity to share session data e.g. 
`admin.example.com` and `www.example.com`. This would actually need a new 
setting LANGUAGE_COOKIE_DOMAIN.

We do not use cache that much yet, so we have not encouter problems with 
that.

I do not actually see any reason for not storing language into cookie. It 
generally does not contain any private data, your language preferences are 
usually in your HTTP headers anyway or in cookies from other webs you 
visited lately.

Parameters of language cookie could be LANGUAGE_COOKIE_NAME, 
LANGUAGE_COOKIE_DOMAIN, not HTTPONLY and not SECURE. Remaining are path and 
age. Path might be fixed to '/'. So only remaining is age. Given that cookie 
does not contain any private data, it can be hardcoded for 1 year (or other 
reasonable time).

I also like possibility to override language cookie params using kwargs on 
set_language view.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/rN2LFvuSHQMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Mikoskay]

Yes, but obviously this is not going to be the blessed, default behavior.

--
Mikołaj Siedlarek


On Mon, Jun 27, 2011 at 3:15 PM, Max Arnold  wrote:

> Another approach is to store language in the url (useful for mobile
> handsets where disabled or unsupported cookies is still an issue).  Django
> app which uses this method: https://bitbucket.org/carljm/django-localeurl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/KD9VoA6u6sEJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Max Arnold]

Another approach is to store language in the url (useful for mobile handsets 
where disabled or unsupported cookies is still an issue).  Django app which 
uses this method: https://bitbucket.org/carljm/django-localeurl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/KD9VoA6u6sEJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Mikołaj S .]

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 not always a better idea than evolution, 
so Madis'es session-and-cookie storing is also an option for me, although I 
don't see how it could be useful.

If somebody has some arguments for session-based language storing, I'd see 
it gladly.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Madis]

Well we are actually not trying to address the issue on ticket #13217
I think. We are addressing the way language gets stored for the
client.
Because LocaleMiddleware checks for a session anyway. If it was
decided wontfix then doing it the way I supposed should be OK I think.

If I'm mistaken - please correct me.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Luke Plant]

On 26/04/11 14:21, Madis wrote:
> Well I think there is no need for another setting and I think there is
> no problem setting the lang twice - as then the cookie is not always
> accessed as it first checks for the language in the session. It only
> looks for it in the cookie if there is no session or the customer is
> returning to the site.
> So the cookie for language just lives there and is only looked in if
> there is no session available. It produces no overhead what so ever
> because set_lang is only called when changing languages.

This does not address the fact that accessing the session to check
causes a session to be created if it did not exist. This is what this
whole thread is about! See also the discussion on ticket #13217.

Luke

-- 
"I washed a sock. Then I put it in the dryer. When I took it out,
it was gone."  (Steven Wright)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Madis]

There is also a ticket here which proposes a patch -
http://code.djangoproject.com/ticket/14825
I used it last night - it also works but wont give the users the
freedom to choose if they want to set the lang cookie or not and also
adds overhead.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Madis]

Well I think there is no need for another setting and I think there is
no problem setting the lang twice - as then the cookie is not always
accessed as it first checks for the language in the session. It only
looks for it in the cookie if there is no session or the customer is
returning to the site.
So the cookie for language just lives there and is only looked in if
there is no session available. It produces no overhead what so ever
because set_lang is only called when changing languages.

And if you want set_lang to store the cookie also then just configure
it in your urls.py - then we dont need another setting also. This can
be documented and maybe many people wont even need this - or want this
as their clients manly speak English. This would then also be
backwards compatible.

Well and the possible downside of this approach is that some people
dont want the language_cookie stored because they consider this
private data (for whatever reason there might be). So giving them an
option to set the cookie is or not is always good.

Right now I rewrote the set_lang view for my app so the cookie is also
stored and expires after 1 year - it works perfect after logout or
when revisiting the site.
http://dpaste.com/hold/535886/
Right now I have no options to set it or not because I want to use it.
But it would be very easy to write it optional with options to also
set the cookie and expiration time/date.

One thought is that maybe when revisiting and the session is also
available the middleware should write the language from the cookie to
the session again - so there is no additional call to look in the
cookie.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Odp: Re: Storing language in session/cookie

[Mikołaj S .]

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 same 
issues that caused the WONTFIX on that ticket. This change would help that 
problem if the cache is able to cache by language cookie.

I'm not in favour of yet another setting if we can avoid it - we need to 
know if there are any downsides to always storing in the cookie rather than 
the session. If not, we always store in the cookie. Since we've documented 
the current behaviour, we may however need a deprecation path involving a 
setting.


So it's now about whether to be backwards compatible but add another setting 
and complicate things a bit, or not to be backwards compatible and move 
current language to separate cookie permanently.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Odp: Re: Storing language in session/cookie

[Mikołaj S .]

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 defaults to False for backwards compatibility. And when it's True, 
the current language is also saved in a separate cookie, no matter if there 
is a session enabled.

But I also wonder if it won't be unnecessarily redundant to have the 
language stored both in a cookie and a session.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Storing language in session/cookie

[Madis]

Well yes I think there is an issue here for sure. I think it would be
quite easy to solve this as follows - but I'm not sure if it's the
best approach.

There is a setting named LANGUAGE_COOKIE_NAME which never gets used if
you use session based cookies. The file cookie is just never saved.
But if there were an option to save data in the session and also save
the LANGUAGE_COOKIE as a file separately - then it would also persist
after logout and solve the issue with languages after the session gets
destroyed.

http://code.djangoproject.com/ticket/14825
I think this middleware fix only fixes things temporarily - and in the
long run you'd still want a persistent separate language cookie saved.


I would propose to have the set_language() view with options to set it
as a file based cookie or a session.
https://github.com/django/django/blob/master/django/views/i18n.py


It would allow the language file based cookie to have a very long
expire date and the session would still be usable for storing secure
data.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Storing language in session/cookie

[Mikołaj S .]

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, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Storing language in session/cookie

[Mikołaj S .]

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 http://code.djangoproject.com/ticket/13217 is the same problem 
but from the slightly different point of view. However it hasn't been 
solved,
the thread seems dead to me, but problem still exists.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Storing language in session/cookie

[Łukasz Rekucki]

2011/3/4 Mikołaj S. :
> 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 django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

Here are some tickets you might find interesting:

http://code.djangoproject.com/ticket/13217
http://code.djangoproject.com/ticket/12794
http://code.djangoproject.com/ticket/65

If you disable sessions, django will use a cookie to store the
language. If you have sessions enabled, then django checks the session
first which results in adding "Vary: Cookie" (even if it doesn't
contain any info).

I'm not an expert on caching, but even if you add a seperate cookie
for a language, but keep the sessions framework enabled, wouldn't that
still break caching ? After all the (session, language) cookie pair is
still unique and the "Vary" header doesn't let you name specific
cookies, AFAIK.


--
Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Storing language in session/cookie

[Mikołaj S .]

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 django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Storing language in session/cookie

[Paul McMillan]

I'm not familiar with that subsystem, but if what you say is correct,
you should open a ticket. That sounds like a definite issue to me.

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Storing language in session/cookie

[Mikołaj S .]

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 client, which makes serving static (ofc I 
mean static, but not media) content through an upstream
cache (such as Squid) really inefficient. I suppose selected language is not 
that secret to protect it by storing in session,
and cookie is just ok. For cookie-varying cache it's a huge difference.

I may be very wrong - in that case please just tell me what design concept 
lays behind this system. ;)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.