LANGUAGE SUBTAG REGISTRATION FORM: pinyin

[Mark Davis]

Mandarin text has been validly tagged as 'zh', and will continue to be
validly tagged as 'zh'. So what Addision is saying is that it would be
absurd not to permit zh with the variant subtag, especially as it is the
only currently possible construction. In the future, hopefully by the end of
this year (or at least the next -- I've been wrong about predicting schedule
before!), it will also be possible to use the narrower subtag sequences cmn
or zh-cmn, which many people will prefer. And at that point we'll add them
as prefixes.

However, that doesn't change the fact that zh-Latn-pinyin (or
zh-Latn-hpinyin or zh-Latn-hanyu, however we end up with a name) is a
perfectly reasonable, unproblematic variant subtag that meets a current
requirement.

Mark


On Mon, Aug 4, 2008 at 10:33 AM, Tracey, Niall <niall.tracey at logica.com>wrote:

> From: Phillips, Addison
>
> > It would be absurd not to permit the use of the 'zh' subtag with
> > the subtag for the Romanization scheme, IMO. Yes, 'cmn' is more
> > accurate. But we allow all sorts of inaccurate tagging.
>
> Absurd? How so?
>
> "zh" on its own is logically no different from "zh_cmn", I'll grant you
> that. I'll also grant you that it leads to the majority of technical staff
> to make the mistake that they are logically identical.
>
> It would be certainly a logical choice for systems designers to interpret
> the logically incomplete tag zh_Latn_hanyu to mean zh_cmn_Latn_hanyu.
>
> However, while it would be nice if the specification itself could encode
> the handling of erroneous cases, as far as I can see it is not designed that
> way -- if you put something in the registry, it is considered correct.
>
> So I feel it's best not to compromise at the spec level, and leave
> error-handling to the systems level.
>
> Níall.
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20080804/733af016/attachment.htm