From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Call for locales maintainer & contributors
Date: Sat, 26 Jul 2014 23:27:58 -0400 [thread overview]
Message-ID: <20140727032758.GT4038@brightrain.aerifal.cx> (raw)
In-Reply-To: <CALONj1d5YoNpLHO6sh5PA3no1fapQ-TfRf6ru6+WjfrysbZLpw@mail.gmail.com>
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:
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
next prev parent reply other threads:[~2014-07-27 3:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-24 19:32 Rich Felker
2014-07-26 13:27 ` Olivier Goudron
2014-07-26 21:27 ` Wermut
2014-07-27 3:27 ` Rich Felker [this message]
2014-07-27 19:43 ` Wermut
2014-07-27 20:41 ` Rich Felker
2014-07-28 3:12 ` Isaac Dunham
2014-07-28 3:28 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140727032758.GT4038@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).