On Fri, Mar 14, 2014 at 2:31 PM, John Layt <jl...@kde.org> wrote: > Hi, > > I'm doing some more work on the new KCM for Translations, i.e. the KCM in > Plasma Next to configure the LANGUAGE env var that startkde will export for > all apps running under Plasma Next to use, including Gtk as well as Qt apps. > Because this is now the workspace/desktop wide setting, and not the setting > for just KDE apps under all workspaces, the way the current KCM works may no > longer be valid.
I very much believe that we'll not only want LANGUAGE but also country in some form or another. > Do we just scan all the locale/*/LC_MESSAGES/* > or locale-bundle/*/LC_MESSAGES/* entries installed to get all the possible > languages (and what is the difference between locale and locale-bundle)? Or > do we list all languages regardless of whether they are installed or not > (probably way too many)? Since I have worked on that a bit for kubuntu, neither will be fine, neither will be nice. What we need is some plugin awesomeness (or equally fancy mechanism) to allow the distribution to put everything into context. The KCM wants to know what translations are available -> try asking a plugin. The KCM wants to set a new language order -> tell a plugin to make sure these languages are installed... Short of finding a plugin the KCM should default to the least weird behavior, which IMHO is control languages the KCM knows are installed. If we generally don't care about whether a language is installed or not, distributions will end up patching or not using the KCM, as it is really very useless to the user if it cannot *help* the user configure their language preference. Currently it still has some value as KLocale is distinct from the system's LANGUAGE. With that gone there is little point to the KCM if it cannot be made useful to distributions, we might as well have a very simply dummy implementation that doesn't do much and encourage distributions to write their own respectively tools. This however seems like a bit of a waste because the UI probably would largely be the same anyway, it's just the logic backing it that is grossly different across distributions (in particular with actually installing packages required for localization in the picture). If we decide to actually provide something sensible though, I already have random code :P. What kubuntu uses for SC4 is avaiable at kde:clones/kde-runtime/sitter/kubuntu branch kubuntu/locale/4.12.2; also diff at [1]. Deducing from that we'll need at least the following interfaces. Plugin API: - Language { string code; bool installed; } - getLanguages(): returns set of available languages - installLanguage(Language): install language, will need additional interfaces to communicate progress of installation (at the very least a signal 'readyForInstallation' indicating that it actually can install stuff, and 'installationProgressChanged' to indicate progress). In addition to that we'll probably want something like: - setGlobalLanguage(LANG, LANGUAGES, ...): sets the configuration system wide while allowing the distribution to run whatever weird maintenance scripts they need to have run; for this we could provide a generic implementation (requires calling locale-gen and fiddling with configs and /etc/environment, fiddling with configs however makes me wonder if it is a good idea to have an implementation ;)) [1] http://goo.gl/ZA2Gk4 HS _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel