KDE Core/KLocale

Details on KLocale and associated classes such as KLocalizedDate and KCalendarSystem.

The Future Of KLocale

KDE Localization is a walled garden. We pay very little attention to the host system Locale settings, and we don't tell any hosted apps what our Locale settings are. So KDE apps running under Gnome, Windows, Mac or Meego while defaulting to the host Country/Language don't use the actual host Locale settings, and Gnome and Qt apps running under KDE Workspace don't use our Locale settings.

Why does KDE have a different Localization backend, why don't we use standard POSIX locales like Gnome does, or CLDR like Qt does? Three historical reasons: extra features, more flexibility, and user configurability. Features allow us to have more standard settings than defined in POSIX or in CLDR at the time, like calendar systems. Flexability allows us to freely mix and match countries and languages, whereas other systems lock you in a standard list of supported locales. Configurability allows our users to change every single setting to any value they want, unlike other systems where settings are fixed to what the system locales provide. These are all good things to have and it worked fine when most of our users were running KDE Workspace, but time has moved on and our implementation needs updating to work on all our supported platforms, especially those where we do not provide the workspace and therefore cannot dictate what the locale settings should be.

There's three areas we need to work on to integrate better:

1. KDE apps running on "foreign" platforms or workspaces (e.g. Windows, Mac, Gnome, Meego) need to use the host system locale settings and ignore the KDE settings
2. "Foreign" apps running under the KDE Workspace need to use the KDE settings
3. The KDE Workspace needs to use the host system settings when deciding what default locale to use

KDE Apps Running Under non-KDE Workspaces

When running under a non-KDE Workspace (Gnome, Windows, OSX, Meego) then KDE apps should use the host locale settings and not the KDE ones, except where the host does not provide the required locale setting.

On Windows and OSX this means either directly accessing the host locale functions, or using QLocale.

On Gnome and Meego this means reading the POSIX locale defined in the envars. It is mooted for QLocale to have a POSIX backend for use on Meego which could be used.

One consequence of this is the KCM should block users from editing settings that KDE reads from the host, they should use the host settings editor for that purpose. Only KDE unique settings should still be available. Shipping a full set of l10n files and a full KCM may then be overkill for these platforms, perhaps a minimal KCM made available in the Help menu or Preferences of every app would be a better solution.

We now have separate KLocale backend classes for each platform with some code completed, work needs to be done to fully migrate the settings.

Non-KDE Apps Running Under KDE Workspace

When running under the KDE Workspace Qt and Gtk apps should use the KDE locale settings. This requires two steps.

Firstly, KDE needs to set the locale envvars at session startup to the current KDE locale so these apps know to load the correct POSIX/CLDR locale file.

The problem here is that KDE may have a unique combination of country and language that are not available in POSIX or CLDR, or the KDE user may have modified their locale settings to their own preference which will not be in the locale file.

The solution here is for KDE to write out the KDE settings as a POSIX locale file and set the session locale envvar to point to that file (the POSIX standard allows for a full path to be set). All standard *nix apps would then use KDE settings to their maximum extent.

For Qt apps this relys on QLocale implementing a POSIX backend with they may be doing for Meego. An alternative is for QLocale to get a KDE backend that directly loads the KDE settings file, but this has been rejected by Qt in the past.

We should also consider allowing the KCM to write out the system locale setting, not just the workspace session locale setting, but we should talk to the distro's on how they feel about this.

Qt5 / KDE5

In Qt 5 we should aim to migrate as much as possible to Qt, with a thin wrapper to implement the KDE special requirements. Using KLocale (and thus KConfig) is a major barrier to Qt-only apps adopting our libraries so we should try remove the need for KLocale where-ever possible. Much can be achieved by pushing KLocale features into QLocale and ensuring QLocale fully supports all options common to all the platforms (some options are still not supported, or are only properly supported on some platforms).

One issue with KLocale in KDE4 is it mixes the settings container with the formatter classes, which can set up a circular dependency that makes customising settings difficult. For example KLocale embeds a KCalendarSystem object, which itself embeds a KLocale object to use for its settings which embeds... Instead the settings container and the parsers/formatters should be separated. This will allow us to pass around custom settings objects as required without having to play tricks like we currently have to.

Possible scenario:

• QLocale or KLocaleSettings class holds the settings
• KLocaleFormatter formats date/time/numbers to required local format
• KLocaleParser parses date/time/number strings to required local format
• KGlobal::format() and KGlobal::parse() provide access to parser/formatter using global locale, e.g. KGlobal::format()->date(QDate)

One large issue with using QLocale instead of KLocale is we have settings that Qt is unlikely to adopt, and it is unclear if QLocale will add setter methods. There are two possible solutions to this.

One solution is to sub-class KLocale from QLocale and add our required methods and the setters. A problem with this would be if Qt later added the required features we could get method name clashes and various messes.

The other solution is for the KDE parsers/formatters to use QLocale wherever possible, then to load the special KDE settings as and when required, for example formatting numbers and currency may be fine to use the QString methods with QLocale but formatting dates using a KDateFormatter class (like in OSX) may need to load extra settings in.

This leaves setters for locale settings. The KCM could obviously write out the POSIX file to be used by QLocale, but what of apps that need to temporarily change the locale settings? I would suggest in most if not all cases this need can actually be met by providing more flexible parser/formatter api's that take the custom settings directly.

Work will be required to sort through the list of all settings to see where we can rely on QLocale and where we need separate settings.

ISO Codes

The KLocale support for ISO Codes for Country, Languages, and Currencies should be separated out. See the ISO Codes proposal page for more details on the planned separate library.

One major part of this will be simplifying the Currency Code support. The ISO Codes library will hold the full details in its file, but KLocale or its replacement will not expose all these details, it really only needs to know the Currency Codes used by a country, the currency name, the currency symbol, and the number of decimal places. All the other details are really only needed by specialist apps who can either read the file for themselves or use the Alkimia library which would gain the KCurrencyCode class.

KDE Core Use

KLocale is used in the following areas in kdecore, causing a number of circular dependencies and leaving an unclear dependency tree. For example KLocale needs KConfig to load the config files, but KConfig needs KLocale to set the locale to use when reading the file.

kdecore/kernel/KGlobal kdecore/kernel/KConfig kdecore/kernel/KAboutData kdecore/kernel/KComponantData kdecore/kernel/KStandardDirs kdecore/config/KConfig kdecore/localization kdecore/date kdecore/sonnet kdecore/services/KMimeType kdecore/util/KPluginFactory kdecore/io/KUrl