Qt5 Locale and Date / Time (and apologies)

[John Layt]

On Friday 20 Jan 2012 21:16:32 Chusslove Illich wrote:
> I have two general questions on relation between locale and translation.
> 
> The current (KDE 4) state is that elements of locale system require a
> translation system, and elements of translation system require a locale
> system.

The circular dependency was something I broke a few times during development, 
it was tricky to stop it causing problems.  With ICU this goes away.

The way this will now work is for all date/time translations will be sourced 
from ICU which has them hard coded in CLDR.  API in QLocale will provide 
access to this.  Originally the Qt parsers/formatters would then use this, but 
now with the ICU backend doing that it's all handled internally in ICU.

While initially this would mean we have no influence over the translations 
used, I am looking at ways that we could "inject" our own KDE locale file into 
ICU to force it to use our settings, but that's a research project for now.

We will lose something here, I believe the Arabic dates/numbers are scripted 
depending on country, we will lose that ability but hopefully ICU already 
takes care of that.

> This brings up the second question: current KDE feature of freely combining
> country and language selection, for a (supposedly) sensible result.

This will be a little different than in KDE4, but hopefully not too much.  ICU 
appears to also have the concept of mixing and matching, but if your requested 
combination of language and country is not actually available it then tries to 
find the closest match.  It's the same system as currently used in Qt4 QLocale 
because it uses the same CLDR data to do so.

It also does a lot of other fallback stuff if certain CLDR fields haven't been 
included in your selected locale, i.e. if you have de_AT and it doesn't have 
translations for the Coptic calendar, it will check in de before trying en.

> I would only let the translation system still refer to locale (for number
> formatting, and anything else convenient), since that basically comes for
> free if the translation system will be a tier 2 component, as I plan it to
> be.

That sounds pretty much how it will (hopefully) work: translation will depend 
on QLocale, QLocale will have no requirement to call translation as ICU will 
provide that.  Tier 1 libraries should have little need for translation, but 
if they do it should be fairly basic so tr() should suffice.

Cheers!

John.

John.