KLocale host system integration

[John Layt]

On Monday 19 July 2010 09:58:29 Chusslove Illich wrote:
> > [: John Layt :]
> > [...] I'm spending the next couple of weeks working on KLocale to set up
> > the infrastructure to to make this work properly.
> 
> That's great, except that "proper" I would call the current situation, and
> what you intend to do "more satisfactory" in some sense. Here's why.
> 
> > [...] KDE not respecting the host system locale settings [...]
> 
> I'd say there's no such thing as "host system locale settings". There are
> some libraries which provide locale functionality, and that's it. For
> example: kdelibs, QtCore, glibc. It is upon each application to choose the
> library it will use for its locale-handling needs. All these libraries
> follow some own model of locales; of course, given the subject, there are
> great similarities between them, but fundamentaly they have no common
 root,
> either by implementation or specification (e.g. an ISO standard, a RFC).
> 
> What this means is that, when the user sets the locale (whatever that
 means
> exactly in the model of the given locales-providing library), the only
> proper way is to set the locale in the configuration of *each* locale-
> providing library in turn. Since they have no common root, there is no
> proper way to set the locale at one place for all those libraries.
> 
> On a contemporary Linux distro, it so happens that the login manager lets
> the user choose the locale for glibc. Further along the proper way, it
> should allow the user to set the locale for kdelibs, for QtCore, etc. I.e.
> the user would set three or more locales at first login. At this point the
> more usability minded among you are reaching for the favorite punishing
> device, but remain calm, even I understand how "proper" here is far from
> "satisfactory".
> 
> Assuming that for each platform we declare one locale-providing library to
> be "primary locale-providing library", and that for no platform that is
> kdelibs[1], one clean way towards at least somewhat satisfactory solution
> is to simply dump kdelibs locales and make KLocale a smart frontend to
> designated other libraries. That also means that there would be zero
> native locale configuration possibility in KDE. The user would be expected
> to make changes in the configuration of primary locale-providing library,
> in whatever the form provided (e.g. with glibc it is only possible to
> define new locales via localedef(1)).
> 
> * [1] I don't think it's possible to declare kdelibs as primary locale-
>   providing library for any platform. E.g. on *nix + KDE workspace that
 you
>   mentioned (even if a bit fuzzy defined), foremost of which are
>   contemporary Linux distros providing KDE, users are still given to
 select
>   glibc locales (on installation, on login) and not kdelibs locales.
> 
> Now, mixing kdelibs locale concepts and settings with other
> locale-providing libraries concepts and settings (e.g. glibc) in some way,
> while also letting users tweak locale settings similarly to what we have
> now, I haven't got a clue how it could be done in any half-way sane way.
> (Had some ideas before, but they were dispersed by rising complexity
> since.) So you'd be kind of breaking new ground :)
> 
> > My first step, making KLocale a fully private implementation and
 creating
> > derived Windows/Mac locale classes is posted for review at
> > http://reviewboard.kde.org/r/4683/ .
> > 
> > The next step will be to default the KDE country to the host system
> > country so most users on all platforms will never need to visit the kcm
> > and change any settings. The correct KDE default settings will almost
> > always be picked up and be an acceptable substitute until the host
 system
> > settings are actually used.
> 
> I don't know about other locale-providing libraries, but glibc almost has
> no concept of country[2]. Glibc locale name can be arbitrary, and there
> may be arbitrary aliases. Inside a glibc locale, there does exist a
> human-readable country name, and the country code burried in obscure
> country_ab2 and country_ab3 fields within LC_ADDRESS category, but reading
> the glibc manual I don't even see if these can be fetched through glibc
> public API.
> 
> * [2] And this is not just a strange detail, but a fundamental difference
>   between kdelibs and glibc locales. With kdelibs locales the user
>   independently chooses a language and a country, while with glibc locales
>   simply "a locale" is choosen (which I think is actually better, but this
>   is irrelevant for current matter).
> 
> But fine, so you do some heuristics and pick a kdelibs country. Some
> questions to that:
> 
> I suppose this is done on each KDE application start (i.e. on each
 creation
> of global KLocale), since the user may not log into a KDE session?
> 
> How is this heuristic choice recorded? What happens when the user later
> logs in with a different glibc locale?
> 
> What happens when the user goes into System Settings and manually sets
> kdelibs country? What happens then when the user later logs in with a
> different glibc locale?
> 
> What happens when the user goes into System Settings and wants to change
> some locale elements only? Does he have to pick kdelibs country before
> that? What happens when the user later logs in with a... yep.

Hi Chusselove,

Apologies for the late reply, but KMail twice ate my reply,
I took that as a sign to go away, think some more, and try my ideas in code
 first :-)

Thanks for your comments, I know you've put a lot of thought into this in
the past, so your input will be invaluable in sorting it out.  They
certainly got me thinking in lots of unexpected directions and doing way
 more research.

My main concern for now is Windows and Mac, I don't plan to change Linux
just yet, there's too many difficulties there for now but I'm slowly
thinking through them.  It is something we need to sort out, especially
given the spread of KDE apps to other platforms such as MeeGo and Symbian
where we are unlikely to the be shell and so really do need to play nice. 
However with Win/Mac we do have a single source for "host system locale
 settings" we should be using as our "primary locale-providing library".

That said, attempting to guess a reasonable default country to use under
Linux is still a good thing to try, as it stands we default to C every time
and every user has to change it.  Even if the guess is only right 10% of the
time it is still 10% of users who won't have to select a country.  I think
it will be better than that though, as the QLocale method I'm calling is
supposed to make some intelligent guesses based on the language.  You can
see the proposed patch on ReviewBoard now.  If testing shows issues we can
 tweak it or disable it under Linux entirely.

You are right about how KDE's concept of separate Country and Language are
different to the concept of Locale (i.e. a collection of cultural
conventions for formats and the like), while they are loosely related with
one implying the other, it is still possible for them to be completely
 different which we don't cater for so well.

I believe we do it the right way around, you choose a country and a language
and your formats get determined from that in an intelligent manner with the
option of choosing your own overrides.  The 'other' way of having a fixed
list of predefined combinations that you must choose from is more
restricted, if you don't fit the standard set of locales you have few
customisation options.  However, that is the most common way of doing it.  I
don't want to change the KDE way, but I'm sure we can find a way to make
 them co-operate better, especially on the new platforms.

Thinking about that, and another of my projects to integrate the ISO 2nd
level country regions (states/provinces etc ), may lead me to separate the
concepts of Home Country and Locale Country much as Windows does, but that's
 still a thought experiment and for another email.

To answer some of your specific questions:

Each time an app starts it
creates its own copy of KLocale, locking in its locale settings as at start
up in order to prevent inconsistencies.  If no country is set by the user,
then KLocale will take an educated guess, or fall back to C.  The guess will
be specific to this app run and not stored anywhere else, the next app to
start-up may guess a different country if the user has changed settings
 somewhere.

[As an aside, I'm looking at methods for telling apps when the locale
settings have changed and allowing them to optionally refresh their locale,
 much as we do with language]

The golden rule is a users selected preferences always trump any system
settings or guesses.  Each individual format setting can be independently
set, even if you don't have a country set.  If a user chooses they prefer a
short date format in ISO format, then they are unlikely to want that to
change if they change their system country.  This is the same as current
practice where changing your KDE country in the kcm will not affect any
 formats you have overridden.

The settings preferences would follow the standard config order of priority,
 i.e.
* Application specific overrides from the apps rc file
* User selected settings from kdeglobals file
* Group policy settings
* Default settings for country, falling back to C settings

The key here is to make it obvious in the kcm where the user has overridden
the defaults and make it easy to revert a single setting at a time.  I'm
currently re-writing the kcm to do this, to lock/hide settings on Win/Mac
that we take directly from the host settings, and add a bunch of new
 localisation options .

Cheers!

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100805/d8642eb7/attachment.htm>