Plasma Next - Translations KCM - What Languages?

[Harald Sitter]

On Fri, Mar 14, 2014 at 2:31 PM, John Layt <jlayt at 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