Actually, logically perhaps it should read: Subtag: zh Type: Macrolanguage and... Subtag: cmn Type: extlang Macrolanguage: zh;1 Subtag: yue Type: extlang Macrolanguage: zh You can easily programme into implementations the scenarios for when a user has used an extlang as a primary language subtag and you don't need a type 2 on the macrolanguage to say that it can be used as a standalone primary language subtag - that's covered by the text. Debbie > -----Original Message----- > From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On > Behalf Of Phillips, Addison > Sent: 10 May 2008 20:02 > To: Doug Ewell; LTRU Working Group > Subject: Re: [Ltru] I'm really confused by chinese in 3066bis > > If we need to indicate that a language is a macrolanguage in > the registry, we should use a separate field. Presumably it > would be something like: > > Subtag: zh > Type: language > Encompasses: cmn, yue, wuu, ... etc. > > Or perhaps: > > Subtag: zh > Type: language > Encompasses: cmn > Encompasses: yue > Encompasses: wuu > ... etc ... > > And the encompasses languages would look like: > > Subtag: cmn > Type: language // or extlang > Macrolanguage: zh > > If we were to restore the use of 'extlang', perhaps the above > wouldn't be necessary, since enclosed languages would not be > of the same type and the 'cmn' record would look more like: > > Subtag: cmn > Type: extlang > Macrolanguage: zh > Prefix: zh > > ... but we would have some enclosed languages grandfathered > into the language slot: > > Subtag: nn > Type: language > Macrolanguage: no > > 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 Doug Ewell > > Sent: Saturday, May 10, 2008 11:48 AM > > To: LTRU Working Group > > Subject: Re: [Ltru] I'm really confused by chinese in 3066bis > > > > Debbie Garside <debbie at ictmarketing dot co dot uk> wrote: > > > > > Yes, I could see that you could get a reverse match from the > > languages > > > containing the Macrolanguage field but I still feel that > the actual > > > macrolanguage should be labelled. If only to stop people from > > > assuming that they should tag all Arabic as 'ar'. If I > was tagging > > > a document and looking for the right code I might well do > a search > > > for "Arabic" or "Chinese". The result would not identify > the subtag > > > as a Macrolanguages and thus I may not look any further. > > > > > > For the sake of 50 or so fields, I think it is worth putting a > > > Macrolangauge field in the Registry - for humans to use :-) > > > > I see three particular problems with using the > Macrolanguage field to > > mean two opposite concepts, "this language HAS a macrolanguage" and > > "this language IS a macrolanguage": > > > > 1. The software problem. In beginning programming you > learn to use > > values like -1 to mean "not a valid value" or "end of list" > or similar. > > This works OK when the real values are non-negative, such as the > > population of a town, but not so well when the values could be > > negative, such as its elevation. Also, other parts of the software > > have to know to treat -1 as a special case, not like an ordinary > > value. Sometimes this gets confusing and you see -1 pop up > in places > > it shouldn't. In intermediate programming you learn to stop doing > > this, and represent special situations in other ways > > > > Similarly, it is possible to imagine software looking > fruitlessly for > > a language subtag 'True' that is the macrolanguage of 'ar' > instead of > > remembering that 'True' is a special case. Remember that 4-letter > > language subtags, though "reserved for future use" (for > some standard, > > I forget which ;-), are valid in the ABNF, and that the casing of > > subtags doesn't matter, though we're supposed to get it > right in the > > Registry. > > > > 2. The human problem. I can easily imagine readers of the > Registry > > becoming confused over this dual usage of a single field. > They might > > wonder why other subtags don't have "Macrolanguage: False", > or why 'ar' > > is considered the opposite of 'True'. They might also experience > > confusion similar to problem 1, as 'tru' is a valid RFC 4646bis > > language subtag for Turoyo. (At least the proposal wasn't to use > > "Macrolanguage: > > yes", thus causing instant confusion with Yeskwa.) > > > > 3. The maintenance problem. Technically the 'True' value is > > redundant information; it can be derived from the records for the > > encompassed languages. Any time you have to maintain redundant > > information, especially in a different place, there is a > much greater > > chance of making a human mistake. > > > > Suppose your friendly team of Designated Experts, presented > with a new > > batch of several dozen ISO 639-3 changes including a new > > classification of macrolanguage 'qma' with encompassed > languages 'qea' > > and 'qeb', remembers to put "Macrolanguage: qma" on the records for > > 'qea' and 'qeb' > > but forgets to put "Macrolanguage: True" on the record for 'qma'. > > Suppose further that the ietf-languages list didn't catch > this during > > the 1-week review. We would end up with an internal inconsistency > > within the Registry. Gosh, your friendly Experts would hate that. > > They > > would also hate the inevitable e-mail flames about "process failure" > > and > > the possibility of removal or replacement at the IESG's discretion. > > > > If it is really felt necessary to indicate that 'ar' is a > > macrolanguage in both ways, with a special value on the > macrolanguage > > record as well as the encompassed languages (ignoring > problem 3), then > > we should have two fields, something like > Is-A-Macrolanguage and My-Macrolanguage-Is. > > (Suggestions for better names are solicited.) As with the Comments > > field, I don't support overloading a single field for fundamentally > > different purposes. > > > > -- > > Doug Ewell * Arvada, Colorado, USA * RFC 4645 * UTN #14 > > http://www.ewellic.org > > http://www1.ietf.org/html.charters/ltru-charter.html > > http://www.alvestrand.no/mailman/listinfo/ietf-languages ^ > > > > _______________________________________________ > > 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 > _______________________________________________ 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.