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

List:       kde-i18n-doc
Subject:    Re: Mistake in l10n/de/entry.desktop
From:       John Layt <jlayt () kde ! org>
Date:       2014-06-28 13:10:41
Message-ID: CAM1DM6=fk841pVArDLsMLzTc=s4V5pdyemXF0vk71mMFehJWFg () mail ! gmail ! com
[Download RAW message or body]

On 26 June 2014 10:42, Sönke Dibbern <s_dibbern@web.de> wrote:

> thanks for clarifying things. Indeed CLDR is AFAICT another (smaller)
> category of problems than ISO standards. I learned only recently that kf5
> will depend on QLocale, with the effect, that I'm currently active on CLDR
> and feeding them data, which is in itself not that simple. Additionally I
> will have to try to organise enough (>20) people that get themselves an
> account and "vote" for my proposals (or make different ones). Additional
> problem here is that Qt apparently uses outdated CLDR files.

Qt updates the CLDR fields just before every point release, but old
releases can hang around for a long time: Qt4.8 especially hasn't been
updated for a while.  The problem actually is that nds support was
moved from CLDR core to Seed status in release 22, which are the
locales they consider not complete enough to be released.  There's no
obvious note in the commit log or Trac explaining why they did this,
and it looks fairly complete to me, so you may want to ask them why.
What's interesting is that Qt still has the locale listed as valid
because it appears in other files like likelySubtags.xml, which
suggests when they "demoted" nds they didn't do it fully.  In Qt we
could start including the Seed locales, but that would mean my
exercising judgement over if something is correct or complete and I'm
a little reluctant to do that.

Needing >20 people to approve changes seems rather excessive and
bureaucratic!  I really can't believe that they have that many people
involved for every language they support, especially when many of the
experts for smaller langauges may not be IT literate enough to
contribute.  Is there some cultural or governmental governing body
responsible for promoting/protecting nds that could help you?  Good
luck with it though.  The up-side to getting it through the CLDR
process is that almost everyone uses it, Apple, Google, IBM, even
Microsoft now uses it, so you'll start seeing nds support appearing
everywhere as a result.

> Please notice http://lists.kde.org/?l=kde-i18n-doc&m=139704818328753&w=2 (of
> which I - not being a coder - admittedly not understood every detail).

That looks to be the issue I discussed above?

>> The ISO codes work is taking the minimal CLDR support one step further
>> and adding more data fields and translation strings that KDE devs
>> need, with perhaps one day those features ending up in CLDR.
>
>
> Up to that point of time - where can I submit my data? :)

For the new ISO code stuff I'm writing for KF5?  It will automatically
tie into the existing KDE translation system, albeit probably using
Qt's tr() system.  It was one of the reasons for NIH and writing my
own, the langauges available in the other similar projects like
isocodes didn't match the set

For existing KDE4 stuff, depending on which things you're changing,
you need to either manually edit the l10n files in kdelibs for the
stuff in there, or the rest is done via the standard KDE i18n
workflow.

Cheers!

John.
[prev in list] [next in list] [prev in thread] [next in thread]