[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Plasma Next - Translations KCM - What Languages?
From:       Harald Sitter <sitter () kde ! org>
Date:       2014-03-24 13:12:20
Message-ID: CAEc+18FKqRV2LAFPzq6Kiu1b2d=U4Sw=jn-MPiyDfaPvqMHHQA () mail ! gmail ! com
[Download RAW message or body]

On Mon, Mar 24, 2014 at 12:36 PM, Chusslove Illich <caslav.ilic@gmx.net> wrote:
>> [: Harald Sitter :]
>> 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. [...] From the locale you can always get the language [...]
>
> Consider the following list of Glibc locales and the languages "codes" for
> Gettext-based translations that should come out:

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).

>   pt_BR.UTF-8        ->  pt_BR
>   pt_PT.UTF-8        ->  pt
>   sr_RS.UTF-8        ->  sr
>   sr_RS.UTF-8@latin  ->  sr@latin
>   zh_CN.UTF-8        ->  zh_CN
>   zh_HK.UTF-8        ->  zh_HK

Picking the most interesting example of sr_RS.UTF-8@latin, which will
be resolved in this order:

sr_RS.UTF-8@latin > sr_RS@latin > sr.UTF-8@latin > sr@latin >
sr_RS.UTF-8 >  sr_RS > sr.UTF-8 > sr > C

It might also map the encoding, not sure about that. Eitherway it will
arrive at language@variant before it tries language.

> 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.

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.

>> 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').
>
> Barring the above indefiniteness in the locale to language mapping, 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.

I thought Qt follows the platform rule, in this case glibc?

> Back to the big picture. There are different locale systems, and there are
> different translation systems. There is no consistency in names and codes,
> across the systems, and also within some systems. Hence, there is no way to
> handle all that both simply and deterministically. A capable translation/
> localization KCM should, at first, provide straightforward control for
> everything that is observed in the wild, no matter how expansive that turns
> out to be. Second, it can provide internal heuristics (extendable by
> translator input) and distro-specific hooks, such that the user can make
> some kind of fuzzy choice (e.g. "I want my user interface in Lower Saxon/
> German/English" and "I live in Germany"), and have the KCM prefill the
> settings for all the underlying systems, possibly install stuff through
> distro hooks, and allow for manual tuning of particular settings.

Considering everything we'd need two configurations (this is assuming
KDE language codes continue to not be system locale codes) :

## single-selection of system locale (primary config)
- defines LANG
- possibly separate settings for LC_* or LC_* always follows LANG
- allows selection of all locales the system offers

### Additional hooking capability
- distros can hook to detail what locales are available (completely
overrides what we may have detected)
- distros can hook to provide on-demand installation of packages for the locale
- distros can hook to set LANG/LC_* (includes possible system level
setup - e.g. localegen)

## single-selection of language (secondary, if nothing is configured,
primary takes effect, i.e. LANGUAGE will not be set and the language
component of the defined LANG locale will be used)
- defines LANGUAGE
- uses kde codes
- allows selection of all languages we know are available
(kde-l10n-foo must be installed), expected result is that one always
gets a localized experience
- allows translators and distros to define additional mappings that
will be used to expand LANGUAGE, such as

### Additional hooking capability
- distros can hook to detail what languages are available (completely
overrides what we may have detected)
- distros can hook to provide on-demand installation of packages for
the language
- distros can hook to set LANGUAGE
- translators can hook to define additional mappings that will be used
to expand LANGUAGE such that when one selects for example Low Saxon
(nds) the resulting value will be "nds:de" since the primary fallback
would probably be expected to be german, rather than english. this
allows translators to define a fallback to a possible base language as
well as gettext codes for whenever the kde code is different or the
kde code might not be present.

The grand result of it all should then be that the user can select
whatever locale settings they want (numeric formats etc.) as well as
whatever KDE localization they want.

Fulll hooking support on top of that ensures that the user has the
ability to select any locale/language (regardless of whether it is
installed right now), and all applications regardless of toolkit or
translation library may find suitable language codes in LANGUAGE to
provide an appropriate localization (regardless of whether the kde
language code is the a code used by gettext and friends).

HS
[prev in list] [next in list] [prev in thread] [next in thread]