'Re: Feedback wanted: fix approach for JB 4255?'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       icu
Subject:    Re: Feedback wanted: fix approach for JB 4255?
From:       "Mark Davis" <mark.davis () jtcsv ! com>
Date:       2004-12-02 0:35:52
Message-ID: 05b401c4d807$0eb30340$056e3009 () sanjose ! ibm ! com
[Download RAW message or body]

1. For the format issue for dialects, I posted a proposal to the CLDR list.

2. As far as distinguishing between nl-BE and nl_BE-BE, or nl-BE_BE, or
nl_BE_nl, etc. First, RFC 3066 and RFC 3066 bis don't allow anything but the
first one. And we have never seen a convincing case that one needs to
express anything but the first (short of going to a much more customized
locale structure, which would require much more than a simple list of
items). If you want to bring this up during our weekly cldr meetings we can
discuss then.

3. For RFC 3066 support, the first thing we will want to add in cldr is
localizations for the UN region codes (there is a bug filed for that). We
can start to look at localizations of extensions and private use, but I
don't think those are a real priority. On the other hand, I think fairly
natural extensions of our current structure would handle them, so I don't
anticipate much of a problem.

‎Mark

----- Original Message ----- 
From: "Deborah Goldsmith" <goldsmit@apple.com>
To: "icu list" <icu@oss.software.ibm.com>
Sent: Wednesday, December 01, 2004 11:03
Subject: Re: Feedback wanted: fix approach for JB 4255?

> I will be happy to implement 4069 when the time comes but I think we
> need to discuss the approach in CLDR first.
>
> One issue is that in nl-BE, for example, the whole string is the
> language. So the display name for nl-BE, which is a language, should be
> "Flemish", but the display name for nl_BE, which is a locale, should be
> "Flemish (Belgium)", where the nl-BE is implicit from nl_BE.
>
> Another issue is that ICU is not set up to handle valid strings like
> nl-NL_BE ("Dutch (Belgium)"), because it treats nl-BE and nl_BE as the
> same. I think at some point it's going to need to handle things like
> this. Not to mention valid 3066bis things like en-Shaw-GB-boont_US
> ("British Boontling (Shavian, United States)".
>
> If we want to do this before 3066bis is fully supported, I think the
> approach to take should be to look for the combined string first in the
> display name table. That is, if you have a locale of nl_BE, first look
> for nl_BE, then if you don't find that, look for nl. That's not ideal,
> because you wouldn't want en_US to be "U.S. English (United States)".
> So we would have to artificially limit the set of dialects we could
> handle.
>
> Finally, I think anything we implement in CLDR should be targeted at
> the full 3066bis solution, not a subset.
>
> Deborah
>
> On Dec 1, 2004, at 10:17 AM, George Rhoten wrote:
>
> >
> > Since you happen to be in that code, did you want to fix it so that it
> > also addresses jitterbug 4069? I don't see much point to redoing the
> > code, if it has to be redone to support different functionality in the
> > future. Also you submitted the 4096 bug, and I presume that you have
> > a vested interest in implementing it ;-)
> >
> >  George Rhoten
> >  IBM Globalization Center of Competency/ICU San José, CA, USA
> >
> >
> >
> >
> > Deborah Goldsmith <goldsmit@apple.com>
> > Sent by: icu-admin@www-124.southbury.usf.ibm.com
> >
> > 12/01/2004 09:19 AM
> >
> > To
> > icu list <icu@www-124.southbury.usf.ibm.com>
> >
> > cc
> >
> > Subject
> > Re: Feedback wanted: fix approach for JB 4255?
> >
> >
> >
> >
> >
> >
> >
> > OK, I'll proceed with the approach I proposed.
> >
> >  Deborah
> >
> >  On Nov 29, 2004, at 5:59 PM, Deborah Goldsmith wrote:
> >
> >  > Any comments?
> >  >
> >  > Deborah
> >  >
> >  > On Nov 19, 2004, at 5:12 PM, Deborah Goldsmith wrote:
> >  >> Hi,
> >  >>
> >  >> I just encountered JB 4255, which is yet another problem with
> > setting
> >  >> warnings properly when fetching display names, this time in
> >  >> uloc_getDisplayName. The problem is that each individaul
> >  >> uloc_getDisplay* smashes the incoming status code, so the code
> >  >> returned by uloc_getDisplayName is the one from the last component
> > of
> >  >> the name, not the union of any warnings encountered. You can read
> > the
> >  >> bug for a slightly lengthier explanation.
> >  >>
> >  >> I know this is too late for 3.2, but I need to fix this in my copy.
> >  >> My proposed fix is to change uloc_getDisplay* to not smash the
> >  >> incoming error code when calling uloc_get*. uloc_getDisplay*
> > already
> >  >> sets the output code if an error occurs, so we might as well use a
> >  >> local status code for the call to uloc_get*; that would preserve
> > the
> >  >> incoming code. Does this seem like a reasonable approach? The other
> >  >> approach would be to have uloc_getDisplayName manually merge the
> >  >> warning codes from the component calls.
> >  >>
> >  >> By the way, uloc_getDisplay(Language/Script/Country/Variant) could
> >  >> share a common worker routine and just pass a pointer to a function
> >  >> to get the desired component, since
> >  >> uloc_get(Language/Script/Country/Variant) all share the same
> >  >> signature. That would save a bit of code. I filed JB 4256 for that.
> >  >>
> >  >> Deborah
> >  >
> >  > _______________________________________________
> >  > icu mailing list
> >  > icu@oss.software.ibm.com
> >  > http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
> >
> >  _______________________________________________
> >  icu mailing list
> >  icu@oss.software.ibm.com
> >  http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
> >
>
> _______________________________________________
> icu mailing list
> icu@oss.software.ibm.com
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>

_______________________________________________
icu mailing list
icu@oss.software.ibm.com
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
[prev in list] [next in list] [prev in thread] [next in thread] 