KLocale porting
Open, Needs TriagePublic

Description

There seems to be quite a few users of KLocale functions that do not have equivalents outside KDELibs4Support. E.g. countryCodeToName (https://api.kde.org/frameworks/kdelibs4support/html/classKLocale.html#a0ecb21950b7e94a3cb7f1ab256019de1) to get Country X in Language Y (Qt offers Country X in Language X or Country X in English).

iso-codes project seems to have necessary data in json format. KContacts already use some of it (it contains a generator that reads json and produces .cpp file with data that is pre-committed to repository). But that's not very scalable...

See also: https://api.kde.org/frameworks/kconfigwidgets/html/classKLanguageName.html

stikonas created this task.Dec 27 2019, 1:10 AM

It might make sense to collect all those iso-codes or CLDR consuming functions in e.g. KI18n and share them there? Whether that's then implemented by runtime reading iso-codes data, or compiling in the subset we need is secondary IMHO. KContacts is also only a rather accidental place for this I think.

stikonas added a subscriber: adridg.EditedDec 27 2019, 11:53 AM

It might make sense to collect all those iso-codes or CLDR consuming functions in e.g. KI18n and share them there? Whether that's then implemented by runtime reading iso-codes data, or compiling in the subset we need is secondary IMHO. KContacts is also only a rather accidental place for this I think.

Yes, I agree that KI18n is a natural place for this.

I'm not against compiling in the subset that we need as long as it's done in a single place and does not get too much out of date. But indeed this is a secondary question.

I guess the first thing is to decide what data we need.

  • Country names
  • Language names? (KLanguageName is part of KConfigWidgets but maybe it is better to keep everything in one place)
  • Timezone names? (@adridg was interested in this, possibly needed by plasma timezone selector too)

Anything else?

KContacts (and KItinerary, which heavily uses this) does need mapping of ISO 3166-1 alpha 2 codes to localized country names, and more difficult, the opposite: mapping from localized country names (and possibly not written in perfect unicode but some translitarion) to ISO 3166-1 alpha 2 codes. The first can be done at runtime from iso-codes, the latter needs CLDR. In both cases performance matters a lot (this is used eg. in list views), so we need to be a bit more clever than parsing JSON/XML at every call.

For KItinerary ISO 3166-2 region code mapping in both ways is also of interest eventually.