Plasma Next - Translations KCM - What Languages?

[Harald Sitter]

On Mon, Mar 17, 2014 at 1:03 PM, Chusslove Illich <caslav.ilic at gmx.net> wrote:
>> [: Harald Sitter :]
>> 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...
>
> I agree these would be nice. If noone steps up to design and implement a
> plugin system, at would be good if at least the code is sectioned in this
> way, so that a distribution-specific patch can be quite clean.

I could do that, what I have done with the kubuntu patch for 4.x
lately is going into the direction already.

>> Short of finding a plugin the KCM should default to the least weird
>> behavior, which IMHO is control languages the KCM knows are installed.
>
> For some distributions, like Debian, a package is a package: there is no
> concept of "installed language" (and frankly I find this stance the most
> appropriate). So, if the distribution does not provide the list of installed
> languages in some way, I don't see how can the KCM do anything in that
> respect.

On debian you have a list of possible locales and actively generated
locales (as per dpkg-reconfigure locales) IIRC, so while there's no
active mapping logic about what package provides which language for
what other package, there still is a concept of use languages vs.
possibly usable language.

> The KDE 4 definition of installed language is that for which the kde-runtime
> package installs the entry.desktop files. This is a vestige of early times:
> when translators showed up, translated the monolithic KDE in general, added
> entry.desktop into kde-runtime, and did anything else necessary in support.
> I think this stopped making much sense long ago. With Frameworks, which KDE
> package will have the authority to declare a language installed? And what
> would that mean, in terms of any guarantees to the user?
>
> Therefore, unless the distribution tells otherwise in some way, I proposed
> that the KCM by default allows selection of "all" languages, with clear
> statement what that selection means. For what is "all", I think the least
> complicated way should suffice: maintain an internal file mapping language
> name to language codes (could be more per language), which is initialized
> _from current kde-runtime. Or, maybe make use of the isocodes package, and
> internally keep only the special additions. When a language/code is missing,
> someone should ask for it to be added. What is language and what is code, is
> rather arbitrary; the person who requests it should provide rationale. The
> KCM should also allow manual entry of codes (appropriately out of direct
> sight).

Do we continue to use monolithic language packs (kde-l10n-fr)? If so,
then I still think the KCM has and ultimately must have the authority
to deduce which languages it can configure based on which kde-l10ns
are installed. Each of the tarballs would install a unique file for
the language so the KCM knows that this is actually installed and
configurable. Otherwise you run into exactly the problem Albert
highlighted, and in my opinion no amount of clarification in the UI is
going to make the end result any more entertainable for the user.
'Configured stuff -> nothing changed' is not really nice, even if that
is how the posix/gettext foundation works, and even if !kde
applications likely won't have appropriate translations installed. It
simply is no excuse to have the core workspace not translated.

>> I very much believe that we'll not only want LANGUAGE but also country in
>> some form or another.
>
> That is an even harder issue. Each locale provider has its own concept of
> country. For Glibc there is only the locale, there is no country as such to
> choose. KLocale did have a country to choose, but within it it could have
> multiple variants of some fields by "current" language code (whatever
> KLocale::language chose to return). Qt, I don't know what it has.

I pretty much had problems with mapping between what KLocale offered
and what the rest of the world was talking about all along with the
kubuntu patch. So here's a daring thought: How about having the KCM
not work with languages but actual system locales (e.g.
de_DE/de_AT/de_CH rather than simply 'de'). From the locale you can
always get the language, equally the locale represents what we
previously configured through the dedicated country setting
(numeric/date/.. formatting).
Ubuntu currently has something like this [1]. It has a ordered list of
locales; the top most will be expored as LANG; all active ones have
their language component split and joined with : to form LANGUAGE.

[1] http://i.imgur.com/rDlkRQn.png

HS