Subject: Re: [Ltru] extlang or not extlang

From: "Doug Ewell" <[email-masked]>
Date: Sat, 10 May 2008 11:59:51 -0600

Peter Constable <petercon at microsoft dot com> wrote:

> Very strong +1. I feel we should not be stipulating or even suggesting 
> that zh is the same as cmn, or that cmn should be deprecated. Saying 
> that, in general, zh content is most often Mandarin is fine.

I am perfectly fine with that idea, and perfectly not fine with the 
similar-sounding but quite different idea that 'zh' is most often *used 
to mean* Mandarin.

In the flood of messages on this topic, I can't find the statement in 
the archives that 'cmn' should be deprecated.  I hope to heaven that is 
a misquote.

--
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: Peter Constable <[email-masked]>
Date: Sat, 10 May 2008 16:23:26 -0700

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

> the archives that 'cmn' should be deprecated.  I hope to heaven that is

IIRC, at one point Shawn said something along the lines that, if we're going to tell people to use 'zh' to mean Mandarin, then effectively we're determining that 'zh' *does* and always will mean Mandarin, so we might as well deprecate 'cmn' to avoid confusion and duplication. I didn't take that as him recommending that we do this; only that that was the logical implication of what he was hearing from others.

Peter

---

From: [email-masked]
Date: Mon, 12 May 2008 14:58:15 -0700

> the archives that 'cmn' should be deprecated.  I hope to heaven that is 

(For the record, this was the message I was referring to...)

Mark Davis wrote:

Not so sure that we will get accuracy; frankly I think the introduction of 
cmn, arb, etc. were well intentioned, but in retrospect a mistake. There 
was no reason not to treat zh, ar, etc just like we treated de. There is 
no substantive difference between zh:yue and de:gsw.

Given the existence and long usage of zh in IT, the introduction of cmn 
(etc) will inevitably just end up with mistagged data, mishandled lookups, 
and unsatisfied users, unless one follows the strategy that unless you 
have a strong reason not to, treat cmn as a synonym for zh. (In fact, it 
is simplest to remap cmn-* to zh-* on input.)

[Our best course of action for compatibility and interoperability would be 
to deprecate cmn, arb, and the few others in that section, but I doubt 
that we could get consensus on that, so I'd never brought it up.]

Karen writes:

Above is the text I was referencing. Though Mark hasn't suggested that we 
actually do this, the fact that he thinks this would be helpful tells me 
that we're looking at this very differently. I'm someone who needs these 
distinctions so I guess I find the continued existence of the "zh" tag to 
be more of a problem than the introduction of the more specific tagging I 
need.

---

From: [email-masked]
Date: Mon, 12 May 2008 15:46:26 -0700

Note: I will be unable to access my e-mail from 6 p.m. PDT today until to 
8 a.m. tomorrow due to a change in my e-mail service. I'm sending this 
warning mostly in case something goes wrong and I'm blocked out of my 
e-mail for longer. If past experience serves, there's also a chance that 
e-mail sent to me during this period could bounce. I apologize for any 
missed connections due to this service change in advance.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 12 May 2008 16:11:27 -0700

> I'm someone who needs these
> distinctions so I guess I find the continued existence of the "zh" tag
> to be more of a problem than the introduction of the more specific tagging
> I need.

So I'm trying to wrap my head around a suitable resolution that addresses the various needs expressed on this list. I tend to agree that you need specific tagging for stuff like written Cantonese and spoken Mandarin, etc. Historical use of vague tags, ascribing meaning not actually in the subtags, is not helpful.

How do you think this would best be solved? If I understand your previous messages, you'd prefer to see:

- Restore 'extlang'
- Require the extlang subtag to be used (via the SHOULD keyword??)
- Clarify that 'zh' means "any kind of Chinese" and thus isn't specifically one sort or another: specificity is desirable.

Or would you prefer:

- Not restore 'extlang'
- Possibly deprecate 'zh' (with no preferred-value)
- Clarify that users SHOULD use the specific flavor of Chinese, with additional subtags as appropriate
- Clarify that 'zh' means "any kind of Chinese" and thus isn't specifically one sort or another

Or, finally:

- Restore 'extlang'
- Allow the encompassed languages to be both extlangs and primary subtags
- Clarify that 'zh' means "any kind of Chinese" and thus isn't specifically one sort or another: specificity is desirable.
- Provide guidelines for choosing between 'zh-???" and "???" forms.

Best Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> [email-masked]
> Sent: Monday, May 12, 2008 2:58 PM
> To: Doug Ewell
> Cc: LTRU Working Group
> Subject: Re: [Ltru] extlang or not extlang
>
> Doug wrote:
>

---

From: [email-masked]
Date: Mon, 12 May 2008 17:34:47 -0700

Addison,

Tough call, really. 

I think my preference is #1 because nothing needs to be deprecated, the 
language hierarchies are represented for all macrolanguages, tag semantics 
don't change, and the legacy connection to "zh" is preserved. I would also 
be satisfied with #2 with the suggestion to deprecate "zh". 

I *might* not be opposed to #3, but fear it might be as confusing as what 
we've got now. I'm open to hearing suggestions on #3 with better spelled 
out usage rules.

Regards,

Karen Broome

"Phillips, Addison" <[email-masked]> 
Sent by: [email-masked]
05/12/2008 04:11 PM

To
"[email-masked]" <[email-masked]>, Doug Ewell 
<[email-masked]>
cc
LTRU Working Group <[email-masked]>
Subject
Re: [Ltru] extlang or not extlang

> to be more of a problem than the introduction of the more specific 
tagging

So I'm trying to wrap my head around a suitable resolution that addresses 
the various needs expressed on this list. I tend to agree that you need 
specific tagging for stuff like written Cantonese and spoken Mandarin, 
etc. Historical use of vague tags, ascribing meaning not actually in the 
subtags, is not helpful.

How do you think this would best be solved? If I understand your previous 
messages, you'd prefer to see:

- Restore 'extlang'
- Require the extlang subtag to be used (via the SHOULD keyword??)
- Clarify that 'zh' means "any kind of Chinese" and thus isn't 
specifically one sort or another: specificity is desirable.

Or would you prefer:

- Not restore 'extlang'
- Possibly deprecate 'zh' (with no preferred-value)
- Clarify that users SHOULD use the specific flavor of Chinese, with 
additional subtags as appropriate
- Clarify that 'zh' means "any kind of Chinese" and thus isn't 
specifically one sort or another

Or, finally:

- Restore 'extlang'
- Allow the encompassed languages to be both extlangs and primary subtags
- Clarify that 'zh' means "any kind of Chinese" and thus isn't 
specifically one sort or another: specificity is desirable.
- Provide guidelines for choosing between 'zh-???" and "???" forms.

Best Regards,

Addison

Addison Phillips

> to

---

From: Shawn Steele <[email-masked]>
Date: Mon, 12 May 2008 21:40:22 -0700

FWIW: If we choose extlang, I think 3 is interesting to consider.  Note that 3 is also very similar to the no-extlang proposal, if you assume applications want to know about the grandfathered tags.  A few points:
- I think whether its restored or not, that we need to be clear that zh means "any kind of chinese".
- If it extlang is restored, I think we should make it clear which languages need the extlang behavior, eg: Chinese.

To me the value of extlang would be to allow additional information in existing protocols that don't allow "lists" of language tags, and it seems kind of like a specialized list to me.  In cases where lists are acceptable, I think that a non-extlang form would be acceptable.  (Because you can specify zh;cmn or whatever).

- Shawn

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Monday, May 12, 2008 5:34 PM
To: Phillips, Addison
Cc: LTRU Working Group
Subject: Re: [Ltru] extlang or not extlang

Addison,

Tough call, really.

Regards,

Karen Broome

To

- Restore 'extlang'

Or would you prefer:

- Not restore 'extlang'

Or, finally:

- Restore 'extlang'

Best Regards,

Addison

Addison Phillips

---

From: "Andrew Cunningham" <[email-masked]>
Date: Tue, 13 May 2008 14:50:14 +1000

> To me the value of extlang would be to allow additional information in existing protocols that don't allow "lists" of language tags, and it seems kind of like a specialized list to me.  In cases wh…

it should be extlangs or no extlangs, anything else woud be too
confusing, too complex

-- 
Andrew Cunningham
Vicnet Research and Development Coordinator
State Library of Victoria
Australia

[email-masked]
[email-masked]

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 12 May 2008 22:12:52 -0700

I think list forms are more dangerous than they look. What alarms Karen--it alarms me too--is that there is confusion about how to tag things. The more choices people have, the more likely that they will make the "wrong" choice or that our software must become much more complex to handle the interplay between various subtag forms. Not to be a wag, but lists give people the chance to be wrong twice.

Of course there is nothing that can completely prevent people from making illegal tags ("chinese") or making ludicrous tagging choices ('tw' when you mean Taiwan and not Twi). But given reasonable people reasonably informed about what they are doing, the number and range of tag choices that achieve the same result should be limited. It is up to you and your applications needs to decide whether "de" or "de-Latn-AT-1984" is the most appropriate tag for your content. But you shouldn't have to chose between three very different forms to say exactly the same thing ("zh"/"cmn"/"zh-cmn", you can s/cmn/yue or any other encompassed language there)--and then face the peril of additional subtags.

I want to add, on the slight tangent, that I don't worry so much about the grandfathered forms. There is a list of these; it is stable; it will have a very direct mapping to the "right" replacement choice; and most of the items on the list are already stone dead. If some of them are redundant rather than deprecated, that's okay with me (it was the idea in the first place). But I wouldn't worry over-much about making some more deprecated 3066 registrations if that is the right choice. "i-enochian" has plenty of friends. For that matter, we have plenty of "bad" Chinese tags:

 i-hak => zh-hakka => (something else when we're done, regardless of extlang or no)

Best Regards,

Addison

Addison Phillips

> From: Shawn Steele [mailto:[email-masked]]
> Sent: Monday, May 12, 2008 9:40 PM
> To: [email-masked]; Phillips, Addison
> Cc: LTRU Working Group
> Subject: RE: [Ltru] extlang or not extlang
>
> FWIW: If we choose extlang, I think 3 is interesting to consider.  Note
> that 3 is also very similar to the no-extlang proposal, if you assume
> applications want to know about the grandfathered tags.  A few points:
> - If it extlang is restored, I think we should make it clear which
> languages need the extlang behavior, eg: Chinese.
>
> To me the value of extlang would be to allow additional information in
> existing protocols that don't allow "lists" of language tags, and it
> seems kind of like a specialized list to me.  In cases where lists are
> acceptable, I think that a non-extlang form would be acceptable.
> (Because you can specify zh;cmn or whatever).
>
> - Shawn
>
> From: [email-masked] [[email-masked]] On Behalf Of
> [email-masked] [[email-masked]]
> > > the archives that 'cmn' should be deprecated.  I hope to heaven
> that
> > is
> > > a misquote.
> >
> > Not so sure that we will get accuracy; frankly I think the
> introduction
> > of
> > [Our best course of action for compatibility and interoperability
> would
> > be
> > Above is the text I was referencing. Though Mark hasn't suggested
> that
> > we
> > be more of a problem than the introduction of the more specific
> tagging
> > I
> > need.
> >
> >
> >
> >

---

From: Martin Duerst <[email-masked]>
Date: Tue, 13 May 2008 14:45:34 +0900

At 13:40 08/05/13, Shawn Steele wrote:

>In cases where lists are 
>acceptable, I think that a non-extlang form would be acceptable.  (Because 
>you can specify zh;cmn or whatever).

I'm not exactly sure about this. In many cases, lists may have
some explicit or implied semantics. As an example, I could immagine
that there is some assumption that the number of language tags
in a list is equal to the number of speech soundtracks on a DVD.

Regards,    Martin.

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

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 13 May 2008 12:25:32 -0700

So... to bring this full circle. Assuming that you'd be willing to compromise with the no-extlangistas by going with option #2, would the following text (replacing the text about macrolanguages in draft-13) work for you? What would you change?

(I apologize for the length of the following quote. However, I put the entire section in, since it has extensive revisions)

--

<section title="Macrolanguages" anchor="macrolanguages">

<t> Some of the languages in the registry are labeled "macrolanguages" by ISO 639-3, which defines the term as "clusters of closely-related language varieties that [...] can be considered distinct individual languages, yet in certain usage contexts a single language identity for all is needed".  These correspond to codes registered in ISO 639-2 as single languages that were found to correspond to more than one language in ISO 639-3 (note that many of these languages also have ISO 639-1 codes).  The record for each of the languages encompassed by a macrolanguage contains a 'Macrolanguage' field in the registry; the macrolanguages themselves are not specially marked.</t>

<t>It is always permitted, and sometimes useful, to tag an encompassed language using the subtag for its macrolanguage.  However, the Macrolanguage concept doesn't define what the relationship  between the encompassed language and its macrolanguage is, nor does it define how languages encompassed by the same macrolanguage are related to each other.</t>

<t>The family of languages encompassed by the macrolanguage Chinese ('zh') provide a useful illustration of this.   Historically many different kinds of content have been tagged with variations of the 'zh' subtag, with application specific meaning being associated with region codes in particular. This is because historically only the macrolanguage code was available for forming language tags.</t><t>For example, before script codes were available, Chinese written in the Traditional script was sometimes associated with the "zh-TW" (Chinese, Taiwan) tag. Another example would be the association of the various spoken or written forms of the Cantonese language with the "zh-HK" (Chinese, Hong Kong) tag. However, each of these forms could also be (and actually were) associated with other language forms as well. For example, "zh-TW" might also indicate the Min Nan language or "zh-HK" could indicate a Chinese content item adapted for Hong Kong (but not necessarily a Cantonese item: many written documents are in Mandarin Chinese). </t>

<t>Using the encompassed language subtags (in concert with other appropriate subtags) makes clear the actual language. Script, region, or other subtags can still delineate any additional or local variations in language (such as using the 'Hans' subtag to identify the simplified Chinese script).</t>

<t>Historically subtags for the various encompassed Chinese languages were not available. To overcome this deficiency, some content in these languages uses grandfathered tags registered for specific languages (such as "zh-yue" for Cantonese or "zh-xiang" for Xiang).  The grandfathered tags were deprecated in the registry upon adoption of this document, but remain valid for use. Since implementations might not be able to associate the grandfathered tags with these modern equivalents, implementations are encouraged to canonicalize tags for comparison purposes.</t>

<t>When faced with a choice between a macrolanguage and one of its encompassed languages, as noted above, the encompassed language subtag is RECOMMENDED to form the language tag.  However, where the macrolanguage tag has been historically used to denote a dominant encompassed language, it SHOULD be used in place of the subtag specific to that encompassed language unless it is necessary to clearly distinguish the macrolanguage as a whole from that enclosed dominant language variety.</t>

<figure anchor="affectedLangs">

  <preamble>The pairs of macro and encompassed languages affected by this issue when this document was published were:</preamble>

  <artwork>

     Arabic 'ar'                    Standard Arabic 'arb'

     Konkani (macrolanguage) 'kok'  Konkani (single language) 'knn'

     Malay (macrolanguage) 'ms'     Malay (single language) 'mly'

     Swahili (macrolanguage) 'sw'   Swahili (single language) 'swh'

     Uzbek 'uz'                     Northern Uzbek 'uzn'

  </artwork>

</figure>

<t>Applications MAY use macrolanguage information to improve matching or language negotiation.  For example, the information that 'sr' (Serbian) and 'hr' (Croatian) share a macrolanguage expresses a closer relation between those languages than between, say, 'sr' (Serbian) and 'ma' (Macedonian).  While it is valid to use either the subtag of the encompassed language or of the macrolanguage to form a language tag, many matching applications will not be aware of the relationship between the languages.</t>

</section>

--

Addison Phillips

It is an architecture.

> From: [email-masked] [mailto:[email-masked]]

> Sent: Monday, May 12, 2008 5:35 PM

> language hierarchies are represented for all macrolanguages, tag

> semantics

> don't change, and the legacy connection to "zh" is preserved. I would

> also

> I *might* not be opposed to #3, but fear it might be as confusing as

> what

> we've got now. I'm open to hearing suggestions on #3 with better

> spelled

> > distinctions so I guess I find the continued existence of the "zh"

> tag

> > to be more of a problem than the introduction of the more specific

> So I'm trying to wrap my head around a suitable resolution that

> addresses

> etc. Historical use of vague tags, ascribing meaning not actually in

> the

> How do you think this would best be solved? If I understand your

> previous

> - Allow the encompassed languages to be both extlangs and primary

> subtags

> > From: [email-masked] [mailto:[email-masked]] On Behalf

> Of

> > > In the flood of messages on this topic, I can't find the statement

> in

> > cmn, arb, etc. were well intentioned, but in retrospect a mistake.

> > There

> > was no reason not to treat zh, ar, etc just like we treated de. There

> > Given the existence and long usage of zh in IT, the introduction of

> cmn

> > (etc) will inevitably just end up with mistagged data, mishandled

> > lookups,

> > and unsatisfied users, unless one follows the strategy that unless

> you

> > have a strong reason not to, treat cmn as a synonym for zh. (In fact,

> > it

> > to deprecate cmn, arb, and the few others in that section, but I

> doubt

> > actually do this, the fact that he thinks this would be helpful tells

> > me

> > that we're looking at this very differently. I'm someone who needs

> > these

> > distinctions so I guess I find the continued existence of the "zh"

> tag

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 15 May 2008 02:50:54 +0200

Addision, your proposal here is supposed to be a variant of option #2 in 
your dialogue with Karen. In that dialogue you described that option 

>     - Clarify that 'zh' means "any kind of Chinese" and thus isn't specifically one sort or another

However, I think your proposed new text differs a bit from the above. It 
differs even more for from option #1 (restoring extlang), where you said 
that "specificity is desirable." See concrete comments below.

Phillips, Addison 2008-05-13 21.25:
...
> <t>It is always permitted, and sometimes useful, to tag an encompassed language using the subtag for its macrolanguage.  However, the Macrolanguage concept doesn't define what the relationship  bet…

To say that "It is always permitted, and sometimes useful" sounds quite 
different from "specificity is desirable". I would have expexted the 
text to express opposite, namely that "it is always permitted and 
sometimes useful to use the Macrolanguage tag for any of the encompassed 
languages". Because, saying it like that would have been to emphasize 
what you told Karen you would emphasize, namely that the Macrolanguage 
means "any kind of Chinese" - thus "the macrolangauge means 'any kind of 
the encompassed languages'".

When you goes on saying that "the Macrolanguage concept doesn't define 
what the relationship between the encompassed language and its 
macrolanguage is", then you are touching the language negotiation issue. 
And, of course, language negotiation becomes very difficult if one has 
to negotiate even over the use of the very Macrolanguage tag. Thus 
again, specificity would have been preferred - except not the way you 
see it, apparently.

I.e. you outline the problems of being spesific. I see no equal 
discussion of the problem of being general.

> <t>When faced with a choice between a macrolanguage and one of its encompassed languages, as noted above, the encompassed language subtag is RECOMMENDED to form the language tag.  However, where th…

I disagree strongly with the above, which I again think contradicts what 
I perceived of your message to Karen.

Firstly, again, you are emphasizing the problems of being spesific, and 
you goes about - as before - saying that one SHOULD use the Macrotag. I 
don't look at your text with such fine reading eyes as Doug, but where 
is the difference from your previous text proposals?

Secondly, what does this phrase "where the macrolanguage tag has been 
historically used to denote a dominant encompassed language" really 
mean? For instance, how can I be certain that someone, having read what 
you said there, will not make the claim that "'no' has been historically 
used to mark up Bokmål (nb) - at least in this context - and therefore 
we wilil use it for that, while 'nn' must be used for 'Nynorsk'" ?

Thirdly, obviously, above you do not describe a 'zh' versus 'en' 
situation, but a  'zh' versus 'yum' situation. In other words a  'zh' 
for Mandarin and 'yum' for Cantonese situation. A typical language 
negotiation context  - or perhaps I should say, a typical context where 
one must discern between several variants of the same Macrolanguage. And 
despite this fact, you say that one SHOULD use the Macrolanguage tag for 
one particular language.

This, to me, effectively says that you can forget aout the spesific tag 
for the dominant language within a Macrolanguage group.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 14 May 2008 18:15:42 -0700

> that "specificity is desirable." See concrete comments below.

It really should be different from option #1, which is mutually exclusive from option #2

> > <t>It is always permitted, and sometimes useful, to tag an
> encompassed language using the subtag for its macrolanguage.  However,
> the Macrolanguage concept doesn't define what the relationship  between
> the encompassed language and its macrolanguage is, nor does it define
> how languages encompassed by the same macrolanguage are related to each
> other.</t>
> >
>
> languages".

Ur, what you propose *is* what the text means. I go on to emphasize that specificity is desirable. I don't at all see how you arrive at the opposite conclusion, unless you are confusing the encompassed languages (nn and nb are encompassed) with the macrolanguage (no is a macrolanguage).

I would respond point-by-point to the rest of your email, but most of your comments seem like a misreading of what the text I proposed says. It says quite clearly that the encompassed language is RECOMMENDED over the macrolanguage subtag... that is, the macrolanguage subtag is to be avoided. There is an extensive example using Chinese that you omit from your commentary.

Please note: this editor, at least, finds it most useful if you propose specific text to right the wrongs you suppose appear in the text. It is easier to discuss specific proposals--not to mention to incorporate them--if you do. I think you'll find that, if you re-read my proposal carefully, it says everything that my option #2 proposed to Karen. I would stipulate that the wording is slightly weaker than my proposal for Karen (it doesn't say 'zh' == deprecated, but it frowns extremely hard at 'zh', along with most of its Macrolanguage brethren).

Finally, you mention language negotiation, I think wrongly. It is not a topic for this document, generally. We have a document about it. It is called RFC 4647 and it is part of BCP 47.

Addison

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 15 May 2008 05:07:29 +0200

> Ur, what you propose *is* what the text means. I go on to emphasize that specificity is desirable. I don't at all see how you arrive at the opposite conclusion, unless you are confusing the encompa…
Ok, I'm sorry. I guess I infact made the exact error you describe - the 
wording 'subtag of its Macrolanguage' managed to confuse my non-English 
head.

To avoid misundersandings I'd like to propose this change, then, to link 
the 'subtag' word more strongly to the 'Macrolanguage' term, and to 
emphasise that the statement is true for "any encompassed language":

    <t>For any encompassed language, it is always permitted and sometimes useful, to use the Macrolanguage subtag in place of the subtag for the encompassed language itself. [...]</t>

Btwe, regarding the following sentence, what does "However, the 
Macrolanguage concept doesn't define ..." etc mean? The last bit "..., 
nor does it define ..." is understandable. But else, the concept of 
Macrolanguage means that the relationship is that they are part of the 
same macrolanguage. You seem to have in mind a situation where one has 
specified e.g. 'zh', and where this may become a problem for the user  
*outside* a language negotiation context? What problem could that be? 
That can only be a problem if the Macrolanguage is associatied with a 
language that user does not understand. However, that is a separate 
issue. Or - then you should say that this can lead to bad language 
negotiation results. I see no problems outside a negotions context. I.e. 
the entire computere is Cantonese, then using 'yum' for Cantonese poses 
no problem. So, the problem you describ is not that there is any unclear 
link from encompassed language to encompassing macrolanguage, but that 
the link from macrolanguage to encompassing language is a one to many 
link. (Thus, the problem is language negotiation, really.)

I'd like, therefore, to propose this text instead, which makes clearer 
that the problem of using the macrolanguage tag is because many 
languages share the same tag:

    <t>[...] However, while the identification from any encompassed
    language to its encompassing macrolanguage is straight forward, the
    relationship from a particular macrolanguage to its encompassed
    languges is always a one to many relationship. Hence the question of
    how, or to which degree, languages encompassed by the same
    macrolanguage are usefully related to each other, is not covered by
    the macrolanguage consept itself.

> I would respond point-by-point to the rest of your email, but most of your comments seem like a misreading of what the text I proposed says. It says quite clearly that the encompassed language is R…

I think my misunderstanding was limited to that very phrase, allthough 
it certainly colored some of the rest of what I said.

Yes, you said RECOMMENDED. But immediately after you said RECOMMENDED, 
you said - as I quoted - that if there was a tradition for it, then one 
"SHOULD" use the macrolangue subtag. And I am interested in the question 
I raised in that context. How can you not admit that the text opens up 
the loophole I described?

And how are we to find out how the tradition is to be interpreted? How 
do we know that the tradition is to treat the tag as "that spesific 
encompassed language" instead of "that tag just seemed to work, and it 
was not wrong ether"?

I think even when there is a tradition, there should be incentive to 
instead use the spesific language subtag.

Thus my concrete proposal is that swtich from

    [......], it MAY be used in place of the subtag specific [...]

instead of

    [...], it SHOULD be used in place of the subtag specific [...]

> Please note: this editor, at least, finds it most useful if you propose specific text to right the wrongs you suppose appear in the text. It is easier to discuss specific proposals--not to mention to incorporate them--if you do. 

Thank you. I like that attitude very much. I tried my limited very best 
above.

> I think you'll find that, if you re-read my proposal carefully, it says everything that my option #2 proposed to Karen. I would stipulate that the wording is slightly weaker than my proposal for Karen (it doesn't say 'zh' == deprecated, but it frowns extremely hard at 'zh', along with most of its Macrolanguage brethren).
>   

I agree that macrolanguage tags should not be deprecated. I hope you 
find my proposals support what you said here.

> Finally, you mention language negotiation, I think wrongly. It is not a topic for this document, generally. We have a document about it. It is called RFC 4647 and it is part of BCP 47.

I disagree, because I was not speaking about that issue in its entirety, 
as you do there. I rather said that you should have language negotiation 
in mind when you are formulating the text.

 I was merely trying to place your text in a context where one would 
turn to it for guidance. The times one most needs guidance about these 
issues mostly relate to language negotation (in a broad sense) - either 
between one macrolanguage and another language (zh verus en) or between 
encompassed languages. (The right choice between macrolanguge subtag 
versus encompassed language subtag for each of those to language 
negotiations situations, might differ.)

I.e. I did not say that you should give specific guidance about language 
negotiation. I only tried to say that the text should be formulated in 
such a way that it would not confuse those who are looking at it to 
solve such problems.
-- 
leif halvard silli

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 15 May 2008 05:43:22 +0200

Leif Halvard Silli 2008-05-15 05.07:

> I.e. the entire computere is Cantonese, then using 'yum' for Cantonese 
> poses no problem.

Sorry, the above should be read as "then using ***'zh'*** for 
Cantonese poses no problem."
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 14 May 2008 21:49:14 -0700

>     <t>For any encompassed language, it is always permitted and
> sometimes useful, to use the Macrolanguage subtag in place of the
> subtag for the encompassed language itself. [...]</t>

I think this stresses the encompassed language too much. How about:

---
It is always permitted, and sometimes useful, to use the Macrolanguage subtag in place of the encompassed language's subtag.
---

> You seem to have in mind a situation where one has
> language that user does not understand.

Speakers of Mandarin (who speak only Mandarin) have no idea what Cantonese speakers are saying when the speak to one-another. There is no guarantee that encompassed languages are mutually intelligible on any level, even with extra effort. An example that should be familiar to you: Danish is far closer to Norwegian than many of the Chinese or Arabic languages are to one-another.

> However, that is a separate

There is no prohibition on using 'zh'. There is a recommendation that you should use 'yue' (Cantonese) when you *mean* Cantonese. If you just mean "some Chinese language", you're welcome to use 'zh', even if "some Chinese language", in your specific case, means "Cantonese Chinese". Of course, you may experience problems with the outside world (when your isolated computer dials up Compuserve, they may consider 'zh' to mean Xiang).

>     language to its encompassing macrolanguage is straight forward, the

I don't think it is. In fact, we say that there is no specific definition here.

>     the macrolanguage consept itself.

I don't see what the point of this text is: we already say this.

> the loophole I described?

There is a specific table of languages for which this is the case directly below the text introduced with the text "The pairs of macro and encompassed languages affected by this issue when this document was published were:"

Perhaps we should not have this table. That is something to discuss. The SHOULD text goes with that table.

> instead use the spesific language subtag.

There are five languages where some people feel that isn't true. These are Arabic, Konkani, Malay, Swahili, and Uzbek.

>     [...], it SHOULD be used in place of the subtag specific [...]

I understand that English is not your first language. I think you mean the opposite of what you say above.

I selected SHOULD in the interest of meeting Karen (and other's) desire for firm guidance on language tag choices. For the reason why SHOULD here, see above.

>
> > Finally, you mention language negotiation, I think wrongly. It is not
> a topic for this document, generally. We have a document about it. It
> is called RFC 4647 and it is part of BCP 47.
> >
>

I always have language negotiation in mind. However, there are many contexts where language negotiation is not called for. I think this is one of Karen's points. We treat negotiation separately on purpose, but it is never far from (some of our) minds.

Addison

Addison Phillips

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 15 May 2008 19:39:08 +0200

> It is always permitted, and sometimes useful, to use the Macrolanguage subtag in place of the encompassed language's subtag.

This seems good. Thank you. (I tried to use "of the language" instead of 
"the language's".)

> Speakers of Mandarin (who speak only Mandarin) have no idea what Cantonese speakers are saying when the speak to one-another. There is no guarantee that encompassed languages are mutually intelligi…

I made a new proposal below.

> > no problem.

I meant to say "then using *'zh'* for Cantonese" - sorry. [ I sent a 
message aftewards where I corrected myself. ]

> > So, the problem you describ is not that there is any
> > unclear link from encompassed language to encompassing macrolanguage,
> > but that the link from macrolanguage to encompassing language is a
> > one to many link. (Thus, the problem is language negotiation,
> > really.)
>
>

Basically, I think we understand each other at this point.

> I don't think it is. In fact, we say that there is no specific definition here.

I believe the only exceptions to what I say here, are found in that 
"table of exceptions" where you list the encompassed language for which 
the macrolanguage tag SHOULD be used for the dominant language.

The problem is that, except for the exceptions in that table, **all** 
the encompassing languages have a strong link to thier macrolangauge.

> > the macrolanguage consept it self.
>

**Perhaps** you really only wanted  point out that the macrolanguage tag 
is a bit uncertain?

With that in mind, here is a new variant of then entire paragraph, where 
I also included your new text from the top of this letter:

    <t>It is always permitted, and sometimes useful, to use the Macrolanguage subtag in place of the encompassed language's subtag.  However, **with some exceptions for the short list of Macrolanguages in the table below,** the Macrolanguage concept **has as consequence that the Macrolanguage subtag allways covers all its encompassing languages**. **And since the consept also does not** define how languages encompassed by the same macrolanguage are related to each other, **its use might could lead users to receive an encompassed language which they may not understand or want**.</t>

> Perhaps we should not have this table. That is something to discuss. The SHOULD text goes with that table.

As is, the point with that paragraph seems not to be to express the 
recommendation but to instead express the exceptions. This could be made 
clearer.

I'd like to propose the following text, to make the link between that 
table and that paragraph clearer, and to have a clearer distinction 
between macrolanguage *name* and macrolanguage *(sub)tag*, and to link 
the first sentence better to the rest of the paragraph. I added **two 
stars** around my insertions:

    <t>When faced with a choice between a macrolanguage **subtag or the subtag of** one of its encompassed languages, as noted above, the encompassed language subtag is RECOMMENDED to form the language tag.  However, **for a few macrolanguages, listed in the table below, there is a particulary strong identification, culturally and historically, between the name of the  macrolanguage and one of its dominant, encompassed languages in particular**. **For these encompassed languages, the choice SHOULD be the macrolanguage subtag** in place of the subtag specific to that encompassed language **except when it** is necessary to clearly distinguish the macrolanguage as a whole from that enclosed dominant language variety.</t>

> There are five languages where some people feel that isn't true. These are Arabic, Konkani, Malay, Swahili, and Uzbek.

I have the feeling that some would disagree about Arabic?

> I understand that English is not your first language. I think you mean the opposite of what you say above.

[ I had allready sent a note correcting myself. ]

> I selected SHOULD in the interest of meeting Karen (and other's) desire for firm guidance on language tag choices. For the reason why SHOULD here, see above.

Above, I accepted using the SHOULD. It might be OK with SHOULD, as long 
as it is made clearer what the paragraph relates to (that table).

> I always have language negotiation in mind. However, there are many contexts where language negotiation is not called for. I think this is one of Karen's points. We treat negotiation separately on…

OK. Good. However, in some sense, I think Karen also has language 
negotation in mind, since she wants people to be absolutely certain what 
a particular tag means when they se it. If one cannot be certain about 
that, then one must start to "negotiate"/guess what it means.

When it comes to that table of exceptions (where Macrolangauge should be 
used to tag a particular language), I see the issue here as a case were 
we try to maintain an existing clarity.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 15 May 2008 11:11:05 -0700

> the encompassing languages have a strong link to thier macrolangauge.

I would not say it that way. All encompassed languages have a strong link to their macrolanguage... or they wouldn't be encompassed by the macrolanguage.

The table lists the macrolanguages for which one particular encompassed language has such a strong link to the "macrolanguage identity" that they are usually considered synonymous (that is, the other encompassed languages are usually considered to be "something else than" the default language).

For example, the individual language 'swh' (Swahili) is apparently very closely identified with the macrolanguage 'sw' (also called Swahili). The other encompassed language 'swc' (Congo Swahili) is somehow separate. Thus, in that particular case, it is appropriate to consider 'sw' to mean 'swh' and distinguish 'swc' consistently from it. That's, at least, what the exception table is trying to express.

I don't necessarily agree or disagree with this idea. I just didn't see a reason to remove it from this proposal, since the working group had previously agreed on this list. I don't have enough personal experience with Swahili, for example, to know how well my paragraph above actually describes the situation with that language. People who do suggested the list.

> **Perhaps** you really only wanted  point out that the macrolanguage
> tag is a bit uncertain?
>
>     <t>It is always permitted, and sometimes useful, to use the
> Macrolanguage subtag in place of the encompassed language's subtag.
> However, **with some exceptions for the short list of Macrolanguages in
> the table below,** the Macrolanguage concept **has as consequence that
> the Macrolanguage subtag allways covers all its encompassing
> languages**. **And since the consept also does not** define how
> languages encompassed by the same macrolanguage are related to each
> other, **its use might could lead users to receive an encompassed
> language which they may not understand or want**.</t>

Hm... this looks to be a useful path down which to travel. I think the text about the short list of exception is probably too strong. Perhaps:

--
Is it always permitted, and sometimes useful, to use the Macrolanguage subtag
in place of the encompassed language's subtag. Each Macrolanguage's subtag,
by definition, always covers all of its encompassed languages. However,
the Macrolanguage concept does not define what the relationship is
between the Macrolanguage and its encompassed language's is nor does it define
how each of the encompassed languages are related to each other. In fact,
this relationship varies, and, with the exception of a few languages cited
below (see table xx), users cannot assume that the macrolanguage subtag means
any particular encompassed language nor that any given pair of encompassed
languages are mutually intelligible or otherwise interchangeable.
--

> between macrolanguage *name* and macrolanguage *(sub)tag*, and to link

The name (description) of any given language should not be confused with the meaning of the subtag.

>     <t>When faced with a choice between a macrolanguage **subtag or the
> subtag of** one of its encompassed languages, as noted above, the

This is a good clarification. Inserted.

> encompassed language subtag is RECOMMENDED to form the language tag.
> However, **for a few macrolanguages, listed in the table below, there
> is a particulary strong identification, culturally and historically,
> between the name of the  macrolanguage and one of its dominant,
> encompassed languages in particular**. **For these encompassed
> languages, the choice SHOULD be the macrolanguage subtag** in place of
> the subtag specific to that encompassed language **except when it** is
> necessary to clearly distinguish the macrolanguage as a whole from that
> enclosed dominant language variety.</t>

These are also good clarification, provided we then proceed to remove the stub of table introduction I quoted (with editing for English usage).

Best Regards,

Addison

Addison Phillips

---

From: John Cowan <[email-masked]>
Date: Thu, 15 May 2008 14:52:50 -0400

Phillips, Addison scripsit:

> For example, the individual language 'swh' (Swahili) is apparently
> very closely identified with the macrolanguage 'sw' (also called
> Swahili). The other encompassed language 'swc' (Congo Swahili) is
> somehow separate. Thus, in that particular case, it is appropriate to
> consider 'sw' to mean 'swh' and distinguish 'swc' consistently from
> it. That's, at least, what the exception table is trying to express.

This is not analogous to diglossic languages like Chinese or Arabic.
Historically, all of Swahili has been tagged "sw", but Ethnologue
considers the varieties spoken in the Congo to be different enough to be
a separate language.  So "sw" means "Swahili", "swh" means "Swahili,
excluding Congolese varieties", and "swc" means "Congo Swahili".
Changing all the "sw" content that is *not* Congolese (i.e. almost all
of it) to be "swh" is probably not worth doing.  The same explanation
applies to Konkani and Uzbek.

Malay is more complicated, both because there are a bunch of encompassed
languages, but also because in February 2008 'mly' became a retired
code element: it has been split into code elements for "Standard Malay",
"Malay (individual language)", and two other languages.  The term "Malay
(individual language)", code element 'zlm', is now used as a cover term
for local varieties of Malay that are distinct from Standard Malay but
not distinct enough to be called separate languages, as the other members
of the Malay macrolanguage are.

Addison, please change "Malay (single language) 'mly'" to "Standard Malay
'zsm'.  Also change "single language" to "individual language" elsewhere.

-- 
You escaped them by the will-death              John Cowan
and the Way of the Black Wheel.                 [email-masked]
I could not.  --Great-Souled Sam                http://www.ccil.org/~cowan
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 15 May 2008 11:59:14 -0700

> 'zsm'.  Also change "single language" to "individual language"

Thanks for this. I noticed it this morning when writing the example (I changed my example as a result).

Addison

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 15 May 2008 11:59:14 -0700

Addison

---

From: John Cowan <[email-masked]>
Date: Thu, 15 May 2008 14:52:50 -0400

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 15 May 2008 21:24:23 +0200

> I would not say it that way. All encompassed languages have a strong link to their macrolanguage... or they wouldn't be encompassed by the macrolanguage.

Yes - agree.

> The table lists the macrolanguages for which one particular encompassed language has such a strong link to the "macrolanguage identity" that they are usually considered synonymous (that is, the other encompassed languages are usually considered to be "something else than" the default language). [...]
>   

Yes. As I was reading your message and trying to understannd the issue 
etc, it occurred to me that that the ownership of the "macrolanguage 
identity", had nothing to do with predominance in the computer industry 
field or something like that, but spoke about something outside that 
field - in "normal" life.

> > With that in mind, here is a new variant of then entire paragraph, 
> > where I also included your new text from the top of this letter:
> >
> between the Macrolanguage and its encompassed language's 

Was that supposed to be a plural of 'encompassed language'? I think it 
would be good, if it was. :-)

> is nor does it define

This is much clearer than before, I think. Thank you!

> The name (description) of any given language should not be confused with the meaning of the subtag.

It can be difficult to find the right way to say it ...

> These are also good clarification, provided we then proceed to remove the stub of table introduction I quoted (with editing for English usage).

Good to hear. After all my fuzz. :-)

I guess we will "meditate" over the text and the solutions in general 
till over the weekend, as the co-chair said. At least, I will try do so 
myself. Have a good weekend!

Best regards,
Leif Halvard Silli

---

From: Shawn Steele <[email-masked]>
Date: Thu, 15 May 2008 13:41:13 -0700

I’m not “sure” about this section.  What’s “remain valid for use” mean?  Can Karen still tag new data that way if it helps her application?

In the following section it isn’t clear to me that the SHOULD excludes zh.  Presumably the list below is the only “SHOULD” cases, but that isn’t terribly clear to me.

  <artwork>

  </artwork>

</figure>

The Chinese family paragraph also emphasizes the historical use of zh, which many tag examples, but there is not complimentary section describing examples of the tags one might now choose (zh/yue/cmn, etc.)

I misread the meaning of “encompassed language”.  Is there a definition of that somewhere?  I think an example would be appropriate, perhaps changing the last sentence to (such as using ‘cmn’ with the 'Hans' subtag to identify Mandarin with the simplified Chinese script)

-    Shawn

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 15 May 2008 13:58:21 -0700

Hi,

Some replies follow. Note that I’m going to push a revision based on this thread to my server soon.

Co-chairs: would you prefer me to submit or not submit the results  as draft-14 before the “quiet time”?

Addison

Addison Phillips

<Addison>”Remain valid for use” means you can still use them. So the answer to your second question is “yes”</Addison>

<Addison>I agree. The edits on list today from John and Leif are instructive here and I think greatly improve this text.</Addison>

<Addison> How about we make the block on Chinese read (this may be easier to follow if I post a diff-markup):

<t>The family of languages encompassed by the macrolanguage Chinese ('zh') provides a useful illustration of this.              Historically many different kinds of content have been tagged with variations of the 'zh' subtag, with application specific meaning being associated with region codes in particular. This is because historically only the macrolanguage subtag was available for forming language tags. With the adoption of this document, subtags for the encompassed languages became available for use in language tags. These subtags SHOULD be used instead of the macrolanguage subtag 'zh' to identify Chinese language content.</t>

<t>For example, before script codes were available, Chinese written in the Traditional script was sometimes associated with the "zh-TW" (Chinese, Taiwan) tag. Another example would be the association of the various spoken or written forms of the Cantonese language with the "zh-HK" (Chinese, Hong Kong) tag. However, each of these tags could also be (and actually were) associated with other language forms as well. For example, "zh-TW" might also indicate the Min Nan language or "zh-HK" could indicate a Chinese content item adapted for Hong Kong (but not necessarily a Cantonese item: many written documents are in Mandarin Chinese).</t>

<t>Using the encompassed language subtags (in concert with other appropriate subtags) makes clear the actual language. Script, region, or other subtags can still delineate any additional or local variations in language (such as using the 'Hans' subtag to identify the simplified Chinese script or using the 'TW' region subtag to identify a Taiwanese regional form of a language). Thus, a Min Nan document written in the Traditional script and using a Taiwanese region form would use the tag "nan-Hant-TW", while a Cantonese sound recording could use the tag "yue" (Cantonese) or possibly "yue-HK" (Cantonese, Hong Kong) if the recording were appropriate to that region.</t>

</Addison>

<Addison>I added formal definitions.</Addison>

-    Shawn

---

From: Shawn Steele <[email-masked]>
Date: Thu, 15 May 2008 14:17:01 -0700

I like these changes.

Re: the grandfathered tags, I think it might be necessary to be clear that, though grandfathered, some existing applications may depend on them, particularly zh-cmn and zh-yue.  I think this is different than previous grandfathered cases because a) They seem to be more widely used (eg Wikipedia) than i-klingon, and b) other grandfathered tags (zh-guoyu) point(ed) at them, and c) RFC 4646 made that direction seem likely.  Maybe these two even need a “grandfathered but recognized as being extra special” category.

- Shawn

From: Phillips, Addison [mailto:[email-masked]]
Sent: Thursday, May 15, 2008 1:58 PM
To: Shawn Steele; [email-masked]
Cc: LTRU Working Group
Subject: RE: [Ltru] extlang or not extlang

Hi,

Addison

Addison Phillips

</Addison>

-    Shawn

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 15 May 2008 14:18:49 -0700

I have posted an edit to inter-locale.com. Rather than quoting extensively, I have done so in a way that allows diffs to be generated. A useful diff of today’s edits:

http://tinyurl.com/5s3lql

Note that today’s version of the document lives in:

  http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14a.txt
  http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14a.html

Addison

Addison Phillips

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillips, Addison
Sent: Thursday, May 15, 2008 1:58 PM
To: Shawn Steele; [email-masked]
Cc: LTRU Working Group
Subject: Re: [Ltru] extlang or not extlang

Hi,

Addison

Addison Phillips

</Addison>

-    Shawn

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 15 May 2008 14:42:05 -0700

Whoops. I sent this a little fast. If you look at these documents now, they are up to date. I’m not going to change these again today.

Addison

Addison Phillips

From: Phillips, Addison
Sent: Thursday, May 15, 2008 2:19 PM
To: Phillips, Addison; Shawn Steele; [email-masked]
Cc: LTRU Working Group
Subject: RE: [Ltru] extlang or not extlang

Addison

Addison Phillips

Hi,

Addison

Addison Phillips

</Addison>

-    Shawn

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 15 May 2008 16:34:46 -0700

Hi -

> From: "Phillips, Addison" <[email-masked]>
> To: "Shawn Steele" <[email-masked]>; <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
...
...

As co-chair, I think it would helpful to have something in i-d form
for the consensus call.  It should be a clear indication of how close
the "extlangless" approach can come to addressing the concerns that
have been voiced, as well as giving us a record of the full context
of the WG's decision.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 15 May 2008 16:41:12 -0700

Your wish is my command. I will submit the draft-14 document in its most complete state just prior to the quiet time. Let's say, COB Pacific Time tomorrow (Friday 16 May).

Addison

Addison Phillips

> Randy Presuhn
> Sent: Thursday, May 15, 2008 4:35 PM
> To: LTRU Working Group

---

From: Felix Sasaki <[email-masked]>
Date: Fri, 16 May 2008 09:12:02 +0900

> I like these changes.

me too.

Felix

>  
>
> Re: the grandfathered tags, I think it might be necessary to be clear 
> that, though grandfathered, some existing applications may depend on 
> them, particularly zh-cmn and zh-yue.  I think this is different than 
> previous grandfathered cases because a) They seem to be more widely 
> used (eg Wikipedia) than i-klingon, and b) other grandfathered tags 
> (zh-guoyu) point(ed) at them, and c) RFC 4646 made that direction seem 
> likely.  Maybe these two even need a “grandfathered but recognized as 
> being extra special” category.
>
>  
>
> - Shawn
>
>  
>
> *From:* Phillips, Addison [mailto:[email-masked]]
> *Sent:* Thursday, May 15, 2008 1:58 PM
> *To:* Shawn Steele; [email-masked]
> *Cc:* LTRU Working Group
> *Subject:* RE: [Ltru] extlang or not extlang
>
>  
>
> Hi,
>
>  
>
> I’m not “sure” about this section.  What’s “remain valid for use” 
> mean?  Can Karen still tag new data that way if it helps her application?
>
>  
>
> <Addison>”Remain valid for use” means you can still use them. So the 
> answer to your second question is “yes”</Addison>
>
>  
>
> In the following section it isn’t clear to me that the SHOULD excludes 
> zh.  Presumably the list below is the only “SHOULD” cases, but that 
> isn’t terribly clear to me.
>
>  
>
> <Addison>I agree. The edits on list today from John and Leif are 
> instructive here and I think greatly improve this text.</Addison>
>
>  
>
> The Chinese family paragraph also emphasizes the historical use of zh, 
> which many tag examples, but there is not complimentary section 
> describing examples of the tags one might now choose (zh/yue/cmn, etc.)
>
>  
>
> <Addison> How about we make the block on Chinese read (this may be 
> easier to follow if I post a diff-markup):
>
>  
>
> <t>The family of languages encompassed by the macrolanguage Chinese 
> ('zh') provides a useful illustration of this.              
> Historically many different kinds of content have been tagged with 
> variations of the 'zh' subtag, with application specific meaning being 
> associated with region codes in particular. This is because 
> historically only the macrolanguage subtag was available for forming 
> language tags. With the adoption of this document, subtags for the 
> encompassed languages became available for use in language tags. These 
> subtags SHOULD be used instead of the macrolanguage subtag 'zh' to 
> identify Chinese language content.</t>
>
>  
>
> <t>For example, before script codes were available, Chinese written in 
> the Traditional script was sometimes associated with the "zh-TW" 
> (Chinese, Taiwan) tag. Another example would be the association of the 
> various spoken or written forms of the Cantonese language with the 
> "zh-HK" (Chinese, Hong Kong) tag. However, each of these tags could 
> also be (and actually were) associated with other language forms as 
> well. For example, "zh-TW" might also indicate the Min Nan language or 
> "zh-HK" could indicate a Chinese content item adapted for Hong Kong 
> (but not necessarily a Cantonese item: many written documents are in 
> Mandarin Chinese).</t>
>
>  
>
> <t>Using the encompassed language subtags (in concert with other 
> appropriate subtags) makes clear the actual language. Script, region, 
> or other subtags can still delineate any additional or local 
> variations in language (such as using the 'Hans' subtag to identify 
> the simplified Chinese script or using the 'TW' region subtag to 
> identify a Taiwanese regional form of a language). Thus, a Min Nan 
> document written in the Traditional script and using a Taiwanese 
> region form would use the tag "nan-Hant-TW", while a Cantonese sound 
> recording could use the tag "yue" (Cantonese) or possibly "yue-HK" 
> (Cantonese, Hong Kong) if the recording were appropriate to that 
> region.</t>
>
>  
>
> <t>Historically subtags for the various encompassed Chinese languages 
> were not available. To overcome this deficiency, some content in these 
> languages uses grandfathered tags registered for specific languages 
> (such as "zh-yue" for Cantonese or "zh-xiang" for Xiang).  The 
> grandfathered tags were deprecated in the registry upon adoption of 
> this document, but remain valid for use. Since implementations might 
> not be able to associate the grandfathered tags with these modern 
> equivalents, implementations are encouraged to canonicalize tags for 
> comparison purposes.</t>
>
>  
>
>  
>
>  
>
> </Addison>
>
>  
>
>  
>
> I misread the meaning of “encompassed language”.  Is there a 
> definition of that somewhere?  I think an example would be 
> appropriate, perhaps changing the last sentence to (such as using 
> ‘cmn’ with the 'Hans' subtag to identify Mandarin with the simplified 
> Chinese script)
>
>  
>
> ------------------------------------------------------------------------
>

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 16 May 2008 14:19:14 -0700

I have been completely swamped with the Unicode Technical committee meeting
all this week, so I've only been able to squeeze in comments here and there.
The new text that you have looks pretty good, but I haven't had time to look
it over in detail. I'll try to respond before EOD today (I'm guessing that's
what you mean by COB?).

Mark

On Thu, May 15, 2008 at 4:41 PM, Phillips, Addison <[email-masked]>
wrote:

> Your wish is my command. I will submit the draft-14 document in its most
> complete state just prior to the quiet time. Let's say, COB Pacific Time
> tomorrow (Friday 16 May).
>
> Addison
>
> Addison Phillips
> > > Some replies follow. Note that I'm going to push a revision based on
> > this thread to my server soon.
> > >
> > > Co-chairs: would you prefer me to submit or not submit the results
> > as draft-14 before the "quiet time"?
> > ...
> >

-- 
Mark

---

From: John Cowan <[email-masked]>
Date: Fri, 16 May 2008 17:56:33 -0400

> it over in detail. I'll try to respond before EOD today (I'm guessing that's

"Close of business", typically 1700 local time.

-- 
We call nothing profound                        [email-masked]
that is not wittily expressed.                  John Cowan
        --Northrop Frye (improved)
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 16 May 2008 15:47:41 -0700

Comments on
http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14b.html#macrolanguages
I assume this is the latest version.

I tried to make minimal changes to the text, and have commentary in [...]
after the paragraph, and replacements in =>

Some primary language records in the registry have a "Macrolanguage" field (
Section 3.1.9 (Macrolanguage
Field)<http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14b.html#macrolang>)
that contains a mapping from each "encompassed language" to its
macrolanguage. The Macrolanguage mapping doesn't define what the
relationship between the encompassed language and its macrolanguage is, nor
does it define how languages encompassed by the same macrolanguage are
related to each other. Either the macrolanguage or the encompassed language
subtag MAY be used when forming the language tag. Generally the
more-specific encompassed language subtag SHOULD be used. This means that,
for example, Cantonese and Hakka SHOULD use the 'yue' and 'hak' subtags
respectively for tagging and lookup in preference to 'zh' (Chinese), Tajiki
Arabic 'abh' instead of 'ar' (Arabic), and Plains Cree with 'crk' rather
than 'cre' (Cree), and so on.

[ok]

 The family of languages encompassed by the macrolanguage Chinese ('zh')
provides a useful illustration of this. Many different kinds of content have
used tags beginning with the 'zh' subtag, with application specific meaning
being associated with region codes in particular. This is because
historically only the macrolanguage subtag was available for forming
language tags. However, these languages are, in the main, not mutually
intelligible when spoken. Written forms of these languages also show wide
variation in form and usage and many of these languages are written in
various contexts.

[ok]

 For some applications, it is possible that there will be cases where it
could be advantageous to deliberately use a tag which is imprecise. For
example, due to the peculiar situation of written Chinese, an application
with large quantities of legacy textual data already using tags that start
with the 'zh' (Chinese) subtag might countinue to use this overly-broad
subtag even for new data, which would otherwise be more precisely be tagged
with 'cmn' (Mandarin).

=>

For some applications, it may be advantageous to use the macrolanguage
instead of the encompassed language, specifically with Chinese and Arabic.
For example, an application with large quantities of textual data already
using tags with the 'zh' (Chinese) subtag might continue to use this more
general subtag even for new data, which could be more precisely be tagged
with 'cmn' (Mandarin). Similarly, an application already using tags that
start with the 'ar' (Arabic) subtag might continue to use this more general
subtag even for new data, which could be more precisely be tagged with 'arb'
(Standard Arabic).

[cleaned up language, removed some unnecessary wording, combined with Arabic
example (see below for reason). ]

With the adoption of this document, subtags for the encompassed languages
became available for use in language tags. Thus, following the general
guideline, for Chinese the encompassed language subtags SHOULD be used
instead of the macrolanguage subtag 'zh'.

[Remove the above paragraph. It doesn't add anything to what is in the first
paragraph, and is better stated there.]

In some cases, encompassed languages had tags registered for them during the
RFC 3066 era. Those grandfathered tags not already deprecated were
deprecated in the registry upon adoption of this document. As grandfathered
values, they remain valid for use and some content or applications might use
them. Since implementations might not be able to associate the grandfathered
tags with the encompassed language subtag equivalents that are recommended
by this document, implementations are encouraged to canonicalize tags for
comparison purposes. Some examples of this include the tags "zh-yue"
(Cantonese), "zh-hakka" (Hakka), and "zh-cmn-Hans" (Mandarin Chinese,
Simplified Chinese script).

[change "Since implementations might not be able to associate the
grandfathered tags" to "As with other grandfathered tags, since
implementations might not be able to associate these grandfathered tags"]

The situation with the Arabic ('ar') macrolanguage is essentially identical
to the Chinese situation, except that while almost all written Arabic is
Standard Arabic ('arb'), most spoken Arabic is in one of the other
encompassed Arabic languages. Consequently, the subtag 'ar' SHOULD be
avoided for tagging spoken varieties.

[Remove the 'ar' paragraph, and fold into paragraph above, as there noted.
It was unnecessarily separated by the grandfathering section, and my
understanding is that the original text was overstating the case with spoken
Arabic.]

Each Macrolanguage's subtag, by definition, includes all of its encompassed
languages. Since the relationship between encompassed languages varies, and,
with the exception of a few languages cited in the table following this
paragraph, users cannot assume that the macrolanguage subtag means any
particular encompassed language nor that any given pair of encompassed
languages are mutually intelligible or otherwise interchangeable. The
languages in the following table represent the only cases in which the
macrolanguage subtag SHOULD be used in preference to the specified
encompassed language subtag. All other encompassed languages contained by
the macrolanguages in this table SHOULD use their specific encompassed
language subtag to distinguish themselves from the broader macrolanguage.

[I'm actually not really happy with removing zh and ar from this list --
because it doesn't reflect reality -- but I can live with it. However, we
have already given exceptional cases above, so for consistency, we need a
bit of wording change, just to point out that 'ar' and 'zh' are handled
differently.]
=>
Each Macrolanguage's subtag, by definition, includes all of its encompassed
languages. Since the relationship between encompassed languages varies, and,
with the exception of a few languages cited in the table following this
paragraph, users cannot assume that the macrolanguage subtag means any
particular encompassed language nor that any given pair of encompassed
languages are mutually intelligible or otherwise interchangeable. The
languages in the following table represent cases in which the macrolanguage
subtag SHOULD be used in preference to the specified encompassed language
subtag. (The situation regarding 'zh' and 'ar' is discussed above.)

------------------------------

  Konkani (macrolanguage) 'kok'  Konkani (individual language) 'knn'
  Malay (macrolanguage) 'ms'     Standard Malay 'zsm'
  Swahili (macrolanguage) 'sw'   Swahili (individual language) 'swh'
  Uzbek 'uz'                     Northern Uzbek 'uzn'

* Figure 8: Macrolanguages closely identified with individual languages *
------------------------------

Applications MAY use macrolanguage information to improve matching or
language negotiation. For example, the information that 'sr' (Serbian) and
'hr' (Croatian) share a macrolanguage expresses a closer relation between
those languages than between, say, 'sr' (Serbian) and 'ma' (Macedonian).
While it is valid to use either the subtag of the encompassed language or of
the macrolanguage to form a language tag, many matching applications will
not be aware of the relationship between the languages.

=>

Applications MAY use macrolanguage information to improve matching or
language negotiation. For example, the information that 'sr' (Serbian) and
'hr' (Croatian) share a macrolanguage expresses a closer relation between
those languages than between, say, 'sr' (Serbian) and 'ma' (Macedonian).
However, this relationship is not guaranteed nor is it exclusive. For
example, Romanian ('ro') and Moldavian ('mo') do not share a macrolanguage,
but are far more closely related to each other than Cantonese ('yue') and Wu
('wuu') , which do share a macrolanguage.

[Point out that the encompassed languages are not necessarily particularly
close in terms of comprehensibility. Another example could be used if people
want. Last sentence not necessary here.]

Mark
 On Thu, May 15, 2008 at 2:18 PM, Phillips, Addison <[email-masked]>
wrote:

>  I have posted an edit to inter-locale.com. Rather than quoting
> extensively, I have done so in a way that allows diffs to be generated. A
> useful diff of today's edits:
>
>
>
> *http://tinyurl.com/5s3lql***
>
> * *
>
> *Note that today's version of the document lives in:*
>
> * *
>
> *  http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14a.txt*
>
> *  http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14a.html*
>
> * *
>
> *Addison*
>
>
>
> Addison Phillips
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Phillips, Addison
> *Subject:* Re: [Ltru] extlang or not extlang
>
>
>
> Hi,
>
>
>
> Some replies follow. Note that I'm going to push a revision based on this
> thread to my server soon.
>
>
>
> Co-chairs: would you prefer me to submit or not submit the results  as
> draft-14 before the "quiet time"?
>
>
>
> Addison
>
>
>
>
>
> Addison Phillips
>
> I'm not "sure" about this section.  What's "remain valid for use" mean?
> Can Karen still tag new data that way if it helps her application?
>
>
>
> <Addison>"Remain valid for use" means you can still use them. So the answer
> to your second question is "yes"</Addison>
>
>
>
> In the following section it isn't clear to me that the SHOULD excludes zh.
> Presumably the list below is the only "SHOULD" cases, but that isn't
> terribly clear to me.
>
>
>
> which many tag examples, but there is not complimentary section describing
> examples of the tags one might now choose (zh/yue/cmn, etc.)
>
>
>
> <t>The family of languages encompassed by the macrolanguage Chinese ('zh')
> provides a useful illustration of this.              Historically many
> different kinds of content have been tagged with variations of the 'zh'
> subtag, with application specific meaning being associated with region codes
> in particular. This is because historically only the macrolanguage subtag
> was available for forming language tags. With the adoption of this document,
> subtags for the encompassed languages became available for use in language
> tags. These subtags SHOULD be used instead of the macrolanguage subtag 'zh'
> to identify Chinese language content.</t>
>
>
>
> <t>For example, before script codes were available, Chinese written in the
> Traditional script was sometimes associated with the "zh-TW" (Chinese,
> Taiwan) tag. Another example would be the association of the various spoken
> or written forms of the Cantonese language with the "zh-HK" (Chinese, Hong
> Kong) tag. However, each of these tags could also be (and actually were)
> associated with other language forms as well. For example, "zh-TW" might
> also indicate the Min Nan language or "zh-HK" could indicate a Chinese
> content item adapted for Hong Kong (but not necessarily a Cantonese item:
> many written documents are in Mandarin Chinese).</t>
>
>
>
> appropriate subtags) makes clear the actual language. Script, region, or
> other subtags can still delineate any additional or local variations in
> language (such as using the 'Hans' subtag to identify the simplified Chinese
> script or using the 'TW' region subtag to identify a Taiwanese regional form
> of a language). Thus, a Min Nan document written in the Traditional script
> and using a Taiwanese region form would use the tag "nan-Hant-TW", while a
> Cantonese sound recording could use the tag "yue" (Cantonese) or possibly
> "yue-HK" (Cantonese, Hong Kong) if the recording were appropriate to that
> region.</t>
>
>
>
> <t>Historically subtags for the various encompassed Chinese languages were
> not available. To overcome this deficiency, some content in these languages
> uses grandfathered tags registered for specific languages (such as "zh-yue"
> for Cantonese or "zh-xiang" for Xiang).  The grandfathered tags were
> deprecated in the registry upon adoption of this document, but remain valid
> for use. Since implementations might not be able to associate the
> grandfathered tags with these modern equivalents, implementations are
> encouraged to canonicalize tags for comparison purposes.</t>
>
>
>
>
>
>
>
> </Addison>
>
>
>
>
>
> I misread the meaning of "encompassed language".  Is there a definition of
> that somewhere?  I think an example would be appropriate, perhaps changing
> the last sentence to (such as using 'cmn' with the 'Hans' subtag to
> identify Mandarin with the simplified Chinese script)
>
>
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Fri, 16 May 2008 15:58:55 -0700

Comments follow, prefixed with <AP>

Comments on http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14b.html#macrolanguages
I assume this is the latest version.

<AP> It is.

For some applications, it is possible that there will be cases where it could be advantageous to deliberately use a tag which is imprecise. For example, due to the peculiar situation of written Chinese, an application with large quantities of legacy textual data already using tags that start with the 'zh' (Chinese) subtag might countinue to use this overly-broad subtag even for new data, which would otherwise be more precisely be tagged with 'cmn' (Mandarin).
=>
For some applications, it may be advantageous to use the macrolanguage instead of the encompassed language, specifically with Chinese and Arabic. For example, an application with large quantities of textual data already using tags with the 'zh' (Chinese) subtag might continue to use this more general subtag even for new data, which could be more precisely be tagged with 'cmn' (Mandarin). Similarly, an application already using tags that start with the 'ar' (Arabic) subtag might continue to use this more general subtag even for new data, which could be more precisely be tagged with 'arb' (Standard Arabic).
[cleaned up language, removed some unnecessary wording, combined with Arabic example (see below for reason). ]

<AP> Done, with some edits, as follows:

<t>For some applications, it might be advantageous to use the macrolanguage subtag to form the tag instead of using the more specific encompassed language subtag. This is specifically the case with the Chinese and Arabic language families. For example, an application with large quantities of textual data already using tags with the 'zh' (Chinese) subtag might continue to use this more general subtag even for new data, even though the content could be more precisely be tagged with 'cmn' (Mandarin). Similarly, an application already using tags that start with the 'ar' (Arabic) subtag might continue to use this more general subtag even for new data, which could be more precisely be tagged with 'arb' (Standard Arabic).</t>
---

With the adoption of this document, subtags for the encompassed languages became available for use in language tags. Thus, following the general guideline, for Chinese the encompassed language subtags SHOULD be used instead of the macrolanguage subtag 'zh'.
[Remove the above paragraph. It doesn't add anything to what is in the first paragraph, and is better stated there.]

<AP> Done. Although I note that this is the specific normative text others have asked for.

In some cases, encompassed languages had tags registered for them during the RFC 3066 era. Those grandfathered tags not already deprecated were deprecated in the registry upon adoption of this document. As grandfathered values, they remain valid for use and some content or applications might use them. Since implementations might not be able to associate the grandfathered tags with the encompassed language subtag equivalents that are recommended by this document, implementations are encouraged to canonicalize tags for comparison purposes. Some examples of this include the tags "zh-yue" (Cantonese), "zh-hakka" (Hakka), and "zh-cmn-Hans" (Mandarin Chinese, Simplified Chinese script).
[change "Since implementations might not be able to associate the grandfathered tags" to "As with other grandfathered tags, since implementations might not be able to associate these grandfathered tags"]

<AP> Done.

The situation with the Arabic ('ar') macrolanguage is essentially identical to the Chinese situation, except that while almost all written Arabic is Standard Arabic ('arb'), most spoken Arabic is in one of the other encompassed Arabic languages. Consequently, the subtag 'ar' SHOULD be avoided for tagging spoken varieties.
[Remove the 'ar' paragraph, and fold into paragraph above, as there noted. It was unnecessarily separated by the grandfathering section, and my understanding is that the original text was overstating the case with spoken Arabic.]

<AP> Done.

Each Macrolanguage's subtag, by definition, includes all of its encompassed languages. Since the relationship between encompassed languages varies, and, with the exception of a few languages cited in the table following this paragraph, users cannot assume that the macrolanguage subtag means any particular encompassed language nor that any given pair of encompassed languages are mutually intelligible or otherwise interchangeable. The languages in the following table represent the only cases in which the macrolanguage subtag SHOULD be used in preference to the specified encompassed language subtag. All other encompassed languages contained by the macrolanguages in this table SHOULD use their specific encompassed language subtag to distinguish themselves from the broader macrolanguage.
[I'm actually not really happy with removing zh and ar from this list -- because it doesn't reflect reality -- but I can live with it. However, we have already given exceptional cases above, so for consistency, we need a bit of wording change, just to point out that 'ar' and 'zh' are handled differently.]
=>
Each Macrolanguage's subtag, by definition, includes all of its encompassed languages. Since the relationship between encompassed languages varies, and, with the exception of a few languages cited in the table following this paragraph, users cannot assume that the macrolanguage subtag means any particular encompassed language nor that any given pair of encompassed languages are mutually intelligible or otherwise interchangeable. The languages in the following table represent cases in which the macrolanguage subtag SHOULD be used in preference to the specified encompassed language subtag. (The situation regarding 'zh' and 'ar' is discussed above.)

<AP> Done.
________________________________________
Applications MAY use macrolanguage information to improve matching or language negotiation. For example, the information that 'sr' (Serbian) and 'hr' (Croatian) share a macrolanguage expresses a closer relation between those languages than between, say, 'sr' (Serbian) and 'ma' (Macedonian). While it is valid to use either the subtag of the encompassed language or of the macrolanguage to form a language tag, many matching applications will not be aware of the relationship between the languages.
=>
Applications MAY use macrolanguage information to improve matching or language negotiation. For example, the information that 'sr' (Serbian) and 'hr' (Croatian) share a macrolanguage expresses a closer relation between those languages than between, say, 'sr' (Serbian) and 'ma' (Macedonian). However, this relationship is not guaranteed nor is it exclusive. For example, Romanian ('ro') and Moldavian ('mo') do not share a macrolanguage, but are far more closely related to each other than Cantonese ('yue') and Wu ('wuu') , which do share a macrolanguage.
[Point out that the encompassed languages are not necessarily particularly close in terms of comprehensibility. Another example could be used if people want. Last sentence not necessary here.]

<AP> Done.

===============

Edits to be posted shortly.

Addison

---

From: John Cowan <[email-masked]>
Date: Fri, 16 May 2008 19:14:34 -0400

> understanding is that the original text was overstating the case with spoken

Well, "most" *is* overstated, but the general point is still true.  However,
I'm happy with your shortened wording above.

> want. Last sentence not necessary here.]

Examples are never *necessary*, but this one IMHO improves clarity, and should stay.

-- 
MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS
John Cowan      [email-masked]      http://www.ccil.org/~cowan
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 16 May 2008 18:16:19 -0700

After looking over your comment, I think we want to make the point of the
last sentence more clearly at the beginning, as well. What I propose is
splitting the first paragraph and inserting a new sentence (in yellow below,
the last line of the first paragraph):

Some primary language records in the registry have a "Macrolanguage" field (
Section 3.1.9 (Macrolanguage
Field)<http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14b.html#macrolang>)
that contains a mapping from each "encompassed language" to its
macrolanguage. The Macrolanguage mapping doesn't define what the
relationship between the encompassed language and its macrolanguage is, nor
does it define how languages encompassed by the same macrolanguage are
related to each other. In particular, two different languages encompassed by
the same macrolanguage may differ from one another more than say, French and
Spanish do.

Either the macrolanguage or the encompassed language subtag MAY be used when
forming the language tag. Generally the more-specific encompassed language
subtag SHOULD be used. This means that, for example, Cantonese and Hakka
SHOULD use the 'yue' and 'hak' subtags respectively for tagging and lookup
in preference to 'zh' (Chinese), Tajiki Arabic 'abh' instead of 'ar'
(Arabic), and Plains Cree with 'crk' rather than 'cre' (Cree), and so on.

How does that sound?

Mark

On Fri, May 16, 2008 at 4:14 PM, John Cowan <[email-masked]> wrote:

> John Cowan      [email-masked]      http://www.ccil.org/~cowan<http://www.ccil.org/%7Ecowan>
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Fri, 16 May 2008 20:26:43 -0700

While doing this edit, I also reversed the stress of the first sentence of the second para. These now read:

--
<t>Some primary language records in the registry have a "Macrolanguage" field (<xref target="macrolang"></xref>) that contains a mapping from each "encompassed language" to its macrolanguage. The Macrolanguage mapping doesn't define what the relationship  between the encompassed language and its macrolanguage is, nor does it define how languages encompassed by the same macrolanguage are related to each other.　Two different languages encompassed by the same macrolanguage may differ from one another more than say, French and Spanish do.</t>

<t>The more specific encompassed language subtag SHOULD be used to form the language tag, although either the macrolanguage or the encompassed language subtag MAY be used. This means, for example, tagging Cantonese ('yue') specifically rather than using the subtag for its macrolanguage Chinese ('zh'); Tajiki Arabic 'abh' instead of 'ar' (Arabic); Plains Cree with 'crk' rather than 'cre' (Cree); and so forth.</t>
--

This puts the emphasis on using the encompassed subtag.

Addison Phillips

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Friday, May 16, 2008 6:16 PM
To: John Cowan
Cc: Phillips, Addison; LTRU Working Group; [email-masked]
Subject: Re: [Ltru] extlang or not extlang

After looking over your comment, I think we want to make the point of the last sentence more clearly at the beginning, as well. What I propose is splitting the first paragraph and inserting a new sentence (in yellow below, the last line of the first paragraph):
Some primary language records in the registry have a "Macrolanguage" field (Section 3.1.9 (Macrolanguage Field)<http://www.inter-locale.com/ID/editor/draft-ietf-ltru-4646bis-14b.html#macrolang>) that contains a mapping from each "encompassed language" to its macrolanguage. The Macrolanguage mapping doesn't define what the relationship between the encompassed language and its macrolanguage is, nor does it define how languages encompassed by the same macrolanguage are related to each other. In particular, two different languages encompassed by the same macrolanguage may differ from one another more than say, French and Spanish do.

Either the macrolanguage or the encompassed language subtag MAY be used when forming the language tag. Generally the more-specific encompassed language subtag SHOULD be used. This means that, for example, Cantonese and Hakka SHOULD use the 'yue' and 'hak' subtags respectively for tagging and lookup in preference to 'zh' (Chinese), Tajiki Arabic 'abh' instead of 'ar' (Arabic), and Plains Cree with 'crk' rather than 'cre' (Cree), and so on.

How does that sound?

Mark
On Fri, May 16, 2008 at 4:14 PM, John Cowan <[email-masked]<mailto:[email-masked]>> wrote:

--
MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS
John Cowan      [email-masked]<mailto:[email-masked]>      http://www.ccil.org/~cowan<http://www.ccil.org/%7Ecowan>