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