Macrolanguages (was: Re: BCP 47)

Mark Davis ☕ mark at
Sat Mar 9 11:18:06 CET 2013

The advantage of BCP47 is that it allows 2 models:

1. Bibliographic: when I ask for 'zh', I'm happy with anything that has
been called Chinese, including Mandarin, Cantonese, Gan, etc.

2. Everything else*: when I ask for 'zh' I expected to get Mandarin, and
perplexed if I got Cantonese instead. Just as if I asked for 'de' and got

* = essentially all consumer and business interactions with computers:
internationalization libraries, OS's, browsers, servers, etc.

You are right that #2 is not really overriding the RA's decision to call a
language a macrolanguage (and thereby define it very broadly); for all
practical purposes, however, #2 is ignoring that call, and always
interpreting it as the standard form of that language. And if the RA
decided to make 'de' a macrolanguage (which would not be inconsistent with
other calls), it simply wouldn't matter for #2.

Mark <>
*— Il meglio è l’inimico del bene —*

On Fri, Mar 8, 2013 at 7:10 PM, Doug Ewell <doug at> wrote:

> Re: Macrolanguages (was: Re: BCP 47)
> Mark Davis ☕ <mark at macchiato dot com> wrote:
> >> implies that we can somehow override the RA's decision.
> >
> > Well, some implementations (I suspect all significant ones) *need* to
> > override the RA's decision. For example, CLDR and people that use it
> > normalize the predominant encompassed form to the macrolanguage, for
> > compatibility. Implementations are just not going to change from using
> > 'zh' or 'ar' to mean the predominant form.
> That's not overriding the RA's decision to assign a macrolanguage.
> That's just a matter of subtag choice. It's entirely consistent with the
> RA's concept of macrolanguages, that in some cases it's appropriate to
> think of one language, and in other cases it's appropriate to think of
> multiple languages. The CLDR approach simply predetermines which of the
> two roads to take.
> Overriding the RA's decision would be saying, well, we think Swabian
> should be encompassed by German even though the RA doesn't agree, so
> we're going to go ahead and put it in the Registry anyway. Or, the RA
> adds a new language code element or reclassifies an existing one as
> encompassed by Arabic, but we don't agree, so we just won't add the
> relationship or the extlang to the Registry. That's what we can't do,
> and what some people (not necessarily Benson) seem to believe we can do.
> --
> Doug Ewell | Thornton, CO, USA
> | @DougEwell ­
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ietf-languages mailing list