Feature #35030

Dynamic locale detection

Added by Andreas Wolf over 9 years ago. Updated about 8 years ago.

Status:
Under Review
Priority:
Should have
Category:
I18n
Target version:
-
Start date:
2012-03-20
Due date:
% Done:

0%

Estimated time:
PHP Version:
Has patch:
No
Complexity:
medium

Description

Currently, the locale is automatically set to "en". It is however possible to manually set the locale to something else.

There should be a way to set the locale manually in a configurable way. Possible sources are: the HTTP "accept language" header, the URL (sth. like "/en/path/to/page.html"), a cookie (after the user manually set the locale) or some user setting.


Related issues

Related to TYPO3 Flow Base Distribution - Story #42408: Locale Detection / SelectionNew2013-06-11

Actions
Has duplicate TYPO3.Flow - Task #49025: Dynamic locale detection / determinationUnder ReviewAdrian Föder2013-06-11

Actions
#1

Updated by Adrian Föder over 9 years ago

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.

#2

Updated by Andreas Wolf over 9 years ago

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

#3

Updated by Andreas Wolf over 9 years ago

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.

#4

Updated by Adrian Föder over 9 years ago

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.

#5

Updated by Alexander Berl over 9 years ago

@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 ;)

#6

Updated by Karsten Dambekalns over 9 years ago

  • Status changed from New to Accepted
  • Assignee set to Karsten Dambekalns
  • Target version set to 1.1

We'd love to nail this for I18n, so keep your ideas coming. Also make sure to check the locale chain configuration in master for an important building block of this.

#7

Updated by Alexander Berl over 9 years ago

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.

#8

Updated by Karsten Dambekalns over 9 years ago

  • Target version changed from 1.1 to 2.0 beta 1
#9

Updated by Gerrit Code Review over 9 years ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/11443

#10

Updated by Andreas Wolf over 9 years ago

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).

#11

Updated by Karsten Dambekalns over 9 years ago

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.

#12

Updated by Andreas Wolf over 9 years ago

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 ;-)

#13

Updated by Karsten Dambekalns almost 9 years ago

  • Target version changed from 2.0 beta 1 to 2.1
#14

Updated by Robert Lemke over 8 years ago

  • Target version deleted (2.1)

Also available in: Atom PDF