[Development] QLocale changes

[John Layt]

Hi,

Following on from my QDateTime changes to QLocale, there's a few other areas I 
want to look into.

1) The following methods currently return QChar and as noted in the code need 
to change to QString:

    // ### Qt 5: We need to return QString from these function since
    //           unicode data contains several characters for these fields.
    QChar decimalPoint() const;
    QChar groupSeparator() const;
    QChar percent() const;
    QChar zeroDigit() const;
    QChar negativeSign() const;
    QChar positiveSign() const;
    QChar exponential() const;

I've started on this, but run into the problem that these methods are used in 
the number parsers which operate a QChar at a time.  I would have to modify or 
rewrite the parsers which is no small task, but the api change needs to be 
done for 5.0.  An interim step might be to change the api to QString now but 
still only return the current 1 char values until the parsers can be adapted.

2) While doing (1), I could also add support for the System/CLDR values for 
NAN, Infinity and Per Mille which are currently hard-coded.
2) Local Week Number systems, i.e US weeks
3) Numbering Systems (aka Digit Sets in KDE)
4) Change MeasurementSystem to use the supplemental CLDR data
5) Change default country for language to use the CLDR LanguageMatching data
6) Clean up QSystemLocale platform implementations to have more consistent 
style, more complete support

Of these only 1) really needs to happen for 5.0.

Now for the KDE wishlist.

For KDE Frameworks 5 we want to switch to using QLocale, and QLocale now meets 
our requirements except for the key ability for our users to modify individual 
locale settings.  While we can write a custom QSystemLocale to load the KDE 
settings, there is no way to query all the current settings to show them to 
the user in System Settings.

At QtCS I briefly discussed this with Denis and also QSystemLocale which 
neither of us are too happy with.  Denis indicated he was open to a different 
approach for QSystemLocale and KDE settings so long as QLocale itself was kept 
clean and simple for apps, i.e. no getters or setters for all the settings.

Currently we have QLocale which is mostly formatters/parsers with a few 
methods to return certain settings, but many settings are not exposed.  We 
then have QSystemLocale which returns what the current host system settings 
are where supported.  QLocale first queries QSystemLocale for settings and if 
none is returned then falls back to the CLDR settings.  If not using the 
default system locale, or support is disabled, then QSystemLocale is not 
queried and the CLDR values are always used

The problem with QSystemLocale is it only tells you what the system locale 
setting for something is, and only if that setting is supported, but not what 
the CLDR fallback value is, which means KDE will be unable to query for the 
values it wants.

I see two possible solutions:
1) Have QSystemLocale return the CLDR setting if it doesn't find or support 
the system setting, or have a QSystemLocale just for CLDR.
2) Have a new QLocaleSettings class that returns either the system or CLDR 
value as appopriate.

The big problem with 1) is that QSystemLocale is an optional feature so moving 
all the CLDR look-up code there would break things, and I wouldn't want to 
duplicate code either.  Also it's not a nice api.

Option 2) would probably look like this:

* QLocale is the app facing api providing just those methods an average app 
needs to use, i.e. mostly just formatters and parsers like toString() and 
toInt() and not the format settings like decimalPoint().  It also keeps the 
locale name/code parts, i.e. Language, Country, etc.

* QLocaleSettings is the platform facing api for those few people who need it 
(i.e. KDE System Settings module, some specialised apps).  This provides 
direct api access to each setting like decimalPoint().  All the CLDR lookup 
code gets moved here, and a method first looks up the QSystemLocale value if 
enabled before defaulting to the CLDR value if needed.  QLocale calls these 
methods when it needs to find out what setting to use.  QLocale also provides 
a method to access the current QLocaleSettings it is using.  Effectively it's 
QLocale with the parser/fomatters removed and a new setitngs api added.

* QSystemLocale remains the same, using the virtual query() method and enum to 
return the system setting, just extended over time with more settings.

The down side here is it adds a slightly unnecessary layer to everything.

Thoughts?

Jhn.