kde vs. locales

[Chusslove Illich]

> [: Oswald Buddenhagen :]
> good. chusslove, that's your call. break stuff now! :) well, actually,
> maybe not break, but we must make sure the api doesn't expose anything
> that would have to change later.

I think there is nothing to break on the API side. This is all about order
of events and priorities and sources of information. E.g. in case KDE's
locale data has something that libc's does not (I'd say at least some stuff
regarding dates, but libc has extras regarding money), then these should not
be removed (as Albert has eloquently indicated :), but rather exposed to
user as KDE-specific.

Then, here are my two scenarios.

/The "perfect" scenario/

Along what Thiago said -- KDE respects libc locale/language data, as set by
login manager, unless the user overrides.

On the user settings side, the current KCM would be changed as follows.
Above all the tabs, there would be a checkbox "Override settings at login",
a listbox "System locale" and a checkbox "Override system locale for KDE
applications".

If "Override settings at login" is unchecked (default), then both the
listbox "System locale", the checkbox "Override ... for KDE apps", and all
options in all the tabs below are greyed out -- *except* those KDE-specific,
which are not contained in libc locale data.

If "Override settings at login" is checked, then "System locale" listbox and
"Override ... for KDE apps" are activated. The user can now select one of
the system locales from the "System locale" listbox", overriding the login
menager. Most of previously disabled options in the tabs are still disabled,
except the language selection, where the user can now select more than one
language for fallback.

If "Override ... for KDE apps" is checked (disabled by default), finally all
the options in the tabs lit up. However, the "System locale" listbox is
still active, as this locale will hold for the libc-aware apps (e.g.
Gnome...)

Note that with this, the user can observe how the availability and values of
options in tabs changes as the two stationary chekboxes and a listbox above
the tabs are toyed with. Also, this allows smooth updating as the libc
locale data possibly gains presently KDE specific features -- merely a
question of what is active upon different setup of top checkboxes.

On the implementation side, there comes the part with ~/.i18n, except that
the file itself is not necessary: at KDE startup, user settings are checked,
and appropriate variables set up. If the "Override settings at login" is
unchecked, only LANG is set according to ~/.dmrc; if it is checked, then
LANG is set to what user had set in "System locale", and LANGUAGE to list of
languages by priority as user had chosen them.

Furthermore, KDE_LANG is out, as is internal global choice of languages
having priority over LANGUAGE -- simply, the LANGUAGE, LC_*, LANG is checked
in that order for languages to use globally for KDE apps. This effectivelly
puts KDE in line with rest of Gettext using apps. The only internal language
setup left would be per application, as set by that "Change language"
feature in application's, erm, "Help" menu.

Unfotunatelly, this scenario is not easy to implement, even if without major
holes :) For one, we would have to implement libc locale data to KDE API
mapping. And I don't even know how much GUI work is entailed.

/The "right-now" scenario/

Just make KDE reasonably set environment variables, for sake of non-KDE
apps.

On the settings side, this would mean one listbox, either above or below
tabs, "System locale for non-KDE apps"; the user could choose one of the
installed locales, or "Locale set at login". In the language selection, also
put a checkbox "Language set at login", which greys out language selection.

On the implementation side, at startup set LANG to either locale chosen by
user, or to what is read from ~/.dmrc if "Locale set at login". For
language, if user checked "Language set at login", no extra environment
variable is set; if the user did select languages, i.e. "Language set at
login" unchecked, then export LANGUAGE with those languages.

Either way, again KDE_LANG and internal global setting are out, leaving
language choice fully at LANGUAGE, etc. chain of priority (and the
application specific choice as top, of course) -- same as in the "perfect"
scenario. I.e. user's choice of languages in KCM is used only to set
LANGUAGE for KDE session, but can be overriden in shells.

                                   * * *

Err, now I wonder, why was it that ~/.i18n was needed? As opposed to
startkde reading what it needs from config and setting the environment?

-- 
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/20071125/8fe62f70/attachment.sig>