> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of > 'Stephane Bortzmeyer' > > I missed the whole extlang debate so I don't really know all the > > reasons why it was dismissed. > > [My personal summary] > > * stability issues (what if a "standalone" language becomes > encompassed or the opposite?). Wasn't an issue if we used extlang only for pre-existing cases, not new cases. > * "dummy" right truncation, as allowed by extlangs, is not a good idea > for macrolanguages, anyway (two encompassed languages of the same > macrolanguage may not be mutually intelligible). An issue only for the cases in which the macro-language ID has been used for some dominant, encompassed language: content would be tagged with (and hence matchable against) the macro-language ID only if there were some conventional form of linguistic expression it was associated with. That would happen only if it were associated with a dominant encompassed language, or if there were some variety of common communication (à la Chinese or African cases Don has alluded to). But in both those scenarios, the fallback probably *would* provide intelligible results for both. > * politically, it may send the message that the encompassed language > is inferior in some way. It seems to me that would only arise if the macro-language ID is particularly associated with one dominant variety -- and that's true whether extlang is used or not. Thus, if we ended up using zh for Mandarin and either yue or zh-yue for Cantonese, that attitude might be conveyed. I think there were a few other reasons cited: * matching processes need to be made more complex / right-truncation doesn't work as expected in some scenarios -- an issue for tags with extlang and script or region subtags The counter-argument made was that matching processes need to be made more complex without extlang in order to capture useful fallback associations between encompassed and macro-language IDs. The rebuttal to that was that the whole point of extlang was to facilitate right-truncation matching involving existing usage of macro-language IDs, yet extlang breaks some desired right-truncation behaviours. I'd note that limiting extlang to certain, pre-existing cases such as zh would cover the bulk of cases of concern, though as we know zh is a case for which script or region subtags may have particular significance. * Not all macro-languages in ISO 639-3 are useful for matching and fallback. Not an issue if not all macro-language IDs are used with extlangs. * Fallback requirements are more involved than what extlang can support. True; but extlang wasn't proposed as a general fallback solution, and the issues exist with or without extlang. > As Randy said here, you can also make a similar list of the good > reasons to keep extlangs. The case is really a 50-50 but we have to > decide on one solution. That's mostly what it amounted to: a compelling case couldn't be made either way, and those arguing for extlang gave up sooner than those arguing against extlang. Peter _______________________________________________ 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.