views:

51

answers:

2

Essentially I would like to have a messages.properties files external to the jar files in my application. So that users can add languages and edit the files easily if my translations are wrong

at the moment i use

ResourceBundle.getBundle("package.MessageBundle");

But i would like to do something like this

ResourceBundle.getBundle("lang/MessageBundle");

Where lang is a folder under my application installation directory.

  1. is this a good idea (if not, why not)?
  2. can someone point me in the right direction, or some sample code that does this

thanks

Alex

+2  A: 

Just put it elsewhere in an existing path covered by the classpath, or add its path to the classpath. This way you can access it the same way, but instead maintain it externally.

BalusC
too simple, i just completely missed the obvious, thanks
bumperbox
You're welcome.
BalusC
A: 

The way ResourceBundle works is that the argument you pass to getBundle is the "basename". This basename will be suffixed with the locale that you're working with, e.g. MessageBundle_en.properties, MessageBundle_fr.properties. If you want a different Locale to your system default, then you pass the Locale is as an additional parameter to getBundle().

So what you end up with is multiple language files in one directory, rather than a directory for each language.

So rather than

ResourceBundle.getBundle("lang/MessageBundle");

you would do

ResourceBundle.getBundle("MessageBundle", locale); // locale corresponds to "lang"

I suppose you could do this by prefixing the basename with the language name, but you'd be losing much of the functionality that ResourceBundle does for you out of the box.

The "externalizing" part is largely irrelevant, since ResourceBundle operates off the classpath, it works regardless of whether it internal (e.g. a JAR file), or external (e.g. a directory).

skaffman
lang is just a static folder called lang, not a folder for each language. sorry for the confusion
bumperbox