Plasma Next - Translations KCM - What Languages?

[Chusslove Illich]

> [: 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.

> 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.

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).

> 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.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140317/c861c6eb/attachment.sig>