Plasma Next - Translations KCM - What Languages?

[Chusslove Illich]

(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 at ijekavian, sr at ijekavianlatin). Then sometimes
>> there is a change of language code (in the past e.g. sr at Latn -> sr at 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 (Часлав Илић)
-------------- 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/20140329/695f0408/attachment.sig>