Proposal to improve support for ISO 3166 Country Codes in KLocale

[Albert Astals Cid]

A Dijous, 4 de febrer de 2010, John Layt va escriure:
> [cc: to Marble, Edu, and i18n lists for comment, please try reply to k-c-d
>  to keep thread in one place]
> 
> I would like to propose improving our support for the ISO 3166 Country Code
> standard (http://en.wikipedia.org/wiki/ISO_3166) in two areas.
> 
> Firstly, some apps need to translate between the alpha 2, alpha 3 and
>  numeric forms of the code, e.g. the EXIF standard uses alpha 3 codes, but
>  KDE uses alpha 2 for example when fetching the translated country name to
>  display.
> 
> Secondly, some libraries and apps would like to use the subdivision codes
>  as provided by ISO 3166-2 (http://en.wikipedia.org/wiki/ISO_3166-2), e.g.
>  KHolidays wants to know a users state or province to know which regional
>  holidays to display.  Other users could be Marble, KGeography, etc.
> 
> While it would be easy to add the alpha 3 code to each locale's .desktop
>  file, this would be inefficient on a one-off look-up (reading 100 files
>  each time on average), so I was initially thinking a static table loaded
>  from a file would work better.
> 
> The subdivisions, however, with some 4200 codes currently defined, could
> quickly become a support and translation nightmare.
> 
> Fortunately, there exists the iso-codes project (http://pkg-
> isocodes.alioth.debian.org/) which provides the ISO 639 Language Codes, ISO
> 3166 Country Codes, ISO 4217 Currency Codes, and ISO 15924 Script Codes in
>  XML files, along with translations into some 38 languages.
> 
> I propose that we depend on iso-codes, use the 3166 xml file as the source
>  for a code conversion method, and use the 3166-2 xml file as a source for
>  the subdivision codes.  The package appears in every major distro I've
>  looked at.
> 
> My big question is over translations.  The XML file contains subdivision
>  names in their local version, so even en_US would require translating.  I
>  assume we would be able to use the provided translations, or would we have
>  to do our own?  

Depends on how translations are provided and what you want to do with them. 
Please elaborate.

>  In either event, not all KDE supported languages are
>  included in iso- codes, would we be able to mix their translations and our
>  own?  Or would we prefer to do our own for all languages?

If we are going to use an external dependency, that dependency must accept 
translations, we have own translations for some not friendly projects like Qt 
or xscreensaver but i would object to having a new dependency that does not 
accept translations from our translators.

> Obviously it's not fair to demand all 4200 subdivisions be translated into
> every language.  I would propose instead we would only require they are
> available in English and their country's language(s).  It would then be at
> each translation team's discretion as to which other codes they translate,
> i.e. I'd expect neighbouring countries and US States to be a popular
>  target, but New Zealand regions not so much.

You can't demand anything since it's an external dependency so we don't have a 
control over its translations (if you follow my suggestion, that's it :D)

> Besides KLocale providing access methods, System Settings would allow
> selection of the users default subdivision.  We could also in theory
>  provide locale files for any country subdivision with localisation
>  standards that differ from the rest of the country.

No, upstream them, if you are going to use a package, use it, don't start 
shipping custom files for it just because you can.

And if the package is orphaned or the maintainer sucks, don't use it.

Albert

> 
> Thoughts?  Any possible problems?  Has anyone looked at using these files
>  in the past?  Any suggestions on alternative sources for the codes or
>  translations (GeoNames?), or other uses in KDE?  Any demand out there for
>  support of the US standard FIPS codes as well?
> 
> Cheers!
> 
> John.
> 
> P.S. Wish I'd known about this when doing currency codes, although it
>  doesn't have all the details we support the translations would have been
>  handy :-)
>