> 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 - 17:48:16 EDT