It is the lack of a uniform policy that bothers me more than the particular case. Anything that is Walliserdeutsch right now would be either tagged "de" (because that was all that was available until gsw was encoded) or "gsw". Let's take precisely your wording and apply it to that case.<br>
<font size="1"><br></font><div style="margin-left: 40px;"><font size="1">If an application requ</font><font size="1">ires standard <b>Swiss German</b> and <b>Walliserdeutsch</b> to be treated as distinct<br>
languages, then clearly it would need to use the new subtag to identify standard<br>Swiss German, since "gsw" would mean "any kind of <b>Swiss German</b>, including <b>Walliserdeutsch</b>". This<br>
is a natural consequence of our "no narrowing" rules - all of the data which is<br>
currently precisely and accurately tagged as <b>Swiss German</b> would remain accurately<br>
tagged, though most would no longer be precisely tagged. (Data for which the<br>
tagger was unable to make a determination whether it was <b>Swiss German</b> or <b>Walliserdeutsch</b><br>
would remain precisely tagged.) The assumption is that it is better to introduce<br>
a (potentially lingering) imprecision in the tagging of legacy data, rather than to<br>
cause any once-accurate tags on legacy data to become incorrect.</font><br></div>
<br>If your reasoning is correct for Latvian, then it is also correct for Swiss German! If it is not correct for Swiss German, then it is not correct for Latvian.<br><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Tue, Dec 1, 2009 at 09:46, Randy Presuhn <span dir="ltr"><<a href="mailto:randy_presuhn@mindspring.com">randy_presuhn@mindspring.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi -<br>
<br>
> From: "John Cowan" <<a href="mailto:cowan@ccil.org">cowan@ccil.org</a>><br>
> To: "Peter Constable" <<a href="mailto:petercon@microsoft.com">petercon@microsoft.com</a>><br>
> Cc: <<a href="mailto:ietf-languages@iana.org">ietf-languages@iana.org</a>>; "Doug Ewell" <<a href="mailto:doug@ewellic.org">doug@ewellic.org</a>><br>
> Sent: Tuesday, December 01, 2009 9:29 AM<br>
<div class="im">> Subject: Re: Criteria for languages?<br>
</div>...<br>
<div class="im"><br>
> Peter Constable scripsit:<br>
><br>
> > If the denotation of "lav" were changed to explicitly exclude Latgalian<br>
> > (which would be necessary if its scope is not set to macrolanguage),<br>
> > then an unknown number of librarians will have broken data. It would<br>
> > be irresponsible of the ISO 639-RA/JAC to do such a thing, IMO.<br>
><br>
> Quite so.<br>
><br>
> In that case, the issue for us is: do we recommend that people continue<br>
> to use "lav" for Latvian proper, or that they adopt the new subtag?<br>
<br>
</div>If an application requires standard Latvian and Latgalian to be treated as distinct<br>
languages, then clearly it would need to use the new subtag to identify standard<br>
Latvian, since "lav" would mean "any kind of Latvian, including Latgalian". This<br>
is a natural consequence of our "no narrowing" rules - all of the data which is<br>
currently precisely and accurately tagged as Latvian would remain accurately<br>
tagged, though most would no longer be precisely tagged. (Data for which the<br>
tagger was unable to make a determination whether it was Latvian or Latgalian<br>
would remain precisely tagged.) The assumption is that it is better to introduce<br>
a (potentially lingering) imprecision in the tagging of legacy data, rather than to<br>
cause any once-accurate tags on legacy data to become incorrect.<br>
<font color="#888888"><br>
Randy<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Ietf-languages mailing list<br>
<a href="mailto:Ietf-languages@alvestrand.no">Ietf-languages@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages" target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br>
</div></div></blockquote></div><br>