[brailleblaster] Re: Encoding of Translated Values

  • From: Michael Whapples <mwhapples@xxxxxxx>
  • To: brailleblaster@xxxxxxxxxxxxx
  • Date: Tue, 07 Dec 2010 16:54:27 +0000

I have to say I am not convinced that subclasses are simpler, you still need to make use of ResourceBundle.getBundle to find your localised data, the only difference is in one case you are creating a .class file (requiring the knowledge of java, compiling java, etc) and putting that in the right place and in the other you are writing a simple .properties file and putting it in the same place as the subclass would have gone. Furthermore as the javadoc for ResourceBundle.getBundle says, you could supply either so as and when the more advanced features of subclasses are needed they can be dropped in without any change of code (thanks to getBundle acting as a factory method).


The more complicated stuff of using additional ClassLoaders is only required if you want to have localised data outside the jar file (would work as well for subclasses) and if you feel extending the classpath to an actual directory is not acceptable. If you feel happy enough in extending the classpath in this way then its easily done with the -cp argument to the JVM.

Michael Whapples
On 07/12/10 15:31, John J. Boyer wrote:
Great information, as usual. However, I think I'll stict to subclasses
of ListResourceBundle until we have a need for users to make new
location property files. It is far simpler, and a location file from a
user can be turned into a subclass easily, even by a script.

John

On Tue, Dec 07, 2010 at 12:44:37PM +0000, Michael Whapples wrote:
It would be placed in the appropriate package on the classpath is
probably the simplest. Now it may not be desirable to have the classpath
to extend to a directory for new locales, so if you want such a
directory for locales to be added to then it may be worth looking at the
javadoc for java.lang.ClassLoader and having one specifically for
loading localised data.

 From how I read that, it looks like you would still be able to have the
core localised data inside the jar file as the parent ClassLoader could
be the system ClassLoader which is used for the classpath.

I am leaving the precise detail of how you would create this specific
ClassLoader as an exercise for you, it might need a subclass or it might
be there is a suitable existing class in the JDK.

Michael Whapples
On 07/12/10 10:52, John J. Boyer wrote:
Thanks for the information. However, if a user wants to write a new
properties file for another language, where would she put it?

John

On Tue, Dec 07, 2010 at 10:39:43AM +0000, Michael Whapples wrote:
What lead you to that conclusion? Where did you look? A less than 5
minute search tells me that unicode can be represented in .properties
files.

Firstly I found an indication of how unicode could be shown in
.properties files by looking at the javadoc for java.util.Properties
http://download.oracle.com/javase/6/docs/api/java/util/Properties.html.
Probably the most useful things here are that .properties files are
written using the ISO8859-1 encoding and any character which cannot be
represented by this encoding can be inserted using the \u (eg. \u0009)
unicode notation.

May be a more readable article might be this wikipedia article, it gives
much more detail on the .properties file format (eg. how you can have
keys with spaces in the name, etc)
http://en.wikipedia.org/wiki/.properties.

I also found this FAQ on java internationalisation which also seems to
have the answer, may be it will have answers to other questions you may
have http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp.

As for the languages which use right to left writing, I don't know the
answer off-hand, it may need looking at to see if SWT provides anything
in this area as SWT will be doing the displaying.

Michael Whapples
On 07/12/10 04:16, John J. Boyer wrote:
There doesn't seem to be a satisfactory answer to encoding of
trranslations in properties files. So it looks to me as if we will have
to use subclasses of ListResourceBundle. The translations can always be
entered as Unicode values. Moreover, for languages suchh as Hebrew and
Arabic we will have to enter them "backwards".

If we need a new subclass for a new lacality only that subclass will
have to be compiled and added to the jar file. With ant this is trivial.

John



Other related posts: