Locale settings in Plasma Next

[John Layt]

Hi,

With the countdown to Plasma Next underway, I thought I'd better outline what 
needs to be done for locale settings, in particular the KCM, in case I don't 
find the time to do it.

In KDE4 we had KLocale in which we wrote the formatting code and provided the 
locale data ourselves which gave our users the ability to override every 
single locale setting in the Locale KCM, but completely failed to apply those 
settings to apps written with Qt or Gtk or anything else that also ran under 
Plasma.  It also meant KDE apps running under other workspaces, such as Gnome 
or Unity, sometimes failed to respect the host locale settings and used the 
KDE settings instead.  We also had separate settings for country and language 
rather than the more standard locale code of country and language combined, 
which while being more user-friendly didn't integrate well when talking to the 
outside world that was using only standard locale codes.

In KF5 we have switched to QLocale to remove the heavy dependency for KF5 
users and to better integrate with Qt apps and the host workspace.  I've been 
working on bringing QLocale up to scratch, but it doesn't yet have the ability 
to load and use the custom KDE settings when running under Plasma Next, it 
will only use the standard POSIX envvars.  This means that any changes made in 
the existing Locale KCM will be applied to KDE4 apps only, not KF5 apps that 
have removed the kde4support version of KLocale.  We need to decide the best 
way to deal with this.

What we can do in Plasma Next is allow users to separately choose which locale 
code to apply for each of the standard unix envars (LC_ALL, LC_NUMERIC, 
LC_TIME, LC_MONETARY, LC_MESSAGES, LC_MEASUREMENT, LANG), and have these apply 
to *all* apps running under Plasma Next by having kdeinit set them at start-
up.  But how do we present that in a usable way in a KCM, and what do we do 
with the KDE4 settings and KCM?

For KDE4 apps running under Plasma Next, I wonder if it will be too confusing 
having them using different locale settings than the KF5 apps?  Perhaps on 
migrating from KDE4 to Plasma Next we delete any old user locale settings in 
kdeglobals and as a consequence the apps will use the same settings as all 
other apps under Plasma Next?  If we do keep the old settings, then we will 
probably also need to keep the old KCM available.

For the new Locale KCM we will need to remove the separate Numbers, Money, 
Calendar, Date & Time and Other tabs for now.  I'd suggest we no longer refer 
to the "Languages" tab but call it "Translations" instead, as that is what 
they really are, it configures how KLocalizedString works.  Referring to them 
as Languages has created a lot of confusion, as has the current gui, but I'm 
not sure how to make it better.  I'd also suggest changing the "Country" tab 
to "Formats", with a series of combo boxes to select the "Number Format", 
"Money Format", etc.  We may be able to merge the Formats and Translations 
tabs into one layout but I suspect that will be too crowded, so instead 
perhaps we should have them as separate KCMs so they appear listed separately 
in the System Settings Locale group and sidebar as Formats, Translations, and 
Spell-Checker.

One question is when these changes to the envvars will get applied, and the 
action required to apply them to the apps.  I believe Gnome forces you to log 
out and in again before the new envvars are applied.  In KDE4 you could simply 
restart individual apps, but to update Plasma itself you had to log out and 
in.  Do we update the envars as soon as the KCM changes are saved, which would 
allow apps to simply be restarted, or would that be considered dangerous for 
running apps that assume the envvars won't change, e.g. would something like 
glibc immediately pick up the change and return inconsistent results?

I guess another obvious question is where to save the envvar settings, I guess 
kdeglobals still?  Or somewhere new?

Longer term we will need to restore the ability to edit the individual 
settings and I have a roadmap for that, but I'm expecting some negative user 
feedback in the meantime :-)

Cheers!

John.