Can I change the language in the program?
What do you mean by that ? Which program ? Which language ?
If by language you mean Java, no, i don’t think it’s possible to use jmonkeyengine without the Java part ^^.
If by program you mean the IDE, i think you should have a look at how to do it in netbeans, as the jme ide is based on it.
Now, if by program you mean YOUR program (the one you are creating) and by language you mean “english/french/german/whatever” yes, of course, it’s possible, but there is no easy way to do it (not like in Qt for exemple).
I was writing a list of my wish for jme 4, and it’s already on the list (+ a lot of stuff ^^). But, as it is right now, you need to do the change yourself. Maybe that your best bet is to have a file which a mapping table in it and change this file when you change the language. However, you’ll likely have to restart the program after that, except if you dive into it and go for a “on the fly” change implementation.
This is not a small topic, have a look at : http://qt-project.org/doc/qt-5.0/qtdoc/internationalization.html
I use GNU gettext.
Works like a charm, except for those error messages that are hardcoded into JME.
There’s also Java’s i18n support that’s based on property files.
It’s inadequate as soon as you start inserting numbers into your strings (such as “nnn hitpoints damage”).
Nifty supports property-file-based i18n. I haven’t seen a way to plug a different i18n framework, unfortunately.
QT i18n handles line breaks in addition to pluralisation, which is a nice addition over gettext.
If you have any plans for supporting non-Western languages such as Japanese, Thai, anything written in Arabic script etc., I think you’ll need to use ICU4J for such “trivial” things such as finding out whether the character the user just typed in is punctuation, letter, or digit. The standard classes in Java aren’t entirely useless, but they don’t cover all cases, and ICU4J is top-notch.
ICU4J also comes with i18n support, but I never tried it out (but have been wanting to for quite a while).
gettext has the advantage that there’s tool support for it. These tools do things like extracting translatable strings from the sources, show similar strings to the one being translated, and such stuff that the translator will love.
I don’t what tool support is available in the Qt or ICU4J world.
What’s wrong with inserting hitpoints into your strings? java i18n supports that just fine.
Pluralization, that’s what’s going to be wrong.
In English, you have a singular and a plural. “The wombat loses 1 hitpoint” vs. “The wombat loses 2 hitpoints”.
So you code it like hp == 1 ? “The wombat loses %d hitpoints” : “The wombat loses %d hitpoints” and think you’re done - except that Russian has a singular, a dual (i.e. for 2 hitpoints) and a plural (3 hitpoints and more).
So you do it for Russian… just to discover that Gaelic and Arabic have even more cases, with rules like “dual applies to just 2”, “dual applies to 2, 12, …”, and “dual applies to 2, 12, … but does not apply for numbers above 100”.
Also, while most languages use plural for zero, but some use singular.
Etc. etc. etc.
A ruleset is available on Plural Forms — Localization Guide 0.9.0 documentation .
A different perspective is available on http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html .
Have fun 
(I had my MEGO moment when I saw that even fractions require language-specific pluralization rules. And not just for exotic languages such as Kabyle, but also for French. Natural language is full of little unappreciated surprises…)
You make a good point but I think you missed some of the Java i18n functionality. The two links from the java site miss something important (but still are a good intro).
http://docs.oracle.com/javase/tutorial/i18n/format/index.html
http://docs.oracle.com/javase/tutorial/i18n/format/choiceFormat.html
The thing they miss out is that you can do the choice format from within the message string too:
For example: lastUpdated=Updated {0} {0,choice,0#seconds|1#second|1<seconds} ago
So you can have your lastUpdated formatted however you like for any language you like and your code doesn’t change at all to support however many permutations you like. It’s embedded directly in the translation string how to handle each variation.
The real complexity comes from the other languages you mention. 
As the comments from the last article say certain languages you do still fall over (there is a Polish example there) - the ones you listed that need to pattern match on the number. ICU4J is supposed to handle that so I really guess it depends on just how far you want to take your i18n. It would be nice to see an update for the standard java ones to handle the missing cases though.
Ah I see; I wasn’t fully aware of the choice format.
It’s based on the assumption that each plural is needed for a contiguous range of number.
This assumption does not hold for Arabic and Slawic languages.
Russian, for example, has this rule (Balkan languages follow similar patterns, though these are generally less relevant):
one → n mod 10 is 1 and n mod 100 is not 11;
few → n mod 10 in 2…4 and n mod 100 not in 12…14;
many → n mod 10 is 0 or n mod 10 in 5…9 or n mod 100 in 11…14;
other → everything else
I.e. the pattern repeats for 0, 100, 200, 300, … - you’d need an infinite list of choices.
Arabic is similar but throws in extra rules for one and two:
zero → n is 0;
one → n is 1;
two → n is 2;
few → n mod 100 in 3…10;
many → n mod 100 in 11…99;
other → everything else
I.e. the repeating pattern is in the “few” and “many” rules.
(EDIT) Oh, and I forgot: gettext is somewhat easier on the translator because he doesn’t have to encode the ranges for each message; gettext inspects the language identifier in the header of the source file and automatically pulls in the appropriate ruleset. The translator only gives the variant text for each of zero, one, two, few, many, and other.
Well, that isn’t THAT different from specifying 0, 1, 2, >10, but gettext can warn you if you make a typo, which Java’s message formatter cannot.