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
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
> -----Original Message-----
> From: Shawn Steele [mailto:Shawn.Steele at microsoft.com]
> Sent: Monday, May 12, 2008 9:40 PM
> To: Karen_Broome at spe.sony.com; 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:
> - 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: ltru-bounces at ietf.org [ltru-bounces at ietf.org] On Behalf Of
> Karen_Broome at spe.sony.com [Karen_Broome at spe.sony.com]
> 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.
>
> 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" <addison at amazon.com>
> Sent by: ltru-bounces at ietf.org
> 05/12/2008 04:11 PM
>
> To
> "Karen_Broome at spe.sony.com" <Karen_Broome at spe.sony.com>, Doug Ewell
> <doug at ewellic.org>
> cc
> LTRU Working Group <ltru at ietf.org>
> Subject
> Re: [Ltru] extlang or not extlang
>
>
>
>
>
>
> > 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-----
> > From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf
> Of
> > Karen_Broome at spe.sony.com
> > Sent: Monday, May 12, 2008 2:58 PM
> > To: Doug Ewell
> > Cc: LTRU Working Group
> > Subject: Re: [Ltru] extlang or not extlang
> >
> > Doug wrote:
> >
> > > 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.
> >
> > (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.
> >
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > Ltru at ietf.org
> > https://www.ietf.org/mailman/listinfo/ltru
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>
>
>
>
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.