Proposal to improve support for ISO 3166 Country Codes in KLocale

[Freek de Kruijf]

Op zaterdag 6 februari 2010 06:35:24 schreef 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.

Translation are done in the translationproject.org, which has strong relations 
with the Free Software Foundation. Currently there are 83 different teams, 
each representing a language.
 
> >  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.

If it is made clear that KDE depends on translations for the 6 iso-packages in 
this project, and translators are encouraged to participate in this project, 
it finally will save a lot of translation work, because in this case 
translation needs to be done only once. Although iso-639_3 could be excluded, 
it contains codes and names for 7699 languages, so far identified.

> > 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.

So far these iso-packages are maintained very well, as soon as the iso 
standard has additions, shortly after that the iso files reflect these 
changes.

> 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 :-)
> 

-- 
fr.gr.

Freek de Kruijf