Menu
▾
▴
Re: [JBoss-user] OT: Data Internationalisation Best Practice
|
From: David W. <dav...@do...> - 2003-03-24 16:09:35
|
(Sending this again as my first reply somehow didn't appear to make it...=
)
Maybe you could do something like this:
+----------------------------+
| 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 =3D unique |
+----------------------------------------+
example data:
product
=3D=3D=3D=3D=3D=3D=3D
product_key name_i18n_id desc_i18n_id
-------------------------------------------
25 41 42
i18n_text
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
i18n_key i18n_id locale value
-------------------------------------------
1 1 en yes
2 1 es s=ED
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=E1cil utilizar
DB note:
=3D=3D=3D=3D=3D=3D=3D=3D
Unless you only care about Western/European languages, I suggest you=20
*install* your database as Unicode, UTF-8. You will then be able to=20
support Japanese, Simplified Chinese, etc.
Possible Code:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
You could either do the CMR's to pull the strings for the value objects,=20
or you could have a singleton, caching I18NTextFactory that returns=20
I18NText objects that maintain the Locale->String mappings.
Maybe:
ProductValue.java
-----------------
public long getDescriptionId() {
return mDescriptionId;
}
public String getDescription(Locale pLocale) {
if (mDescriptionText =3D=3D null) {
mDescriptionText =3D
I18NTextFactory.getInstance().getText(mDescriptionId);
}
return mDescriptionText.getValue(pLocale);
}
private I18NText mDescriptionText =3D null;
productPage.jsp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<%=3D productValue.getDescription( request.getLocale() ) %>
Let me know how you decide to do it as i18n is very interesting to me.
Thanks,
David
Brian McSweeney escribi=F3::
> Hi all,
> =20
> 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.
> =20
> we are looking at internationalising the
> xpetstore application http://xpetstore.sourceforge.net
> =20
> 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!
> =20
> 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:
> =20
> +------------------+
> | Category | =20
> +------------------+
> | name |
> | description |=20
> | etc |
> +------------------+
> | 1
> |
> |
> | * =20
> +------------------+
> | Product | =20
> +------------------+
> | name |
> | description |=20
> | etc |
> +------------------+
> | 1
> |
> |
> | * =20
> +------------------+
> | Item | =20
> +------------------+
> | name |
> | description |=20
> | list price | =20
> | etc |
> +------------------+
> =20
> 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.
> =20
> We identified two initial possiblities -
> =20
> Strategy 1)
> Have a field in each table for each language
> =20
> +-------------------------------+
> | Product | =20
> +-------------------------------+
> | name_default |
> | name_french |
> | name_german |
> | description_default |=20
> | description_french |=20
> | description_german |=20
> | etc |
> +-------------------------------+
> =20
> Now we can write methods to get each parameter using the
> Locale object eg: =20
> =20
> getDescription(Locale loc)=20
> =20
> Advantage - the information is still contained in the database
> =20
> 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).
> =20
> Strategy 2)
> Remove all the locale specific information from database and try
> to hold it in resource bundles.
> =20
> Advantage - can add new language with same database structure,
> no new code.
> =20
> Disadvantage - coupling the primary keys of database tables to informat=
ion
> held in resource bundles (actually I don't even know if this would work=
).
> =20
> Anway, this seems to highlight the difficulty of internationalising dat=
a=20
> 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 top=
ic.
> =20
> cheers,
> Brian
|