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