Request: better override functionality in locale settings

[John Layt]

Hi,

Just to add to the background (and seeing as I'm the primary culprit
in the death of KLocale and the slow pace of improvements to QLocale),
there's 2 very big reasons for removing it (and the consequent loss of
the customization feature):
1) It was very big and a maintenance burden, especially when Qt
provides good-enough facilities for most purposes. The size stopped
people using KDE libraries and reduced the number of potential KDE
apps, and adding new features like proper collation and spell-out
formatting would have taken a lot of duplicated work.
2) It was a walled garden, only KDE apps used the settings, all other
apps ignored them, and KDE apps running on other desktops/platforms
ignored their host settings, leaving an inconsistent user experience.

Just setting the standard POSIX codes has one very big advantage in
being universal: all apps running under Plasma will respect them,
rather than just KDE apps. If we implement a Qt-only solution then any
POSIX/glibc/Java/Firefox/
Chrome/etc apps will look out-of-place again,
as they did under KDE4.  Any solution needs to apply to everything
(even if not everything is implemented at once).

We do want the configurability back, I use it myself, but there's a
series of technical steps we need to achieve first. The first is
removing Qt's own locale system which has the same size/maintenance
problems and has hard-coded locale data that cannot be changed, as
well as being short on some features. I've written 3 different
solutions so far over the last 2 years and none have been accepted. We
do now have a fourth design that has come out of these efforts, and I
have some code towards it, but I estimate it as a 6 month full-time
effort to get it implemented, tested and integrated, as it is nothing
less than a complete rewrite of all of QLocale for every platform Qt
supports without breaking any previous behaviour or api. That is time
I don't have to give right now, and no-one in the Qt world seems
interested in paying for it in spite of many people wanting it (just
like printing really).

The design is basically to wrap the host services on each platform in
a common api, with ICU as the chosen backend on Linux due to
POSIX/glibc localization being totally useless. Unfortunately that
means we end up catering for some lowest common denominator feature
set, in this case Windows XP.  If we ignore XP (and we will) then it's
better but still not what we really want, and the current debate is
whether we have an advanced api in QtCore that degrades gracefully on
Windows, or if the advanced features go in a new QtLocale add-on
module.

Even once this full rewrite of QLocale is completed, that still
doesn't give us the ability to edit individual settings on Linux (only
Win and Mac), but it does set the precedent that QLocale should
respect the users override settings and so make it acceptable to add
some 'hacks' into Qt on Linux to make it work.  For Qt the mechanism
will probably be a small json file that stores the custom overrides
that QLocale loads and then applies as overrides when calling in to
ICU.

But even once Qt reads and uses our custom settings, that still
doesn't apply those settings to POSIX / glibc / gtk apps, we need an
extra step there as well. There is a hack we could use, which is that
the System Settings module could save a POSIX format locale file with
the custom settings and set the LC_* envvar to point directly to the
file, but that would require all toolkits to correctly implement the
POSIX standard and I'm not convinced they do.  Alternatively we could
ask the user for the root password and install the locale file
globally, but I'm not keen on that.  It also doesn't solve things for
apps that use ICU directly, like Chrome, where we have no possible
solution.

All that is besides the point with the System Settings module.  We did
say at the time that a drop-down with 200+ entries was probably not
the best solution, but it was an interim implementation for 5.0.  I'm
sure with a little thought we can come up with a better way of
managing such long lists, for example with a pop-up selector which
includes filters by language or region, or something like that.
Perhaps for metric/imperial we could be a little smarter and use the
users chosen language or default locale to "guess" at a suitable
locale match to use.  For date/time format overrides, well that I'm
afraid belongs in individual apps and plasmoids for now.

John.