Feature #7720

Implement automatic locale detection

Added by Karol Gusak about 11 years ago. Updated almost 11 years ago.

Status:
Resolved
Priority:
Must have
Assignee:
Category:
I18n
Target version:
-
Start date:
Due date:
% Done:

100%

Estimated time:
PHP Version:
Has patch:
Complexity:

Description

Locale detection can be done in web application framework in three ways:
  • using HTTP "Accept-Language" header
  • using user preference from cookies (if he already was visiting our website)
  • by letting user choose preferred locale by UI

All these methods will be supported by i18n / l10n subsystem.


Related issues

Related to TYPO3.Flow - Feature #6724: Internationalization, locale, multi-language ect.ResolvedKarol Gusak

Actions
#1

Updated by Karol Gusak about 11 years ago

  • Priority changed from Should have to Must have
#2

Updated by Karol Gusak about 11 years ago

  • Status changed from New to Needs Feedback
  • % Done changed from 0 to 50

The commit in Revision 4308 was done mainly for the record. I plan to reimplement this part anyway in order to use tree of Locales (not array of Locales), as there should be a hierarchical relation between Locales, as it was planned.

Also, I'm unsure about the directory structure for locales. I planned to support directories named as locale identifiers, in [Package]/Resources/Private/Locale and Public/Locale folders, eg:
FLOW3/Resources/Private/Locale/en_GB
FLOW3/Resources/Public/Locale/ru_Cyryl_RU
... etc

Different classes would interpret how the structure in these folders looks like (eg translation messages under the private path, and locale-dependent images under the public path).

This seems pretty clear structure for me. But on other hand, where to place the CLDR data folder (and maybe others in the future too)? As for now it's in FLOW3/Resources/Private/Locale/CLDR so it would be interpreted as a locale folder. I thought about a "root" folder which would be the special case ("root" in general is used in CLDR so it probably will be needed in some logic anyway).

What do you think about that?

#3

Updated by Karol Gusak about 11 years ago

  • % Done changed from 50 to 90

I rewrote the Detector class and implemented a LocaleTree class, which represents all available locales in a tree structure and provides convenient methods to obtain best-matching locales etc. More tests need to be written, but as for now all seems to work as expected ;-).

This issue is almost done, I need a response for my last update's questions. I also not sure yet how to make the framework to automatically provide the default Locale object on start.

#4

Updated by Karsten Dambekalns about 11 years ago

  • Status changed from Needs Feedback to Accepted
I just discussed this with Robert and we would opt for a different solution:
  • all files should be localizable (graphics, css, translations, templates, ...)
  • to do that provide a service you can ask for a localized version to a filename
  • translation code, resource handling, ... would use that service
  • locale identifiers are embedded in filenames, so no folders for that purpose (foobar.png, foobar.en.png, foobar.en_GB.png)
    That would solve the "Locale" folder name clash as well. As for a folder that contains label translations a name like "Labels" or "Translations" would be better than "Locale" as well, because it's not a locale in there.
#5

Updated by Karol Gusak about 11 years ago

Removed the tree as k-fish said (now there are just two arrays :-) ). Implemented the idea with locale resources. I think it's almost all for this issue (needs to cache result of filesystem scanning for locale detection yet).

#6

Updated by Karol Gusak about 11 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 90 to 100

Also available in: Atom PDF