Thanks!

I agree, this is better.

My submission to the main program got accepted, but downgraded to a lightning talk. No result yet from the privacy dev room.

Awesome, thanks!

Longer term we probably either want to convince upstream to install cmake config files, or at least have this in ECM, a quick local grep find a handful of copies of this.

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.

Thanks!

Thanks! Test data is always a good idea to prevent this breaking on engine changes. For plain text it might even be possible to create a synthetic one to add to the extractor tests in this repo, but that's not a blocker.

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.