Locale in KF5 / Qt5

[John Layt]

Hi,

I want to propose a plan for KLocale in Frameworks 5 as a result of the 
various discussions at Platform 11 and the Qt Contibutors Summit.  I'll be 
splitting the proposal up into 3 emails about Locale, Date/Time, and 
Translation.

Please note that the Translation part is outside my area of expertise and I 
will mostly report on the QtCS session that I attended. The plan there 
requires proper discussion with the translation maintainers first.

This is the Locale email, i.e. discussing the settings such as date format, 
number format, etc for a given country and language.

Locale settings in KDE has two major advantages over most other localization 
systems but also two major problems.

The major advantages are:
1) Support for many more options
2) Allowing users and apps to change every single setting

The major problems are:
1) KDE Apps running outside the KDE Workspace do not use the host Locale 
settings, they just fake it.
2) Non-KDE Apps running under the KDE Workspace, and low-level pure-Qt KDE 
libraries (i.e. kdesupport), do not use the KDE Locale settings.

Related to this is the perception by 3rd parties that using KDE libraries is 
both 'heavy' due to the dependency on KLocale, the settings files, and 
consequently KConfig, and 'low quality' due to not using the host settings.  
If we want our libraries to be used as Qt-Addons then we need to solve this 
perception.

I'm also not happy with KLocale being a mixture of Settings Container, Object 
Container, Formatter/Parser, and Translation tools with some circular 
dependencies, when a cleaner separation would be better.

My proposal for KF5 is to use QLocale and CLDR as the source of the locale 
settings.  This solves the first problem completely, and solves the second 
problem with respect to Qt based apps.  The second problem will be solved for 
other toolkits by the Locale KCM writing out a POSIX format locale file and 
startkde setting the locale envvar to an absolute path to that locale file 
as defined in the POSIX standard (this could be done in KDE4).

Obviously work is required to QLocale to make it meet KDE's requirements.  
After discusions with the Qt maintainers and looking at improvements already 
in QLocale in 4.8 I believe this can be done to the benefit of both KDE and 
Qt.

1) We will no longer maintain our own settings files, instead using the 
Unicode CLDR settings as provided by QLocale.

2) QLocale will add support for all CLDR settings required by KDE to 
QSystemLocale (and optionally some other settings) and expose them in the 
QSystemLocale api for the KCM and KDE formatters/parsers to read.

3) QLocale will implement a QSystemLocale platform plugin for KDE Workspace to 
load the KDE country and language settings and any user settings that override 
the default CLDR settings.

4) QLocale will add support for most if not all the KDE options to their 
parsers/formatters, as well as some options KDE does not currently support.

5) Where QLocale formatter/parser support is sufficient and no translations 
are involved, then KDE apps will directly use the QLocale methods.

6) Where the QLocale formatter/parser support is insufficient or advanced 
translation is possibly required, then KDE will implement our own 
formatter/parser classes (e.g. KDateTimeFormatter) which can be used directly 
or possibly accessed through a new KLocalization class.  Qt-Addon libraries 
may use the QLocale versions, in almost all cases this should be good-
enough for their purposes.

7) QLocale will not provide setter methods, if an app needs to temporarily 
change individual locale settings for a formatting/parsing operation then they 
should use the formatter/parser api which will be reviewed to confirm that 
they provide all the options commonly used.  If an app needs to 
format/parse for a locale other than the current system locale they should be 
creating a new locale instance for the required country/language rather than 
messing with their copy of the system locale.  For extreme corner cases 
QSystemLocale can be subclassed.

Some current KDE settings may not be in CLDR and so may not be supported by 
QLocale.  At the moment the only known options to fall in this category are 
BinaryUnitDialect (which is under consideration by Qt) and DayOfPray.  
BinaryUnitDialect is not actually set in any of our l10n files so everyone 
gets the default unless they explictly change it.  If this is the only 
exception then I think this can just be at user level in kdeglobals.  
DayOfPray is also something I think is better supported at user or app level.

The major disadvantage to this plan is that it will break source compatability 
for virtually all localization methods.  Keeping the old KLocale in 
KDE4Support will alleviate this and allow apps time to migrate, although I 
don't see this being that difficult.

The end result should be that KLocale is moved to KDE4Support, with QLocale 
replacing most (and possibly all) uses of KLocale, and specialised 
formatter/parser classes supplementing any possible shortcomings in QLocale.

Much of the required work is already being done by the Qt maintainers, and I 
will be helping out as needed.

Obviously, we need a Plan B if Qt is unable to deliver (which I find very 
unlikely, Denis is very keen to do this regardless of OpenGov).  Plan A should 
actually be flexible enough to cover most situations, but in the worst case 
scenario I would just restructure KLocale along the lines described here and 
work to get a platform plugin into Qt.

I'm sure there's areas I haven't thought of yet that need to resolved, for 
example how will this affect Kisok, so I would like to get peoples feedback on 
the proposal.

Cheers!

John.