Subject: [Ltru] Consensus call: extlang

From: tex <[email-masked]>
Date: Wed, 28 May 2008 18:03:58 -0700 (PDT)

Aw heck. I have been trying hard to resist engaging on this for months and months, but now my resistance is gone...
If you don't mind late votes, then put me down for:
Q1: A
Q2: C
tex
Hi -
Martin and I double-checked the tally, and it turns out that
*two* responses were sent directly to me, rather than to the [email-masked] mailing list. One was sent after the deadline.
Here's the tally including those three:
Q1: A-4 B-9 C-4
Q2: A-8 B-5 C-4
Excluding those three responses, it looks like:
Q1: A-2 B-9 C-3
Q2: A-7 B-5 C-2
Either way, the support for an extlang-less approach appears to be in he distinct minority, and there appears to be a marked preference (which we'll call a *rough* consensus) for "reinstating" extlang.
Or have a bunch of people changed their minds?
Randy

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

---

From: "Broome, Karen" <[email-masked]>
Date: Wed, 28 May 2008 19:26:22 -0700

Why are people so afraid to restate their honest opinions on this? Why are people only voting in private? I'm getting private e-mail too.

I thought the primary goal was identification, not fallback. Without extlang, we lose some information the ISO standards otherwise contain.  I think we may be losing an oppportunity to clean up some historically muddy tags. I raise questions about identification and I am answered with arguments about fallback. I honestly fear this draft may not be an improvement for me.

Phrases like "throws in the towel," "my resistance is gone," "as neutral as I can be" ... Something does not feel good about this.

Karen Broome

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of tex [[email-masked]]
Sent: Wednesday, May 28, 2008 6:03 PM
To: [email-masked]
Subject: [Ltru] Consensus call: extlang

Q1: A

Q2: C

tex

Hi -

Q1: A-4 B-9 C-4

Q2: A-8 B-5 C-4

Q1: A-2 B-9 C-3

Q2: A-7 B-5 C-2

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 28 May 2008 21:14:31 -0700

If identification is what you want, then "cmn" IS unambigously Mandarin
(indeterminate script); "yue" is unambiguously Cantonese (indeterminate
script); you certainly don't need extlang complicating matters.
The string "zh-yue" is really a different semantic; it is not just
Cantonese, it is
"Cantonese-but-fall-back-to-ambiguously-Chinese-of-indeterminate-script" in
lookup (but not some other operations like RFC 4646 filtering).

And "zh-yue-Hant-MO"
is "Cantonese-in-Simplified-Han-script-and-as-used-in-Macao-but-fall-back-to-ambiguously-Chinese-of-indeterminent-script",
again, in lookup.

Mark

On Wed, May 28, 2008 at 7:26 PM, Broome, Karen <[email-masked]>
wrote:

> Why are people so afraid to restate their honest opinions on this? Why are
> people only voting in private? I'm getting private e-mail too.
>
> I thought the primary goal was identification, not fallback. Without
> extlang, we lose some information the ISO standards otherwise contain.  I
> think we may be losing an oppportunity to clean up some historically muddy
> tags. I raise questions about identification and I am answered with
> arguments about fallback. I honestly fear this draft may not be an
> improvement for me.
>
> Phrases like "throws in the towel," "my resistance is gone," "as neutral as
> I can be" ... Something does not feel good about this.
>
>
> Karen Broome
>
>
> *two* responses were sent directly to me, rather than to the [email-masked] list. One was sent after the deadline.
>
> Either way, the support for an extlang-less approach appears to be in he
> distinct minority, and there appears to be a marked preference (which we'll
> call a *rough* consensus) for "reinstating" extlang.
>

-- 
Mark

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 29 May 2008 09:01:48 +0200

Mark Davis 2008-05-29 06.14:

> [...] The string "zh-yue" is really a different semantic; it is
>  not just Cantonese, it is "Cantonese-but-fall-back-to- 
> ambiguously-Chinese-of-indeterminate-script" in lookup (but not
> some other operations like RFC 4646 filtering). [...]

If the focus is identification, then the fallback and filtering 
doesn't matter (or must be defined subsequently).  Certainly, 
however, it is because 'zh-yue' can be identified with 'zh' that 
it can default/fall back to 'zh'.  By saying 'zh-yue' we are also 
identifying 'zh' - as a wide tag.

Extlang makes identifying/finding *all* Chinese languages simple, 
for those that need to do find them all. It would only require 
that you ask for 'zh'. Thus with extlang one could start tagging 
resources spesificly *immediatly*, because it should be highly 
compatible with existing application behaviour.

(Btw, this approach strikes me as higly compatible with another 
popular slogan: Don't break the Web.)

Whether 'zh' or any other Macrolanguage tag would be recommended 
  - alone or together with more spesific tags - as "preferred 
language tag" in Web browsers etc, is a question that must be 
determined by examining the situation for each language and 
localisation.  And it must determined separately from the question 
of how to tag the resources to be consumed (text/audio/video) by 
that program.

(I personally have a hard time thinking that it will *ever* happen 
that e.g. a Chinese user will *not* need to ask for 'zh' 
regardless what we do.)

> On Wed, May 28, 2008 at 7:26 PM, Broome, Karen: 
>> I thought the primary goal was identification, not fallback.
>> Without extlang, we lose some information the ISO standards
>> otherwise contain.  I think we may be losing an oppportunity
>> to clean up some historically muddy tags. I raise questions
>> about identification and I am answered with arguments about
>> fallback. I honestly fear this draft may not be an 
>> improvement for me

What I have understood lately, because I've understood better how 
fallback works, is that extlang WRT fallback is closer to the 
no-extlang solution than I thought. This fact ought to be a reason 
to  focus more on the identifaction issue. The identification 
issue is also more related to tagging *resources* than to saying 
how *applications* should find those resources. At the same time, 
it is of course good to have a compatible model.

I think that deprecating the 'zh' or any of the other 
macrolanguage tags must be out of question. If the purpose of the 
RFC is to deal especially with the Macrolanguages, then it would 
be a strange thing to deprecate those tags. ISO has defined them. 
They must be accepted. Instead  one could focus on saying hat 
macrolanguage tags and extlang tags are good for different 
purposes. One should generally advice strongly against using the 
macrolanguage subtags alone, for tagging, for the identication 
reasons you mention. While at the same time doing a much more 
careful evaluation about what to do inside Web browsers and other 
applications that can be used to find those resources.

This thing with "historically muddy tags" is important. The 
identification argument *is* connected to those Macrolanguage tags 
which are allready in use, and especially to those Macrolanguage 
tags which have been the sole tag for an entire Macrolanguage.

Btw, for those macrolanguages which will not get extlang, we 
should get into the RFC, that to use the Macrolanguage subtag in 
e.g. a Web browser will lead to all encompassed languages being 
included. (With the exception for Swahili, Uzbek etc.) That way, 
for those Macrolanguges which are covering closely related 
encompassed languages, the users and implementors will only need 
to include two tags in order to cover the entire Macrolanguage 
*and* to specify one's preferred encompassed language. I.e. the 
same number of tags that those *with* encompassed languages 
generally will need to include .
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 29 May 2008 09:24:36 +0200

Leif Halvard Silli 2008-05-29 09.01:
   [... snip to last sentence ... ]

> I.e. the same number of tags that those *with* encompassed
> languages generally will need to include .

Sorry, meant to say "... those *with* extlang language tags ...".
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Kent Karlsson" <[email-masked]>
Date: Thu, 29 May 2008 10:07:52 +0200

Broome, Karen wrote:
> otherwise contain. 

You seem to be arguing for (in an ideal case) a partial
language family hierarcy in each tag. Tags like

gem-de (or gem-deu)

or even

und-ine-gem-de-gsw

and the like. Of course that is not possible to introduce, for
several reasons. I'm just trying to understand your argument.
As Mark mentioned, the individual language codes do identify
a language, without explicitly giving any part of the
hierarchy in the tag.

	/kent k

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 29 May 2008 10:36:47 +0200

> a language, without explicitly giving any part of the

Like I said in my response, I think the identification issue has 
to do with the currently used general tags. If 'gem' a) had been a 
macrolanguage tag and b) had been the currently used tag for all 
the encompassed languages, then we would have had the same situation.

Then, when ISO defineed "deu" as tag for Hochdeutch, LTRU could 
have implempented tagging as 'gem-deu'. Browsers searching for 
'gem' would still find it, while we at the same time could get new 
browsers to search for  'gem-deu' primarely and 'gem' secondly.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Broome, Karen" <[email-masked]>
Date: Thu, 29 May 2008 09:19:32 -0700

Yikes, if I implied that, my apologies. I don't want that at all. I don't want any hierarchies that aren't already baked into the ISO standards.

Karen

>-----Original Message-----
>From: Kent Karlsson [mailto:[email-masked]]
>Sent: Thursday, May 29, 2008 1:08 AM
>To: Broome, Karen; [email-masked]
>Subject: RE: [Ltru] Consensus call: extlang
>
>
>Broome, Karen wrote:

---

From: "Kent Karlsson" <[email-masked]>
Date: Thu, 29 May 2008 18:38:37 +0200

The 630-* ISO standards have a hierachy "baked in", though not
explicitly, until ISO 639-5:2008, Codes for the representation
of names of languages -- Part 5: Alpha-3 code for language families
and groups (which I haven't seen a copy of yet). The hierarchy
is still implicit in parts 1-3 which have collection codes
(part 1 has only, if you pardon the expression, half-hearted
collection codes, zh and ar).

I understand that you do not want tags like gem-deu, but you seem
to want to have tags like zh-yue. For "identification purposes"
(as well as much else) the approach for both those examples seem
to be the same. I'm still just trying to understand your argument.

	/kent k

> From: Broome, Karen [mailto:[email-masked]] 
> Sent: Thursday, May 29, 2008 6:20 PM
> To: Kent Karlsson; [email-masked]
> Yikes, if I implied that, my apologies. I don't want that at 
> all. I don't want any hierarchies that aren't already baked 
> into the ISO standards.
> 
> Karen
>

---

From: "Broome, Karen" <[email-masked]>
Date: Thu, 29 May 2008 09:42:05 -0700

Mark writes:

>If identification is what you want, then "cmn" IS unambigously
>Mandarin (indeterminate script);

But is "cmn" the tag you will use, Mark?

>Cantonese, it is "Cantonese-but-fall-back-to-ambiguously-Chinese-of-
>indeterminate-script" in lookup (but not some other operations like
>RFC 4646 filtering).

The fallback is *NOT*, I repeat *NOT*, part of the semantic of that tag. ISO defines the semantics of the tags and fallback has nothing to do with identifying languages.

My issue is this: If I look at my real-world language list and the codes I've assigned, I think everyone on this list would agree that the codes I've chosen based on the IANA registry and RFC 4646 are the best tags for that content. I have codes for everything I need today, thanks to the patient guidance of everyone on this list.

However, when RFC 4646bis is released, it seems like I will be using different tags than everyone else on this list and we will no longer agree on what the best tag is. I fear the subtleties in the rules may prove tougher to explain than today's rules which already cause some eyerolling. Considering this, I start to wonder if the release of RFC 4646bis is a step backward or forward. While I'm happy there's a tag for Broome Pearling Lugger Pidgin in ISO 639-3, I don't have any personal need for it.

Regards,

Karen Broome

---

From: Peter Constable <[email-masked]>
Date: Thu, 29 May 2008 09:53:28 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Leif Halvard Silli

> doesn't matter (or must be defined subsequently).

Sorry, but this is not a sensible approach to coding.

By "identification", we're talking about devising a coding scheme that provides code elements used to represent a semantic for the purpose of declaring language identity on information objects, and *also* for use in various kinds of processing on those information objects. If declaring identity was the only purpose, and processing is irrelevant, then all bets are off as to what the best way is to represent identities -- for instance, a URI pointing to some encyclopedic description strikes me as a far better identifier.

Our language tags exist *because* of processing scenarios. Nobody would bother wasting time adding a tag to metadata on information objects if it was just going to _be_, ignored and taking up space.

The coded representation of a semantic category can take any form, and as long as all are equally documented the identificational value of each of those potential forms is exactly equivalent. For instance, "cmn" and "zh-cmn" are exactly equal in terms of identificational value -- meaning "Mandarin". Mark described these as different, but I think the difference he pointed out was one of processing, not one of identity.

If I know the relationship between Mandarin and "Chinese", then I can make exactly the same processing decisions with "cmn" as I can with "zh-cmn". But the two differ wrt what kinds of processing mechanisms are available to me: "cmn" requires that a process have a separate business knowledge relating Mandarin and "Chinese", but "zh-cmn" embeds that knowledge into the tag itself. Since both are the same in terms of their identificational value, the question to be asked is which of these is more useful for processing.

And not just for *this* pair, but for all macrolanguage cases -- unless we're considering using extlang for just certain cases.

> Extlang makes identifying/finding *all* Chinese languages simple,

Note that you have already introduced processing.

> compatible with existing application behaviour.

For applications that use right-truncation matching, but not lookup.

> popular slogan: Don't break the Web.)

Well, not all servers use right-truncation matching logic, and for those that don't your plan would be breaking the Web. (I'm not saying that the no-extlang path doesn't have some of the same issues; either way, there are things that would need to be done to keep everything working smoothly if we want to transition from a "zh"-only past into a future that includes "cmn"/"yue"/etc.)

Peter

---

From: John Cowan <[email-masked]>
Date: Thu, 29 May 2008 14:06:55 -0400

Kent Karlsson scripsit:

> and groups (which I haven't seen a copy of yet)

The most recent version I know about is two years old, self-confessedly
incomplete, and has 105 code elements, of which 53 are shared with 639-2.
It is not clear why the nine remaining 639-2 collection code elements
(bad, btk, day, ijo, kar, kro, nah, son, znd) do not appear.

> The hierarchy is still implicit in parts 1-3 which have collection
> codes (part 1 has only, if you pardon the expression, half-hearted

Parts 1 and 3 have macrolanguage and individual language code elements.
Part 2 has language collection and individual language code elements.

> to be the same. 

Nobody treats all the Germanic languages as a single language for
any purpose.  Many people treat Chinese as a single language for many
purposes or even for all purposes.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
This great college [Trinity], of this ancient university [Cambridge],
has seen some strange sights. It has seen Wordsworth drunk and Porson
sober. And here am I, a better poet than Porson, and a better scholar
than Wordsworth, somewhere betwixt and between.  --A.E. Housman
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 29 May 2008 20:25:19 +0200

Peter Constable 2008-05-29 18.53:

>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Leif Halvard Silli
> 
> 
>> If the focus is identification, then the fallback and
>> filtering doesn't matter (or must be defined subsequently).
> 

   [...]

Note the "if". And if we try to solve too many issues at once, 
then perhaps we won't solve any thing at all.

> "cmn" requires that a process have a separate business
> knowledge relating Mandarin and "Chinese", but "zh-cmn" embeds
> that knowledge into the tag itself. Since both are the same in
> terms of their identificational value, the question to be asked
> is which of these is more useful for processing. [...]

Who will be more useful - ok. But also: Who will lead to most 
processing/most tagging.

I think that 'cmn' will be perceived as 'oh, now they have decided 
something entirely new'.  We used 'zh' in all these yeaers, and 
now - why 'yue'?

> Note that you have already introduced processing.

I know.

>> for those that need to do find them all. It would only
>> require that you ask for 'zh'. Thus with extlang one could
>> start tagging resources spesificly *immediatly*, because it
>> should be highly compatible with existing application
>> behaviour.
> 

It is of course not difficult to per se to add all tags instead of 
just one or two to one's Web browser. But in my experience it is 
difficult to even add more than one. Not to mention how difficult 
it is to get application to ad sensible algoritms so that spesific 
tags does not lead you to loose content.

>> (Btw, this approach strikes me as higly compatible with
>> another popular slogan: Don't break the Web.)
> 
> Well, not all servers use right-truncation matching logic, and
> for those that don't your plan would be breaking the Web. (I'm

It would be interesting to know some Web servers and othe servers 
where it works differently.

> not saying that the no-extlang path doesn't have some of the
> same issues; either way, there are things that would need to be
> done to keep everything working smoothly if we want to
> transition from a "zh"-only past into a future that includes
> "cmn"/"yue"/etc.

But there are no Web browsers today which ask for 'cmn' or 'yue'. 
It is 'zh' they ask for. Hence there is a chance that content 
tagged as 'zh-cmn' will Just Work, today, many places. And 
therefore I view it as a good bit more compatible with existing 
content to go for Extlang.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Broome, Karen" <[email-masked]>
Date: Thu, 29 May 2008 11:48:57 -0700

>something entirely new'.  We used 'zh' in all these yeaers, and

Depends on the context. In my industry, made-up codes are the rule rather than the exception for Mandarin and Cantonese. Having the ability to precisely code the difference in an internationally recognized way is very important to us. Web developers who do not YET deal with video content may not see the importance, but for anyone who classifies audio/video content, the existence of these tags is a relief. I think the reaction from Hollywood is likely, "What took you so long?"

Karen

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 29 May 2008 11:51:42 -0700

Here is a brief description:

   - Map deprecated codes to the canonical codes*. Thus "zh-yue" maps to
   "yue", and identifies Cantonese, "zh-hakka" maps to "hak", and so on.
      - * There are a few exceptions to this where we use the deprecated
      form as the canonical form, for backwards compatibility, eg "iw" for "he".
      - We have yet to decide what to do with codes that are illegal in
      4646, but where the intent is clear, like "zh-yue-Hant-HK"; I
suspect that
      we'll also remap those also, eg "zh-yue-Hant-HK".
      - We don't want to deal with irregular codes, so any that can't be
   resolved by this mapping are disallowed (there is a separate thread on
   that). Luckily in draft 14 there are only a small handful of those.
   - For lookup, use the kind of fallback that Addison outlined, taking into
   account backward compatibility considerations like the fact that "zh-TW" was
   used to represent "zh-Hant".
   - cmn-Hant-TW
      - zh-Hant-TW
      - cmn-Hant
      - zh-Hant
      - cmn-TW
      - zh-TW
      - cmn
      - zh
   - We have fallbacks that are unrelated to macro/micro, like
   Romanian-Moldavian, Filipino-Tagalog, and I'd expect to add to that list
   over time as we support additional languages. Mandarin might be a good
   fallback for, say, Gan; but Spanish might be a better fallback for
   various Quechua encompassed languages. Each case has to be decided on its
   own merits as it comes up: we've found that macrolanguage is not very useful
   for the goal to "give the user what s/he wants/needs".
   - Because extlang brings no benefit and only complications, if BCP 47
   were to adopt it, I suspect we would cease trying to be conformant to BCP 47
   internally.

Mark

On Thu, May 29, 2008 at 9:42 AM, Broome, Karen <[email-masked]>
wrote:

> The fallback is *NOT*, I repeat *NOT*, part of the semantic of that tag.
> ISO defines the semantics of the tags and fallback has nothing to do with
> identifying languages.
>
> My issue is this: If I look at my real-world language list and the codes
> I've assigned, I think everyone on this list would agree that the codes I've
> chosen based on the IANA registry and RFC 4646 are the best tags for that
> content. I have codes for everything I need today, thanks to the patient
> guidance of everyone on this list.
>
> However, when RFC 4646bis is released, it seems like I will be using
> different tags than everyone else on this list and we will no longer agree
> on what the best tag is. I fear the subtleties in the rules may prove
> tougher to explain than today's rules which already cause some eyerolling.
> Considering this, I start to wonder if the release of RFC 4646bis is a step
> backward or forward. While I'm happy there's a tag for Broome Pearling
> Lugger Pidgin in ISO 639-3, I don't have any personal need for it.
>
> Regards,
>
> Karen Broome
>

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 29 May 2008 11:55:22 -0700

As Karen says, we need the "yue" code, because it is very different than
"cmn", as different as French and Spanish. It would be like having to tag
all Skandinavian content with *"ski" instead of being able to distinguish
"da", "is", ...
Mark

On Thu, May 29, 2008 at 11:48 AM, Broome, Karen <[email-masked]>
wrote:

> Depends on the context. In my industry, made-up codes are the rule rather
> than the exception for Mandarin and Cantonese. Having the ability to
> precisely code the difference in an internationally recognized way is very
> important to us. Web developers who do not YET deal with video content may
> not see the importance, but for anyone who classifies audio/video content,
> the existence of these tags is a relief. I think the reaction from Hollywood
> is likely, "What took you so long?"
>
> Karen
>
>

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 29 May 2008 21:33:54 +0200

I'm sorry if it was possible to think that I said that one do not 
need to distinguish Mandarin and Cantonese.

---

From: "Broome, Karen" <[email-masked]>
Date: Thu, 29 May 2008 13:28:08 -0700

Mark,

What is the shortest ISO 639 code for Mandarin?

Karen

>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Mark Davis
>Sent: Thursday, May 29, 2008 11:52 AM
>To: Broome, Karen
>Cc: [email-masked]
>Subject: Re: [Ltru] Consensus call: extlang
>
>*      Map deprecated codes to the canonical codes*. Thus "zh-yue"
>maps to "yue", and identifies Cantonese, "zh-hakka" maps to "hak",
>and so on.
>
>       *       * There are a few exceptions to this where we use the
>deprecated form as the canonical form, for backwards compatibility,
>eg "iw" for "he".
>
>
>       *       We have yet to decide what to do with codes that are
>illegal in 4646, but where the intent is clear, like "zh-yue-Hant-
>HK"; I suspect that we'll also remap those also, eg "zh-yue-Hant-
>HK".
>
>
>*      We don't want to deal with irregular codes, so any that can't
>be resolved by this mapping are disallowed (there is a separate
>thread on that). Luckily in draft 14 there are only a small handful
>of those.
>*      For lookup, use the kind of fallback that Addison outlined,
>taking into account backward compatibility considerations like the
>fact that "zh-TW" was used to represent "zh-Hant".
>
>
>       *       cmn-Hant-TW
>       *       zh-Hant-TW
>       *       cmn-Hant
>       *       zh-Hant
>       *       cmn-TW
>       *       zh-TW
>       *       cmn
>       *       zh
>
>*      We have fallbacks that are unrelated to macro/micro, like
>Romanian-Moldavian, Filipino-Tagalog, and I'd expect to add to that
>list over time as we support additional languages. Mandarin might be
>a good fallback for, say, Gan; but Spanish might be a better
>fallback for various Quechua encompassed languages. Each case has to
>be decided on its own merits as it comes up: we've found that
>macrolanguage is not very useful for the goal to "give the user what
>s/he wants/needs".
>*      Because extlang brings no benefit and only complications, if
>BCP 47 were to adopt it, I suspect we would cease trying to be
>conformant to BCP 47 internally.
>
>Mark
>
>On Thu, May 29, 2008 at 9:42 AM, Broome, Karen
><[email-masked]> wrote:
>
>
>       Mark writes:
>
>       The fallback is *NOT*, I repeat *NOT*, part of the semantic of
>that tag. ISO defines the semantics of the tags and fallback has
>nothing to do with identifying languages.
>
>       My issue is this: If I look at my real-world language list and
>the codes I've assigned, I think everyone on this list would agree
>that the codes I've chosen based on the IANA registry and RFC 4646
>are the best tags for that content. I have codes for everything I
>need today, thanks to the patient guidance of everyone on this list.
>
>       However, when RFC 4646bis is released, it seems like I will be
>using different tags than everyone else on this list and we will no
>longer agree on what the best tag is. I fear the subtleties in the
>rules may prove tougher to explain than today's rules which already
>cause some eyerolling. Considering this, I start to wonder if the
>release of RFC 4646bis is a step backward or forward. While I'm
>happy there's a tag for Broome Pearling Lugger Pidgin in ISO 639-3,
>I don't have any personal need for it.
>
>       Regards,
>
>       Karen Broome
>
>
>
>
>
>--
>Mark

---

From: Peter Constable <[email-masked]>
Date: Thu, 29 May 2008 23:36:07 -0700

> Broome, Karen

> But is "cmn" the tag you will use, Mark?

I think it must be recognized that, even if Mark says, "Yes, I will use cmn," there will inevitably someone else (and lots of existing process implementations and content) that do not. I think there's general willingness to say that one should use cmn for Mandarin, but also a necessary recognition that we can't avoid saying that some may use zh for Mandarin content.

> different tags than everyone else on this list and we will no longer
> agree on what the best tag is.

I don't see that that needs to be the case.

> I fear the subtleties in the rules may
> prove tougher to explain than today's rules which already cause some
> eyerolling.

I don't see that they're necessarily tougher -- at least not for Chinese since we already have tags for the encompassed languages. The existing RFC didn't say anything about use of zh versus registered tags in part, I think, because the latter were not directly sanctioned by the RFC, and because the issues that arise from availability of subtags for both macrolanguages and for their encompassed languages don't exist inherently in RFC 4646 whereas they do in 4646bis. Even so, there are options for Chinese today, and there's as much need for guidance wrt Chinese today under 4646 as there would be tomorrow under 4646bis.

> Considering this, I start to wonder if the release of RFC
> 4646bis is a step backward or forward. While I'm happy there's a tag
> for Broome Pearling Lugger Pidgin in ISO 639-3, I don't have any
> personal need for it.

The problem cat of Chinese is already out of the bag, and there are people that need support for many of the items coded in 639-3 but not in 639-2.

Peter

---

From: Martin Duerst <[email-masked]>
Date: Fri, 30 May 2008 16:46:19 +0900

At 13:14 08/05/29, Mark Davis wrote:
>If identification is what you want, then "cmn" IS unambigously Mandarin (indeterminate script); "yue" is unambiguously Cantonese (indeterminate script); you certainly don't need extlang complicating matters.
>
>The string "zh-yue" is really a different semantic; it is not just Cantonese, it is "Cantonese-but-fall-back-to-ambiguously-Chinese-of-indeterminate-script" in lookup (but not some other operations like RFC 4646 filtering).
>
>And "zh-yue-Hant-MO" is "Cantonese-in-Simplified-Han-script-and-as-used-in-Macao-but-fall-back-to-ambiguously-Chinese-of-indeterminent-script", again, in lookup.

Strictly speaking, wouldn't that be "Cantonese-in-Simplified-Han-script-and-as-used-in-Macao-but-then-fall-back-to-Cantonese-in-Simplified-Han-script-and then fall-back-to-Cantonese-in-Simplified-Han-script-and-then-fall-back-to-ambiguously-Chinese-of-indeterminent-script", in lookup?

Regards,   Martin.

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

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 30 May 2008 09:19:24 -0700

You're right, that's the more complete description.
"zh-yue-Hans-MO"
=>
"yue-Hans-MO, yue-Hans, yue, zh"
=
"Cantonese-in-Simplified-Han-script-and-as-used-in-Macao
-but-then-fall-back-to-Cantonese-in-Simplified-Han-script-and then
fall-back-to-Cantonese-in-Simplified-Han-script-and
-then-fall-back-to-ambiguously-Chinese-of-indeterminent-script"

Mark

On Fri, May 30, 2008 at 12:46 AM, Martin Duerst <[email-masked]>
wrote:

> Cantonese, it is "Cantonese-but-fall-back-to-ambiguously-Chinese-of-indeterminate-script"
> in lookup (but not some other operations like RFC 4646 filtering).
> >
> >And "zh-yue-Hant-MO" is "Cantonese-in-Simplified-Han
> -script-and-as-used-in-Macao-but-fall-back-to-ambiguously
> -Chinese-of-indeterminent-script", again, in lookup.
>
>
> Strictly speaking, wouldn't that be "Cantonese-in-Simplified-Han
> -script-and-as-used-in-Macao-but-then-fall-back-to-Cantone
> se-in-Simplified-Han-script-and then fall-back-to-Cantonese-in
> -Simplified-Han-script-and-then-fall-back-to-ambiguously
> -Chinese-of-indeterminent-script", in lookup?
>
> Regards,   Martin.
>
>
>
>
>