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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> wrote:
On 8/10/06, Spark Shen <[EMAIL PROTECTED]> wrote:

2006/8/10, Richard Liang <[EMAIL PROTECTED]>:

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:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Spark Shen
China Software Development Lab, IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to