Re: Linux Foundation Collaboration Summit 2013: The GNU C Library.

[Marko Myllynen <myllynen at redhat dot com>]

Hi,

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 <vapier@gentoo.org> 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 [1]
which was released half a year after release 22) but it also covers
areas like keyboards for certain devices nowadays [2] 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 [3]. 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.

1)
http://unicode.org/cldr/trac/query?milestone=23dsub&milestone=23dres&milestone=23&revw=!
2) http://unicode.org/Public/cldr/23/
3) http://sourceware.org/bugzilla/show_bug.cgi?id=12962

Cheers,

-- 
Marko Myllynen