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

Re: [Ltru] Re: Description on tags, not just subtags?



In http://www.alvestrand.no/pipermail/ietf-languages/2008-January/007279.html I proposed using the Comments field for this purpose, to avoid introducing a new mechanism that would probably be used by only a handful of (cherry-picked) variations:

Type: language
Subtag: gsw
Description: Swiss German
Description: Alemannic
Added: 2006-03-08
Suppress-Script: Latn
Comment: gsw-FR represents the Alsatian dialect


I dislike this idea. We already have experience with it and its "unintended consequences". See: sign language tags.

For that matter, we have ample experience with region subtags being imbued with artificial meaning. For a long time, "zh-TW" 'meant' Traditional Chinese, for example. Part of the reason behind this whole effort is to reduce the need to attach artificial meaning to subtags.

This isn't to say that the tag "gsw-FR" doesn't encompass or "mean" the Alsatian dialect of Alemannic. It certainly encompasses Alsatian. But to start packing the registry with these sorts of comments (and the registration process with requests for same) strikes me as counter-productive to the point that I'd almost favor adding a MUST NOT to draft-4646bis.

Guidance on tag formation should, incidentally and in my opinion, be in the form of external documentation (such as on Langtag.net, in CLDR, or via the W3C articles on same, just to name a few) or in an additional informational documents (possibly an Informational RFC). Burying tag choice information like this in the registry seems complicated and haphazard.

Addison

--
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.


_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www1.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.