why store internationalization "words" in separate (xml) files?

I've been reading up a bit on how people do internationalization. It seems that th开发者_如何学Ce common consensus is to save those strings in a separate file (usually xml) and load it when necessary.

I'm wondering why not just store those strings in a database instead? isn't it much better this way?

Btw the nature of my app is a website app.

---

The most important thing is to store your string tables outside of your compilation units so that incorporating updated translations does not require a rebuild. This allows for new or updated translations to be incorporated at a later point without too much hassle.

Of course, those string tables could be stored anywhere. If you want to put them in a database, knock yourself out. As long as your application can reach them and your translation staff know how to deliver them into the right place, it doesn't make a difference.

---

Serious Internationalization is always a big project with a lot of parts and players. As @zerkms alludes to, the translation task is very often an offline activity by individuals and teams around the world.

So it makes sense to have a clean work product that a translation team can produce (the translated XML file).

Once the file is translated, it is up to you how you handle the translations within your software. It is common to keep them in memory since you often need to substitute in variables into the placeholders.

---

If you do store in the database, you will introduce additional overhead of querying the database everytime your "locale" switches.

This the reason for resource bundles. You package it along with source code, but you dont have to change code to add support for languages.

You could also subclass the resourcebundle class yourself and implement jdbc support so the locale-specific strings are stored in the database.

http://java.sun.com/developer/technicalArticles/Intl/ResourceBundles/