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

[Mark Davis ☕ <[e-mail]>]

There are two very different issues: votes of the technical committee, and
the voting process used in deriving consensus on submitted locale data for
each release.

You seem to be focusing on the later, which is not relevant for this issue.
But just to prevent further FUD on it, I'll take a minute. The voting on
data is by organization, with administrators in the organization responsible
for setting the voting level for participants. Some organizations are full
voting (and paying) members of the consortium, while others are representing
liaison (gratis) members. For more information, see
http://cldr.unicode.org/index/process.

As to the issue of "I seem to remember a lot of Google data being
incorporated (dumped) into CLDR", Google data, like others' data, has been
contributed into CLDR. There were some problems with translators'
understanding of instructions and context, but that happens all the time, so
the committee ends up going through successive data resolution phases to
mediate any differences and adjust for problems. The process isn't
perfect--but no process could be, especially when we have to handle the
volume of data with each release, with over 600 locales and up to 3,000
values per locale.

As to the IETF not being willing to work with membership organizations,
well, that would preclude the Unicode Consortium, as well as many other
organizations like the W3C. For that matter you'd have to pay a lot to be an
ISO member, since you'd have to start your own country ;-)

Mark
*— Il meglio è l’inimico del bene —*


On Thu, Jul 7, 2011 at 10:00, Debbie Garside <[e-mail]>wrote:

> Let me elaborate further on this.  From memory, data in CLDR may be
> incorporated on a vote system,  This vote system is linked to the amount
> paid by companies by way of subscriptions.
>



> Or am I wrong?  I seem to remember a lot of Google data being incorporated
> (dumped) into CLDR against the wishes of experts in the field who had been
> working most diligently to make sure their data was correct.  A paid for
> votes system is contrary to the entire ethos of IETF where, I believe, a
> general consensus is required rather than paid votes and affiliations are
> not taken into account.  This is the basis for my concern.****
>
> ** **
>
> Maybe I am totally wrong and if so I apologise.  Please feel free to
> correct me.****
>
> ** **
>
> If I am right, there is still a way for Unicode to do this, as stipulated
> within the RFC, but rather by recommendation to the IETF-Languages Registrar
> who can then invite further discussion.****
>
> ** **
>
> Best wishes****
>
> ** **
>
> Debbie****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of
> *Debbie Garside
> *Sent:* 07 July 2011 17:01
> *To:* 'Mark Davis ☕'; 'Mykyta Yevstifeyev'
>
> *Cc:* 'Pete Resnick'; [e-mail]
> *Subject:* Re: [Ltru] Fwd: draft-davis-t-langtag-ext****
>
> ** **
>
> I am also concerned about the structure of the Unicode Committee and voting
> rights. Perhaps someone can explain how this will work and why it is
> required in addition to the current structure for the registration of
> language tags.****
>
> ** **
>
> Have I missed something here? (I probably have as I have been away from the
> list for some time)  Have Unicode already taken over some of the duties of
> the BCP47 registrar?****
>
> ** **
>
> Best wishes****
>
> ** **
>
> Debbie****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of
> *Mark Davis ?
> *Sent:* 07 July 2011 15:43
> *To:* Mykyta Yevstifeyev
> *Cc:* Pete Resnick; [e-mail]
> *Subject:* Re: [Ltru] Fwd: draft-davis-t-langtag-ext****
>
> ** **
>
> Thanks for the feedback. We can make those corrections.
> ****
>
> ** **
>
> One question. The primary reason that we chose to use a BCP was primarily
> because it provided a stable reference; the underlying RFCs can (and have)
> changed while "BCP47" has remained the same. Listing the current RFCs
> somewhat undercuts that. Note: if that is the practice we should do it, but
> it seems odd.****
>
> ** **
>
> Mark****
>
> *— Il meglio è l’inimico del bene —*****
>
> On Wed, Jul 6, 2011 at 20:55, Mykyta Yevstifeyev <[e-mail]>
> wrote:****
>
> Hello,
>
> I've identified the following issue in the draft.
>
> Section 2.2 says:
>
> ****
>
>    The subtags in the 't' extension are of the following form:****
>
> ** **
>
>      +--------+-------------------------+----------------------------+****
>
>      | Label  | ABNF                    | Comment                    |****
>
>      +--------+-------------------------+----------------------------+****
>
>      | t_ext= | "t"                     | Extension                  |****
>
>      |        | ("-" lang *("-" field)  | Source + optional field(s) |****
>
>      |        | / 1*("-" field))        | Field(s) only (no source)  |****
>
>      | lang=  | language                | [BCP47 <http://tools.ietf.org/html/draft-davis-t-langtag-ext-01#ref-BCP47>], with restrictions |****
>
>      |        | ["-" script]            |                            |****
>
>      |        | ["-" region]            |                            |****
>
>      |        | *("-" variant)          |                            |****
>
>      | field= | sep 1*("-" 3*8alphanum) | With restrictions          |****
>
>      | sep=   | 1ALPHA 1DIGIT           | Subtag separators          |****
>
>      +--------+-------------------------+----------------------------+****
>
>
> I should note that, first of all, reference to RFC 5234 is missing;
> moreover, and this is more important, making the ABNF definition in the form
> of table makes such definition an invalid one, in terms of RFC 5234.  Also,
> there are a number of ABNF nits here.  So, please consider changing this to:
>
> ****
>
>    The subtags in the 't' extension are of the following form, defined****
>
>    using ABNF [RFC5234] in <t-ext> rule:****
>
> ** **
>
>      t-ext    = "t" ("-" lang *("-" field) / 1*("-" field))****
>
>      lang     = langtag****
>
>      field    = sep 1*("-" 3*8alphanum)****
>
>      sep      = ALPHA DIGIT****
>
>      alphanum = ALPHA / DIGIT****
>
> ** **
>
>    where <langta> rule is specified in BCP 47 [BCP47], <ALPHA> and <DIGIT>****
>
>    rules - in RFC 5234 [RFC5234].****
>
> Also, the minors comments on references.  Reference to BCP 47 should
> include both references to RFC 5646 and RFC 4647, like:****
>
>    [BCP47]    Phillips, A. and M. Davis, "Matching of Language Tags", ****
>
>               BCP 47, RFC 4647, September 2006.****
>
> ** **
>
>               Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying****
>
>               Languages", BCP 47, RFC 5646, September 2009.****
>
> ...and, referencing UTS 35 you shouldn't reference specific parts of the
> document; this should be done in the text.  Finally, I don't see where
> [US-ASCII] is used in the text.
>
> Thanks,
> Mykyta Yevstifeyev****
>
>
>
> 07.07.2011 2:49, Pete Resnick wrote: ****
>
> Most of the people on the ietf-languages list are probably on the
> [e-mail] list as well, but I wanted to confirm that everyone got a
> chance to review this before it proceeded to the IESG. Please have a look at
> the ltru archive
> <http://www.ietf.org/mail-archive/web/ltru/current/maillist.html><http://www.ietf.org/mail-archive/web/ltru/current/maillist.html>and send any comments to the
> [e-mail] list since that's where discussion seems to be taking place.
>
> Thanks.
>
> pr****
>
> ** **
>
>
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ltru****
>
> ** **
>