Re: Feedback wanted: fix approach for JB 4255?
George Rhoten <[email protected]> Wed, 1 Dec 2004 11:21:22 -0800
| Newsgroups | gmane.comp.lib.icu.general |
|---|---|
| Message-ID | <OFE63AF6AC.6EC9E556-ON86256F5D.0068E91C-88256F5D.006A2B0E@us.ibm.com> |
This is a multipart message in MIME format.
--=_alternative 006A2B0988256F5D_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
That's fine if you don't implement it, but just keep it mind while you're=20
doing your work.=20
This is the type of layout that some people were thinking about from=20
previous discussions. At least this is my understanding. This can go on=20
for another long discussion at a later time.
FullLocaleName {
nl=5FBE { "Flemish (Belgium)" } // nl is usually called Dutch
i-lang=5FSPECIAL=5FVARIANT { "Made up language with a special varia=
nt"=20
}
}
George Rhoten
IBM Globalization Center of Competency/ICU San Jos=E9, CA, USA
Deborah Goldsmith <[email protected]>=20
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=20
need to discuss the approach in CLDR first.
One issue is that in nl-BE, for example, the whole string is the=20
language. So the display name for nl-BE, which is a language, should be=20
"Flemish", but the display name for nl=5FBE, which is a locale, should be=20
"Flemish (Belgium)", where the nl-BE is implicit from nl=5FBE.
Another issue is that ICU is not set up to handle valid strings like=20
nl-NL=5FBE ("Dutch (Belgium)"), because it treats nl-BE and nl=5FBE as the =
same. I think at some point it's going to need to handle things like=20
this. Not to mention valid 3066bis things like en-Shaw-GB-boont=5FUS=20
("British Boontling (Shavian, United States)".
If we want to do this before 3066bis is fully supported, I think the=20
approach to take should be to look for the combined string first in the=20
display name table. That is, if you have a locale of nl=5FBE, first look=20
for nl=5FBE, then if you don't find that, look for nl. That's not ideal,=20
because you wouldn't want en=5FUS to be "U.S. English (United States)".=20
So we would have to artificially limit the set of dialects we could=20
handle.
Finally, I think anything we implement in CLDR should be targeted at=20
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=20
> also addresses jitterbug 4069? I don't see much point to redoing the=20
> code, if it has to be redone to support different functionality in the=20
> future. Also you submitted the 4096 bug, and I presume that you have=20
> a vested interest in implementing it ;-)
>
> George Rhoten
> IBM Globalization Center of Competency/ICU San Jos=E9, 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=20
> setting
> >> warnings properly when fetching display names, this time in
> >> uloc=5FgetDisplayName. The problem is that each individaul
> >> uloc=5FgetDisplay* smashes the incoming status code, so the code
> >> returned by uloc=5FgetDisplayName is the one from the last component =
> of
> >> the name, not the union of any warnings encountered. You can read=20
> 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=5FgetDisplay* to not smash the
> >> incoming error code when calling uloc=5Fget*. uloc=5FgetDisplay*=20
> already
> >> sets the output code if an error occurs, so we might as well use a
> >> local status code for the call to uloc=5Fget*; that would preserve=20
> the
> >> incoming code. Does this seem like a reasonable approach? The other
> >> approach would be to have uloc=5FgetDisplayName manually merge the
> >> warning codes from the component calls.
> >>
> >> By the way, uloc=5FgetDisplay(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=5Fget(Language/Script/Country/Variant) all share the same
> >> signature. That would save a bit of code. I filed JB 4256 for that.
> >>
> >> Deborah
> >
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> > icu mailing list
> > [email protected]
> > http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
icu mailing list
[email protected]
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
--=_alternative 006A2B0988256F5D_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
<br><font size=3D2 face=3D"sans-serif">That's fine if you don't implement i=
t,
but just keep it mind while you're doing your work. </font>
<br>
<br><font size=3D2 face=3D"sans-serif">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.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">FullLocaleName {</font>
<br><font size=3D2 face=3D"sans-serif"> nl=5FBE
{ "Flemish (Belgium)" } // nl is usually called Dutch</font>
<br><font size=3D2 face=3D"sans-serif"> i-lang=
=5FSPECIAL=5FVARIANT
{ "Made up language with a special variant" }</font>
<br><font size=3D2 face=3D"sans-serif">}</font>
<br>
<br><font size=3D2 face=3D"sans-serif">George Rhoten<br>
IBM Globalization Center of Competency/ICU San Jos=E9, CA, USA</font>
<br>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td width=3D40%><font size=3D1 face=3D"sans-serif"><b>Deborah Goldsmith <=
;[email protected]></b>
</font>
<br><font size=3D1 face=3D"sans-serif">Sent by: [email protected]=
.usf.ibm.com</font>
<p><font size=3D1 face=3D"sans-serif">12/01/2004 11:03 AM</font>
<td width=3D59%>
<table width=3D100%>
<tr>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">To</font></div>
<td valign=3Dtop><font size=3D1 face=3D"sans-serif">icu list <icu@www-12=
4.southbury.usf.ibm.com></font>
<tr>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">cc</font></div>
<td valign=3Dtop>
<tr>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">Subject</font></div>
<td valign=3Dtop><font size=3D1 face=3D"sans-serif">Re: Feedback wanted: fix
approach for JB 4255?</font></table>
<br>
<table>
<tr valign=3Dtop>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=3D2><tt>I will be happy to implement 4069 when the time comes
but I think we <br>
need to discuss the approach in CLDR first.<br>
<br>
One issue is that in nl-BE, for example, the whole string is the <br>
language. So the display name for nl-BE, which is a language, should be
<br>
"Flemish", but the display name for nl=5FBE, which is a locale,
should be <br>
"Flemish (Belgium)", where the nl-BE is implicit from nl=5FBE.<br>
<br>
Another issue is that ICU is not set up to handle valid strings like <br>
nl-NL=5FBE ("Dutch (Belgium)"), because it treats nl-BE and nl=5F=
BE
as the <br>
same. I think at some point it's going to need to handle things like <br>
this. Not to mention valid 3066bis things like en-Shaw-GB-boont=5FUS <br>
("British Boontling (Shavian, United States)".<br>
<br>
If we want to do this before 3066bis is fully supported, I think the <br>
approach to take should be to look for the combined string first in the
<br>
display name table. That is, if you have a locale of nl=5FBE, first look
<br>
for nl=5FBE, then if you don't find that, look for nl. That's not ideal,
<br>
because you wouldn't want en=5FUS to be "U.S. English (United States)&=
quot;.
<br>
So we would have to artificially limit the set of dialects we could <br>
handle.<br>
<br>
Finally, I think anything we implement in CLDR should be targeted at <br>
the full 3066bis solution, not a subset.<br>
<br>
Deborah<br>
<br>
On Dec 1, 2004, at 10:17 AM, George Rhoten wrote:<br>
<br>
><br>
> Since you happen to be in that code, did you want to fix it so that
it <br>
> also addresses jitterbug 4069? I don't see much point to redoing
the <br>
> code, if it has to be redone to support different functionality in
the <br>
> future. Also you submitted the 4096 bug, and I presume that
you have <br>
> a vested interest in implementing it ;-)<br>
><br>
> George Rhoten<br>
> IBM Globalization Center of Competency/ICU San Jos=E9, CA,
USA<br>
><br>
><br>
><br>
><br>
> Deborah Goldsmith <[email protected]><br>
> Sent by: [email protected]<br>
><br>
> 12/01/2004 09:19 AM<br>
><br>
> To<br>
> icu list <[email protected]><br>
><br>
> cc<br>
><br>
> Subject<br>
> Re: Feedback wanted: fix approach for JB 4255?<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> OK, I'll proceed with the approach I proposed.<br>
><br>
> Deborah<br>
><br>
> On Nov 29, 2004, at 5:59 PM, Deborah Goldsmith wrote:<br>
><br>
> > Any comments?<br>
> ><br>
> > Deborah<br>
> ><br>
> > On Nov 19, 2004, at 5:12 PM, Deborah Goldsmith wrote:<br>
> >> Hi,<br>
> >><br>
> >> I just encountered JB 4255, which is yet another problem
with <br>
> setting<br>
> >> warnings properly when fetching display names, this
time in<br>
> >> uloc=5FgetDisplayName. The problem is that each individ=
aul<br>
> >> uloc=5FgetDisplay* smashes the incoming status code,
so the code<br>
> >> returned by uloc=5FgetDisplayName is the one from the
last component <br>
> of<br>
> >> the name, not the union of any warnings encountered.
You can read <br>
> the<br>
> >> bug for a slightly lengthier explanation.<br>
> >><br>
> >> I know this is too late for 3.2, but I need to fix
this in my copy.<br>
> >> My proposed fix is to change uloc=5FgetDisplay* to not
smash the<br>
> >> incoming error code when calling uloc=5Fget*. uloc=5Fge=
tDisplay*
<br>
> already<br>
> >> sets the output code if an error occurs, so we might
as well use a<br>
> >> local status code for the call to uloc=5Fget*; that wou=
ld
preserve <br>
> the<br>
> >> incoming code. Does this seem like a reasonable approac=
h?
The other<br>
> >> approach would be to have uloc=5FgetDisplayName manually
merge the<br>
> >> warning codes from the component calls.<br>
> >><br>
> >> By the way, uloc=5FgetDisplay(Language/Script/Country/V=
ariant)
could<br>
> >> share a common worker routine and just pass a pointer
to a function<br>
> >> to get the desired component, since<br>
> >> uloc=5Fget(Language/Script/Country/Variant) all share
the same<br>
> >> signature. That would save a bit of code. I filed JB
4256 for that.<br>
> >><br>
> >> Deborah<br>
> ><br>
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F<br>
> > icu mailing list<br>
> > [email protected]<br>
> > http://oss.software.ibm.com/developerworks/oss/mailman/list=
info/icu<br>
><br>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F<br>
> icu mailing list<br>
> [email protected]<br>
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/=
icu<br>
><br>
<br>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br>
icu mailing list<br>
[email protected]<br>
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu<br>
</tt></font>
<br>
--=_alternative 006A2B0988256F5D_=--