How to handle multiple languages best in database applications? How to handle multiple languages best in database applications? database database

How to handle multiple languages best in database applications?


Rather than storing the language information in property files, store it in tables in your database. Then it can all be done easily.

Records:first | last  | messageid |John  | Smith | 1         |Messages:messageid | language | message |1         | English  | Mr.     |1         | Spanish  | Sr.     |2         | English  | Doctor  |etc...

Then a query sorting by message in the local language would be like this:

select first, last, message from records r    inner join messages m on m.messageid = r.messageid    where language = [your current language]    order by message


Great question!

IMHO, you want to continue to use property files for localizing this kind of string - it allows you to use the built-in IL8N features of Java, and that saves you a lot of time.

In general, my recommendation is to store local strings for domain objects in the database - for instance, if you have a product database, and you need to store the product names, that's clearly a part of the domain; the people managing the products need to also manage the product names, and you want to be able to enforce business logic and referential integrity.

You could argue that this applies to the example you give - titles are part of the "person" domain, and should be managed in the database.

For user interface elements - the text on a button, the name of a menu item - properties files are absolutely right.

If you consider the "title" to be part of the user interface, or you don't want to move it because you have an established localization process, my recommendation is to do the sorting in Java, rather than SQL; depedning on how you connect to the database, there are plenty of ways to do that.


On application startup you could synchronize tables that contain the key, locale and actual message. These would be normal tables, so you can access them in the normal SQL queries.

But I would recommend to do the sorting you describe always in the application, because this seems really like application logic.