[KDE/Mac] Country / Locale settings in non-KDE desktops/OS

[John Layt]

[cc to win and mac lists, please ensure your replies go to kcd as well]

I've been pondering the state of KLocale and Country based locale settings 
such as number and date formats when running apps outside the KDE desktop 
(Win/OSX/Gnome) or with only kdelibs installed.  (This is separate to 
languages which appear to integrate well and are outside my area of interest).

My understanding of how it currently works, please correct me if I'm wrong:

KLocale lives in kdelibs, but the .desktop config files for each country live 
in kdebase/runtime/l10n.  If kdebase is not installed (say the user only wants 
1 KDE app like Amarok or Digikam), then KLocale will default to C, i.e. USA 
settings.  This results in apps literally looking and acting foreign to the 
desktop/OS they run under.  The lack of kdebase also means the user is unable 
to adjust the settings in SystemSettings to match their locale unless they are 
able to hack config files.

Even when kdebase is installed and the country files and SystemSettings are 
available you still have to know to manually configure to use the right 
country, and even then some of the settings may be inconsistent with the host.

I think we should be friendlier to the user by picking up the host settings 
and using them where possible, and where this is not possible applying our own 
settings that are relevant for the users country as set on the host.

So that leads to the following questions:
1)  What is the status of the Windows integration?
2)  What is the status of the OSX integration?
3)  Should we move the country files from kdebase to kdelibs?
4)  Should we look at Gnome integration? In both directions? Env vars perhaps?

With regards 1) and 2), it doesn't look very far progressed. It would seem 
that QLocale::system() might provide some of the required details, but the 
rest will need to be worked through item-by-item to determine what the host 
provides and what it doesn't.

With regards to 3), if we move the country files we could make KLocale load 
the country file for the host's country setting instead of the default C 
whenever no country has been explicitly set in KDE.  If the user has set a 
country or other regional setting in KDE, we would need to decide what to 
honour and what to override with the host's setting, possibly disabling some 
options from being set in SystemSetttings when running under the host.

This has a few advantages, such as having more sensible values for settings 
that we have not yet or cannot pick up from the host (especially when the user 
is unable to change them), and there are some useful functions like 
Klocale::countryNameFromCode() that apps may want to use that are useless 
without the .desktop files, and it also gives us a guaranteed source of flags 
to display :-).

The downside is this would be an extra 1.6Mb in kdelibs, but most of that is 
the flags which is another discussion we need to have (I'm also thinking about 
adding support for regions within the countries, but that's another e-mail too 
:-).

For 4), that's probably an fdo thing to look into, but I guess I'm thinking 
along the lines that we have pluggable backends for KLocale that adapt to 
whatever desktop/platform a KDE app is running under to make it best look like 
a 'local' app rather than a foreign invader.

Thoughts?

John.