[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] a modest proposal...



It's a proposal that (whether with or without Shawn's variation) might be just the right compromise. (See my comments in another mail I just posted.)

We would still need to have text giving clear guidance on how to tag for Chinese.


Peter

> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of
> Shawn Steele
> Sent: Thursday, May 29, 2008 12:54 PM
> To: Phillips, Addison; LTRU Working Group
> Subject: Re: [Ltru] a modest proposal...
>
> I would either like that, or the same thing, except where cmn and yue
> are allowed as aliases of zh-cmn & zh-yue
>
> - Shawn
>
> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of
> Phillips, Addison
> Sent: Thursday, May 29, 2008 12:38 PM
> To: LTRU Working Group
> Subject: [Ltru] a modest proposal...
>
> Since:
>
> 1. We appear to be stuck.
> 2. We (most of us, anyway) would like to see this work completed.
> 3. We haven't a compelling-enough technical argument that resolves the
> issue.
>
> I would like to submit a "modest proposal" for addressing the impasse:
>
> 1. Restore a *single* extlang to the ABNF.
> 2. Keep the Macrolanguage field in the registry for all encompassed
> languages, which information may be use by implementations however
> makes the most sense.
> 3. Cherry pick *only* the 'zh' (and possibly the 'ar') encompassed
> languages for registration as extlangs. This is done in the name of
> compatibility alone. 4. Permit implementations to treat the 'language'
> production as atomic (that is, the sequence "zh-yue" MAY be treated as
> if it were a single subtag but MAY be treated as separate subtags,
> notably by existing implementations). Note that the 'language'
> production is the one that includes both the primary and extended
> language subtags.
>
> Thoughts?
>
> Addison
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
> _______________________________________________
> 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.