Re: [Ltru] Consensus call: extlang

[Peter Constable <[e-mail]>]

> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Broome, Karen


> Before I spend too much time picking apart your lengthy screed
> involving a scenario where the BBC presents its web site in Sudanese
> Creole Arabic with rotating languages code logic for each day of the
> week ... (ahem) ... here's my real-world Chinese language list:
>
> Chinese (Variant Unknown)
> Chinese (Cantonese, Spoken)
> Chinese (Cantonese, Written)
> Chinese (Mandarin, Spoken)
> Chinese (Mandarin, Spoken Taiwanese)
> Chinese (Mandarin, Simplified)
> Chinese (Mandarin, Traditional)
> Chinese (Taiwanese, Spoken)
> Chinese (Taiwanese, Written)


> 1             2          3         4
> zh            zh         zh        zh
> zh-yue        yue        yue       yue
> zh-yue        yue        yue       yue
> zh-cmn        cmn        zh        cmn
> zh-cmn-TW     cmn-TW     zh-TW     cmn-TW
> zh-cmn-Hans   cmn-Hans   zh-Hans   zh-Hans
> zh-cmn-Hant   cmn-Hant   zh-Hant   zh-Hant
> zh-min-nan    nan        nan       nan
> zh-min-nan    nan        nan       nan


> Comments:
>
> * Option #1 is unambiguous and shows that there is a relationship
> between these languages.

The only difference with #2 is that the relationship is not reflected directly in the tags.

Since you mention having the relationship shown, I gather you think there's a benefit, but you don't explain what that benefit is.


> It also preserves the legacy "zh" tag so
> developers that aren't hip to later versions of BCP 47 or 639-3 will
> have some idea what these tags mean.

I'm not sure how significant a benefit that is. The developers may encounter many subtags that they're not familiar with, and they'll need to do some learning to make sense of them. And if feedback we got the first time we tried a last call for 3066bis were to be believed (before this WG was formed), there are developers out there who will be confused by any new patterns for forming tags. I agree that the presence of "zh" will give them a hint, but I expect in any of these situations people that need to will find out what these things they don't recognize are.


> The tags are maybe longer than
> they need to be, but if I need a fixed-length tag, I can wait for 639-6.

The length is not a problem, nor is the variation in length a problem.

I've got some people in my company expressing concern over people (meaning people in my company, not users) being confused by the fact that some languages will be represented as "aa", others "aaa", and (worst of all) still others "aa-bbb" or "aaa-bbb". While I expect people in a technology company who need to work directly with these things ought to be able to learn about and understand extlangs, I think if any of these things we've been talking about is likely to be a source of confusion, it's probably this (extlang). I'm still not sure that's a serious concern, but my point is that I think something like unfamiliarity with "cmn" is less of a concern.


> The languages may not be mutually intelligible in some contexts, but
> they are related.

English and Frisian are related. French and Spanish are related. Vietnamese and Khmer are related. I'm not sure how those facts are especially significant for tagging.



> * Option #2 is unambiguous, but Microsoft, Google, and Amazon won't be
> using the same tags for Chinese that I do. Even if I don't follow their
> lead, others likely will. This worries me.

The potential for different parties to use different tags exists in any of the schemes you list.

While we may not always use the same tags that you do, it isn't necessarily the case that we would never use the same tags that you do. I can't speak for other vendors, but I wouldn't at all rule out MS using the same tags you use in scenarios where your content needs to be supported.


> Also, the rules for #2 must
> include fuzzy guidelines such as, "use the 'zh' tag except when you
> think it's a bad idea" and "use the shortest tag except when you don't
> want to."

That's the same for #1, though.


> This presents complications in trying to explain some sort of
> consistent method to the LTRU madness to others. Given this, I start to
> wish ISO 639-6 a safe and speedy passage.

Have you at all considered what complications there would be in going to that? If all you're thinking about is "identification" (how to declare an identity), then I can imaging you might not have. Being on the side of thinking about how to consume tags and do something with them, I don't see that as a rosy and simple alternative.


> * Option #3 is what I believe you might suggest, but for me, that's the
> worst list of all. There are five ambiguous "zh" categories on that
> list. It follows the "always use the shortest tag" rule and respects
> history, but it's useless to me from an identification perspective.

I won't argue against your concerns here: they are valid. You do need to acknowledge, though, that all of the tags you find problematic in this case (zh, zh-TW, zh-Han?) would all be valid in *any* case, no matter what we decide, and these *will* be encountered.


> * Option #4 has three ambiguous tags and means I have to explain to
> people who aren't in this industry about why I use different tags for
> the same language. This strategy is less ambiguous that #3, but I'm not
> sure I can explain it to other content creators for the same reasons as
> #2 and presents the spoken/written complication others may not want. In
> the long run, this seems messy and unclear enough that it will result
> in bad tagging.

Again, with or without extlang, some kind of guidance needs to be given, and some reasonable means must be available for those who must somehow support legacy processes and data.


> * Options #2,3,4: In general, it worries me that RFC 4646bis offers so
> many "preferred" options for the same thing. I really can't see how
> this simplifies things for anyone.

There is no avoiding certain options for Chinese, whether with or without extlang, whether with RFC 4646bis or some entirely new scheme based on ISO 639-6 or whatever (since IETF language tags as we know them aren't about to disappear).



Peter
_______________________________________________
Ltru mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ltru