Locale changes in Plasma Next

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.
kcmformats_thumb
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.

11 Responses to “Locale changes in Plasma Next”

  1. Sam says:

    Thank goodness, that was one of the most complicated settings to go through just to change the time to 24h and measurements to Metric. I may live in America, but I prefer sanity any day.

  2. CTown says:

    That’s great news; thanks to theming efforts, this could make GTK apps more native easier in Plasma. Too bad GTK wants to move to client-side window decorations (those guys seem love to making things difficult for others) but I’m sure between the the themers and KWin people, everything will get fixed.

    Also, will there be a choice to have a 12 hour time format without suffixes. No one says am or pm anymore, since it is very obvious what part of the day it is; that’s why I’m using the “Adjustable Clock” Plasmoid.

  3. This is indeed a welcome change! Some users might complain that now they have to know – or guess – which region/language uses which settings (which is where the preview below comes in very handy, though), but the fact that it writes out the POSIX locale variables is very helpful. I always found it weird when I changed some locale setting in Plasma but e.g. command line applications did adopt it. As a user, I simply expected locale settings to affect everything instead of only Plasma and KDE applications, so now the reality is closer to my expectations.

  4. GreatEmerald says:

    Nice. Although this sort of raises the question of where the other settings got moved to. I’m used to going into Locale settings to change the file size units (because screw 1024 multipliers, that’s not how humans work). Though it’s true that this has little to do with locale, at least for now.

    Also, I’m not sure I like how half the page is greyed out by default. Why not have that hidden under an “advanced” button or something, so it doesn’t look so needlessly cluttered?

  5. RJVB says:

    I’m a bit wary of this kind of “know it better than the user” approach. It’s fine as long as there remains an override allowing fine-grained control. For instance, I live in France, but want my desktop configured to UK (European) English, use the Euro sign as a default for currency, no thousands grouping and a point as a decimal separator. I also want my compact date to be YYYYMMDD.
    A preselection is fine, but please keep drop-down lists with the obvious alternatives, or something of the sort!

    I really hope KDE isn’t going to follow OS X’s lead too much!!

    • Jan says:

      I have to second that. The way the current POSIX locales work (at least on glibc, wouldn’t know if it’s implementation specific) is that day/month names are localized according to LC_TIME! So if you have LC_MESSAGES=en_US.UTF-8 and LC_TIME=de_DE.UTF-8 you end up not getting what you want: German date format and day/month names instead of German date format but English day/moth names. It always has been a pain point I hated about it. This doesn’t even yet provide a way to get the intelligent ISO YYYY-MM-DD format and other customizations that people may want.

      So please, please, please fix the POSIX locale system/glibc implementation of it. Having to modify/create a needlessly complex (for current standards) file in /usr/share/i18n/locales/ is *not* the right way. These little modifications need to be providable by environment variables for those who want them.

      I commend that you want to unify this, but I can only appreciate that when these things are fixed and glibc is made sane.

    • John says:

      The ability to modify each individual setting is planned to return in the course of the next year or so, it’s just that we have some fundamental engineering issues to solve first, mostly in Qt itself. It’s something I want myself for the very same reasons, so I’m incentivised to make it happen :-) We have to be able to tell Qt and the other toolkits/libraries to use our custom settings, not just the POSIX locale code as a whole. For Qt we can add platform specific code to be used when it detects it is running under KDE, but for the others we need to write out a custom POSIX file and tell the likes of glibc to use that instead of the standard POSIX locale file.

      Oh, and following OSX’s lead is very much what we’re doing, they actually allow you to override your individual formats just as KDE4 does, but in a far far more user friendly way, and it applies to everything :-)

      • RJVB says:

        OS X’s lead was great to follow up to and including 10.6; from there on Apple started locking too many things down, IMHO. And not following their own guidelines and opportunities provided by the frameworks.
        To be honest, that’s also the reason I got involved with KDE; I see it as a very serious potential replacement for OS X (Linux included, or simply running *on* OS X!)

  6. Alexander E. Patrakov says:

    Nice demonstration of the benefits brought by just following the relevant standard (POSIX in this case).

  7. smls says:

    Wouldn’t it make more sense to show the examples next to the corresponding drop-down boxes?

    Then you wouldn’t have to duplicate the labels (“Numbers:”, “Time:”, …)