I'm joining the party a bit late on this thread, but I have a few
relevant points. The commercial project I am currently using Cayenne
on exists in 14 "interface" languages and contains around 200gb of
data in any of a number of arbitrary languages.
In reality, it is important that you separate the "thing" from the
translation. This allows you to stay normalized in your data model.
For us, each translated entity has its normal table (Country,
DocumentType, etc...) and a translation table (CountryInLang,
DocumentTypeInLang, etc...). The translation tables have a compound
key with a Language table. The usage of a single but separate table
for all languages was crucial and made our lives much easier. Anything
less would have been a nightmare.
I think Adrian's suggestion of a single translation table is great. We
kept ours separate due to data management requirements. Either
approach allows for a "I18nManager" similar to what Andrus proposed.
In fact, this is effectively what we are using.
In Cayenne, each of the base objects (Country, etc) extends from a
Translatable root. The wrappers are modified to export the name of the
table that contains the translation (this step could be skipped in our
case because the table name is always *InLang). A Translator then
returns a Translation that contains a string representation of the
object and the object itself.
In either instance, the application is totally isolated from the
datastore through the Translation interface. I would not consider the
option of separate tables for each locale, though. It does not scale
well and keeps you from taking some handy shortcuts in design (for
example, our languages use the Locale 2 digit code as their pk, saving
a lot of lookup code)
One note of importance though... whatever you do, eat, breathe and die
in Unicode (UTF-8 or whatever is appropriate for you). Unless you have
to support legacy browsers / clients, its just not worth the added
cost.
And I do think its very on topic for Cayenne... the ability to
separate the DBEntity from the ObjEntity made it possible for us to
easily isolate the application from the translation logic. Most of the
other ORM tools out there did not allow for the same beautiful
solution :)
Cris
On 6/23/05, Adrian Wiesmann <awiesman..omap.org> wrote:
> > Actually translation table makes a lot of sense.
>
> I did use such concepts in quite a few projects. Making software in
> Switzerland requires you normally to at least support french and german.
> So i18n is mostly a requirement...
>
>
> > Internally it can use SQLTemplate to serve translated strings either
> > from a single global translation table or multiple tables (one per
> > locale), or any other strategy that makes sense (as SQLTemplate
> > allows table name to be a dynamic parameter). With this and a custom
> > code generation template we can create DataObjects with
> > internationalized properties. I really like this idea.
>
> I did some tests with Cayenne and never really came to an end. I must
> admit I did not do it with SQLTemplate but I tried my luck making one
> super-object as a kind of virtual representation of the object in question
> (TableGoods to stay with my example) and then writing properties to that
> super-object which are actually wrappers to the objects table and the
> translation table. Accessing the Description property gets one translation
> object with the Description of the main object. Accessing the price
> accesses the TableGoods object to get at the price value.
>
> But this does not work with DataViews which is very bad. I had then to
> start working on the TableModels as well. :)
>
> Adrian
>
This archive was generated by hypermail 2.0.0 : Thu Jun 23 2005 - 18:05:04 EDT