Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-14084

Fix wrong locale codes and solve alphabet problem

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: 3.10.1, 3.9.5, 4.0.1
    • Fix Version/s: Future
    • Component/s: Language
    • Labels:
      None
    • Environment:

      Operating System: All
      PHP Version: All
      Database and version: All
      Browser (and version): All

      Description

      Some locale codes in eZ Publish are wrong according to definition, see below. We should fix them. Note backwards compatibility - should we only deprecate them and make the new ones as copies?

      The current kernel does not allow us to code all locales correctly. This is what we currently support:
      language-COUNTRY.charset@countryvariation
      For example eng-GB.utf8@euro, which means english, as spoken in the UK, in the utf-8 charset, using the 'euro' countryvariation (presumably using the euro instead of GBP). Countryvariation is only used for locales. It can not be used when fetching translations. See eZLocale::localeInformation() and eZLocale->TranslationCode.

      For serbian, there are two translations, using the same language and country (srp-RS), but different alphabets (latin and serbian cyrillic). Charset is irrelevant here. Thus, we cannot support serbian using our current locale codes.

      Suggestions:
      1) Change the kernel code to support countryvariations in translation names (i.e. srp-RS and srp-RS@latin). Then we can keep the existing locale code rules.
      2) Change the locale code rules to allow variations in the language (i.e. srp-RS and srplatin-RS). Then we can keep the existing kernel code.
      3) Extend the locale code rules to include alphabets, i.e. language@alphabet-COUNTRY.charset@countryvariation or, to be backwards compatible: language-COUNTRY.charset@countryvariation@alphabet

      I like 1), it seems clean although this is not the originally intended purpose of countryvariations. We can make it backwards compatible by making it fall back to swe-SE when swe-SE@euro is not found among the translations.

      The following locale changes must be done to be consistent with the standards:

      cro-HR -> hrv-HR
      ell-GR -> gre-GR
      nor-NO -> nob-NO (Norwegian Bokmål) [1]
      ser-SR -> srp-RS@latin [2]
      cyr-SR -> srp-RS (Cyrillic)
      slk-SK -> slo-SK
      esl-ES -> spa-ES (Spanish, Castilian)

      Both SVN and ez.no must be updated. Furthermore, we must confirm that the locale variation syntax (srp-RS@latin) actually works with languages. So far it has AFAIK only been used for locales.

      ISO 639-2 (languages)
      http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes
      Following the bibliographic (B) rather than the terminology (T) here, i.e. for chinese, "chi" rather than "zho".

      ISO 3166-1-alpha-2 (countries)
      http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

      [1]
      There is no single standard norwegian, so nor-NO should not be used.
      http://en.wikipedia.org/wiki/Norwegian_language

      [2] Cyrillic is the official script:
      http://en.wikipedia.org/wiki/Serbian_language#Writing_systems

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              gl (inactive) Gunnstein Lye
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated: