Re: Plasma Next - Translations KCM - What Languages?
On Sunday 16 March 2014 15:49:02 Chusslove Illich wrote: > 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. This vision isn't fully true, though. Large software packages do come with splitted out translations, at least the way some distros package them. OK, I actually have only one example: libreoffice-l10n-af | African Localization Files for LibreOffice | package libreoffice-l10n-am | Amharic Localization Files for LibreOffice | package libreoffice-l10n-ar | Arabic Localization Files for LibreOffice | package libreoffice-l10n-as | Assamese Localization Files for LibreOffice | package libreoffice-l10n-ast | Asturian Localization Files for LibreOffice | package libreoffice-l10n-be-BY| Belorussian Localization Files for LibreOffice | package libreoffice-l10n-bg | Bulgarian Localization Files for LibreOffice | package libreoffice-l10n-br | Breton French Localization Files for LibreOffice | package [...] > I think that the only reasonable thing for Frameworks themselves is to ship > with translations as part of each framework. Yes. > Some packaging scripts will > have to be adapted to make this easy on the release person. Yes please !!! :-) > I would suggest > using the same system for everything else that was so far covered by > standalone language packages, and doing away with them. No opinion from me about workspace and apps. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next - Translations KCM - What Languages?
(Because of my screw up on reply, there are two messages in this thread which went only to kde-i18n-doc, sorry.) > [: Harald Sitter :] > At least with gettext there's fallback mechanisms in place, whether that > is an expected thing to have I do not know, certainly seems like a > sensible thing to have though (verification needed). In some cases the fallback will do the right thing, in same cases not. But, isn't this beside the point here? Since we are pondering how the locale/ language KCM should determine which languages are "available". The examples I picked were to illustrate that such determination based on Glibc locale names is problematic. >> [: Chusslove Illich :] >> Then there are language "codes" that are provided by KDE now, but have no >> Glibc locale to it (e.g. sr@ijekavian, sr@ijekavianlatin). Then sometimes >> there is a change of language code (in the past e.g. sr@Latn -> sr@latin, >> no_NN -> nn), where for quite some time the deprecated code should be >> supported. > > [: Harald Sitter :] > To be honest, I strongly believe all of this is a home made problem. If we > got codes created upstream in glibc rather than make them up ourselves, > there'd be no problem to speak of. And as far as I can tell glibc code vs. > gettext code is a 1:1 mapping, so then we might just be able to only talk > about locales and not locales+languages. In an ideal world, yes. But in a very, very ideal world. For Glibc, for example, special cases are strongly adversely affected by the D-factor (e.g. Serbian Ijekavian locales were turned down once). But even if the Glibc situation were all-clear on its own, Glibc/Gettext is not the only locale/ translation system. >> [: Chusslove Illich :] >> [...] what about Qt locales, which have nothing to do with Glibc locales. >> But other than that, yes, I too think there should be direct selection of >> the locale -- but for each locale system (Glibc/Qt/etc). And then the KCM >> should set LANG for Glibc, and so on for the rest. > > [: Harald Sitter :] > I thought Qt follows the platform rule, in this case glibc? In Qt I can see that it has internal definitions of locales. I don't know if and when Qt will use Glibc's definitions, and in what way. > Considering everything we'd need two configurations (this is assuming KDE > language codes continue to not be system locale codes): In the following you were specifying something more capable than just using Glibc locales, but... In my opinion, there are two approaches that can work. One is "locale/translation system Y is the whole world" (such as with some other DEs and Glibc/Gettext). Everything outside this system is just ignored. It is responsibility of every other locale/translation system to adapt itself to settings of locale/translation system Y, or not, and that's it. The other approach is a modular one. By examining the features of extant locale/translation systems, we define a set of abstract choices (e.g. "language" and "country") that are to be presented to the user. These choices are not directly related to any one locale/translation system on its own. This is one module. The second module is collecting the information on the system, in any number of heuristic ways, in orther to make a reduction of all possible choices (e.g. "available languages"). Here come distro- /platform-specific hooks and so on. The third module is making sure that any known locale/translation systems are initialized properly according to user's selection of abstract choices. It should also allow direct override of all elements, in advanced-something section. I think this is the only way to prevent spaggetization of the code. Furthermore, I think this system should be part of Frameworks themselves. KCM would be a simple wrapper around it. The benefit is that then we can keep the current feature of selecting "language" per application: instead of current half-baked solution, it would open a dialog which is exactly the same as the one in the KCM, allowing the user to tune exactly everything on the application level as can be done on the session level. -- 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
Re: Plasma Next - Translations KCM - What Languages?
On Mon, Mar 17, 2014 at 1:03 PM, Chusslove Illich 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next - Translations KCM - What Languages?
> [: 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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next - Translations KCM - What Languages?
On Fri, Mar 14, 2014 at 2:31 PM, John Layt wrote:
> Hi,
>
> I'm doing some more work on the new KCM for Translations, i.e. the KCM in
> Plasma Next to configure the LANGUAGE env var that startkde will export for
> all apps running under Plasma Next to use, including Gtk as well as Qt apps.
> Because this is now the workspace/desktop wide setting, and not the setting
> for just KDE apps under all workspaces, the way the current KCM works may no
> longer be valid.
I very much believe that we'll not only want LANGUAGE but also country
in some form or another.
> Do we just scan all the locale/*/LC_MESSAGES/*
> or locale-bundle/*/LC_MESSAGES/* entries installed to get all the possible
> languages (and what is the difference between locale and locale-bundle)? Or
> do we list all languages regardless of whether they are installed or not
> (probably way too many)?
Since I have worked on that a bit for kubuntu, neither will be fine,
neither will be nice.
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... Short of finding a plugin the
KCM should default to the least weird behavior, which IMHO is control
languages the KCM knows are installed.
If we generally don't care about whether a language is installed or
not, distributions will end up patching or not using the KCM, as it is
really very useless to the user if it cannot *help* the user configure
their language preference. Currently it still has some value as
KLocale is distinct from the system's LANGUAGE. With that gone there
is little point to the KCM if it cannot be made useful to
distributions, we might as well have a very simply dummy
implementation that doesn't do much and encourage distributions to
write their own respectively tools. This however seems like a bit of a
waste because the UI probably would largely be the same anyway, it's
just the logic backing it that is grossly different across
distributions (in particular with actually installing packages
required for localization in the picture).
If we decide to actually provide something sensible though, I already
have random code :P.
What kubuntu uses for SC4 is avaiable at
kde:clones/kde-runtime/sitter/kubuntu branch kubuntu/locale/4.12.2;
also diff at [1]. Deducing from that we'll need at least the following
interfaces.
Plugin API:
- Language { string code; bool installed; }
- getLanguages(): returns set of available languages
- installLanguage(Language): install language, will need additional
interfaces to communicate progress of installation (at the very least
a signal 'readyForInstallation' indicating that it actually can
install stuff, and 'installationProgressChanged' to indicate
progress).
In addition to that we'll probably want something like:
- setGlobalLanguage(LANG, LANGUAGES, ...): sets the configuration
system wide while allowing the distribution to run whatever weird
maintenance scripts they need to have run; for this we could provide a
generic implementation (requires calling locale-gen and fiddling with
configs and /etc/environment, fiddling with configs however makes me
wonder if it is a good idea to have an implementation ;))
[1] http://goo.gl/ZA2Gk4
HS
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next - Translations KCM - What Languages?
El Diumenge, 16 de març de 2014, a les 15:49:02, Chusslove Illich va escriure: > >>> [: 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, Is that happening? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next - Translations KCM - What Languages?
>>> [: 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
Re: Plasma Next - Translations KCM - What Languages?
El Divendres, 14 de març de 2014, a les 22:34:27, Chusslove Illich va escriure: > > [: John Layt :] > > Or do we list all languages regardless of whether they are installed or > > not (probably way too many)? > > 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". 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. Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next - Translations KCM - What Languages?
> [: John Layt :] > Or do we list all languages regardless of whether they are installed or > not (probably way too many)? 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". -- 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
Plasma Next - Translations KCM - What Languages?
Hi, I'm doing some more work on the new KCM for Translations, i.e. the KCM in Plasma Next to configure the LANGUAGE env var that startkde will export for all apps running under Plasma Next to use, including Gtk as well as Qt apps. Because this is now the workspace/desktop wide setting, and not the setting for just KDE apps under all workspaces, the way the current KCM works may no longer be valid. The current Languages KCM has two columns, "Available Languages" and "Preferred Languages". The Available Languages is populated with the list of all KDE translations installed by calling KLocale::installedLanguages(), i.e. all the QStandardPaths::GenericDataLocation/locale/*/entry.desktop files installed. Now, that seems a fine idea, until you think about non-KDE apps that may have other translation languages installed which won't get listed. Are we concerned about those? Is there a common cross-distro way to find out all languages that are installed? Do we just scan all the locale/*/LC_MESSAGES/* or locale-bundle/*/LC_MESSAGES/* entries installed to get all the possible languages (and what is the difference between locale and locale-bundle)? Or do we list all languages regardless of whether they are installed or not (probably way too many)? If we stick with just KDE translations installed, do we copy the KLocale::installedLanguages() code (will we still be installing the entry.desktop files?), or use the new KLocalizedString::availableApplicationTranslations() method which requires setting an Application Domain to define which LC_MESSAGES file to look for (if so, which one)? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
