pinyin (and wadegile) request has gotten derailed
addison at amazon.com
Sun Sep 14 01:01:26 CEST 2008
> However although I supported and support moving the subtag request
> forward prior to RFC 4646bis for expediency, I'm a bit troubled by
> our officially sanctioning [zh] as denoting specifically Mandarin
> Chinese even if people now use it to mean such--I think this has
The field Prefix and the phrase "officially sanctioning" do not fit with one-another. Prefix shows recommended subtags for use with the given variant. Is there any doubt that 'zh' would be one of these for any subtag meaning some kind of a Pinyin transcription? Other prefixes are possible and even desirable later, but that doesn't change the applicability of 'zh'.
Further, "officially sanctioning" gives too much recognition to the status of Prefix.
> So it's not like Michael Everson just came up with this objection
> now. When RFC 4646bis comes out, we can request the second subtag
> and have a subtag exclusively for Mandarin Chinese. In the
> meantime I think it should be Chinese in general we are using the
> [zh] subtag to mean.
Chinese in general encompasses Mandarin Chinese in specific. In practice, pinyin transcriptions of "Chinese" documents are very likely to be Hanyu Pinyin transcriptions of Mandarin Chinese documents.
If, as you claim, 'pinyin' and 'zh' should both be considered "general purpose", Mark would be entirely correct to tag content "zh-pinyin" or "zh-Latn-pinyin". *He* might choose to interpret that tag to mean "hanyu pinyin transcription of Mandarin", even if the tag means "any pinyin transcription of any Chinese". But I think that forcing such interpretations on him do not serve his quite specific request very well (see below).
> If Mark wants to use [zh-Latn-pinyin] (or whatever) to tag
> primarily Mandarin content that is fine as [zh] is the only subtag
> available, and Mandarin speakers will probably be able to find
> their content?? But we don't have to restrict the subtag [zh] here
> to mean that . . .
I don't think anyone has suggested that.
> Can't the language subtag reviewer suggest a revision? (I'd also
> like to hear from the orginal requester what he thinks of the
> revision too, if it's o.k.?)
Actually, I think the original requester has a greater importance here. The reviewer can only approve or reject requests. If I were to request a subtag 'twain' (to denote the language usage of the author Mark Twain), I would be greatly aggrieved and not very well served if the reviewer instead approved a 'tolkein' subtag or a '1883' subtag (to denote works published in 1883, the year Huck Finn was published).
Other types of requests also fit this pattern. A request to add a Prefix to an existing record, for example, does not open up the other fields in the record. Only the requested addition (and attendant changes) are open to accept/reject decisions. I don't see any other way that Section 3.5 can be interpreted. Edits to a request to make it conformant with BCP 47 rules or to put it into an acceptable state for the reviewer's approval, of course, are permitted via new request submission. But I would tend to think that edits that change the meaning of the request in a way opposed by the requester would, at best, be problematic.
In addition, if we don't give requesters a subtag that fits their requirements (or tell them why it would be inappropriate), the request process will have failed and we'll see a lot of private use nonsense. And appeals.
If the reviewer doesn't want to give Mark a subtag for Hanyu Pinyin at all, that should be explained. I think such a decision would be wrong: it is absurd to think that because there are other pinyin transcriptions Mark doesn't need to tag a specific type of transcription. A case can be made that the subtag should not take the form 'pinyin' or that we should have a 'pinyin' and a 'hanyu' (with prefix 'pinyin'), although really I think that's getting a bit complicated.
In this case, time having expired, I would like to request that the reviewer announce the decision (which may include a two-week extension), as is required. I can't tell if Solomon has cut the baby in half yet ;-).
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
More information about the Ietf-languages