Re: language variant subtag "pinyin" modification request

Nice discussion, Doug.

I'd add that very few systems support variants, especially for language
matching. So one would expect currently a request for "zh-pinyin" to return
the same as "zh".  With "zh-Latn-pinyin", on the other hand, is likely to
return the same as "zh-Latn" if available, namely pinyin content.

So in practice,  "zh-pinyin" is really best avoided until there is good
support for variants.

Mark


On Tue, Nov 20, 2018 at 10:07 PM Doug Ewell <[email protected]> wrote:

> Phake Nick wrote:
>
> > Type: variant
> > Subtag: pinyin
> > Description: Pinyin romanization
> > Prefix: zh-Latn
> > Prefix: zh
> > Prefix: bo-Latn
>
> I'm not entirely sure of the benefits of having both "zh" and "zh-Latn"
> as Prefix fields for the same variant, since the more general Prefix
> generally encompasses the more specific. But since it's an example in
> Section 2.2.5, and we have some cases of this in the Registry ('1994',
> 'ekavsk', 'ijekavsk'), I won't argue, except perhaps to wonder why this
> request isn't made for ''bo' as well.
>
> > Suppress-Script:
> > Macrolanguage:
> > Comments:
>
> As an administrative note, it's not necessary to include these blank
> fields in a proposal. The form in Section 3.5 merely shows all the
> fields that /could/ be included if necessary. I realize the document
> doesn't make this very clear.
>
> > The request is a request to modify an existing entry, with the aim of
> > adding an additional prefix for the variant subtag "pinyin". The
> > proposed "zh-pinyin" tag would have same effect as "zh-Latn-pinyin"
> > but it is shorter and is currently in use in multiple places to
> > reflect Chinese content being written in Pinyin romanization,
>
> There are pros and cons to this. Suggesting "zh-pinyin" instead of, or
> in addition to, "zh-Latn-pinyin" does make the tag shorter (remember
> that Prefix is only a suggestion, not a matter of "permit" vs.
> "prohibit," although not everyone understands this). Since Pinyin is a
> romanization scheme, it may seem a bit redundant to suggest 'Latn' as
> well. Many tags do assume a certain amount of knowledge on the user's
> part (e.g. what exactly distinguishes "en-GB" from en-US"?); assuming
> the user knows that Pinyin is Latin script doesn't seem far-fetched.
>
> On the other hand, "zh-Latn-pinyin" would correctly match a request for
> "zh-Latn" using the truncate-from-right approach, while "zh-pinyin"
> would not. It would be identifiable to any human reader as "Chinese in
> Latin script," which is what it is. (Question: why is this request not
> also being made for 'wadegile' and 'hepburn' and 'jyutping'?) And Prefix
> is only a suggestion, so it isn't really necessary. Plus, there is a
> school of thought on this list that redundancy of the type exemplified
> by "zh-Latn-pinyin" is desirable.
>
> I will defer to other as to the merits of this request.
>
> > including OpenStreetMap. See
> > https://wiki.openstreetmap.org/wiki/Multilingual_names#China
>
> That page makes several false or questionable statements about BCP 47
> language tagging, and I might not want to present it as representative
> of the users who would benefit from your request. Among other things,
> the page states under "Issues" that only valid BCP 47 tags can be used
> in OSM, but under "China" it recommends using the invalid "zh_pinyin"
> (with underscore) instead of a valid tag, even the currently
> non-suggested but valid "zh-pinyin". It also suggests using invalid tags
> in the Japan section, where it makes the bizarre statement that "BCP 47
> makes no difference between '-' and '_'". Be careful when citing this
> project.
>
> --
> Doug Ewell | Thornton, CO, US | ewellic.org
>
>
> _______________________________________________
> Ietf-languages mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-languages
>

_______________________________________________
Ietf-languages mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-languages