when internationalizing applications, it is
suggested to use PropertyResourceBundles
in the tutorial, but after realizing that
property bundles wouldn't load properly with
languages  xxxxx  than english, i submitted a bug
report (4093632).  after months of waiting, i 
noticed that the bug was finally looked at and 
the result??...

This is not a bug: xxx.properties files must be 
encoded in ASCII.
Use the "\uXXXX" notation for non-ASCII Unicode 
characters.

now, this isn't a very pleasant way to internationalize
applications, now is it??...
after translating labels, etc. into a foreign language
(often through a 3rd party), we now have to 
take that translated file (which will more than
likely be in unicode) and convert it to this
"\uXXXX" notation??


PLEASE ALLOW THE USE OF UNICODE PROPERTY FILES!!!
(Review ID: 25397) 
======================================================================

i suppose i could write a little program to
convert these unicode files into this "\uXXXX"
format, but that makes the editing of the labels
afterwards an extra hassle.
======================================================================


 xxxxx@xxxxx  2000-02-18
The native2ascii tool already does this conversion, so another tool is unnecessary.

This would require perhaps UTF-8 encoding of property files, but would then break many of the existing property files out there. Still, this is a reasonable request. Unfortunately, we have to worry about backward compatibility at this point.

You don't have to write any utility to convert into \uXXXX 
format.  One is provided in the JDK called native2ascii.  
Also, if you use ListResourceBundle instead of 
PropertyResourceBundle then you can encode the file any way 
you want and use the -encoding parameter when you compile 
it.

Unicode=vaporware. 

I've looked at the java.util.Properities code: (JDK 1.3)
L.198 : BufferedReader in = new BufferedReader(new
InputStreamReader(inStream, "8859_1"));

All you need to do is allow for a variant on the input stream!

There are two possible solutions that come to mind:
1) overload the .load function to accept an encoding as a
paramter, or
2) read a System property!
String propEnc = 
System.getProperty("java.util.Properties.ENCODING","8859_1");

and then 
... new BufferedReader(new InputStreamReader(inStream,
propEnc));

Users can define -Djava.util.Properties.ENCODING value in
there java command line to set the properties file encoding.

Since UTF-8 is ASCII compatible, if someone specifies UTF-8,
their older properties files will still work... right? And
they get the benefit of having all their special characters
get interpreted properly. This is especially useful for
Servlets using ResourceBundles.

I have to deploy a platform that allows developers to
translate the ResourceBundles: having to deploy native2ascii
and forcing them to run it is an extra headache we'd like to
avoid: especially since Java does such an excellent job of
character conversions anyhow!

Could I also make the following conversion in an Applet?
new BufferedReader(new InputStreamReader(inStream,
unicode)); 
I have tried it and get an exception at 
sun/io/ByteToCharConverter.getConverter
     at java/io/InputStreamReader.<init>
Which is the problem?
Thanks

A new method getResourceBundle(<old 
parameters>,String encoding) would not have any 
backward compatibility problems and allow 
developers to use .properties files in any encoding 
they like.