This content has been marked as final. Show 2 replies
I would share my experice here.
For the internationalization of our product, we do not have a table per locale, rather we have a row per locale in the appropriate table. We have localeCode, messageCode and messageDescription columns in that table and the application picks up the right row depending on user locale.
By default we have English data in the database. For inserting french data we run a database script which inserts same rows as English rows appended by some french characters. This is for internal testing purpose only.
In addition, we also run another translation script for creating locale specific resource bundle files and tiles files.
So, labels will come from tiles files and data/messages would come from resource bundle and database. These scripts will not be delivered to the customer. They have their own translators and its their job to provide translations at all necessary places.
After running this script we have experienced that the server takes more time to startup.
Thanks for sharing, Rahul.
I am not sure that duplicated row per locale is a good approach at least for my application usage. In my application, retrieving date is for one locale, but not all. For your approach, you need to have one fetching query statement for each locale date. And you have a row of data, the locale, in a table only is valid for one row of data, what locale the data is. That might not be a good schema design practice. But, the read and write operations are quicker than the join table approach.
I think the challenge part is various presentations (read as multi-languages) of the same entry. Otherwise, it is not difficult at all, [like this small utility multi-language web application for bookmark, directory, and reminder|http://homepage.kgbinternet.com].
Edited by: vwuvancouver on Sep 4, 2009 10:39 AM