public inbox for libc-locales@sourceware.org
 help / color / mirror / Atom feed
* Re: CLDR support?
@ 2016-05-13 22:43 Steven Loomis
  2016-05-14  6:43 ` Chris Leonard
  0 siblings, 1 reply; 3+ messages in thread
From: Steven Loomis @ 2016-05-13 22:43 UTC (permalink / raw)
  To: libc-locales

Dear [g]libc-locales,
  I read with interest the message from last week
https://sourceware.org/ml/libc-locales/2016-q2/msg00246.html

In particular from Mike Frysinger:
>we have recently started a process to try and align the two bodies so we aren't duplicating effort.

What is the status of this process? Would it be helpful to have some discussion with the CLDR-TC?

Regards,
Steven




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CLDR support?
  2016-05-13 22:43 CLDR support? Steven Loomis
@ 2016-05-14  6:43 ` Chris Leonard
       [not found]   ` <777A9AA2-6533-42F6-BC80-C799EF9A486C@icu-project.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Chris Leonard @ 2016-05-14  6:43 UTC (permalink / raw)
  To: Steven Loomis; +Cc: libc-locales

On Fri, May 13, 2016 at 6:40 PM, Steven Loomis <srl@icu-project.org> wrote:
> Dear [g]libc-locales,
>   I read with interest the message from last week
> https://sourceware.org/ml/libc-locales/2016-q2/msg00246.html
>
> In particular from Mike Frysinger:
>>we have recently started a process to try and align the two bodies so we aren't duplicating effort.
>
> What is the status of this process? Would it be helpful to have some discussion with the CLDR-TC?
>
> Regards,
> Steven


I think such a discussion would be helpful.  glibc locales and CLDR
locales are substantially overlapping subsets, with similar overall
diffs in terms of unique languages covered. CLDR requires more
translation effort (given the ISO language, country and script
elements included), but this is not an insurmountable obstacle to
"upstreaming" unmatched glibc locales or even less so to
"downstreaming" unmatched CLDR locales.

The real challenges come in agreeing on certain corner cases where
glibc uses a more specific ISO code for a language (e.g. quz for
Quechua (Cuzco-Collao) instead of rolling up to the qu macro-language
code).  As the commiter of the quz locale and having contact with
Quechua-speakers and a substantial body of potential users in Peru, I
have concerns about the indiscriminate clustering of distinct
languages  (e.g. quz, quy) under macrolanguage codes like qu.

Such matters are clearly amenable to reasoned discussion (including
stake-holder input) and compromise, as there is a shared commitment to
use of appropriate standards and only minor differences in how to
apply them in a given case.

cjl

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CLDR support?
       [not found]   ` <777A9AA2-6533-42F6-BC80-C799EF9A486C@icu-project.org>
@ 2016-05-15  6:19     ` Chris Leonard
  0 siblings, 0 replies; 3+ messages in thread
From: Chris Leonard @ 2016-05-15  6:19 UTC (permalink / raw)
  To: Steven R. Loomis; +Cc: libc-locales

On Sun, May 15, 2016 at 1:20 AM, Steven R. Loomis <srl@icu-project.org> wrote:
> Chris,
>
> After I sent the previous note, I remembered that cldr and glibc are
> actually related datasets -- given
> http://unicode.org/iuc/iuc18/papers/a2-paper.pdf  and commits such as
> http://sourceware.org/git/?p=glibc.git;a=commit;h=5d96a5f68915ac7edbe54b1ebfaf9c7c500fdd1c
> - some data was extracted from the dataset that was to become cldr.

Both of your referenecs are 15 years old, interesting from a
historical perspective, but not very relevant to the current
situation.

> I'm neither authorized nor informed enough (not sure which I'm less of) to
> make a statement about qu/quz/quy but I will say that cldr now has
> mechanisms to potentially have quy and quz inherit from qu- so any
> distinctions could be represented without wholesale duplication of effort. I
> also know that qu and other locales in South America have seen increased
> attention in the past two years in cldr.

Yes, the emergence of the indigenous languages of Central and South
American indigenous languages in FOSS is an important trend, making it
all the more important to not forestall the advancement of additional
languages by rolling up to macrolanguage codes as a default.  You or I
would hardly be satisfied with one 'Romance language" locale.

>  What's the right way forward? I'll bring this up on cldr's weekly call.

I've been pondering that question.  I think a consultation with
stakeholders, including speakers and providers of services (e.g. MinEd
Peru) to those langauge communities would be important.

cjl

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-05-15  6:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-13 22:43 CLDR support? Steven Loomis
2016-05-14  6:43 ` Chris Leonard
     [not found]   ` <777A9AA2-6533-42F6-BC80-C799EF9A486C@icu-project.org>
2016-05-15  6:19     ` Chris Leonard

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 read-only IMAP folder(s) and NNTP newsgroup(s).