How can I make POJO Business Objects to be multi language?
For example I have the attribute "description". There have to be descriptions in 10 languages?
How do I do this? Is there any best practice? What about ResourceBundle? It seems a strange solution.
-
Multi Language Business Objects (4 messages)
- Posted by: Hans Schw?bli
- Posted on: October 15 2003 13:13 EDT
Threaded Messages (4)
- Multi Language Business Objects by Paul Strack on October 15 2003 17:29 EDT
- Multi Language Business Objects by Hans Schw?bli on October 16 2003 12:47 EDT
- Multi Language Business Objects by Paul Strack on October 16 2003 10:40 EDT
- Multi Language Business Objects by Hans Schw?bli on October 16 2003 12:47 EDT
- multi-language business objects by bruce goldstein on October 22 2003 17:19 EDT
-
Multi Language Business Objects[ Go to top ]
- Posted by: Paul Strack
- Posted on: October 15 2003 17:29 EDT
- in response to Hans Schw?bli
You have a ton of options here. The ResourceBundle is designed to handle text/configuration data, not application data. It is probably not your best choice. My suggestion is that you figure out how you are going to store your business object data (XML, RDMS, etc.) and build your POJOs around that.
For example, say that you are greating a "Product" POJO that represents a product in a catalog with internationalized descriptions. You can set up a PRODUCT table with generic product data (id, weight, inventory, etc.), and a LOCALIZED_PRODUCT table with localized descriptions:
PRODUCT_ID
PRODUCT_LOCALE
DESCRIPTION
[Other localized fields]
Primary Key: PRODUCT_ID, PRODUCT_LOCALE
Foreign Key: PRODUCT_ID to PRODUCT table.
Then you can create localized accessor methods like this:
Product product = Product.getProduct(id, locale);
Those are just some very rough ideas. The possibilities are endless. If your application involves any kind of currency, things get even more complex. -
Multi Language Business Objects[ Go to top ]
- Posted by: Hans Schw?bli
- Posted on: October 16 2003 12:47 EDT
- in response to Paul Strack
Maybe 40% of the Business Objects have attributes which need multi language support.
Would you create a table for each multi languag Bussiness Object or one big table for all Bussiness Objects? -
Multi Language Business Objects[ Go to top ]
- Posted by: Paul Strack
- Posted on: October 16 2003 22:40 EDT
- in response to Hans Schw?bli
Maybe 40% of the Business Objects have attributes which need multi language support.
>
> Would you create a table for each multi languag Bussiness Object or one big table for all Bussiness Objects?
It depends on the nature of the data. I might combine tables for similar business objects, or I might not. Odds are good that I would separate them, though. Never be afraid to create lots of tables in a relational database. That is what they are for.
Finally, my post above is the first thing that popped into my head based on almost no knowledge of your actual situation. Give the problem some careful thought, comparing things to the way the ResourceBundle works, and you may be able to come up with something better than my 30 second design. -
multi-language business objects[ Go to top ]
- Posted by: bruce goldstein
- Posted on: October 22 2003 17:19 EDT
- in response to Hans Schw?bli
I have the same problem on my project and here is my solution:
1. I embed a Map into each of my business objects called the languageMap.
2. I created a pair class called LanguageKey which is a locale and a text key.
3. I use JDO's capability to store Maps to store this data in one table, but this is configurable.
I write code as follows:
LanguageKey englishDisplayName = new LanguageKey("en", "displayName");
LanguageKey germanDisplayName = new LanguageKey("de", "displayName");
Business Object bo = ...
bo.getLanguageMap().put(englishDisplayName, some text);
bo.getLanguageMap().put(germanDisplayName, some text);
Pros:
1. I can store name-value pairs for any language and I can change which names I store at runtime (also which languages).
Tables could look like:
BusinessObject
id
...
LanguageData
id
business_object_id
locale
key
value
Note that this assumes that ids are unique for all tables. You could also store the table name to descriminate if ids were only unique to a table.
Hope this helps.
Bruce