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
>