[loc-en-dev] [Fwd: grandfathered language tags]

[Doug Felt]

So I guess you're suggesting, Naoto, that we throw an exception for these
now?

It does seem that we could accept and parse private use tags without doing
canonicalization.  That leaves only the grandfathered tags that we'd reject
outright, and of course if there is a standards-body-defined list we can
handle those internally as special cases.  I'm not sure how much additional
work this would be.  It's my feeling that all the work is in the
specification and API design (and in writing thorough tests), and that the
actual implementation is relatively straightforward by comparison.

Doug

On Thu, Feb 12, 2009 at 1:23 PM, Naoto Sato <Naoto.Sato at sun.com> wrote:

> I vote against supporting this for JDK7 due to the schedule/resource.  I
> believe that this could be added later.  For JDK7 I think we should only
> focus on "langtag" in the following BCP47 ABNF.
>
> Language-Tag  = langtag
>                 / privateuse    ; private use tag
>                 / grandfathered ; grandfathered registrations
>
> Thanks,
> Naoto
>
>
> Yoshito Umaoka wrote:
>
>> I scanned the data in the latest draft -
>> http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-09.txt
>>
>> With this update (expected coming soon), the grandfathered list look like
>> below -
>>
>> art-lojban(deprecated) -> jbo
>> cel-gaulish
>> en-GB-oed
>> i-ami(deprecated) -> ami
>> i-bnn(deprecated) -> bnn
>> i-default
>> i-enochian
>> i-hak(deprecated) -> hak
>> i-klingon(deprecated) -> tlh
>> i-lux(deprecated) -> lb
>> i-mingo
>> i-navajo(deprecated) -> nv
>> i-pwn(deprecated) -> pwn
>> i-tao(deprecated) -> tao
>> i-tay(deprecated) -> tay
>> i-tsu(deprecated) -> tsu
>> no-bok(deprecated) -> nb
>> no-nyn(deprecated) -> nn
>> sgn-BE-FR(deprecated) -> sfb
>> sgn-BE-NL(deprecated) -> vgt
>> sgn-CH-DE(deprecated) -> sgg
>> zh-guoyu(deprecated) -> cmn
>> zh-hakka(deprecated) -> hak
>> zh-min(deprecated)
>> zh-min-nan(deprecated) -> nan
>> zh-xiang(deprecated) -> hsn
>>
>>
>> -Yoshito
>>
>>
>> -------- Original Message --------
>> Subject: grandfathered language tags
>> Date: Mon, 09 Feb 2009 16:30:38 -0500
>> From: Yoshito Umaoka <y.umaoka at gmail.com>
>> To: locale-enhancement-dev at openjdk.java.net
>>
>> I scanned the latest language tag registry -
>> http://www.iana.org/assignments/language-subtag-registry
>>
>> There is a category - grandfathered.  Use of these tags are valid in
>> BCP47 language tag.  Some of them were deprecated and its preferred
>> "well-formed" mappings.  Below is the full list of grandfathered tags
>> currently available (File-Date: 2009-01-13).
>>
>> art-lojban(deprecated) -> jbo
>> cel-gaulish
>> en-GB-oed
>> i-ami
>> i-bnn
>> i-default
>> i-enochian
>> i-hak(deprecated) -> zh-hakka
>> i-klingon(deprecated) -> tlh
>> i-lux(deprecated) -> lb
>> i-mingo
>> i-navajo(deprecated) -> nv
>> i-pwn
>> i-tao
>> i-tay
>> i-tsu
>> no-bok(deprecated) -> nb
>> no-nyn(deprecated) -> nn
>> sgn-BE-fr
>> sgn-BE-nl
>> sgn-CH-de
>> zh-cmn
>> zh-cmn-Hans
>> zh-cmn-Hant
>> zh-gan
>> zh-guoyu(deprecated) -> zh-cmn
>> zh-hakka
>> zh-min
>> zh-min-nan
>> zh-wuu
>> zh-xiang
>> zh-yue
>>
>> I'm wondering if we should include the support for grandfathered tags,
>> especially ones which do not have well-formed mappings.  If we want to
>> support such cases, I would expect the whole string is handled as a
>> single unit (do not try to parse them out into separated fields.).
>> Anyway, I'd like to get your inputs.
>>
>> Thanks,
>> Yoshito
>>
>>
>
> --
> Naoto Sato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090212/383d2cb4/attachment.html