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. :)
It almost sounds like this could be represented with vertical inheritance
once VI has been implemented.
But maybe I'm misunderstanding it.
-Mike
This archive was generated by hypermail 2.0.0 : Thu Jun 23 2005 - 17:56:00 EDT