TYPO3.Flow

my two cents to this; there may be even a locale determiner mechanism that goes through a chain of LocaleDeterminers (?), each with a priority, and takes the best matching one.
Similar patterns are already used for the RequestHandling or TypeConverters etc.

So, at the base distribution for example, an HttpRequestLocaleDeterminer could be shipped out, that tries to get the most appropriate locale from the request header.
Developers can adapt this to more Determiners that e.g. fetch the right locale from the settings of a logged-in user.

Adrian, that's more or less what I was thinking of ;)

For me, the chain would be (highest priority first): URL -> cookie -> user settings -> HTTP headers

Not to forget, we need to have a way of inserting the locale into URLs if it has been set via the URL. Otherwise we will either loose the locale on the next request or need to put it into a cookie, but then the alternative locales might not be available for search engines.

The most obvious place for this would be the URI builder, but this might pose other problems, e.g. how to reset the locale or set another one.

well, that's a question that must be discussed really well. My very humble opinion is, that the language should not be part of the latter part of the URI. I'd prefer going a subdomain way for example. That would also satisfy the idea of an URI being a locator to a "thing", no matter in what language that thing is represented. The representation is decoupled and set into the subdomain, for example.
If a user/developer does not want it for "marketing" purposes, he should handle that of himself.
Both building the route and analyzing the route must take care of that language then; using the subdomain wouldn't affect the building of the links.

@Adrian: The correct way would then be to not have subdomains, but full TLDs for each locale/language used (hierarchy of domain names). That's too much of an requirement IMO, so I guess it would be best to support both locale in (sub)domain names as well as URI parts, even though it's (much) more work.

If a user/developer does not want it for "marketing" purposes, he should handle that of himself.

In many projects such decisions are not made by the developer, so we should really spare him of the blame and instead help him get his job done ;)

As a side-note, when selecting locale from HTTP headers the response should also send the matching "Vary: Accept-Language" headers to allow caching proxies to handle this case properly.

Any comments on the patch I pushed to Gerrit? I'm using this in a project for quite a while now and so far it works as expected (though not in a production environment currently).

Andreas Wolf wrote:

Any comments on the patch I pushed to Gerrit?

Given the WIP status and the list of todos I am not really surprised this has not received any feedback so far… and we were pretty busy with 1.1.

Karsten Dambekalns wrote:

Andreas Wolf wrote:

Any comments on the patch I pushed to Gerrit?

Given the WIP status and the list of todos I am not really surprised this has not received any feedback so far… and we were pretty busy with 1.1.

I don't want to remove the WIP as long as I don't feel it's ready for commit, but some feedback on the general direction would be nice before I invest more time into polishing it ;-)