Re: [Ltru] Fwd: draft-davis-t-langtag-ext

"Debbie Garside" <debbie@ictmarketing.co.uk> Fri, 08 July 2011 08:01 UTC

Return-Path: <debbie@ictmarketing.co.uk>
X-Original-To: ltru@ietfa.amsl.com
Delivered-To: ltru@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5198B21F874F for <ltru@ietfa.amsl.com>; Fri, 8 Jul 2011 01:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.692
X-Spam-Level:
X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L35pM4ctGG52 for <ltru@ietfa.amsl.com>; Fri, 8 Jul 2011 01:01:11 -0700 (PDT)
Received: from 145.nexbyte.net (145.nexbyte.net [62.197.41.145]) by ietfa.amsl.com (Postfix) with ESMTP id D655B21F874E for <ltru@ietf.org>; Fri, 8 Jul 2011 01:01:10 -0700 (PDT)
Received: from ICTPC ([78.145.15.218]) by 145.nexbyte.net with MailEnable ESMTP; Fri, 08 Jul 2011 09:01:16 +0100
From: "Debbie Garside" <debbie@ictmarketing.co.uk>
To: "'Steven R. Loomis'" <srl@icu-project.org>
References: <4E14F473.6030101@qualcomm.com> <4E152E4F.9070203@gmail.com> <CAJ2xs_Fm0NLOyL6PLps=77mb=o-gU2cCvi0=i0nj6NQJ01qnVw@mail.gmail.com> <075f01cc3cbf$0f04ba90$2d0e2fb0$@co.uk> <CAJ2xs_ED6pmF=t=0g9G5fUJH8GyM8X+G=_juC93uuw0JHtcsJQ@mail.gmail.com> <07be01cc3ce6$114dfc90$33e9f5b0$@co.uk> <1310071653.2702.3.camel@tehran.htpassport.net> <07de01cc3cea$c0b56930$42203b90$@co.uk> <1310075884.2702.21.camel@tehran.htpassport.net> <07fb01cc3cf3$16c46170$444d2450$@co.uk> <20110707182756.7333f020@naf.sanjose.ibm.com>
In-Reply-To: <20110707182756.7333f020@naf.sanjose.ibm.com>
Date: Fri, 8 Jul 2011 09:01:51 +0100
Message-ID: <083a01cc3d45$4c365a50$e4a30ef0$@co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
thread-index: Acw9DtbUXcoPM6XxTU65e0/PWxSODAANbkfA
Content-Language: en-gb
Cc: 'LTRU Working Group' <ltru@ietf.org>, 'CLDR list' <cldr@unicode.org>, 'Pete Resnick' <presnick@qualcomm.com>, 'Roozbeh Pournader' <roozbeh@htpassport.com>
Subject: Re: [Ltru] Fwd: draft-davis-t-langtag-ext
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2011 08:01:12 -0000

Hi Steven

Thanks.  I really am not trying to criticise CLDR.  I understand (somewhat) the problems and the needs of industry.  As already mentioned, I am a supporter of both Unicode and CLDR.  I will ask my colleague to speak with you about his concerns.

My concern here on IETF-LTRU is that a process is being taken out of IETF unnecessarily IMHO - at least from the responses received so far, I can see no added value in CLDR functioning as the Registrar for -t extensions.

Best wishes

Debbie



-----Original Message-----
From: cldr-bounce@unicode.org [mailto:cldr-bounce@unicode.org] On Behalf Of Steven R. Loomis
Sent: 08 July 2011 02:28
To: Debbie Garside
Cc: 'Roozbeh Pournader'; 'Mark Davis ☕'; 'Mykyta Yevstifeyev'; 'Pete Resnick'; 'LTRU Working Group'; 'CLDR list'
Subject: Re: [Ltru] Fwd: draft-davis-t-langtag-ext

Debbie,

I think that the concern about the data dump was due to some
 misunderstandings regarding the CLDR process. As the one who developed
 and manages major parts of the CLDR tooling (along with many others),
 I can say that the human users involved with the "data dump" (which
 was another misconception, that it was merely a one-way "dump") were
 very involved with the CLDR forum process.

We are hard at work to make the vetting process easier to use for
everyone. The sheer number of increased users and data the last time
around, brought to the forefront stability and performance issues that
were still unresolved. One of the issues is the amount of data that is
in a CLDR locale can be daunting, it would be in the tens of thousands
of data items. We've already introduced a system ('coverage') that lets
the user reduce what is shown normally to just critical items. This
system is already slated to be improved.  As well, we have some faster
hardware to run the server on that we will be testing out soon.

I realize that you are relaying a concern from a third party, but I
would invite your colleague to discuss the specific concerns with us if
they had not already.  One of the very exciting parts, for me, of this
process is that anyone regardless of other 'status' can (and does) sign
up and contribute data, and has a voice. Previous to the launch of the
CLDR project about eight years ago, this locale data existed in
multiple organization's repositories, where it would take a bug report
to cause any change.  Then I (and others in different companies,
independently) would have to look at the bug report and decide when and
if to spend time updating that data.  Now there is a process for
sorting out the data, and also a common repository and format for many
projects (both open-source and commercial) to pick up and use. It's not
a perfect process, but it's a process.

Regards,

Steven



On Thu, 7 Jul 2011 23:13:19 +0100
"Debbie Garside" <debbie@ictmarketing.co.uk> wrote:

> I will say just say a couple of things on this and then will let it
> go.  I really am not about attacking either Unicode or CLDR as I
> believe I am still a member (and have been since they last printed a
> hard copy - whenever that was).
> 
> I believe that CLDR has lost experts due to a data dump from Google
> that overwrote their work.  I had a face to face conversation with a
> colleague involved whilst in Korea three weeks ago.
> 
> Saying that all the core people are still there after 20 years does
> not address the issue of paying for votes - they may have been paying
> for 20 years.  In any case, I believe CLDR was created some 7 years
> ago (or maybe 8).
> 
> One could ask, how many people are on the proposed CLDR committee
> and, of these, how many are not attached to paying organisations?
> 
> Best wishes
> 
> Debbie
> 
> -----Original Message-----
> From: cldr-bounce@unicode.org [mailto:cldr-bounce@unicode.org] On
> Behalf Of Roozbeh Pournader Sent: 07 July 2011 22:58
> To: Debbie Garside
> Cc: 'Mark Davis ☕'; 'Mykyta Yevstifeyev'; 'Pete Resnick'; 'LTRU
> Working Group'; 'CLDR list' Subject: RE: [Ltru] Fwd:
> draft-davis-t-langtag-ext
> 
> On Thu, 2011-07-07 at 22:13 +0100, Debbie Garside wrote:
> 
> > I have heard from a colleague who has been instrumental in adding
> > 100 locales to CLDR that many volunteers are disillusioned and have
> > stopped contributing.
> 
> That's not because of committee voting. Maintaining and updating the
> data in CLDR locales uses a vetting procedure vastly different from
> the CLDR commitee itself. And I have seen the feedback from experts
> with limited voting right incorporated not only in CLDR data, but
> also in updates to the CLDR data vetting process. From what I've
> seen, most volunteer experts objections has been about not being able
> to keep up with the pace of data that comes from some full members.
> So, it's mostly been volunteer contributors (myself included) trying
> to slow down the process, instead of voting members. So contrary to
> what you think, it's the organizational and data support from the
> voting members that makes sure the process is fast enough. Not only
> it doesn't put development back for years, it's usually volunteer
> contributors who want the process slowed down so they can catch up.
> 
> Again, all of that is about "locale data", which is really very large
> amount of data. I don't think we can use that experience to see how
> the "t" extension will be maintained. A better comparison is how the
> Unicode Consortium and the CLDR committee has been maintaining the
> already-registered "u" extension. Do you know anybody who has had a
> problem with that?
> 
> > I would hate for IETF to find that they agree to "outsource" this
> > work and then find that their volunteer experts disappear.
> 
> Well, Unicode has been here for more than two decades, and I have yet
> to see expertise disappear from it. Not only that, but also almost
> all the core people are still contributing.
> 
> Roozbeh