Subject: [Ltru] 2nd WG last call: expanding codes

From: Martin Duerst <[email-masked]>
Date: Tue, 16 May 2006 19:36:49 +0900

One of the editing guidelines that I think we have adopted
is that we always make clear what the codes in the examples
mean. There are a few cases where we forgot:

                                                     For example, a
    process might cause paragraphs whose language tag matched the
    language range "nl" to be displayed in italics within a document.

    Note that canonicalizing language ranges makes certain operations
    impossible.  For example, an implementation that canonicalizes the
    language range "art-lojban" to use the more modern "jbo" cannot be
    used to select just the items with the older tag.

    An extended language range is mapped to a basic language range as
    follows: if the first subtag is a '*' then the entire range is
    treated as "*", otherwise each wildcard subtag is removed.  For
    example, if the language range were "en-*-US", then the range would
    be mapped to "en-US".

    For example, if the language priority list consists of the
    range "de-CH", one might see tags such as "de-CH-1996" but one will
    never see a tag such as "de" (because the 'CH' subtag is missing).

                                  For example, the language-range "de-de"
    matches the language tag "de-DE-1996", but not the language tags "de-
    Deva" or "de-Latn-DE".

The following list (at least those that we didn't explain previously)

      de-DE

       de-Latn-DE

       de-Latf-DE

       de-de

       de-DE-x-goethe

       de-Latn-DE-1996

       de-Deva-DE

    The same range does not match any of the following tags for the
    reasons shown:

       de (missing 'DE')

       de-x-DE (singleton 'x' occurs before 'DE')

       de-Deva ('Deva' not equal to 'DE')

                                                                For
    example, starting with the range "zh-Hant-CN-x-private1-private2",
    the lookup progressively searches for content as shown below:

    For example, an implementation could return the matching tag that is
    first in ASCII-order.  If the language range were "*-CH" and the set
    of tags included "de-CH", "fr-CH", and "it-CH", then the tag "de-CH"
    would be returned.  Another possibility would be for an
    implementation to map the extended language ranges to basic ranges.

    For example, if a particular user's language priority list were
    "fr-FR, zh-Hant" and the program doing the matching had a default
    language range of "ja-JP", the program would search as follows:

[I have not mentioned all the repetitions of the same tag, because
I don't think giving the same explanations every time is necessary.]

Regards,    Martin. 

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Tue, 16 May 2006 09:10:49 -0400

> mean. There are a few cases where we forgot:

+1 to all.

-- 
Híggledy-pìggledy / XML programmers            John Cowan
Try to escape those / I-eighteen-N woes;        http://www.ccil.org/~cowan
Incontrovertibly / What we need more of is      [email-masked]
Unicode weenies and / François Yergeaus.

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 16 May 2006 14:09:56 -0700

Comments follow.

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]]
> Sent: 2006?5?16? 3:37
> To: LTRU Working Group
> Subject: [Ltru] 2nd WG last call: expanding codes
> 

Done.
>     used to select just the items with the older tag.

Done. It reads:

<t>Note that canonicalizing language ranges makes certain operations
impossible. For example, an implementation that canonicalizes the language
range "art-lojban" (artificial language, lojban variant) to use the more
modern "jbo" (Lojban) cannot be used to select just the items with the older
tag.</t>
>     example, if the language range were "en-*-US", then the range would

Done.
>     never see a tag such as "de" (because the 'CH' subtag is missing).

Done:

--
For example, if the language priority list consists of the range "de-CH"
(German as used in Switzerland), one might see tags such as "de-CH-1996"
(German as used in Switzerland, orthography of 1996) but one will never see
a tag such as "de" (because the 'CH' subtag is missing).
--
>     matches the language tag "de-DE-1996", but not the language tags "de-

Done.

--
For example, the language-range "de-de" (German as used in German) matches
the language
tag "de-DE-1996" (German as used in Germany, orthography of 1996), but not
the language tags "de-Deva" (German as written in the Devanagari script) or
"de-Latn-DE" (German, Latin script, as used in Germany).
--
> The following list (at least those that we didn't explain previously)
<t>de-DE (German, as used in Germany)</t>
<t>de-de (German, as used in Germany)</t>
<t>de-Latn-DE (Latin script)</t>
<t>de-Latf-DE (Fraktur variant of Latin script)</t>
<t>de-DE-x-goethe (private use subtag)</t>
<t>de-Latn-DE-1996 (orthography of 1996)</t>
<t>de-Deva-DE (Devanagari script)</t> > 
>     the lookup progressively searches for content as shown below:

Done

--
For example, 
starting with the range "zh-Hant-CN-x-private1-private2" (Chinese,
Traditional script, China, two private use tags) the lookup progressively
searches for content as shown below:
--
>     implementation to map the extended language ranges to basic ranges.

Done.
>     language range of "ja-JP", the program would search as follows:

Done.
> I don't think giving the same explanations every time is necessary.]
Good. The ones we have are ugly enough :-).