Review Request 118063: New Formats KCM

John Layt jlayt at kde.org
Mon May 12 13:15:07 UTC 2014 


> On May 11, 2014, 6:59 p.m., John Layt wrote:
> > kcms/formats/kcmformats.cpp, line 204
> > <https://git.reviewboard.kde.org/r/118063/diff/1/?file=272244#file272244line204>
> >
> >     Why are you writing all these entries here?  If all they have set is the global then all we need to export is LANG, so only writing out lcGlobal should be enough. If there's no overrides we should always be deleting them.
> 
> Sebastian Kügler wrote:
>     Hm, LANG will be set from the Translations KCM, and affects that, no? (I might be off here, that's how I understand it.)
>     
>     This brings me back a bit to the way this KCM works, it's used to override settings specified elsewhere, if necessary. I think in combination with the Translations KCM, a clean separation makes sense, but I'm not 100% sure that's achievable. Effectively, with the current version of code, we have a few scenarios:
>     
>     - Language set from distro installer, however. User's happy, doesn't touch the KCM
>     - User sets Language in the Translations KCModule, which sets LANG (in the same fashion as we do here), LC_* is not set, so everything falls back to LANG -> we're peachy
>     - User sets Language, but wants something else changed, configures that in the Formats KCM, and it's applied by exporting LC_*, -> we're fine again
>     
>     The Translations KCM probably the first one we should show when the category in systemsettings is opened, as it allows a very "Global" setting: LANG is changed, affects translations, and additionally all the formatting because LC_* not set means fall back to LANG.

Ah, here we get to the difference between LANG and LANGUAGE and LC_* and the override hierarchy (see http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Locale-Categories.html).  LANG is the "global" default locale to use, with LC_* and LANGUAGE used to override that default for certain functions.  The LANGUAGE override is a GNU gettext extension that allows you to define a priority list of languages to be used in the translation system, whereas LANG and LC_* only allow a single locale code at a time.  For example, QLocale::uiLanguages() returns the list of whatever is held in LANGUAGE, otherwise whatever is in LC_MESSAGES, otherwise whatever is in LANG, otherwise defaulting to the C locale (en_US).

Defining how that relationship between LANG and LANGUAGE will work in the config GUI is the tricky part.  My original plan was to treat them completely separately:

* The LANGUAGE envvar configures the gui translation systems, i.e. gettext and KLocalizedString, and QTranslator.  The Translations kcm would configure it from a list of available translation catalogs installed, usually only 1 or 2, with en_US as the fallback.  startkde would always export a LANGUAGE value, defaulting to the system LANG if no LANGUAGE value set in the kcm.  It would also export the first value in the LANGUAGE list as LC_MESSAGES

* The LANG and LC_* envvars configure the localization system, i.e. date formatting, number formatting, etc in glibc and ICU and QLocale.  The kcm configures them from a list of available locale files installed, usually several hundred.  These locale files contain month and day name translations separate to the gui translation system.  startkde would export a value for LANG or LC_* only if set in the kcm.

This would give users maximum flexibility while perhaps making it clearer why just selecting say an Arabic locale doesn't give you an Arabic gui translation.  However I'm rethinking that a bit now, as while by default most users would never need to change anything after their initial distro install, I could see those users who do need to change being confused/annoyed at having to do it in two separate places.  Having the two kcms messing with each others settings also seems a no-no to me, so the only alternative is to merge them.

One other reason for the original approach was the rather problematic Languages tab in the old Locale kcm which I was copying for Translations.  It uses a KActionSelector widget which shows side-by-side lists of Available Languages and Preferred Languages: you move the languages you want from Available to Preferred and then adjust the order.  Problem is this takes up a lot of space so needs a separate pane or tab, but most of this space and functionality is wasted on most users who only have 1 or 2 KDE language packs installed: its a gui optimised for the 0.1% corner case of someone with dozens of languages installed who's regularly modifying them.  There's also a debate about what the Available Languages list should show given we are setting LANGUAGES now for all apps under the workspace including gettext ones: do we list just the KDE language packs, or also all languages installed into /usr/share/locale, or all possible languages?

One possibility is to throw away all the old code and have a single list of Preferred Languages, with a small + button to pop up a selector of the Available Languages (just the KDE languages installed for now).  The whole list would be exported as LANGUAGE, with the first item exported as LC_MESSAGES and LANG.  This would then fit in the Formats kcm in place of the Region combo (and we'd rename the kcm as Locale).  The main problem I see here is it restricts the choice for LANG to only those locales that we have translations installed for, but allowing most LC_* to be overridden should counter that.  A variation might be that the Preferred Languages gets exported as LANGUAGE and LC_MESSAGES, but we keep the Region combo for LANG with a default text of "Use Preferred Language", but that just seems too confusing.

TBH, neither way is perfect, they each reflect the historic shortcomings of the whole POSIX Locale code scheme.


> On May 11, 2014, 6:59 p.m., John Layt wrote:
> > kcms/formats/kcmformats.cpp, line 294
> > <https://git.reviewboard.kde.org/r/118063/diff/1/?file=272244#file272244line294>
> >
> >     Shouldn't lcGlobal just be exported as LANG?  The lcCollate and lcCtype should be read form the config and exported in their own right?
> 
> Sebastian Kügler wrote:
>     lcCtype now checks if it's set from config, and if so, that's used, otherwise the global setting. I don't want to add another combo for this, as this setting is almost impossible to explain to the user, so it follows the global setting.

Fully agree, I don't properly understand it myself :-)


- John


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118063/#review57726
-----------------------------------------------------------


On May 12, 2014, 3:34 a.m., Sebastian Kügler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118063/
> -----------------------------------------------------------
> 
> (Updated May 12, 2014, 3:34 a.m.)
> 
> 
> Review request for Plasma and John Layt.
> 
> 
> Bugs: 331930
>     https://bugs.kde.org/show_bug.cgi?id=331930
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> -------
> 
> The current "Locale" KCM is almost entirely broken. The way forward is to split it into localization options (this, Formats), and translaticons. This patch implements a new Formats KCM which writes out an environment suitable for QLocale to pick it up.
> 
> It's a rewrite of the current KCM, since:
> - everything under the hood is different (KLocale is gone, QLocale takes over)
> - everything above the hood is different, in QLocale, everything is deduced from the country / region
> 
> Now this includes feature regressions compared to the old KCM, but not all of these features can be done at all on top of QLocale right now, so we have to set up what we can.
> 
> This KCM caches the settings in a config file, but most importantly, it writes out a script with export instructions, which can be picked up by startkde. This is all done according to John's suggestions, and I have a patch for startkde to pick up the settings here. It all works fine (on my machine).
> 
> Many more details about the implementation can be found in the plasma-devel thead "Locale settings in Plasma Next", started by John on February, 23rd 2014.
> 
> 
> Diffs
> -----
> 
>   kcms/CMakeLists.txt ed86efa 
>   kcms/formats/CMakeLists.txt PRE-CREATION 
>   kcms/formats/Messages.sh PRE-CREATION 
>   kcms/formats/formats.desktop PRE-CREATION 
>   kcms/formats/kcmformats.h PRE-CREATION 
>   kcms/formats/kcmformats.cpp PRE-CREATION 
>   kcms/formats/kcmformatswidget.ui PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/118063/diff/
> 
> 
> Testing
> -------
> 
> Tried all kinds of different combinations, applied them, made sure they're exported correctly in the script.
> 
> 
> File Attachments
> ----------------
> 
> new Formats KCM in kcmshell5
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/873980fe-04f2-4d75-9074-2aa676723061__formatskcm.png
> Formats KCM in systemsettings
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/86a830ed-2d5d-4bdd-ba82-71ec73e6ce2c__formatskcmss.png
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140512/48f20761/attachment-0001.html>

More information about the Plasma-devel mailing list