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

Fix wrong locale codes and solve alphabet problem

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Medium 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

        Issue Links

          Activity

          Hide
          Kristof Coomans added a comment -

          Patch that implements suggestion 1). Patch for #14007 is also incorporated in this patch.

          One thing still to do if this is the patch we go for: deprecate eZLocale::translationCode() (and check if any other code is still using it).issue_14084_eztstranslator_i18n_trunk.patch

          Show
          Kristof Coomans added a comment - Patch that implements suggestion 1). Patch for #14007 is also incorporated in this patch. One thing still to do if this is the patch we go for: deprecate eZLocale::translationCode() (and check if any other code is still using it). issue_14084_eztstranslator_i18n_trunk.patch
          Hide
          Kristof Coomans added a comment -

          In reply to comment #022036
          I moved this into a separate enhancement: http://issues.ez.no/14089

          Show
          Kristof Coomans added a comment - In reply to comment #022036 I moved this into a separate enhancement: http://issues.ez.no/14089
          Hide
          Paul Borgermans added a comment -

          Since http://issues.ez.no/14089 implements 1) (the preferred solution)

          and also a scan reveals no further use of eZLocale::translationCode() it may be all be done

          So moving to future for a final decision

          Show
          Paul Borgermans added a comment - Since http://issues.ez.no/14089 implements 1) (the preferred solution) and also a scan reveals no further use of eZLocale::translationCode() it may be all be done So moving to future for a final decision

            People

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

              Dates

              • Created:
                Updated: