ezpublish-legacy icon indicating copy to clipboard operation
ezpublish-legacy copied to clipboard

Fix EZP-19856: [HTTP].ContentLanguage settings in locale files updated; ...

Open trolek opened this issue 12 years ago • 4 comments

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

trolek avatar Jul 02 '13 21:07 trolek

+1 About the "edge cases" - as long as end users can easily configure this in their own installations, it's fine.

gggeek avatar Oct 21 '13 12:10 gggeek

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

ghost avatar May 22 '15 07:05 ghost

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 ja for Japanese and not ja-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).

trolek avatar May 22 '15 09:05 trolek

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 en can be said to match en-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...

ghost avatar May 22 '15 10:05 ghost