Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-8709

Allow use of IETF Language Tags

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Done
    • Icon: Normal Normal
    • 6.3.0
    • 6.2.27
    • i18n
    • None
    • 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.

      The language subtag registry.

      Unicode Technical Standard #35

        Acceptance criteria

              mdivilek Milan Divilek
              mgeljic Mikaël Geljić
              DeveloperX
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved:
                Work Started:

                  Task DoD

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Remaining Estimate - Not Specified
                    Not Specified
                    Logged:
                    Time Spent - 1h
                    1h