Develop Reference

Modify Wicket's XML Resource Bundle with Java internationalization (i18n)

In the resource XML there are all these values associated with keys.I want to modify a value associated with a key directly from Java.
For instance,I have <entry key="greetingMessage">Welcome to my app</entry> and this is displayed in the view,but also the message can be modified from the view and I want to be automatically updated in the XML.
I have managed to do this by parsing and changing the XML with javax.xml and org.w3c but I feel I am missing something.Does Java internationalization or Wicket framework have a method to achieve this?

Wicket only has facilities to read i18n resources (for example, XmlFilePropertiesLoader). Properties.storeToXML() is not used in Wicket 6 code, while Properties.loadFromXML() is used to read those XML properties files.
To store those translations back to XML files you need to be cautious. At least, synchronization has to be implemented to make sure that simultaneous edits are not lost.
I'd not recommend to store the edits in XML (especially in the original XML files). It seems better to have two levels of properties:
First, immutable, level, is based on the original (and immutable) XML files.
Second level consisting of 'edits' acts like a patch over the first level. It may be stored in a database which is much more convenient for storing a constantly updating data (like such edits).

Spring messages in JavaScript and Thymeleaf

I use Thymeleaf with Spring MVC 4.1.1 and I want to be able to re-use my Spring messages (with the user's automatically detected locale) for my JavaScript files. E.g. I want to do:
$('#fooTitle').text(messages['foo.title']);
...and #fooTitle would contain the value under foo.title for the user locale.
What would be the easiest way to do this? Note that I would like a JavaScript object ("dictionary") or another data structure which is easy to navigate.

If not the easiest (but admittedly easy enough), the cleanest and most robust way is to use html5 data attributes to pass back-end data to js. This way, no matter if you move your javascript to external files, it still works. Use some element as container (choose the most proper for your case) as a carrier of the thymeleaf back-end retrieved i18n values and then access them with jQuery
in html:
<div id="container" th:attr="data-foo-title-txt=#{foo.title}"></div>
in js:
$('#fooTitle').text($("#container").data("foo-title-txt"));
See also my older similar answer, (although the OP has not left any sign of life after that :) )
,
JavaScript, Thymeleaf and localizing text

The easiest way to include localization messages would be:
$('#fooTitle').text([[#{foo.title}]])

Internationalize a Java Application?

I have a Java Desktop App, the users of the application have the availability to set the aplications language.
By now i manage it in the database, i call the value of a field called - userLanguage - which is an Integer, and when the user has logged in depending on this value i set the corresponding text to each element on the app by using a switch ( case 1: set labels text ENGLISH, case 2: set labels text SPANISH ... etc)
But i've heard that control the language from the database is an insult, and i would like to know which's a nice way to do it, or what's the best way to do so, it doesn't matter how difficult it would be but the efficence of the method to internationallize an app is what metters for me.

I would actually handle this problem using the Java Preferences. It keeps the preferences for each user separately in a system independent way (for you at least). If you use XML you need to create a SAX/DOM parser or if you use a DB you need to use jdbc. Neither XML or the DB is a bad or a tough solution, I just think the preferences are the easiest.
For internationalization, I would use a ResourceBundle that localized for different Locales. It is a pretty big topic see The Java internationalization (I18n) tutorial

Java Preferences is what you are looking for then.
Or, instead of using XML file you can use Properties.
...i've heard that control the language from the database is an insult...
I do not agree with that. I think it is scenario dependent, and in your case I think you should keep it the way it is to avoid unnecessary work, unless there is an absolute need for keeping the preferred idiom outside your DB.

You've received two answers, both of which are plainly wrong. If you have Java Desktop Application, you should this code:
Locale locale = Locale.getDefault(Locale.Category.DISPLAY);
This will give you valid User Interface language for your application - the one user set in his OS preferences. If you want to keep the language in a database or in some kind of preferences, you'll be forcing users to chose language. What for? I've already set what language I want. If you don't have it, let Java fall back to your application's default.
In case you wonder, if you use ResourceBundle, the default would be the one without a Locale in its name. That is unless you override this process by using custom ResourceBundle.Control.

Is it good practice to use property text placeholders inside JSPs?

For many projects I have worked on, programming teams work with the style of placholding every piece of static text in an xhtml file into a properties file. For example:
xhtml=
...
<h1>${messages.resourceBundle['key.to.static.text.placeholder']}</h1>
...
messages.properties=
...
key.to.static.text.placeholder=This will be the heading for this page only
...
Would anybody be able to explain what the advantage in this is?
So far, I can only see the following disadvantages:
making changes to any xhtml file requires you to hunt for the correct .properties file, and then the individual property to make the change to
if others have re-used properties, then deleting them becomes tricky as you have to be certain no other page is referencing the property, therefore after several change request rounds, properties files become large with redundant properties
if there are 1000 xhtmls, there will be 1000 .properties files to load, which is more cycles on the cpu to load and inject static pieces of text
if your using WebFlow and have flows that pass into other flows, properties have to be duplicated, meaning that sometimes you must place the same property in many different properties files to render correctly
hard to read code; if you know you want to work on the text 'This will be the heading for this page' only, you'll need to work out where that is on the xhtml from the property files first - you can't simply look at the xhtml and see clearly how the content will be laid out once rendered.
The only advantages I can see are text reuse and possibly html escaping.
Apologies if its coding 101, but I've had a hunt around Google and can't find the reasoning to the pattern.
Many Thanks

This is a common practice for internationalizing content.
You create one property file per language (or locale) and use a dynamic way off resolving which one to load depending on the context. (e.g. Language HTTP header the browser sends).
It is arguably more flexible than providing 1 jsp file per language, and can still deal with complex cases where plurals or stylistic differences might change the way you write localized text.
This is a standard JDK feature, lookup resource bundles.
You do not have to build 1 file per jsp (maybe your framework works this way?), although doing so can help the person writing the translation.

Java saving strings

I have a RuneScape Private Server project coded in Java, and am trying to code a personal "tag" that players can use. I have managed to do this, but everytime there is a restart on the server, their "tag" gets reset to "null".
Their "tag" is initalized by doing a command ";;settag [name]". Their tag is then set to whatever they want. I have done this through a string:
if (command[0].equals("settag")) {
newTag = getCompleteString(command, 1);
newTag = player.yellTag
player.sendMessage("Your tag is now:" +newTag);
}
I am unsure what the most efficient way to fix this would be, I am thinking of just loading and saving through .xml/.txt files. By the way, player.yellTag is where the next command (::mytag) searches it from, which works fine, until there is a restart of the server.

it all depends on the context of your application. If you are planning on having less than a few hundreds players, then a xml file may be ok. You should look at JAXB, which is, afaict, the standard way to store your objects in Java. You can also store them as JSON files, using gson which is way simpler to use and implement than XML stuff.
But if you get to have more than thousands of players, you may want to get some more efficient way to serialize your tags by putting them in a database, and thus an ORM library like hibernate could help you do that.
You may want to make your own stuff, like a tag directory full of files named after unique ids of your players containing the players' tag... It's a lot more "hackish" but still quite efficient.