This is the mail archive of the
mailing list for the glibc project.
Re: Linux Foundation Collaboration Summit 2013: The GNU C Library.
- From: Marko Myllynen <myllynen at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 20 Mar 2013 17:45:36 +0200
- Subject: Re: Linux Foundation Collaboration Summit 2013: The GNU C Library.
- References: <5141E6A0 dot 4020604 at redhat dot com> <CAHdAatZ+BviR+FzVHr8+D9=kYmP291uRpOZFSVbhukPwJV=7mw at mail dot gmail dot com> <201303151543 dot 14597 dot vapier at gentoo dot org> <CAHdAatYUVYv+qWsBUeQNL4=pCKA_w3_QD6dA3Wq=ZTX-FYZnuA at mail dot gmail dot com> <5145F874 dot 5080809 at redhat dot com>
- Reply-to: myllynen at redhat dot com
On 2013-03-17 19:08, Carlos O'Donell wrote:
> On 03/16/2013 10:16 PM, Chris Leonard wrote:
>> On Fri, Mar 15, 2013 at 3:43 PM, Mike Frysinger <email@example.com> wrote:
>>> On Friday 15 March 2013 12:30:16 Chris Leonard wrote:
>>>> An area I would like you to touch on is the role of the GNU C Library
>>>> in internationalization (i18n) and localization (L10n) via it's
>>>> stewardship of the glibc locale files.
>>> glibc is important in this area, but i wonder if libicu isn't filling a bigger
>>> role. as you mention further along, cross-device portability is playing a
>>> huge factor in application development. for such projects, relying on glibc
>>> isn't feasible (since they often want to run on Android, iOS, OS X, Windows,
>>> etc...), so they turn to libicu which can do all of these platforms.
>> Nor will I disagree with your point that CLDR locales (used by libicu,
>> Mozilla, etc.) are increasingly important, but I will note that Carlos
>> is speaking at a "Linux Collaboration Summit" and in that context,
>> glibc locales are critical.
> That's correct. I see value in glibc having as much support for
> as many languages as possible. How that support is maintained or
> created is a unique and difficult problem.
FWIW, I could provide few additional comments about CLDR and glibc
locales based on experiences as being a member of the steering group for
the Finnish national localization initiative (Kotoistus) and also trying
to keep fi_FI in glibc up to date. As others above, I am not
agreeing/disagreeing with anything above but hopefully providing a point
or two for discussions at the Summit.
First of all, my personal impression is that CLDR gathers the world's
leading l10n/i18n experts together and at least in some cases (e.g.
Finnish/Finland) it can be considered authoritative (since the
aforementioned national project is working directly with CLDR - I
presume this happens with some other countries as well). CLDR gets lots
of updates (see for example the changes for the recent release 23 
which was released half a year after release 22) but it also covers
areas like keyboards for certain devices nowadays  which are
unrelated to glibc.
However, there are some categories defined in glibc locales which are
not (at least yet) in CLDR (like LC_NAME and LC_ADDRESS). Thus one can't
create a complete glibc locale file just based on CLDR data. And the
format used by CLDR and glibc locale files is very different. Although
there are certain categories (like LC_MEASUREMENT) where automated
conversion from CLDR data to glibc locale data would be trivial some
other categories would be much harder to parse and translate.
Also, an important non-technical point is that if one considers CLDR as
an upstream for a glibc locale then any issues should be discussed and
solved in the context of CLDR first. Depending on view, this might be
seen as a good or a bad thing. For the fi_FI case I mentioned, we went
through the differences manually and discussed on the items which
differed and updated CLDR and glibc accordingly . It was a notable
task but now that it's mostly done (some discussions still on going)
keeping both CLDR and glibc in sync should be much easier in the future.