Doug Ewell wrote: > I know some WG members will argue that collection codes are Evil, in > which case I would respond that perhaps we need to think beyond Web > servers and spell-checkers. Our intent is for language tags to be > useful for a wide variety of applications, and as far as I know -- > despite the horror stories -- collection codes haven't caused major > tagging problems since 2001 (publication date of RFC 3066, > which first allowed them). I assume that for -5 there is a rule that the codes are in the same "namespace" as 639-3 codes. In that case, I would not at all mind including the "new" -5 code elements (but I'm a bit hesitant to exclude some of them based on a not-sure-to-be-correct coverage analysis). I also don't mind making collection/family codes inclusive, i.e. exclude the "(other)", as Peter mentioned. But I would like some firmer recording in the LSR of the fact that a code is a collection/family code (rather than relying on "languages" or "(family)" being part of the name, or just referring back to 639-5). Something like "Type: language collection" or similar. Pushing this a bit, macrolanguages should similarly be explicitly recorded as such (rather than just implicitly), by something like "Type: macrolanguage" instead of just "Type: language". I know there is a way of inferring this information, but it is better to be explicit, and not need to infer that information or refer back to the -3 registry. IIUC, this would leave "Type: language" for individual languages only. I'm not suggesting any formal restrictions on the use of language collection/family codes, beyond the informal warning we have already. I'm sure some of the (non-new) collection codes have been used to language tag documents in languages not covered by the LSR yet (but will be, once LTRU II finishes...) with an individual language code. /kent k _______________________________________________ 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.