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

[Masayoshi Okutsu]

That is my concern too as I stated in my comments message. Once we 
integrate the minimal function set to JDK 7, the rest should be easier 
to handle. But it's hard to integrate big changes in the late 
development cycle.

Masayoshi

On 2/13/2009 8:37 AM, Naoto Sato wrote:
> Or default to a default locale.
>
> Anyway, the point I would like to make here is not technical, but more 
> like a project management reason.  To make JDK7, we should go for the 
> minimal function set and we have to nail down the 
> spec/resource/schedule ASAP.  Since this project is not tied to any 
> release at the moment, we will need to persuade the JDK7 planning team 
> with a concrete plan, in order for them to include this feature.
>
> Naoto
>
> Doug Felt wrote:
>> 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 
>> <mailto: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
>>         <mailto:y.umaoka at gmail.com>>
>>         To: locale-enhancement-dev at openjdk.java.net
>>         <mailto: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
>>
>>
>
>