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