Mark Davis scripsit: > I disagree. The base information of whether an instance of written language > is in a given script is pretty clear, and the number of scripts are quite > bounded. While it may take some effort to determine whether a script is in > overwhelming usage for a language, it is a relatively straightforward task. c If it's so straightforward, why has nobody done it? We have some Suppress-Script entries for 639-2 languages, but by no means all, and the 639-3-only set is going to make the job ten times bigger. > On the other hand, the boundaries between languages (languages vs dialects > and so on) are always the subject of dispute. According to a conversation > with Ken Whistler, there is a considerable controversy among the linguistics > community over the language model used in SIL which then went into 639-3. It doesn't matter to us, the IETF; we are committed to doing whatever 639 does. > Now, this is not at all to say that they did a bad job -- they did a great > job, especially with the huge number of languages that they had to deal with > -- however, it is inherently a much more difficult task. And the whole > notion of macrolanguage is not something that exists "in the wild"; it is a > construct designed to enable certain usage patterns -- and it is up to us to > determine whether it fits best in 4646bis as the Macrolanguage: field or > hard-wired into extlang. That's why I'm proposing making the macrolanguage information fully available in the Macrolanguage: header, as mutable as SIL decides it needs to be, and then using the current state (plus the sign language case) for use in the extlang pattern. We have macrolanguages at all because of the vagaries of 639-2, but 639-2 is our core language set: we can't just deprecate all those languages in favor of obligatorily precise tagging. -- No, John. I want formats that are actually John Cowan useful, rather than over-featured megaliths that http://www.ccil.org/~cowan address all questions by piling on ridiculous cowan at ccil.org internal links in forms which are hideously over-complex. --Simon St. Laurent on xml-dev _______________________________________________ Ltru mailing list Ltru at ietf.org https://www1.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.