From kde-panel-devel Sat Mar 29 21:35:32 2014 From: Chusslove Illich Date: Sat, 29 Mar 2014 21:35:32 +0000 To: kde-panel-devel Subject: Re: Plasma Next - Translations KCM - What Languages? Message-Id: <201403292235.32335.caslav.ilic () gmx ! net> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=139626658903005 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7905122529644745590==" --===============7905122529644745590== Content-Type: multipart/signed; boundary="nextPart4292990.Rtg7Hc8Uhi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart4292990.Rtg7Hc8Uhi Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable (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. =46urthermore, 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. =2D-=20 Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8= =D1=9B) --nextPart4292990.Rtg7Hc8Uhi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlM3PKQACgkQMSGXgigGr3FuKgCghlordYaBMjqS8rGKYYWS4VGM OXoAnikXPDmb0p283EOXIb/Y/VzJeSYS =LYV1 -----END PGP SIGNATURE----- --nextPart4292990.Rtg7Hc8Uhi-- --===============7905122529644745590== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============7905122529644745590==--