+----------------------------+ | product | +----------------------------+ | product_key number pk | | name_i18n_id number | | desc_i18n_id number | +----------------------------+ | sequence: product_key | +----------------------------+
|
V+----------------------------------------+ | i18n_text | +----------------------------------------+ | i18n_key number pk | | i18n_id number | | locale varchar(5) | | value varchar | +----------------------------------------+ | sequence: i18n_key | | contstraint: i18n_id + locale = unique | +----------------------------------------+
example data:
product
=======
product_key name_i18n_id desc_i18n_id
-------------------------------------------
25 41 42
i18n_text ============ i18n_key i18n_id locale value ------------------------------------------- 1 1 en yes 2 1 es sí 179 41 en example product 180 41 es producto del ejemplo 181 42 en very easy to use 182 42 en_US freakin' easy to use 183 42 es muy fácil utilizar
DB note:
========
Unless you only care about Western/European languages, I suggest you *install* your database as Unicode, UTF-8. You will then be able to support Japanese, Simplified Chinese, etc.
Possible Code:
==============
You could either do the CMR's to pull the strings for the value objects, or you could have a singleton, caching I18NTextFactory that returns I18NText objects that maintain the Locale->String mappings.
Maybe:
ProductValue.java
-----------------
public long getDescriptionId() {
return mDescriptionId;
}
public String getDescription(Locale pLocale) {
if (mDescriptionText == null) {
mDescriptionText =
I18NTextFactory.getInstance().getText(mDescriptionId);
}
return mDescriptionText.getValue(pLocale);
}
private I18NText mDescriptionText = null;
productPage.jsp ===============
<%= productValue.getDescription( pRequest.getLocale() ) %>
Let me know how you decide to do it as i18n is very interesting to me.
Thanks, David
Brian McSweeney escribió::
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
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
