KLocale host system integration

[Chusslove Illich]

> [: 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.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100719/0522947f/attachment.sig>