I generally agree with the idea that having some of this ancillary information in the registry would be useful. However, the 'Type' field isn't the way to do this. The 'Type' field indicates what kind of subtag it is. Instead, I would suggest that we include some more meta-information in specific fields in the registry. For example, we could have a 'Source' field to indicate where a record came from and an Attribute field for derived attributes. Here's what our record collection might contain: Type: language | extlang | script | region | variant | grandfathered | redundant Subtag | Tag: <value> Added: <date> Deprecated: <date> Prefix: <value> Suppress-Script: <value> Description: <text> Source: ISO639-1 | ISO639-2 | ISO639-3 | ISO639-5 | ISO3166-1 | ISO15924 | registration Attribute: macrolanguage | collection | ... Comments: <text> Thoughts? Addison Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On > Behalf Of Kent Karlsson > Sent: Sunday, June 01, 2008 4:43 AM > To: 'LTRU Working Group' > Subject: [Ltru] 639-5 (was RE: ISO 639 language code addition > rules...) > > 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 _______________________________________________ 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.