Re: Feedback wanted: fix approach for JB 4255?

That approach doesn't solve the problem for which I wrote the bug. :-)

I need to be able to do a uloc_getDisplayLanguage or equivalent on 
"nl-BE" and get "Flemish", not "Flemish (Belgium)". I need to treat it 
as a language, not a full locale. Similarly, in the long run, en-GB is 
"British English", not "British English (Great Britain)".

If you do full locale names, I think the results should be as follows:

en-GB_GB/en_GB -> "English (Great Britain)"
en-GB_US -> "British English (United States)"
en-US_US/en_US -> "English (United States)"
en-US_GB -> "U.S. English (Great Britain)"
nl_BE -> "Flemish (Belgium)"
nl_NL -> "Dutch (Netherlands)"
nl-NL_BE -> "Dutch (Belgium)"

Implementing this level of discrimination will be a little tricky. 
Obviously it requires locale support.

I guess we need more discussion on this. It might have to wait until we 
handle full 3066bis.

Deborah

On Dec 1, 2004, at 11:21 AM, George Rhoten wrote:

>
> That's fine if you don't implement it, but just keep it mind while 
> you're doing your work.  
>
> This is the type of layout that some people were thinking about from 
> previous discussions.  At least this is my understanding.  This can go 
> on for another long discussion at a later time.
>
> FullLocaleName {
>         nl_BE { "Flemish (Belgium)" }  // nl is usually called Dutch
>         i-lang_SPECIAL_VARIANT { "Made up language with a special 
> variant" }
> }
>
> George Rhoten
>  IBM Globalization Center of Competency/ICU  San José, CA, USA
>
>
>
>
> Deborah Goldsmith <[email protected]>
> Sent by: [email protected]
>
> 12/01/2004 11:03 AM
>
> To
> icu list <[email protected]>
>
> cc
>
> 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 <[email protected]>
>  > Sent by: [email protected]
>  >
>  > 12/01/2004 09:19 AM
>  >
>  > To
>  > icu list <[email protected]>
>  >
>  > 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
>  >  > [email protected]
>  >  > 
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>  >
>  >  _______________________________________________
>  >  icu mailing list
>  >  [email protected]
>  >  http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>  >
>
>  _______________________________________________
>  icu mailing list
>  [email protected]
>  http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>