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.