Subject: Re: [Ltru] draft-16 (editor's copy) posted...

From: "Doug Ewell" <[email-masked]>
Date: Tue, 10 Jun 2008 18:42:31 -0600

Addison Phillips <addison at amazon dot com> wrote:

> I have just posted the editor's copy of draft-16 on inter-locale. Note 
> that Mark and I did some typo-fixing. I also made some more changes to 
> the Scope section per some messages on the thread that I had missed 
> (about making individual the default value). Diff links are available. 
> Check it out.

Thanks for making this change; it saved me from having to write (and the 
group from having to delete) a big long screed about the silliness of 
adding "Scope: individual" to 7,641 language and extlang subtags (97.7 
percent of the total).

I note that draft-16 still allows "Scope: individual" as a no-op, which 
still seems a bit silly, but I can ignore that.

Not that I mind, but was it a conscious decision to omit the word 
"local" (or "reserved" or "private") for the "qaa..qtz" record?  Most 
private-use language subtags will probably be meant for individual 
languages, but you never know: someone might dream up a new 'zxx'-like 
category.  (For people who like the idea of using the Scope field to 
identify the private-use range, I note that no similar facility is 
planned for script and region subtags.)

John Cowan <cowan at ccil dot org> wrote:

> 3.1.10: s/will have a Scope of 'macrolanguage'/& and vice versa/.

I think "vice versa" here is intended to mean "Many of the language 
subtags with a Scope of 'macrolanguage' will be prefixes for extended 
language subtags (although some will not)."  This is true only for small 
values of "many" and large values of "some"; only "sgn" plus six of the 
57 macrolanguages will be extlang prefixes.

Then:

> Plan 1:  Include both zh-cmn and cmn, and both zh-yue and yue, etc., 
> but deprecate zh-cmn in favor of cmn and zh-yue in favor of yue, etc.
>
> A) I prefer this plan.
> B) I can live with this plan.
> C) I cannot live with this plan.
>
> Plan 2:  Include both zh-cmn and cmn, and both zh-yue and yue, etc., 
> but deprecate cmn in favor of zh-cmn and yue in favor of zh-yue, etc.
>
> A) I prefer this plan.
> B) I can live with this plan.
> C) I cannot live with this plan.

B and B, again.

Mark Davis <mark dot davis at icu dash project dot org> wrote:

> At this point, I think it would be best to just find out just a thumbs 
> up or thumbs down on the following question:
>
> Can you live with draft 15 as the basis* for going forward?

I prefer the "Scope" treatment in -16 over -15.  I suspect most of the 
other -16 changes will be minor editorial tweaks, like changing 
"enclosed" to "encompassed," though I guess the Mandarin MAY/SHOULD 
debate still isn't dead.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 10 Jun 2008 21:10:08 -0700

(editor hat ON)
> adding "Scope: individual" to 7,641 language and extlang subtags

At your service...

> still seems a bit silly, but I can ignore that.

This is mostly to allow an erroneous entry with a status other than individual to be replaced with a positive registration of type 'individual'.

> "local" (or "reserved" or "private") for the "qaa..qtz" record?

Not conscious. I can add it in the next editor copy (tomorrow). Is 'private' or 'private-use' good enough? 'reserved' gives the wrong impression, I think, and 'local' is somewhat non-specific.

> 57 macrolanguages will be extlang prefixes.

See the specific text in draft-16. I didn't add "and vice versa" explicitly.

> d
> I prefer the "Scope" treatment in -16 over -15.

Since 'scope' is new, I would be surprised if some editing weren't required.

> I suspect most of
> the

(editor hat OFF)

The Mandarin MAY/SHOULD and related debates do need to be resolved, though. As indicated, I can live with either direction of deprecation, but I don't think I can live with co-equal representations.

Addison

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 11 Jun 2008 00:30:27 -0600

Addison Phillips <addison at amazon dot com> wrote:

>> I note that draft-16 still allows "Scope: individual" as a no-op, 
>> which still seems a bit silly, but I can ignore that.
>
> This is mostly to allow an erroneous entry with a status other than 
> individual to be replaced with a positive registration of type 
> 'individual'.

I don't understand.  Why should we make a rule that the Scope field can 
never be removed, and then create a "Scope: individual" value that has 
the same meaning as no value at all, but allows us to get around the 
rule?  If ISO 639-3 changes the scope of a language to Individual, why 
can't we just remove the value?  We allow "Macrolanguage" to be removed 
if ISO 639-3 changes that one.

> Not conscious. I can add it in the next editor copy (tomorrow). Is 
> 'private' or 'private-use' good enough? 'reserved' gives the wrong 
> impression, I think, and 'local' is somewhat non-specific.

I was trying to preserve the ISO 639-3 names for these things, in the 
same spirit as matching our Description fields exactly to the ISO 639-3 
names, down to the last hyphen, which some contend is important.  (We 
will actually have both "Macedo Romanian" and "Macedo-Romanian" for this 
reason.)  However, if the list doesn't feel there is a traceability 
problem, I'd be fine with 'private'.

> Since 'scope' is new, I would be surprised if some editing weren't 

Certainly.  I just didn't support freezing at -15.

> The Mandarin MAY/SHOULD and related debates do need to be resolved, 
> though. As indicated, I can live with either direction of deprecation, 
> but I don't think I can live with co-equal representations.

I agree, this would be the worst choice.

---

From: Peter Constable <[email-masked]>
Date: Thu, 12 Jun 2008 07:49:14 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Doug Ewell

> names, down to the last hyphen, which some contend is important.

Matching description fields and matching this particular property value are not the same. I think "local" is inappropriate in our context. (I don't like it in ISO 639 either, but the history there precedes me.) We use the term "private use" for this concept elsewhere in our spec, and that's what we should use for that concept here.

Peter

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 12 Jun 2008 08:05:02 -0700

> Matching description fields and matching this particular property
> value are not the same. I think "local" is inappropriate in our
> context. (I don't like it in ISO 639 either, but the history there
> precedes me.) We use the term "private use" for this concept
> elsewhere in our spec, and that's what we should use for that
> concept here.
>

I agree. In the text we can mention that private use corresponds to the value 'local' in ISO 639.

Addison