[HttpKernel] removed the storage of the current locale in the session

Before this commit, the current locale was stored in the session (if one
was already started). That way, for the next requests, even if the
request locale attribute was not set, the locale was "restored".

But this is a really bad practice as it means that the same URL can have
a different content depending on the previous requests. It would have
been better if the Vary header was set but the locale can be different
from the value coming from the Accept-Language anyway.

This is a BC break but fortunately, you can restore the 2.0 behavior by
creating a simple event listener that contains the logic removed by this
commit.
merged branch fabpot/locale-listener (PR #4692)

Commits
-------

88caf3a [HttpKernel] removed the storage of the current locale in the session

Discussion
----------

[HttpKernel] removed the storage of the current locale in the session

Before this commit, the current locale was stored in the session (if one
was already started). That way, for the next requests, even if the
request locale attribute was not set, the locale was "restored".

But this is a really bad practice as it means that the same URL can have
a different content depending on the previous requests. It would have
been better if the Vary header was set but the locale can be different
from the value coming from the Accept-Language anyway.

This is a BC break but fortunately, you can restore the 2.0 behavior by
creating a simple event listener that contains the logic removed by this
commit.

---------------------------------------------------------------------------

by travisbot at 2012-07-01T06:56:48Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1748659) (merged 009e30f0 into 2e356c1a).

---------------------------------------------------------------------------

by schmittjoh at 2012-07-01T08:15:46Z

How about using a cookie instead? It would remove the BC break, and also be possible to use a vary header?

---------------------------------------------------------------------------

by fabpot at 2012-07-01T09:13:44Z

The goal is to make Symfony as stateless as possible; introducing a cookie would defeat this goal.

---------------------------------------------------------------------------

by drak at 2012-07-01T09:19:37Z

@fabpot - thank you for bringing this to attention. I was meaning to do it a long time ago. The requested language is entirely a per request issue and must always be so. URLs must only ever return one content, and not multiple (e.g. different languages). The correct way to behave is to detect the language based on URL and failing that where a language is not requested, to look at the preferred language from the browser request and if available it can be redirected to that resource (e.g. /fr). This is what we do in Zikula. We have a further session based setting for "preferred language" which if set will override the browser default.

In summary:

1. If the language is specified in the GET request, return that language always. E.g. domain.com/fr/foo should return a French version of foo

2. If no language is specified in the GET request: first check the session for a preferred language, otherwise check the browser string for the preferred language and then if necessary, redirect to that resource. We have a setting which additionally say "always have language in URL, and don't put language code in URL for default language"

This means what in Zikula we only ever have one URL per language version of a page, but it still allows for users to set their preferred language which is taken in to account mainly when they visit the homepage (but in fact any page without a specific language in the request).

---------------------------------------------------------------------------

by drak at 2012-07-01T09:38:06Z

+1 on this PR. Basically the request locale should be in the Request object and calculated according to the applications preferences.

---------------------------------------------------------------------------

by schmittjoh at 2012-07-01T12:38:25Z

I agree that content must be detected based on the request, but I strongly disagree with relying entirely on the URL.

@fabpot, if you think about it using a cookie would still be stateless. There would be no state whatsoever, the detection would be entirely based on the request. Whether the language information is transmitted in the URL or as part of request headers is for the developer to decide eventually, at least IMO. My suggestion would just provide a default which is more BC.

---------------------------------------------------------------------------

by drak at 2012-07-01T20:08:50Z

@schmittjoh it's not entirely from the URL, there are browser preferences and also user defaults ca nalso available but the latter is slightly higher level. IMO it's not really Symfony's job here, it's application level specific. We have a pretty good working example of that in Zikula. Anyone can easily implement your own requirements with a listener.

What is absolutely clear however is it is wrong for one URL to deliver more than one version of any content.

---------------------------------------------------------------------------

by schmittjoh at 2012-07-01T21:16:52Z

I'm 100% for this change. My suggestion would just be more BC while still keeping Symfony2 stateless. Of course, it can be easily implemented in userland if we do not care about BC here.

Regarding different URLs per content, I do not think that this is our decision to make. Generally, developers should be able to make whatever content negotation they see fit. Whether they rely solely on the URL, or also take other request headers into account should not be limited by Symfony2.

---------------------------------------------------------------------------

by fabpot at 2012-07-02T10:37:26Z

I've added a paragraph in the UPGRADE file with a listener example that can be used to keep BC.