> On May 11, 2014, 5: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. > > John Layt wrote: > 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. >
Thanks for the link, I had been using the documentation at opengroup, which didn't say much at all about the gettext bits -- quite useful to know. :) I've now made the following change (plasma-desktop[sebas/locale]): - If [ ] details is unchecked, we now do not export LC_* at all, only LANG. They'll all fall back to LANG anyway, and the less env vars we touch, the better. So, with the Locale part sorted, we can "think the translations into the picture". I like the idea to have two separate KCMs for that. It brings balance into the UI, by adding one KCM to the left-hand-side, we save a top-level tabwidget (or something like that) in the Formats KCM. The LHS is quite empty otherwise, with only two options, adding one there has a lower affordance than adding another level in the KCM. You say that these things shouldn't mess with each other's config, but this is actually quite limited. Take the following cases (which I consider most likely): 0) User has installed distro, chose language from installer, environment is set up correctly, no action required from us. That was easy. 1) User has installed distro, but language is wrong. Goes into systemsettings, changes "Language" (LANGUAGE) setting. Logs out and back in again: Everything is correctly set to the language. This is the overlapping case: between the KCMs. In this case, the Language KCM should set LANGUAGE, LANG and LC_MESSAGES and leave LC_KITCHENSINK untouched. 2) User has changed language, but wants some setting overridden. User goes to the Formats KCM, which sets LANG, or LC_GUMMIBÄR. Expected behaviour ensues. 3) User wants to use default language (en_US) or whatever, but local currency, time, etc.. User Goes to the Formats KCM, changes values there. LANG is set, LC_MESSAGES is untouched (but might still be in the config, set by translation). (This User is me, actually. ;)) 4) Anything I forgot which would screw up? :) The translation and formatting settings are related, and they need to take each other into account. Trying to deny that in the code makes, as you note, little sense. In the Formats KCM, the logic is in writing the config, then we have a relatively dumb function that writes out the exports file from that config. This latter thing, and the underlying configuration layout (keys, basically) would need to be shared between the KCMs. That's quite easy to do, either by putting them both into the same subdirectory (but still install two separate KCMs), or otherwise by one of them including a file from the other. They're neighbors, so this would be quite a local thing. Both are based on the same config file (plasma-localerc), which is written out taking the Language and Format settings into account. There's otherwise no syncing needed since the orchestration of the exported variables all happens in writeConfig() (which both KCMs call in their ::save()). I like that approach for the balance it brings to the UI. The Formats KCM is already a bit cramped, and adding the Translation option there would make it feel even more cramped. (We are at 6 comboboxes already, adding even more ui there would make it a really complex beast). I see this much more as an "Advanced" piece of UI. The focus should clearly lie on enabling the workflow that the user wants to use one common setting for the translation. Separate KCMs would allow to hide the complexity "behind" the top KCM in window, which presents a somewhat nice way to pick a language (from whatever is installed, or install it), and add one or more fallback languages. We could keep this quite clean by not using the two-sided selection widget monster, but a more prominent list with one or two items, and a plus buttons which lets the user add more languages. For now, the two-sided selection thing could even do, until we have something nicer. It's important to the get functionality in no w, as we have a dysfunctional system at the moment. Let's try to fix this first, and then make it nicer. The language picker wouldn't even be a regression, just a transplanted / ported feature. As to the "which languages to show?", I'd say let's go with our own for now, and add others later. This could perhaps use some hooking into packagekit or so in order to install language packs that might be missing. I think we can rely on the distro for now. Leaving this as-is for now would, anyway, not be a regression. Some unrelated changes that came to mind in the overall category: - Change systemsettings category name to "Language & Region", reason: "Locale" is a very technical term, and although correct and precise, it's not a commonly known term outside a group of techies. "Language & Region" conveys the same, in an understandable manner. - "Spell Checker" -> "Spell Checking": Less "configure a component of the system", more "what the system does for the user. Minor change, but I think a nice improvement to the tone. - Sebastian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118063/#review57726 ----------------------------------------------------------- On May 12, 2014, 2: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, 2: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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
