You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Spark Shen <sm...@gmail.com> on 2006/08/10 09:49:24 UTC
[classlib][luni] Our locale data is incomplete, and Locale("", "CD").getDisplayCountry() return different string compared with ISO3166-1
Hi All:
Construct a locale like this:
Locale l = new Locale("", "CD");
On RI, l.getDisplayCountry() will return "The Democratic Republic Of Congo",
which is different from ISO 3166-1 standard.
("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the Democratic Republic
of the")
Mean while, on harmony, we do not have a country "CD"->"CONGO, THE
DEMOCRATIC REPUBLIC OF THE" data item or a
"CD"->" Congo, the Democratic Republic of
the<http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo>"
data item at all.
This test case will fail on Harmony since the returned displayCountry is
"CD".
public void test_getDisplayCountry() {
Locale l_countryCD = new Locale("", "CD");
assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
l_countryCD.getDisplayCountry());
}
I need to add a mapping into harmony locale data. But which?
"CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
or
"CD"->"Congo, the Democratic Republic of the"
or
"CD"->"The Democratic Republic Of Congo" (RI)
Personally, I prefer RI, since there may be applications relies on the
returned displayCountry value. Your opinions?
Best regards
--
--
Spark Shen
China Software Development Lab, IBM
Re: [classlib][luni] Our locale data is incomplete, and Locale("",
"CD").getDisplayCountry() return different string compared with ISO3166-1
Posted by Geir Magnusson Jr <ge...@pobox.com>.
What does IBM and BEA do? Did they fix this?
geir
Ilya Okomin wrote:
> On 8/10/06, Spark Shen <sm...@gmail.com> wrote:
>
>> 2006/8/10, Richard Liang <ri...@gmail.com>:
>> >
>> >
>> >
>> > Spark Shen wrote:
>> > > Hi All:
>> > > Construct a locale like this:
>> > > Locale l = new Locale("", "CD");
>> > > On RI, l.getDisplayCountry() will return "The Democratic Republic Of
>> > > Congo",
>> > > which is different from ISO 3166-1 standard.
>> > > ("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the Democratic
>> > > Republic
>> > > of the")
>> > IMHO, we may follow the Java Specification, that is, ISO-3166. Do you
>> > think user applications would be broken because of the difference with
>> RI.
>>
>>
>> I am not sure. But this may be a risk.
>
>
> To follow ISO-3166 standard mentioned in the spec sounds better and
> logical but...if you take a look on other several words country names you
> can find that they are not the same on RI than in the ISO-3166. E.g.:
>
> new Locale("", "KP");
> ISO-3166 expected value: "Korea, Democratic People's Republic of "
> RI returns: "North Korea"
>
> new Locale("", "MK");
> ISO-3166 expected value: "Macedonia, the former Yugoslav Republic of "
> RI returns: "Macedonia"
>
> ..and so on.
>
> IMO in this case to be compatible with RI we can use "The Democratic
> Republic Of Congo" for "CD" country. To follow completely the ISO-3166
> standard we have to make changes not only for "CD" country.
>
> Thanks,
> Ilya.
>
>
>> Best regards
>>
>> Richard.
>> > >
>> > > Mean while, on harmony, we do not have a country "CD"->"CONGO, THE
>> > > DEMOCRATIC REPUBLIC OF THE" data item or a
>> > > "CD"->" Congo, the Democratic Republic of
>> > > the< http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo>"
>> > > data item at all.
>> > >
>> > > This test case will fail on Harmony since the returned displayCountry
>> is
>> > > "CD".
>> > > public void test_getDisplayCountry() {
>> > >
>> > > Locale l_countryCD = new Locale("", "CD");
>> > > assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
>> > > l_countryCD.getDisplayCountry());
>> > > }
>> > >
>> > > I need to add a mapping into harmony locale data. But which?
>> > >
>> > > "CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
>> > > or
>> > > "CD"->"Congo, the Democratic Republic of the"
>> > > or
>> > > "CD"->"The Democratic Republic Of Congo" (RI)
>> > >
>> > > Personally, I prefer RI, since there may be applications relies on
>> the
>>
>> > > returned displayCountry value. Your opinions?
>> > >
>> > > Best regards
>> > >
>> >
>> > --
>> > Richard Liang
>> > China Software Development Lab, IBM
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>>
>> --
>> Spark Shen
>> China Software Development Lab, IBM
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] Our locale data is incomplete, and Locale("",
"CD").getDisplayCountry() return different string compared with ISO3166-1
Posted by Spark Shen <sm...@gmail.com>.
Geir Magnusson Jr 写道:
> I'm for doing what we need to do to ensure that user apps don't break.
>
> If IBM, BEA and Sun all do the 'broken' thing, and it isn't
> unreasonable,
I tried the following statement on IBM JDK 1.4:
System.out.println(new Locale("", "CD").getDisplayCountry());
And the displayed message is:
The Democratic Republic Of Congo
The same as SUN JDK 1.5, that is to say, IBM do the 'broken' thing. And
I think I agree with the point:
> then we should do as well and note it in our "differences
> from spec' list
>
Best regards
> geir
>
>
> Spark Shen wrote:
>
>> 2006/8/10, Alex Blewitt <al...@gmail.com>:
>>
>>> I think we should follow the ISO-3166 standard for everything; after
>>> all, that's the point of the standard :-) If the RI has bugs in, then
>>> fair enough, but the point of the ISO codes is to have a standard way
>>> of referencing it (CD) -- how it appears on displays shouldn't be
>>> important, and you shouldn't have code that depends on the display
>>> name when you've got the ISO code ...
>>>
>>> It's much easier to be strict about it now (and fix bugs as they get
>>> found in other apps) than to be lax now and try and add strictness
>>> later. So I'd say, let's go with the ISO-3166 for everything.
>>>
>>> Alex.
>>>
>>> On 10/08/06, Ilya Okomin <il...@gmail.com> wrote:
>>>
>>>> On 8/10/06, Spark Shen <sm...@gmail.com> wrote:
>>>>
>>>>
>>>>> 2006/8/10, Richard Liang <ri...@gmail.com>:
>>>>>
>>>>>>
>>>>>> Spark Shen wrote:
>>>>>>
>>>>>>> Hi All:
>>>>>>> Construct a locale like this:
>>>>>>> Locale l = new Locale("", "CD");
>>>>>>> On RI, l.getDisplayCountry() will return "The Democratic Republic
>>>>>>>
>>> Of
>>>
>>>>>>> Congo",
>>>>>>> which is different from ISO 3166-1 standard.
>>>>>>> ("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the
>>>>>>>
>>> Democratic
>>>
>>>>>>> Republic
>>>>>>> of the")
>>>>>>>
>>>>>> IMHO, we may follow the Java Specification, that is, ISO-3166. Do
>>>>>>
>>> you
>>>
>>>>>> think user applications would be broken because of the difference
>>>>>>
>>> with
>>>
>>>>> RI.
>>>>>
>>>>>
>>>>> I am not sure. But this may be a risk.
>>>>>
>>>> To follow ISO-3166 standard mentioned in the spec sounds better and
>>>> logical but...if you take a look on other several words country names
>>>>
>>> you
>>>
>>>> can find that they are not the same on RI than in the ISO-3166. E.g.:
>>>>
>>>> new Locale("", "KP");
>>>> ISO-3166 expected value: "Korea, Democratic People's Republic of "
>>>> RI returns: "North Korea"
>>>>
>>>> new Locale("", "MK");
>>>> ISO-3166 expected value: "Macedonia, the former Yugoslav Republic of "
>>>> RI returns: "Macedonia"
>>>>
>>>> ..and so on.
>>>>
>>>> IMO in this case to be compatible with RI we can use "The Democratic
>>>> Republic Of Congo" for "CD" country. To follow completely the ISO-3166
>>>> standard we have to make changes not only for "CD" country.
>>>>
>>>> Thanks,
>>>> Ilya.
>>>>
>>>>
>> Emm, now two are for being compliance with RI, one for spec. :-)
>>
>> There is a concern that we may eliminate all locale related information
>> maintained in Harmony itself,
>> but uses a third party component, say ICU4J to manage all these data. And I
>> guess if people get agreed on that
>> scheme, all these argument may shift to that component related threads.
>>
>> Best regards
>>
>>
>>>>> Best regards
>>>>>
>>>>> Richard.
>>>>>
>>>>>>> Mean while, on harmony, we do not have a country "CD"->"CONGO,
>>>>>>>
>>> THE
>>>
>>>>>>> DEMOCRATIC REPUBLIC OF THE" data item or a
>>>>>>> "CD"->" Congo, the Democratic Republic of
>>>>>>> the<
>>>>>>>
>>> http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo
>>>
>>>> "
>>>>
>>>>>>> data item at all.
>>>>>>>
>>>>>>> This test case will fail on Harmony since the returned
>>>>>>>
>>> displayCountry
>>>
>>>>> is
>>>>>
>>>>>>> "CD".
>>>>>>> public void test_getDisplayCountry() {
>>>>>>>
>>>>>>> Locale l_countryCD = new Locale("", "CD");
>>>>>>> assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
>>>>>>> l_countryCD.getDisplayCountry());
>>>>>>> }
>>>>>>>
>>>>>>> I need to add a mapping into harmony locale data. But which?
>>>>>>>
>>>>>>> "CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
>>>>>>> or
>>>>>>> "CD"->"Congo, the Democratic Republic of the"
>>>>>>> or
>>>>>>> "CD"->"The Democratic Republic Of Congo" (RI)
>>>>>>>
>>>>>>> Personally, I prefer RI, since there may be applications
>>>>>>>
>>> relies on
>>> the
>>>
>>>>>>> returned displayCountry value. Your opinions?
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Richard Liang
>>>>>> China Software Development Lab, IBM
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>
>>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>>> To unsubscribe, e-mail:
>>>>>>
>>> harmony-dev-unsubscribe@incubator.apache.org
>>>
>>>>>> For additional commands, e-mail:
>>>>>>
>>> harmony-dev-help@incubator.apache.org
>>>
>>>>>>
>>>>> --
>>>>> Spark Shen
>>>>> China Software Development Lab, IBM
>>>>>
>>>>>
>>>>>
>>>> --
>>>> --
>>>> Ilya Okomin
>>>> Intel Middleware Products Division
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
--
Spark Shen
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] Our locale data is incomplete, and Locale("",
"CD").getDisplayCountry() return different string compared with ISO3166-1
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I'm for doing what we need to do to ensure that user apps don't break.
If IBM, BEA and Sun all do the 'broken' thing, and it isn't
unreasonable, then we should do as well and note it in our "differences
from spec' list
geir
Spark Shen wrote:
> 2006/8/10, Alex Blewitt <al...@gmail.com>:
>>
>> I think we should follow the ISO-3166 standard for everything; after
>> all, that's the point of the standard :-) If the RI has bugs in, then
>> fair enough, but the point of the ISO codes is to have a standard way
>> of referencing it (CD) -- how it appears on displays shouldn't be
>> important, and you shouldn't have code that depends on the display
>> name when you've got the ISO code ...
>>
>> It's much easier to be strict about it now (and fix bugs as they get
>> found in other apps) than to be lax now and try and add strictness
>> later. So I'd say, let's go with the ISO-3166 for everything.
>>
>> Alex.
>>
>> On 10/08/06, Ilya Okomin <il...@gmail.com> wrote:
>> > On 8/10/06, Spark Shen <sm...@gmail.com> wrote:
>> >
>> > > 2006/8/10, Richard Liang <ri...@gmail.com>:
>> > > >
>> > > >
>> > > >
>> > > > Spark Shen wrote:
>> > > > > Hi All:
>> > > > > Construct a locale like this:
>> > > > > Locale l = new Locale("", "CD");
>> > > > > On RI, l.getDisplayCountry() will return "The Democratic Republic
>> Of
>> > > > > Congo",
>> > > > > which is different from ISO 3166-1 standard.
>> > > > > ("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the
>> Democratic
>> > > > > Republic
>> > > > > of the")
>> > > > IMHO, we may follow the Java Specification, that is, ISO-3166. Do
>> you
>> > > > think user applications would be broken because of the difference
>> with
>> > > RI.
>> > >
>> > >
>> > > I am not sure. But this may be a risk.
>> >
>> >
>> > To follow ISO-3166 standard mentioned in the spec sounds better and
>> > logical but...if you take a look on other several words country names
>> you
>> > can find that they are not the same on RI than in the ISO-3166. E.g.:
>> >
>> > new Locale("", "KP");
>> > ISO-3166 expected value: "Korea, Democratic People's Republic of "
>> > RI returns: "North Korea"
>> >
>> > new Locale("", "MK");
>> > ISO-3166 expected value: "Macedonia, the former Yugoslav Republic of "
>> > RI returns: "Macedonia"
>> >
>> > ..and so on.
>> >
>> > IMO in this case to be compatible with RI we can use "The Democratic
>> > Republic Of Congo" for "CD" country. To follow completely the ISO-3166
>> > standard we have to make changes not only for "CD" country.
>> >
>> > Thanks,
>> > Ilya.
>> >
>
>
> Emm, now two are for being compliance with RI, one for spec. :-)
>
> There is a concern that we may eliminate all locale related information
> maintained in Harmony itself,
> but uses a third party component, say ICU4J to manage all these data. And I
> guess if people get agreed on that
> scheme, all these argument may shift to that component related threads.
>
> Best regards
>
>>
>> > > Best regards
>> > >
>> > > Richard.
>> > > > >
>> > > > > Mean while, on harmony, we do not have a country "CD"->"CONGO,
>> THE
>> > > > > DEMOCRATIC REPUBLIC OF THE" data item or a
>> > > > > "CD"->" Congo, the Democratic Republic of
>> > > > > the<
>> http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo
>> >"
>> > > > > data item at all.
>> > > > >
>> > > > > This test case will fail on Harmony since the returned
>> displayCountry
>> > > is
>> > > > > "CD".
>> > > > > public void test_getDisplayCountry() {
>> > > > >
>> > > > > Locale l_countryCD = new Locale("", "CD");
>> > > > > assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
>> > > > > l_countryCD.getDisplayCountry());
>> > > > > }
>> > > > >
>> > > > > I need to add a mapping into harmony locale data. But which?
>> > > > >
>> > > > > "CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
>> > > > > or
>> > > > > "CD"->"Congo, the Democratic Republic of the"
>> > > > > or
>> > > > > "CD"->"The Democratic Republic Of Congo" (RI)
>> > > > >
>> > > > > Personally, I prefer RI, since there may be applications
>> relies on
>> the
>> > >
>> > > > > returned displayCountry value. Your opinions?
>> > > > >
>> > > > > Best regards
>> > > > >
>> > > >
>> > > > --
>> > > > Richard Liang
>> > > > China Software Development Lab, IBM
>> > > >
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > > > To unsubscribe, e-mail:
>> harmony-dev-unsubscribe@incubator.apache.org
>> > > > For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Spark Shen
>> > > China Software Development Lab, IBM
>> > >
>> > >
>> >
>> >
>> > --
>> > --
>> > Ilya Okomin
>> > Intel Middleware Products Division
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Re: [classlib][luni] Our locale data is incomplete, and Locale("", "CD").getDisplayCountry() return different string compared with ISO3166-1
Posted by Spark Shen <sm...@gmail.com>.
2006/8/10, Alex Blewitt <al...@gmail.com>:
>
> I think we should follow the ISO-3166 standard for everything; after
> all, that's the point of the standard :-) If the RI has bugs in, then
> fair enough, but the point of the ISO codes is to have a standard way
> of referencing it (CD) -- how it appears on displays shouldn't be
> important, and you shouldn't have code that depends on the display
> name when you've got the ISO code ...
>
> It's much easier to be strict about it now (and fix bugs as they get
> found in other apps) than to be lax now and try and add strictness
> later. So I'd say, let's go with the ISO-3166 for everything.
>
> Alex.
>
> On 10/08/06, Ilya Okomin <il...@gmail.com> wrote:
> > On 8/10/06, Spark Shen <sm...@gmail.com> wrote:
> >
> > > 2006/8/10, Richard Liang <ri...@gmail.com>:
> > > >
> > > >
> > > >
> > > > Spark Shen wrote:
> > > > > Hi All:
> > > > > Construct a locale like this:
> > > > > Locale l = new Locale("", "CD");
> > > > > On RI, l.getDisplayCountry() will return "The Democratic Republic
> Of
> > > > > Congo",
> > > > > which is different from ISO 3166-1 standard.
> > > > > ("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the Democratic
> > > > > Republic
> > > > > of the")
> > > > IMHO, we may follow the Java Specification, that is, ISO-3166. Do
> you
> > > > think user applications would be broken because of the difference
> with
> > > RI.
> > >
> > >
> > > I am not sure. But this may be a risk.
> >
> >
> > To follow ISO-3166 standard mentioned in the spec sounds better and
> > logical but...if you take a look on other several words country names
> you
> > can find that they are not the same on RI than in the ISO-3166. E.g.:
> >
> > new Locale("", "KP");
> > ISO-3166 expected value: "Korea, Democratic People's Republic of "
> > RI returns: "North Korea"
> >
> > new Locale("", "MK");
> > ISO-3166 expected value: "Macedonia, the former Yugoslav Republic of "
> > RI returns: "Macedonia"
> >
> > ..and so on.
> >
> > IMO in this case to be compatible with RI we can use "The Democratic
> > Republic Of Congo" for "CD" country. To follow completely the ISO-3166
> > standard we have to make changes not only for "CD" country.
> >
> > Thanks,
> > Ilya.
> >
Emm, now two are for being compliance with RI, one for spec. :-)
There is a concern that we may eliminate all locale related information
maintained in Harmony itself,
but uses a third party component, say ICU4J to manage all these data. And I
guess if people get agreed on that
scheme, all these argument may shift to that component related threads.
Best regards
>
> > > Best regards
> > >
> > > Richard.
> > > > >
> > > > > Mean while, on harmony, we do not have a country "CD"->"CONGO, THE
> > > > > DEMOCRATIC REPUBLIC OF THE" data item or a
> > > > > "CD"->" Congo, the Democratic Republic of
> > > > > the< http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo
> >"
> > > > > data item at all.
> > > > >
> > > > > This test case will fail on Harmony since the returned
> displayCountry
> > > is
> > > > > "CD".
> > > > > public void test_getDisplayCountry() {
> > > > >
> > > > > Locale l_countryCD = new Locale("", "CD");
> > > > > assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
> > > > > l_countryCD.getDisplayCountry());
> > > > > }
> > > > >
> > > > > I need to add a mapping into harmony locale data. But which?
> > > > >
> > > > > "CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
> > > > > or
> > > > > "CD"->"Congo, the Democratic Republic of the"
> > > > > or
> > > > > "CD"->"The Democratic Republic Of Congo" (RI)
> > > > >
> > > > > Personally, I prefer RI, since there may be applications relies on
> the
> > >
> > > > > returned displayCountry value. Your opinions?
> > > > >
> > > > > Best regards
> > > > >
> > > >
> > > > --
> > > > Richard Liang
> > > > China Software Development Lab, IBM
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Spark Shen
> > > China Software Development Lab, IBM
> > >
> > >
> >
> >
> > --
> > --
> > Ilya Okomin
> > Intel Middleware Products Division
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Spark Shen
China Software Development Lab, IBM
Re: Re: [classlib][luni] Our locale data is incomplete, and Locale("", "CD").getDisplayCountry() return different string compared with ISO3166-1
Posted by Alex Blewitt <al...@gmail.com>.
I think we should follow the ISO-3166 standard for everything; after
all, that's the point of the standard :-) If the RI has bugs in, then
fair enough, but the point of the ISO codes is to have a standard way
of referencing it (CD) -- how it appears on displays shouldn't be
important, and you shouldn't have code that depends on the display
name when you've got the ISO code ...
It's much easier to be strict about it now (and fix bugs as they get
found in other apps) than to be lax now and try and add strictness
later. So I'd say, let's go with the ISO-3166 for everything.
Alex.
On 10/08/06, Ilya Okomin <il...@gmail.com> wrote:
> On 8/10/06, Spark Shen <sm...@gmail.com> wrote:
>
> > 2006/8/10, Richard Liang <ri...@gmail.com>:
> > >
> > >
> > >
> > > Spark Shen wrote:
> > > > Hi All:
> > > > Construct a locale like this:
> > > > Locale l = new Locale("", "CD");
> > > > On RI, l.getDisplayCountry() will return "The Democratic Republic Of
> > > > Congo",
> > > > which is different from ISO 3166-1 standard.
> > > > ("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the Democratic
> > > > Republic
> > > > of the")
> > > IMHO, we may follow the Java Specification, that is, ISO-3166. Do you
> > > think user applications would be broken because of the difference with
> > RI.
> >
> >
> > I am not sure. But this may be a risk.
>
>
> To follow ISO-3166 standard mentioned in the spec sounds better and
> logical but...if you take a look on other several words country names you
> can find that they are not the same on RI than in the ISO-3166. E.g.:
>
> new Locale("", "KP");
> ISO-3166 expected value: "Korea, Democratic People's Republic of "
> RI returns: "North Korea"
>
> new Locale("", "MK");
> ISO-3166 expected value: "Macedonia, the former Yugoslav Republic of "
> RI returns: "Macedonia"
>
> ..and so on.
>
> IMO in this case to be compatible with RI we can use "The Democratic
> Republic Of Congo" for "CD" country. To follow completely the ISO-3166
> standard we have to make changes not only for "CD" country.
>
> Thanks,
> Ilya.
>
>
> > Best regards
> >
> > Richard.
> > > >
> > > > Mean while, on harmony, we do not have a country "CD"->"CONGO, THE
> > > > DEMOCRATIC REPUBLIC OF THE" data item or a
> > > > "CD"->" Congo, the Democratic Republic of
> > > > the< http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo>"
> > > > data item at all.
> > > >
> > > > This test case will fail on Harmony since the returned displayCountry
> > is
> > > > "CD".
> > > > public void test_getDisplayCountry() {
> > > >
> > > > Locale l_countryCD = new Locale("", "CD");
> > > > assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
> > > > l_countryCD.getDisplayCountry());
> > > > }
> > > >
> > > > I need to add a mapping into harmony locale data. But which?
> > > >
> > > > "CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
> > > > or
> > > > "CD"->"Congo, the Democratic Republic of the"
> > > > or
> > > > "CD"->"The Democratic Republic Of Congo" (RI)
> > > >
> > > > Personally, I prefer RI, since there may be applications relies on the
> >
> > > > returned displayCountry value. Your opinions?
> > > >
> > > > Best regards
> > > >
> > >
> > > --
> > > Richard Liang
> > > China Software Development Lab, IBM
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Spark Shen
> > China Software Development Lab, IBM
> >
> >
>
>
> --
> --
> Ilya Okomin
> Intel Middleware Products Division
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] Our locale data is incomplete, and Locale("", "CD").getDisplayCountry() return different string compared with ISO3166-1
Posted by Ilya Okomin <il...@gmail.com>.
On 8/10/06, Spark Shen <sm...@gmail.com> wrote:
> 2006/8/10, Richard Liang <ri...@gmail.com>:
> >
> >
> >
> > Spark Shen wrote:
> > > Hi All:
> > > Construct a locale like this:
> > > Locale l = new Locale("", "CD");
> > > On RI, l.getDisplayCountry() will return "The Democratic Republic Of
> > > Congo",
> > > which is different from ISO 3166-1 standard.
> > > ("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the Democratic
> > > Republic
> > > of the")
> > IMHO, we may follow the Java Specification, that is, ISO-3166. Do you
> > think user applications would be broken because of the difference with
> RI.
>
>
> I am not sure. But this may be a risk.
To follow ISO-3166 standard mentioned in the spec sounds better and
logical but...if you take a look on other several words country names you
can find that they are not the same on RI than in the ISO-3166. E.g.:
new Locale("", "KP");
ISO-3166 expected value: "Korea, Democratic People's Republic of "
RI returns: "North Korea"
new Locale("", "MK");
ISO-3166 expected value: "Macedonia, the former Yugoslav Republic of "
RI returns: "Macedonia"
..and so on.
IMO in this case to be compatible with RI we can use "The Democratic
Republic Of Congo" for "CD" country. To follow completely the ISO-3166
standard we have to make changes not only for "CD" country.
Thanks,
Ilya.
> Best regards
>
> Richard.
> > >
> > > Mean while, on harmony, we do not have a country "CD"->"CONGO, THE
> > > DEMOCRATIC REPUBLIC OF THE" data item or a
> > > "CD"->" Congo, the Democratic Republic of
> > > the< http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo>"
> > > data item at all.
> > >
> > > This test case will fail on Harmony since the returned displayCountry
> is
> > > "CD".
> > > public void test_getDisplayCountry() {
> > >
> > > Locale l_countryCD = new Locale("", "CD");
> > > assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
> > > l_countryCD.getDisplayCountry());
> > > }
> > >
> > > I need to add a mapping into harmony locale data. But which?
> > >
> > > "CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
> > > or
> > > "CD"->"Congo, the Democratic Republic of the"
> > > or
> > > "CD"->"The Democratic Republic Of Congo" (RI)
> > >
> > > Personally, I prefer RI, since there may be applications relies on the
>
> > > returned displayCountry value. Your opinions?
> > >
> > > Best regards
> > >
> >
> > --
> > Richard Liang
> > China Software Development Lab, IBM
> >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Spark Shen
> China Software Development Lab, IBM
>
>
--
--
Ilya Okomin
Intel Middleware Products Division
Re: [classlib][luni] Our locale data is incomplete, and Locale("", "CD").getDisplayCountry() return different string compared with ISO3166-1
Posted by Spark Shen <sm...@gmail.com>.
2006/8/10, Richard Liang <ri...@gmail.com>:
>
>
>
> Spark Shen wrote:
> > Hi All:
> > Construct a locale like this:
> > Locale l = new Locale("", "CD");
> > On RI, l.getDisplayCountry() will return "The Democratic Republic Of
> > Congo",
> > which is different from ISO 3166-1 standard.
> > ("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the Democratic
> > Republic
> > of the")
> IMHO, we may follow the Java Specification, that is, ISO-3166. Do you
> think user applications would be broken because of the difference with RI.
I am not sure. But this may be a risk.
Best regards
Richard.
> >
> > Mean while, on harmony, we do not have a country "CD"->"CONGO, THE
> > DEMOCRATIC REPUBLIC OF THE" data item or a
> > "CD"->" Congo, the Democratic Republic of
> > the<http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo>"
> > data item at all.
> >
> > This test case will fail on Harmony since the returned displayCountry is
> > "CD".
> > public void test_getDisplayCountry() {
> >
> > Locale l_countryCD = new Locale("", "CD");
> > assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
> > l_countryCD.getDisplayCountry());
> > }
> >
> > I need to add a mapping into harmony locale data. But which?
> >
> > "CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
> > or
> > "CD"->"Congo, the Democratic Republic of the"
> > or
> > "CD"->"The Democratic Republic Of Congo" (RI)
> >
> > Personally, I prefer RI, since there may be applications relies on the
> > returned displayCountry value. Your opinions?
> >
> > Best regards
> >
>
> --
> Richard Liang
> China Software Development Lab, IBM
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Spark Shen
China Software Development Lab, IBM
Re: [classlib][luni] Our locale data is incomplete, and Locale("",
"CD").getDisplayCountry() return different string compared with ISO3166-1
Posted by Richard Liang <ri...@gmail.com>.
Spark Shen wrote:
> Hi All:
> Construct a locale like this:
> Locale l = new Locale("", "CD");
> On RI, l.getDisplayCountry() will return "The Democratic Republic Of
> Congo",
> which is different from ISO 3166-1 standard.
> ("CONGO, THE DEMOCRATIC REPUBLIC OF THE" or "Congo, the Democratic
> Republic
> of the")
IMHO, we may follow the Java Specification, that is, ISO-3166. Do you
think user applications would be broken because of the difference with RI.
Richard.
>
> Mean while, on harmony, we do not have a country "CD"->"CONGO, THE
> DEMOCRATIC REPUBLIC OF THE" data item or a
> "CD"->" Congo, the Democratic Republic of
> the<http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo>"
> data item at all.
>
> This test case will fail on Harmony since the returned displayCountry is
> "CD".
> public void test_getDisplayCountry() {
>
> Locale l_countryCD = new Locale("", "CD");
> assertEquals("CONGO, THE DEMOCRATIC REPUBLIC OF THE",
> l_countryCD.getDisplayCountry());
> }
>
> I need to add a mapping into harmony locale data. But which?
>
> "CD"->"CONGO, THE DEMOCRATIC REPUBLIC OF THE"
> or
> "CD"->"Congo, the Democratic Republic of the"
> or
> "CD"->"The Democratic Republic Of Congo" (RI)
>
> Personally, I prefer RI, since there may be applications relies on the
> returned displayCountry value. Your opinions?
>
> Best regards
>
--
Richard Liang
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org