It *almost* sounds reasonable to me. Some comments follow. Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of Mark Davis Sent: Wednesday, July 02, 2008 8:31 AM To: Doug Ewell Cc: LTRU Working Group Subject: Re: [Ltru] A radical proposal (was: Re: extlang & deprecation) It sounds reasonable to me. Mark On Tue, Jul 1, 2008 at 10:34 PM, Doug Ewell <doug at ewellic.org> wrote: What about this: (Warning: some of these suggestions are radical, but meant to reach a workable accord) 1. Provide an explicit definition for the word "deprecated" in BCP 47, something on the order of "There is another tag or subtag that means the same as this one, but is preferred, and validating processors will translate this subtag into the preferred equivalent. But nobody will beat you up or make you register with the police if you use the non-preferred one instead." Make sure other text in the draft does not contradict this. <AP> -1 I don’t think we need to define ‘deprecated’, the current thread notwithstanding (more below). </AP> 2. Define all of the Y forms (e.g. "cmn") in the Registry as Type: extlang, none as Type: language. Bear with me here. <AP> This introduces the problem of defining rules for when an ISO 639 code is registered as type extlang and when as type language. I think it would be better if the proposal were that all language subtags have type 'language'. Those with a prefix field MAY be used as "extended language subtags" with their prefix. The (future) decision to include a prefix would rest with ietf-languages. </AP> 3. Change the prose (and ABNF if necessary) to specify that an "extlang" can be used either alone, as "cmn" (Y), or together with its Prefix, as "zh-cmn" (X-Y). In other words, an "extlang" is a special type of "language" that has an optional Prefix. Specify that the Y form is "preferred" and the X-Y form is "deprecated," using the clearly specified, watered-down definition of "deprecated" from item 1. <AP> The ABNF would be tricky to do. As I say, it would be easier to make everything a language. I think it a mistake to water down "deprecated". The problem we have with deprecation at present is the use of the Preferred-Value field in 'extlang' records requires deprecation. If we don't want to deprecate the extlang form, then we don't deprecate it. The question is whether a tag of form "X-Y" is in its canonical form or not. That is, is "zh-cmn-Hans-CN" canonical? Or is its canonical form "cmn-Hans-CN"? It isn't necessarily true that non-canonical forms are deprecated. For example, the tag "en-b-moo-a-foo" is not in canonical form, but isn't necessarily deprecated.</AP> 4. Apply this logic to all encompassed languages, not just those belonging to a cherry-picked set of macrolanguages plus "sgn". For extra credit, figure out how to make this work with changing ISO 639-3 groupings. <AP> Sure: do as we've suggested and ban all such future registrations. Or we can just set the rules to track ISO 639-3, with the proviso that prefixes may only be added or broadened, never removed. </AP> This would allow both extlangistas and non-extlangistas to tag as needed to achieve the desired matching and fallback behavior, and would solve Addison's concern about being able to normalize without the Registry, since all valid tags of form XX(X)-YYY could be normalized to YYY blindly. <AP> Canonicalization is not the same thing as permission to normalize. Permission to normalize is much weaker. If we say that the 'Y' form is canonical, it will save us having to modify aspects of matching (we may still have to say something about matching). </AP> Part 4 removes arbitrariness, partly to help this document survive IETF LC, but also for its own sake. I am sensitive to Addison's point that we should have as few duplicate tags as possible, but I still feel this is an adequate compromise, in which the extlangistas concede the formal "preferability" of the non-extlangy forms but reserve the right to use the easily normalized, deprecated forms that they prefer without being branded with a scarlet D. <AP> It doesn't remove the arbitrariness. It is just a different set of arbitrariness. Personally, I prefer the smaller set of languages we have now. But we could solve this by only initially registering a few and allowing ietf-languages to register others. Or just register them all. </AP> _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.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.