|
Message-ID: <CALONj1dky0eZGj7ZGQyevmDR-N5=ZHJbT6Am5dNgKR5wZ2g5=g@mail.gmail.com>
Date: Sun, 27 Jul 2014 21:43:34 +0200
From: Wermut <wermut@...il.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Call for locales maintainer & contributors
Hi
With the exception of the musl translation itself, I think the most
parts are doable. My problem at the moment is, that I am not a C hero
like you guys and don't know exactly how these locale files should
look like (file format, content). As a consequence fully answering
your questions is non trivial at the moment. I can do some research
and do some dirty work, but first I would need a sample locale file in
the musl format, or some documentation to get kick started. I have
worked in the past and even created locale files for glibc and cldr,
so I am at least not a complete newbie on the topic.
Unfortunately I have not enough time to act as a maintainer, but I
could periodically help out if someone stands up and take the lead.
For the translation of musl itself: Do you plan to add a *.pot file to
the musl repository?
Regards
Kevin
On Sun, Jul 27, 2014 at 5:27 AM, Rich Felker <dalias@...c.org> wrote:
> On Sat, Jul 26, 2014 at 11:27:38PM +0200, Wermut wrote:
>> Hi
>>
>> I don't like the idea of an entirely new tree of locale data written
>> from scratch. Glibc has one (with a lot of unmaintained data) and then
>> there is also the CLDR repository which aims to be the central source
>> for such data, maintained by unicode. The CLDR data is also used as a
>> basis for the Microsoft and Apple locale files and is often maintained
>> by national language experts. What I could offer is an effort to write
>> some magic code that imports the actual CLDR data and converts the
>> relevant information to the musl formatted ones. The CLDR data is
>> freely available from: http://cldr.unicode.org/index/downloads
>
> I have no objection to using data from CLDR if there's no restrictive
> license, but at first glance it looks like most of the data is outside
> the scope of the C/POSIX locale system. What we need is:
CLDR license (botom of the page): http://unicode.org/copyright.html I
my eyes this is a BSD like license. If somebody thinks the license is
not OK, please say so. Copy is attached to this mail.
>
> 1. Weekday and month names (full and abbreviated) - these should
> almost certainly be available from CLDR or other public sources.
>
> 2. Time format strings for strftime - unless CLDR has C-oriented data
> like that, these might not be available in a form that's easy to
> automatically adapt. Research on this topic is welcome.
>
> 3. Regexes for yes and no responses - seems unlikely to be in CLDR,
> but again I'd be happy for someone to prove me wrong.
>
> 4. Translations of the message strings in libc. Note that musl's
> strings already deviate some from the legacy strings used on glibc
> and other systems. For example the strerror strings are adjusted to
> align more closely with the POSIX description and the actual
> situations they arise in than the legacy strings (like "Not a
> typewriter"). I'd like to aim to have our translated strings
> equally modernized. And before really spending a lot of work on
> these we should review the English strings again for possible
> improvements and missing messages (I think some newer error codes
> may be missing).
>
> 5. Collation rules - these almost certainly can come from Unicode/CLDR
> but musl does not even support collation yet.
>
> 6. Monetary formatting and currency names - these almost certain can
> come from CLDR or other public sources, but again the code to use
> the data isn't there yet.
>
>> Contribution is not completely open, but you normally interested
>> people get access if they want to. I got mine within a week.
>>
>> This is only a suggestion open to discussion. What do you guys think about it?
>
> Overall I like it. But I think we still need a maintainer to manage
> pulling the data, maintaining string translations for messages, etc.
> Any comments on my items 1-6 above?
>
> Rich
View attachment "unicode-license.txt" of type "text/plain" (2933 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.