[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:       Sönke_Dibbern <s_dibbern () web ! de>
Date:       2014-06-26 9:42:00
Message-ID: op.xh12kav4ku6xww () schwarz ! eeg-clearingstelle ! intern
[Download RAW message or body]

Op den 26.06.2014 schreev John Layt <jlayt@kde.org> Klock 10.10:

> On 25 June 2014 22:48, Sönke Dibbern <s_dibbern@web.de> wrote:
>> Am 24.06.2014, 19:16 Uhr, schrieb Luigi Toscano  
>> <luigi.toscano@tiscali.it>:
>
>>> Please note that in the long run those information will be taken from  
>>> ISO
>>> standards; John Layt is working on a new framework (KStandards is the
>>> temporary/work-in-progress name, no code available yet). So I would
>>> suggest to
>>> check if the information for your country (this is for everyone) are
>>> accurate
>>> in the relevant standards.
>>
>>
>> This is bad news.
>
> Not so bad actually :-)  I'm afraid Luigi has gotten a little confused
> here and mixed up my work on ISO codes with my work on switching from
> KLocale to QLocale and CLDR (although they are related).  For
> Date/Time formats we will no longer use our own data files via
> KLocale, but will instead use QLocale which currently uses the CLDR
> data files.  Later I will be switching QLocale to use the host
> platform localization facilities which on Linux will be ICU which also
> uses the CLDR data files.  The intention here is that we are
> consistent with the host platform, gain advanced features that would
> otherwise be hard for me to write and maintain, and remove a large
> additional dependency for people wanting to reuse our libraries.

> CLDR appears to have shipped nds support since version 1.7 in 2009.
> Looking at the CLDR survey tool
> http://st.unicode.org/cldr-apps/v#/nds// it shows they have nds
> specific date formats, but not nds specific time formats. Instead it
> will inherit from some other defaults, I'm not sure which.  If you
> think any of their data is wrong, it's really easy to submit
> suggestions for fixes using that same tool, it appears to be a very
> open process.

Hi John,

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.

>
> I checked the Qt5 code and it lists nds_DE as a supported locale.  The
> best way for you to check that everything is fine is to download the
> latest Project Neon ISO for Plasma 5 and test it for yourself
> (http://apachelog.wordpress.com/2014/06/20/weekly-plasma-5-live-iso/).
> Go into System Settings / Local / Formats and try set to nds.  I've
> had a quick look myself, and the list is unsorted so it's hard to be
> sure, but it's not listed in the available options, so that's a
> possible bug.  I'll have a deeper dig later today.

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

> 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? :)

Gröten
Sönke
[prev in list] [next in list] [prev in thread] [next in thread]