One of the things that take care of internationalization of Plasma is the locale. Locale is a container concept that includes Wikipedia defines Locale as “a set of parameters that defines the user’s language, country and any special variant preferences that the user wants to see in their user interface”. There have been some changes in this area between Plasma 4.x and Plasma Next. In this article, I will give an overview of some of the changes, and what it means for the user. I’ll exclusively talk about the locale and although there is some overlap between Locale and Translations, I’ll concentrate just on the locale for now.
In Qt5, the locale support has seen a lot of improvements compared to Qt4. John Layt has done some fantastic work in contributing the features that are needed by many KDE applications, to a point where in most cases, KLocale is not needed anymore, and code that used it can now rely on QLocale. This means less duplication of code and API (QLocale vs. KLocale), more compabitility across applications (as more apps move to use QLocale), less interdependencies between libraries, and a smaller footprint.
This is one of the areas where porting of applications from KDE Platform 4.x to KDE Frameworks 5 can cause a bit of work, but it has clear advantages. KLocale is also still there, in the kde4support library, but it’s deprecated, and included as a porting aid and compatibility layer.
In Plasma, we have already made this transition to QLocale, and we’re at a point where we’re mostly happy about it. This also means that we had to revisit the Locale settings, which is probably the single component that is most visible to the user. Of course the locale matters everywhere, so the most fundamental thing is that the user gets units, number formats, currencies and all that presented in a way that is familiar and in line with overall regional settings. There’s a bunch of cases where users will want to have more fine-grained control over specific settings, and that is where the “Formats” settings interface in systemsettings comes in. In Plasma 4.x, the settings were very much based on either using a common setting and overriding specific properties of that in great detail. You could, for example, specify the decimal separator as a string. This allows a lot of control, but it’s also easy to get wrong. It also does not cover all necessary cases, as the Locale is much more subtle than can be expressed in a bunch of input boxes. Locale also has impact on sorting, collation of strings, has its own rules for appending or prepending the currency.
QLocale, as opposed to the deprecated KLocale doesn’t allow to set specific properties for outside users. This is, in my opinion, a valid choice, and can be translated in a fashion that is more useful to the user as well. The Formats settings UI now allows the user to pick a regional/language setting per “topic”. So if you pick, for example “Netherlands” for currency, and United States” for time, you’ll get euros, but your time will display with AM/PM. So UI has moved, so to say to using a region and language combination instead of overriding locale internals.
The mechanism we’ve put behind it is simple, but it has a number of advantages as well. The basic premise is that systemsettings sets the locale(s) for the workspace, and apps obey that. This can be done quite easily, following POSIX rules, by exporting variables such as LANG, LC_CURRENCY, LC_TIME, etc.. Now if the user has configured the locale in systemsettings, at next login, these variables will be exported for apps that are run within that session to be picked up. If the user didn’t specify her own locale settings, the default as set by the system is used. QLocale picks up these variables and Does The Right Thing. A “wanted side-effect” of this is that applications that do not use QLocale will also be able to pick up the locale settings, assuming they’re following the POSIX standard described above. This means that GTK+ apps will follow these settings as well — just as it should be within the same session. It also means that if you run, for example LXDE, it will also be able to have apps follow its locale, without doing special magic for Qt/KDE applications.