-
Improvement
-
Resolution: Done
-
Normal
-
6.2.27
-
None
-
-
Empty show more show less
-
Yes
-
Yes
-
Yes
Magnolia does not support IETF Language Tags (also known as BCP 47) as languages configuration. IETF Language Tags are used in most web standards, and allow for more flexible and semantically accurate representation of language variations and local specificities.
Historically, Magnolia languages can only be configured 1:1 according to Java Locale constructs, i.e. by their respective ISO language and country codes.
Proposed solution
Support a more permissive languageTag property in languages configuration, aka LocaleDefinitions. Then we can pass that to the BCP 47-interoperable factory method Locale#forLanguageTag, instead of using the plain Locale constructor.
See full research notes on Locales and IETF Language Tags.
Original Description
reported by chris.jennings
Finer Handling of Locales
As a provider of content across the globe, I would like finer handling of locales.
Magnolia's concept of locales revolves around the pattern of two letter language code and two letter country code. ie. en_GB v en_US or de_CH v de_DE.
This does not account for languages with different scripts such as Chinese which as zh is available as Simplified Chinese and Traditional Chinese.
Making these available using currently available techniques fails.
The locale in the URL is validated using the isLocaleValid class which is given a locale object created by parsing the URL in to "language_country" in Abstracti18nContentSupport.
The result is no way of signalling to Magnolia that zh_HANS or zh_HANT is my locale. A combination of language and optional country is always assumed with no space for script.
Notes
Supported Locales Java 11 - https://www.oracle.com/java/technologies/javase/jdk11-suported-locales.html
There is also this library https://javadoc.io/static/com.neovisionaries/nv-i18n/1.2/com/neovisionaries/i18n/CountryCode.html which conforms to the ISO 3166-1 country code (See ISO 3166 Country Codes).
Would it be possible to make the library or lookup class configurable? I think in most cases what comes with the JVM is enough but perhaps I'd like to use a library which covers more codes or even use my own custom library.
Another layer is the corner case of "variant subtags". Consider Valencian where the IETF says:
Not all linguistic regions can be represented with a valid region subtag: the subnational regional dialects of a primary language are registered as variant subtags. For example, the valencia variant subtag for the Valencian variant of the Catalan is registered in the Language Subtag Registry with the prefix ca. As this dialect is spoken almost exclusively in Spain, the region subtag ES can normally be omitted.
- is related to
-
MULTISITE-191 Page editor doesn't resolve correctly site and fallbacks to "fallback" one
- Closed
-
MGNLUI-8766 Locale selector doesn't reflect changes in site i18n setting
- Closed
- relates to
-
MAGNOLIA-8229 Non JVM-default Locales are not used in I18n
- Closed
-
MAGNOLIA-7897 Provide Compatibility And Documentation for Changing Java 7 Locale Names To Java 8
- Closed
-
MAGNOLIA-8733 Add Locale variant support to I18nContentSupport
- Open
-
MAGNOLIA-8667 Allow variants of locales in i18n configuration
- Closed
-
MGNLDEMO-429 Use IETF language tags in demo
- Closed
-
MGNLREST-797 Let I18nContentSupport determine the locale from lang parameter
- Closed
-
MGNLUI-8809 Take item into account when resolving localized property name in I18NAuthoringSupport
- Closed
- to be documented by
-
MAGNOLIA-9289 DOC: Using IETF Language Tags
- Accepted
- links to