Plasma Next - Translations KCM - What Languages?

[Chusslove Illich]

>>> [: John Layt :]
>>> Or do we list all languages regardless of whether they are installed or
>>> not (probably way too many)?
>>
>> [: Chusslove Illich :]
>> I would rather go this way, have this finished once and for all. I would
>> only try to clearly present it not as "you will get this language when
>> you choose it" but as "this is the list of your preferred languages, you
>> get first there is".
>
> [: Albert Astals Cid :]
> Is this really usable? I could choose three languages just to see i still
> get my text in english and then say "this is crap, KDE is not translated
> to any language" without realizing i actually have to install those
> languages translations.

With standard Gettext approach it was always like this: user language
selection are preferred languages, not necessarily available. The user sets
LANG for the locale and the single main language, and possibly LANGUAGES for
special order of preference. In GUI context, the login manager lets user
chose one of the locales and that's it. If some translation is available but
not installed, no hand-holding.

With the intention being that the KCM now controls LANGUAGES, i.e. that it
can set the language for all Gettext-using software in the session, I don't
see how we could even define "available languages". Looking through usual
system locations with MO files does not mean all MO files will be found;
even for those that are found and languages collected, the user might use
entirely different set of software, that has no translation in the chosen
language.

The related problem for me is this: why are there still standalone language
packages for some of KDE software (the SC)? Other than historical reasons,
the only advantage I see is installation space. But I don't see anyone
complaining about all the other Gettext-using software coming with all
translations. In fact, for me installing the standalone language package is
always one more thing to remember to do, or to explain to people that they
should do.

I think that the only reasonable thing for Frameworks themselves is to ship
with translations as part of each framework. Some packaging scripts will
have to be adapted to make this easy on the release person. I would suggest
using the same system for everything else that was so far covered by
standalone language packages, and doing away with them.

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