Phillips, Addison 2008-05-30 02.18: > It means: it is not linked to "macrolanguage", a feature of ISO > 639-3. It is strictly recognition that past tagging practice > has used "zh-*" and "sgn-*". It has nothing to do with anything > else. So the currently grandfathered "zh-cmn" etc will remain grandfatherd. The tagger will find "zh" and "cmn" separately, in order to construct "zh-cmn". But when something has been tagged "zh-cmn", then it may be treated either as 'zh' with an extlang, or as an atomic tag. When treated as atomic, it is in reality treated as one of the grandfathered tags -- as long as it is a grandfathered tag. > You are proposing having TWO methods tagging the same language > variety, an idea that is antithetical to language tagging and > which presents more problems than it solves I meant that zh-* should be allowed not for strict compatibility reasons, as you said, but in order to tag macrolanguage relationship. Still one method, though. Of course, this means that sgn-* would have to be allowed for another reason -- for the compatibility reason. The text below serves as background for the following question: Is your proposal, that the language production might be read as atomic, only relevant for the Chinese tags? Or did you also have 'ar-*' and 'sgn-*' in mind? Background: The macrolangauge field came up, as I understood it, because there were no extlang. In Doug's draft, all encompassed language subtags have that field. Except the grandfathered tags "zh-cmn" etc. But my question is: What macrolanguge information comes with 'zh-cmn' when it is read as an atomic? The answer should be, that when read as an atomic --- grandfathered zh-cmn -- the registry says that it is a synonym of 'cmn'. The 'cmn' then has a Macrolanguaga field which might be used by the application in order to find 'zh' etc. However, if you read 'ar-*' or 'sgn-*' as an atomic, then there is no grandfathered tags that they match. And thus no place to find the macrolanguage information (for 'ar-*' -- unrelevant to 'sgn-*'). -- leif halvard silli _______________________________________________ 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.