suppress-script values for fil, mi, pes, prs, qu members

Mark Davis ☕ mark at macchiato.com
Fri Oct 22 18:40:54 CEST 2010


I agree with the direction of the conversation, that we should add the SS
fields that Peter recommended.

====

For those interested, we have related data in Unicode. See the following (you
may have to "View Source" in some browsers)

http://unicode.org/repos/cldr/trunk/common/supplemental/likelySubtags.xml


In particular, these lines are relevant to Peter's request (and are in line
with it):

<likelySubtag from="fil" to="fil_Latn_PH"/> <!--{ Filipino; ?; ? } => {
Filipino; Latin; Philippines }-->
<likelySubtag from="mi" to="mi_Latn_NZ"/> <!--{ Maori; ?; ? } => { Maori;
Latin; New Zealand }-->
<likelySubtag from="qu" to="qu_Latn_PE"/> <!--{ Quechua; ?; ? } => {
Quechua; Latin; Peru }-->


The goal of this mapping is broader than SS, but related. The 'likelySubtag'
mapping says basically that if you get a request for resource data for "fil"
*(with **no** other information)*, the best practice is to assume
equivalence with "fil-Latn-PH" (Unicode treats "-" and "_" as equivalent),
and vice versa. That extends to the parts (unless they are otherwise
mentioned in the data table), so you end up with the following equivalence
class for resource matching:

{fil, fil-Latn, fil-PH, fil-Latn-PH, und_PH}


The "no other information" clause is important: if there is other
information available (like geolocation), that would be a reason for using a
different mapping.

The requirements are broader than SS. For SS, no data means either means
"there is more than one customary script", *or* "there isn't any data
available". In resource matching, even if there is more than one customary
script, we have to provide the one, the most likely one, such as in:

<likelySubtag from="zh" to="zh_Hans_CN"/> <!--{ Chinese; ?; ? } => {
Chinese; Simplified Han; China }-->
<likelySubtag from="zh_TW" to="zh_Hant_TW"/> <!--{ Chinese; ?; Taiwan } => {
Chinese; Traditional Han; Taiwan }-->


New information can be added via ticket (
http://unicode.org/cldr/trac/newticket).

Mark

*— Il meglio è l’inimico del bene —*


On Fri, Oct 22, 2010 at 07:34, Doug Ewell <doug at ewellic.org> wrote:

> John Cowan <cowan at mercury dot ccil dot org> wrote:
>
> > Michael Everson scripsit:
> >
> >>> Even if this is so, S-S is also mutable: we can add it to or remove
> >>> it from either the macrolanguage or the encompassed languages at
> >>> will, as new information comes to light.
> >>
> >> Isn't this a stability problem?
> >
> > Yes, but correctness trumps stability here.  We knew we would
> > occasionally make the wrong decision based on incomplete evidence, as
> > with Wolof.
>
> Not only that, but S-S — like Description — is only informative.
> Stability of informative fields is a much lesser concern than stability
> of normative fields.
>
> --
> Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
> RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ­
>
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/ietf-languages/attachments/20101022/234926bd/attachment-0001.html>


More information about the Ietf-languages mailing list