ezpublish-legacy
ezpublish-legacy copied to clipboard
Fix EZP-19856: [HTTP].ContentLanguage settings in locale files updated; ...
...closes #671
I tried to to simplify ContentLanguage codes using IANA (http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) document and W3C recommendations (http://www.w3.org/International/questions/qa-choosing-language-tags). Not all have been shortened to 2 characters.
For the possible discussion: I had doubts about (* means chosen):
*zh-CN or zh or cmn or zh-Hans (China)
*es-ES or es-ES (Spain)
*es-MX or es-419 (Mexico)
*fr or fr-BE (wikipedia http://en.wikipedia.org/wiki/Belgian_French sais "Belgian French and the French of northern France are almost identical, but there are a few distinct phonological and lexical differences.") (Belgium)
*fr-CA or fr (Canada)
*pt-MZ or pt (Mozambique)
*sr-Latn and *sr-Cyrl or sr (Serbia)
+1 About the "edge cases" - as long as end users can easily configure this in their own installations, it's fine.
Hi,
Just opened a dupplicate PR yesterday, I just want to add some feedback.
It seems important to me to set the country if a language is used in more than one country (like French, German, Dutch, Spanish...)
I might be wrong, but I consider this ContentLanguage parameter just the same as the lang attribute of your <html> tag (which also could be used in alternate hreflang tags). In that case, specifying the target country seems to be important (because the Swiss version of your website might not have the same contents, not to mention currency and prices).
What do you think ? Since this PR has been open for two years, I suppose it is not as obvious as it might seem...
In document Language tags in HTML and XML you may read:
The golden rule when creating language tags is to keep the tag as short as possible. Avoid region, script or other subtags except where they add useful distinguishing information. For instance, use
jafor Japanese and notja-JP, unless there is a particular reason that you need to say that this is Japanese as spoken in Japan, rather than elsewhere.
With english and german is not that obvious. I understand this way:
Use de instead of de-DE when you provide only one german localization not directed to specific country, dialect or market (i.e. "international").
I think you could use de even for Austrian website, if it uses an official german dialekt.
I assume the same with english and other languages.
Otherwise you could never have a chance to use en, de, es, ... values.
Sometimes the flag icon may be inadequate for international localization (should I use UK or US flag), but this another issue (also raised in the Internet).
Allright, so are you saying this question should be handled manually for each eZ installation, depending on the languages used ?
About the en value, we recently used it to describe an english landing page (en) that only had a list of all availables languages (including en-GB). I suppose the same logic could be used by a french website having customers in France, Switzerland and Belgium and wanting to have a country-selection page ?
The golden rule when creating language tags is to keep the tag as short as possible
On the other hand, it looks like systems are able to match specific language-country markers as simple language markers, but not the opposite, see http://www.w3.org/International/articles/language-tags/#matching :
According to BCP 47
encan be said to matchen-GB.
My best guess is to have simple language value for languages that are spoken in only one country (ja not ja-JP, el not el-GR, ...) and language that are spoken in several countries as complex tags (fr-BE, fr-CH, fr-FR for example).
Perhaps a more inclusive solution would be "international" languages. Adding a new "International English" ini in /share/locale enables the user to determine whether he uses international language (en) or country-specific language (en-GB) on a fresh install. It avoids making any edit in the /share/locale folder.
It also enables every english-speaking country (US, UK, IE...) to inherit from the international english and modify or add specific content in its own sublanguage.
The drawbacks I see in this solution are
- Complexity it might introduce on a fresh install (which language should the admin pick ?)
- Flag used to describe the notion of "international english", "International Spanish" and so on...