[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. _______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
