Country / Locale settings in non-KDE desktops/OS
John Layt
johnlayt at googlemail.com
Thu Aug 27 16:27:43 BST 2009
[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.
More information about the kde-core-devel
mailing list