[JBoss-user] OT: Data Internationalisation Best Practice

[Brian McSweeney]

Hi all,   This is way off JBoss as a topic, but because of the expertise in developing J2EE apps and because the xpetstore applicaiton shows off using JBoss as a J2EE server I thought I'd ask this design question here anyway. Hope that's okay.   we are looking at internationalising the xpetstore application http://xpetstore.sourceforge.net   Luckily, Herve build the application using Resource bundles for the front end, so all the JSPs can grab all the web-site's labels from the correct language Resource Bundle. Great!   However, some data that is represented in the database might not be so easy to internationalise. For example, the application is a basic webstore, so it has a product catalogue with the following database structure:                   +------------------+                 |    Category   |                    +------------------+                 |  name          |                 |  description  |                  |       etc        |                 +------------------+                            | 1                            |                            |                            | *                     +------------------+                 |    Product     |                    +------------------+                 |  name          |                 |  description  |                  |       etc        |                 +------------------+                            | 1                            |                            |                            | *                     +------------------+                 |        Item      |                    +------------------+                 |  name          |                 |  description  |                  |  list price     |                   |       etc        |                 +------------------+   Now, some of this information must obviously be displayed on the website, such as names, descriptions and prices. However they are currently entered in the database as english.   We identified two initial possiblities -   Strategy 1) Have a field in each table for each language                   +-------------------------------+                 |    Product                  |                    +-------------------------------+                 |  name_default            |                 |  name_french             |                 |  name_german           |                 |  description_default     |                  |  description_french     |                  |  description_german   |                  |       etc                      |                 +-------------------------------+   Now we can write methods to get each parameter using the Locale object eg:      getDescription(Locale loc)    Advantage - the information is still contained in the database   Disadvantage - would have to put in a field in advance for every language we would want to support. Otherwise when we come to support a new language the database would have to be re-deployed. (This is not good at all I think).   Strategy 2) Remove all the locale specific information from database and try to hold it in resource bundles.   Advantage - can add new language with same database structure, no new code.   Disadvantage - coupling the primary keys of database tables to information held in resource bundles (actually I don't even know if this would work).   Anway, this seems to highlight the difficulty of internationalising data vs. just display labels. If anyone has any suggestions or design patterns we'd love to hear about them and again sorry that this is off JBoss topic.   cheers, Brian