<div dir="ltr"><div class="gmail_default" style="font-family:'times new roman',serif">The advantage of BCP47 is that it allows 2 models:</div><div class="gmail_default" style="font-family:'times new roman',serif">
<br></div><div class="gmail_default" style="font-family:'times new roman',serif">1. Bibliographic: when I ask for 'zh', I'm happy with anything that has been called Chinese, including Mandarin, Cantonese, Gan, etc.</div>
<div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">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 Schwiitzertütsch.</div>
<div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">* = essentially all consumer and business interactions with computers: internationalization libraries, OS's, browsers, servers, etc.</div>
<div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">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.</div>
</div><div class="gmail_extra"><br clear="all"><div><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><div></div></div>
<div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><br></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">
<a href="https://plus.google.com/114199149796022210033" target="_blank">Mark</a></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><i><br></i></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">
<i>— Il meglio è l’inimico del bene —</i></div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div>
<br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 7:10 PM, Doug Ewell <span dir="ltr"><<a href="mailto:doug@ewellic.org" target="_blank">doug@ewellic.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Re: Macrolanguages (was: Re: BCP 47)<br>
<div class="im"><br>
Mark Davis ☕ <mark at macchiato dot com> wrote:<br>
<br>
>> implies that we can somehow override the RA's decision.<br>
><br>
</div>> Well, some implementations (I suspect all significant ones) *need* to<br>
<div class="im">> override the RA's decision. For example, CLDR and people that use it<br>
> normalize the predominant encompassed form to the macrolanguage, for<br>
> compatibility. Implementations are just not going to change from using<br>
> 'zh' or 'ar' to mean the predominant form.<br>
<br>
</div>That's not overriding the RA's decision to assign a macrolanguage.<br>
That's just a matter of subtag choice. It's entirely consistent with the<br>
RA's concept of macrolanguages, that in some cases it's appropriate to<br>
think of one language, and in other cases it's appropriate to think of<br>
multiple languages. The CLDR approach simply predetermines which of the<br>
two roads to take.<br>
<br>
Overriding the RA's decision would be saying, well, we think Swabian<br>
should be encompassed by German even though the RA doesn't agree, so<br>
we're going to go ahead and put it in the Registry anyway. Or, the RA<br>
adds a new language code element or reclassifies an existing one as<br>
encompassed by Arabic, but we don't agree, so we just won't add the<br>
relationship or the extlang to the Registry. That's what we can't do,<br>
and what some people (not necessarily Benson) seem to believe we can do.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Doug Ewell | Thornton, CO, USA<br>
<a href="http://ewellic.org" target="_blank">http://ewellic.org</a> | @DougEwell ­<br>
<br>
</div></div></blockquote></div><br></div>