Re: [Ltru] Macrolanguage usage

> From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of
> Leif Halvard Silli

> As I see it, extlang is supposed to handle the issues dealing with
> negotiation between encompassed languages.

The reasons extlang was originally proposed were:

- it would allow a set of already-registered tags such as zh-yue to change from being grandfathered to being redundant (they would fall out generatively)

- it would all truncate-from-right fallback to provide a match in cases in which the macrolanguage ID was already in widespread use

The former was relevant only to Chinese.

The latter makes sense only if it can be assumed that content tagged aa-bbb would be a reasonable match for requests for aa. That may be valid in cases such as content in zh-cmn or ar-arb (i.e. a predominant language) or in cases in which the encompassed languages really are mutually intelligible (sh-??? would be fitting examples except that sh is among cases in which extlang would not have been used). It is probably not valid, however, in all the other cases, e.g. when the content is zh-yue or ar-auz. Thus, I think it may be fair to say that when extlang was first proposed the putative benefits wrt right-truncation fallback had not been thought through carefully.

> > Even so, and even though 'no' ('nor') is a macrolanguage code for
> nn/nb
> > (or nno/nob), extlang does not apply to nn/nb for backwards
> compatibility
> > reasons.
>
> The Norwegian case is still valid as an example of what extlang
> can/cannot do for a Macrolanguage situation.

Yet, indeed, Norwegian is one case for which it had been assumed extlang would *not* be used.

Peter
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru