Re: [PATCH 1/3] localedata: use same comment_char/escape_char in these files

[Mike Frysinger <vapier at gentoo dot org>]

On 11 Apr 2016 16:45, Chris Leonard wrote:
> On Mon, Apr 11, 2016 at 2:58 PM, Mike Frysinger wrote:
> > seeing as you can represent the concerns of these communities better
> > than probably any of us, it would be great if you could look into the
> > cldr process.  from my glances around there, it doesn't look *too*
> > hard to break in and start posting contributions, especially when you
> > have no one else representing those languages.
> 
> One of the joys of working with the Sugar Labs / OLPC community is
> that we find ourselves on the bleeding edge of new language-in-Linux
> introduction.  The substantial OLPC deployments in Peru have driven
> indigenous language work (Aymara, Quechua, Awajun, and others to
> come).  The same can be said of our work with deployments in Mexico
> and their languages as well as some others.
> 
> I am generally sympathetic with the notion of trying to drive both
> glibc and CLDR locale development forward together. and I have long
> wanted to leverage the excellent work of the "100 locales for Africa"
> project (in CLDR) into glibc locales as well.  The CLDR
> information/translation requirements are somewhat greater, including
> as it does portions of the Debian iso-code project strings (languages,
> countries, scripts, etc.).  However it is easy enough to simply
> locally host versions of those PO files from the Translation Project
> on the Sugar Labs Pootle instance to allow their accumulation to
> critical mass for CLDR development in the same manner that I had
> created a "glibc-helper.pot" file to collect the core translations of
> a glibc locale.
> 
> If I can get Pootle language setup information (plural numbers, plural
> equation) for the languages that exist in glibc, but not CLDR, I'll
> host some CLDR-relevant PO files and start looking to recruit
> interested localizers, but it must be understood that it is not
> particularly easy to find localizers for these languages, they have a
> very small footprint on the Internet.

my only clarification/semi-counter point is that getting languages into
CLDR probably has a wider impact than only getting into glibc.  that db
is pulled by a significant number of projects/companies (and i know for
a fact it's used internally at Google in conjunction with ICU).  if it's
only glibc though, that impact is entirely limited to people using glibc
as i don't think there's that many people downstream from glibc's locale
db.  and we want to try to automate/smooth the process for adding any of
the locales that exist in CLDR today but not glibc.

tl;dr: locales in glibc might get short term returns, but CLDR is the
       only long term answer.
-mike

Attachment: signature.asc
Description: Digital signature