Country / Locale settings in non-KDE desktops/OS

[Ralf Habacker]

John Layt schrieb:
> [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. 
the initial design of kde 4 says that kdebase-runtime is a required 
dependency beside kdelibs for running apps.
If you run amarok or digikam and opens the application related help this 
starts khelpcenter for displaying the help.
Because of that dependency khelpcenter is located into kdebase-runtime.
> 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.
>   
systemsettings is currently located in kdebase-workspace and will not be 
available when installing single applications.
This means that for any single application kdebase-workspace is a 
required dependency.
> Even when kdebase is installed 
i guess you mean kdebase-runtime, not kdebase-apps
> 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.
>   
One additional item is to move systemsettings to kdebase-runtime as 
mentioned above.
> 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?
>   
if kdebase-runtime is still a required dependency for any application is 
there still a need for your request ?

Regards
 Ralf