>>> [: 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 (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
