Archived

forked from https://github.com/symfony/symfony

This repository has been archived on 2023-08-20. You can view files and clone it, but cannot push or open issues or pull requests.

Go to file

Fabien Potencier 81fe2ff8e2 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.		2012-07-02 12:37:57 +02:00
src/Symfony	merged branch fabpot/locale-listener (PR #4692 )	2012-07-02 12:37:57 +02:00
.editorconfig	Add EditorConfig File	2012-06-16 14:08:15 +02:00
.gitignore	ignore composer.phar	2012-04-20 14:10:06 +01:00
.travis.yml	merged 2.0	2012-05-30 13:44:37 +02:00
autoload.php.dist	removed unneeded code	2012-06-30 16:47:41 +02:00
CHANGELOG-2.0.md	updated CHANGELOG for 2.0.14	2012-05-17 18:29:55 +02:00
composer.json	merged 2.0	2012-06-20 21:33:33 +02:00
CONTRIBUTORS.md	update CONTRIBUTORS for 2.0.14	2012-05-17 18:30:22 +02:00
LICENSE	Updated LICENSE files copyright	2012-02-22 10:10:37 +01:00
phpunit.xml.dist	Set init.default_locale to 'en' in phpunit.xml.dist	2012-05-11 09:33:42 +02:00
README.md	updated minimum PHP version to 5.3.3	2012-05-07 10:29:11 +02:00
UPGRADE-2.1.md	merged branch fabpot/locale-listener (PR #4692 )	2012-07-02 12:37:57 +02:00

README.md

README

What is Symfony2?

Symfony2 is a PHP 5.3 full-stack web framework. It is written with speed and flexibility in mind. It allows developers to build better and easy to maintain websites with PHP.

Symfony can be used to develop all kind of websites, from your personal blog to high traffic ones like Dailymotion or Yahoo! Answers.

Requirements

Symfony2 is only supported on PHP 5.3.3 and up.

Installation

The best way to install Symfony2 is to download the Symfony Standard Edition available at http://symfony.com/download.

Documentation

The "Quick Tour" tutorial gives you a first feeling of the framework. If, like us, you think that Symfony2 can help speed up your development and take the quality of your work to the next level, read the official Symfony2 documentation.

Contributing

Symfony2 is an open source, community-driven project. If you'd like to contribute, please read the Contributing Code part of the documentation. If you're submitting a pull request, please follow the guidelines in the Submitting a Patch section.