Subject: [Ltru] diffs, changes, etc.

From: Addison Phillips <[email-masked]>
Date: Mon, 11 Sep 2006 11:38:17 -0700

All,

I just submitted draft-00 to the I-D editor.

My home page is up-to-date, although I need to do some clean up. The 
HTML wdiff can be found by using this link:

    http://tinyurl.com/qtmag

Changes:

1. The RFC Editor and AUTH48 changes for RFC 4646 have been incorped.

2. I added references to ISO 639-3.

3. I added rules for adding language and extlang tags to Section 3.4 
(this was done this morning). I'm not married to these, but tried to 
incorporate extlangs according to discussion to date, as well as a 
special case for sign languages.

4. I removed text pertaining to the conversion from 3066 unless it was 
necessary for document understanding.

5. I changed the section discussing registry conversion rules 
substantially. In particular, I tried to remove all conversion rules and 
merely cited the new draft-initial, whatever that is, as the place to 
find these. I purposely avoided defining how the registry gets updated. 
Note that the reference to "4645bis" is not correct (of course).

6. I changed 'variant' validation along the lines I previously proposed, 
although I recognize that this is not a resolved issue.

7. I cut down the acknowledgments list. I will add names as I 
incorporate textual suggestions.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 12 Sep 2006 02:16:31 +0200

> http://tinyurl.com/qtmag

Thanks, I just read it top down, some mostly minor points:  

---
(2.2.8)
| Those that would not be well-formed according to the ABNF
| in this document or that contain subtags that do not
| individually appear in the registry are maintained in the
| registry in record of the "grandfathered" type.

s/record/records/.  Maybe s/Those that/Other tags which/ plus
s/or that contain/or contain/.  When I first read 2.2.8 I
hallucinated "Those tags" instead of "Those that", continuing
the statement about "redundant".  You could also split 2.2.8
in two paragraphs, the second paragraph about "grandfathered".

---
2.2.9:  Right, that's the validation issue.  Maybe we find a
better example than es-Latn-CO-x-private for 4646bis.  If the
rules are changed as you want it the old example is complete
overkill - and it's also unrelated to prefixes for variants.
   
--- 
3.1:  Nit, why do we define a field-body in the ABNF, and later
use field-value in the prose ?  

Apparently s/field-value/field-body/g is okay (there could be
cases with multi-line bodies where a distinction is necessary,
but not for 4646bis)

---
3.1, near "The field 'Deprecated' MAY" etc.:  Please check why
your spell-checker proposed to add a comma after "Usually" and
after "In some historical cases".  Apparently it also likes a
serial comma (?)

---
3.1, "'Suppress-Script' MUST only appear in records whose
'Type' field-value is 'language'".  Do we want to keep this as
is, or allow Suppress-Script for extlang records ?  If we keep
it as is, are tags with extlang subtags supposed to inherit the
Suppress-Script of the primary tag (if any) ?

---
3.3 s/[initial-registry]/[RFC 4645] and [4645bis]/ (?)  Please
strike the part about art-lobjan, it confuses me - especially
where you talk about a hypothetical variant lobjan eligible
for registration.

---
Omigod, now I get it, are all those comma and s/which/that/
modifications Rfc-editor changes ?  They should post a manual
of style (or its URL).

---
3.4.3
| If a prefix is added to a record that does not contain the
| same primary language subtag as an existing prefix, one
| 'Comment' field per prefix SHOULD be added to record
| explaining the different usages.

Proposal (simplification):
: If a prefix is added to a 'Variant' record, 'Comment' fields
: SHOULD explain different usages per primary language subtag.

It's only relevant for variants, and the SHOULD is only for
different languages.  Not if somebody adds say de-BE to 1996.

---
3.4.9  In essence that says "once an extlang-monster always an
extlang-monster".  IMO it should be allowed to deprecate the
convoluted extlang-monsters in favour of new 639-1 or 639-2
codes as soon as they are available.  This would also affect a
MUST NOT in the "Preferred-Value" chapter, so that's a major
point (but still compatible with 4646).

---
3.4.10  Same here.  Let's get rid of extlang-monsters a.s.a.p.

The MUST NOT about 'Preferred-Value' is anyway dubious:  If a
script "Flat" is deprecated recommending to use "Altn", then
why should the registry not say so (in addition to noting this
deprecation) ?

---
3.4.12:  Related, replacing an extlang foo by a language foo
is a good idea where possible, not a MUST NOT.  The MUST NOT
affects an unrelated foo (without replacing the extlang foo),
and the opposite attempt, adding a new extlang foo where an
ordinary language tag foo already exists (related or not).

---
3.5
Remove "reserved for future standardization. These subtags
will be" (that results in ...subtags are REQUIRED...)

| Note: The purpose of the "Description" in the registration
| is to aid to people
s/"Description"/"Reference"/ (this is unrelated to the field)
s/to aid to/to aid/

---
3.6
| The addition or maintenance of fields (generally of an
| informational nature) in Tag or Subtag records as described
| in Section 3.1 and subject to the stability provisions in
| Section 3.4.

This sentence no verb, s/as/is/ (?)

---
3.8 s/IANA SHALL/IANA is asked to/.  Same procedure as last
year, I don't like 2119-keywords while talking to IANA... :-)
---
5.1:  Same here.

I had completely forgotten how *_long_* this text actually is.

Frank

---

From: Addison Phillips <[email-masked]>
Date: Mon, 11 Sep 2006 21:53:29 -0700

Thanks for the first substantial read-through. Comments follow.

Frank Ellermann wrote:
> s/record/records/. 

Good catch. Done.

  Maybe s/Those that/Other tags which/ plus
> s/or that contain/or contain/.  

I made the first one "Of those tags, those that..." which makes the 
second one "Those tags that..."

When I first read 2.2.8 I
> in two paragraphs, the second paragraph about "grandfathered".

I made the split. The rewrite above addresses weaknesses in both our eyes.

> overkill - and it's also unrelated to prefixes for variants.

It could be a prefix for a variant. It is overkill, but it does 
illustrate the point completely. The main question is: validate prefixes 
or not?

> cases with multi-line bodies where a distinction is necessary,

Yuck. How did *that* slip by? Performed s/field-value/field-body/g

> after "In some historical cases".  Apparently it also likes a

Heh heh heh. It's the insidious comma disease of the RFC Editor. It is 
correct, so it's here. They also like serial comma (I usually do too, 
but Harald didn't appear to) and have an allergy to colons (full and 
semi). The "which/that" mistakes are my fault entirely.

> Suppress-Script of the primary tag (if any) ?

I kept this as is out of a certain kind of parsimony. The question is 
whether there is ever a case where 'xx' is written in more than one 
script but 'xx-yyy' or 'xx-yyy-zzz' is written customarily in one 
script---and we need to call it out.

I think the answer is no, since Suppress-Script is a kludge for 
*existing* tag compatibility. Since there are no existing extlangs, they 
don't need the kludge :-).

> where you talk about a hypothetical variant lobjan eligible

I need to fix the 4645/4645bis references.

I always thought the 'art-lojban' example referred to the first part of 
the sentence. It would be better to cite something like '-scouse' 
(although John Cowan is trying to exterminate our example!!).

> modifications Rfc-editor changes ?  They should post a manual

Bwah-ha-ha-ha. Yep.

> different languages.  Not if somebody adds say de-BE to 1996.

:: shudder :: my text is impenetrable, no? I don't understand why you 
wouldn't want an explanation for longer prefixes though... especially 
for a mere recommendation.

How about (very subtly different from yours):

--
If a prefix is added to a variant record, Comment' fields SHOULD be used 
to explain different usages with the various prefixes.
--

> extlang-monster".  

Yes. I'm following the idea that "one a canonical tag/always the 
canonical tag".

> IMO it should be allowed to deprecate the

The problem is that ISO 639-2 might find a few tags that are "promoted" 
from ISO 639-3. If we have 'yue' enclosed by 'zh' today, we don't want 
to have "zh", "zh-yue" and "yue" being used interchangeably (as 
prefixes). Among other things, that breaks matching in particularly 
uncomfortable ways.

> 3.4.10  Same here.  Let's get rid of extlang-monsters a.s.a.p.

The only way I see to do that is to prohibit them ex post facto.

> why should the registry not say so (in addition to noting this

I'd be willing to consider deprecation of codes "best forgotten as 
mistakes". But not for recycling codes as various kinds of subtag. 
That's messy.

> ordinary language tag foo already exists (related or not).

Except 'foo' is not unrelated. Since 639-2 and 639-3 share a code space, 
'foo' MUST have the same meaning in both. What this says is: you won't 
find "Foo-ese" with two different tag forms. It's xx-foo or it's foo. 
Period.

We can and should debate this point.

> will be" (that results in ...subtags are REQUIRED...)

Good catch. I put:

--
<t>Extended language subtags MUST include exactly one 'Prefix' field.</t>
--

> s/"Description"/"Reference"/ (this is unrelated to the field)

I made the sentence:

--
Note: The purpose of the "Reference to published description" section in the
registration form is to aid in verifying whether a language is 
registered or what language or
language variation a particular
subtag refers to.
--

> This sentence no verb, s/as/is/ (?)

It's the formatting that's confusing here. Each bullet item dangles from 
the trailing "includes:" above the list.

> year, I don't like 2119-keywords while talking to IANA... :-)

Oddly, this is what we did last time. Still, making "SHALL" into "will" 
was easy enough.

> 5.1:  Same here.

Cleansed.

> I had completely forgotten how *_long_* this text actually is.

And it lost several pages during this edit!!

Thanks again,

Addison

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 12 Sep 2006 08:32:44 +0200

Addison Phillips wrote:

>> better example than es-Latn-CO-x-private for 4646bis.  If
>> the rules are changed as you want it the old example is
>> complete overkill - and it's also unrelated to prefixes for
>> variants.

> It could be a prefix for a variant. It is overkill, but it
> does illustrate the point completely.

If we drop variant-validation let's better use a simple extlang
example.  And if we keep it let's use an example relevant for a
variant and get rid of the -x-private part.

> The main question is: validate prefixes or not?

If we replace SHOULD by MUST elsewhere (eliminating generic
variants) validating the prefixes is in theory possible.  Like
it's possible to validate extlang prefixes (with an obsolete
copy of the registry it can fail).  I'm not sure about this.

---
> They also like serial comma (I usually do too,
Me too, mainly because it's the only English comma rule I know.

>> 'Type' field-value is 'language'".  Do we want to keep this
>> as is, or allow Suppress-Script for extlang records ?  If we
>> keep it as is, are tags with extlang subtags supposed to
>> inherit the Suppress-Script of the primary tag (if any) ?

> I kept this as is out of a certain kind of parsimony. The
> question is whether there is ever a case where 'xx' is
> written in more than one script but 'xx-yyy' or 'xx-yyy-zzz'
> is written customarily in one script---and we need to call
> it out.

> I think the answer is no, since Suppress-Script is a kludge
> for *existing* tag compatibility. Since there are no existing
> extlangs, they don't need the kludge :-).

Plausible.  And if 'xx' has a Suppress-Script, does this affect
'xx-yyy' ?  Somewhere you have "add guidlines here" as an open
question, that could be a point.

---
>> 3.3 s/[initial-registry]/[RFC 4645] and [4645bis]/ (?)
[...]
> I need to fix the 4645/4645bis references.

In 3.3 you apparently need both.

> I always thought the 'art-lojban' example referred to the
> first part of the sentence. It would be better to cite
> something like '-scouse' (although John Cowan is trying to
> exterminate our example!!).

If it's gone we can't use it.  For art-lobjan the language has
now its own ordinary tag, therefore registering lobjan as a
variant for that language (prefix) makes no sense.  It could be
used for an unrelated dialect of another language.  I thought
that's the point of this example.  What's the real point, in
what sense is lobjan "eligible to be registered" ?

---
> I don't understand why you wouldn't want an explanation for
> longer prefixes though...

If it's interesting I want it.  But that's no general SHOULD,

> If a prefix is added to a variant record, Comment' fields
> SHOULD be used to explain different usages with the various
> prefixes.
> --

Okay, now "different usages" is better visible, and the SHOULD
won't justify to add "de-BE is used for German in BE" comments.

---
> The problem is that ISO 639-2 might find a few tags that are
> "promoted" from ISO 639-3. If we have 'yue' enclosed by 'zh'
> today, we don't want to have "zh", "zh-yue" and "yue" being
> used interchangeably (as prefixes). Among other things, that
> breaks matching in particularly uncomfortable ways.

On the other hand yue is shorter than zh-yue, and we mention
"shortest" in another chapter.  A strategy like "take 639-1,
if that fails take 639-2 (plus details), and if it still fails
take 639-3 (as extlang if necessary)" is simple.  Adding steps
"and verify if it's registered" wasn't necessary for 3066/4646.

---
 [MUST NOT Preferred-Value]
> I'd be willing to consider deprecation of codes "best
> forgotten as mistakes". But not for recycling codes

Yes, cases like iw, where the registry offers he.  The MUST NOT
apparently says "this must never happen again", and that's IMO
too optimistic for a zoo with several thousands new 639-3 tags.

Frank

---

From: John Cowan <[email-masked]>
Date: Wed, 13 Sep 2006 01:57:25 -0400

> semi). The "which/that" mistakes are my fault entirely.

Leaving out serial commas can cause dreadful ambiguities:

	I dedicate this thesis to my parents, Ayn Rand[,] and God.

Putting them in can never hurt.

But as for the supposed which/that rule, it does not exist except
in the fantasies of "usage" book authors who copy it from their
predecessors.  See:

http://itre.cis.upenn.edu/~myl/languagelog/archives/000918.html
http://itre.cis.upenn.edu/%7Emyl/languagelog/archives/001464.html
http://itre.cis.upenn.edu/~myl/languagelog/archives/001467.html
http://itre.cis.upenn.edu/%7Emyl/languagelog/archives/002189.html
http://itre.cis.upenn.edu/~myl/languagelog/archives/002205.html

and many others.

-- 
John Cowan   [email-masked]    http://ccil.org/~cowan
Original line from The Warrior's Apprentice by Lois McMaster Bujold:
"Only on Barrayar would pulling a loaded needler start a stampede toward one."
English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to
lose support instead of finding it when you threat with the charged weapon."

---

From: Martin Duerst <[email-masked]>
Date: Fri, 15 Sep 2006 15:20:09 +0900

>I just submitted draft-00 to the I-D editor.

There is a 'changes from RFC 4646' section. Given material changes
from RFC 4646 are supposed to be small, but potentially very relevant
for implementing software, I think this section should be much more
precise.

>7. I cut down the acknowledgments list. I will add names as I incorporate textual suggestions.

This is fine, but:

1) it should not say that RFC 4647 is a precursor of this document, and
2) it should not say that Michael was the Language Subtag Reviewer
   since RFC 1766, because there was no Language Subtag Reviewer at
   that time.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]