Re: BoF item 5/14: glibc locales



Digging back to an old post I meant to reply to earlier.

On Thu, Aug 2, 2012 at 4:04 PM, Gil Forcada <gforcada gnome org> wrote:
> Hi all,
>
> As I said in previous mails, let this mail be a kickstart for giving
> feedback about the items that are defined on
> https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012
>
> In this mail please give feedback about the glibc locales item.
>
> Cheers,
> --
> Gil Forcada

Quoting from:
https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012

glibc locales

Background:

Now and then new translation projects appear on GNOME i18n mailing
list. Sadly most of them needs to create a glibc locale, which is both
a tedious and a complex process in itself. Having some expertise and
knowledge about how the glibc locale does work, knowing who can help
on both creating the locale and getting the locale on glibc will
greatly help those new languages.

Bullet points:

    we need to gather some expertise on it

Gil,

This is an issue very near and dear to my heart.  By the nature of the
user communities that Sugar Labs seeks to serve, we are often involved
in assisting with the development of glibc locales for languages or
regions that are not currently represented in the glibc project.

I have taken it upon myself to reach out to people needing assistance
with glibc locale creation (usually off-list, but sometimes on-list).
In general,  I am happy to continue to perform this sort of
orientation, consultation and hand holding on the arcane art of
developing glibc locales.

For example, the initial message about nhn_MX, followed by a few
friendly off-list e-mails:
https://mail.gnome.org/archives/gnome-i18n/2012-August/msg00041.html

Has produced this ticket:
http://sourceware.org/bugzilla/show_bug.cgi?id=14501

I think we need to acknowledge that there are bigger problems with
regard to glibc locales, in particular their submission and correction
workflow, than the occasional message to this list and even the
technical complexity of creating one.

Claude Paroz has done excellent work on facilitating the constructing
the obscure Unicode code point required format for glibc locales.
http://lh.2xlibre.net/locales/

However, I think the core issue with glibc locales as it relates to
i18n/L10n is the fact that the responsiveness of the glibc team to
locale-related tickets is in need of real and immediate improvement.
Take a look at the list of pending localedata bugs filed against the
glibc component.

http://sourceware.org/bugzilla/buglist.cgi?product=glibc&component=localedata&resolution=---&list_id=5916

I have submitted locale patches that are obvious (even to an
English-only speaker), indisputably correct and entirely
uncontroversial that have been sitting in the queue for months with
out attention:
http://sourceware.org/bugzilla/show_bug.cgi?id=13950

Similar delays are encountered by people who have submitted new glibc
locale files.  This is a huge barrier to entry for new languages and
frankly it is all too easy to kill the momentum of a new language
effort.  It is critical to work with new language efforts while the
enthusiasm is high, so that it can be maintained by visible signs of
progress.

We all know that the glibc bug-tracker has long had a (well-deserved
and notorious) reputation as a very unfriendly place to interact with
the Gnome project.  What is needed is someone on the glibc team that
has a focus purely on the localedata and a modicum of basic social
skills that is willing to deal with newcomers to the Gnome world in a
welcoming fashion.

In addition, ideally something like the work that Claude has done on
his Locale Helper needs to be turned into a web-app like the CLDR
locale submission process Survey Tool and integrated into Gnome's SOPs
for locale submission.

Improving the "customer service" ethos of the glibc locale submission
process is essential and long overdue, facilitating it with a
user-friendly tool would be icing on the cake.

Just my thoughts. What are yours?

cjl
Sugar Labs Translation Team Coordinator


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]