Andrus Adamchik <andru..bjectstyle.org> wrote:
> Forgot to mention ... One idea is to use "wide" tables with each
> i18ned column "multiplied" for each supported Locale. E.g. you'd have
> my_table.name, my_table.name_de, my_table.name_fr and so on.
>
> Then you can deploy your application using multiple Cayenne
> DataDomains, one domain per supported Locale. All domains will have
> the same exact object model, but mapped differently to a database
> layer. So a "name" Java object property will be mapped to different
> column in each domain. This scenario would lock a user to a
> particular Locale on the session creation by making a DataContext
> with a Locale specific DataDomain.
>
> And then you can have an admin application that has same entities
> mapped with all i18ned columns included, so that administrator could
> enter data in multiple languages.
I would think it would be easier to have a separate table for each Locale.
ie, My_table, my_table_de, my_table_fr.
Then in order to add a new localization, you just clone and translate the
table data.
To change the localization, you just change the table name.
It seems unlikely that the adminstrator can enter data in multiple languages
all at once,
but if you did want to do it this way, software could handle it.
I haven't done localization, but I've provided "customization" for my
clients where they can change what text is displayed for a given message
tags. In practice, it's almost the same thing, except there's only a
single language supported.
My implementation can no doubt be improved, but I have these columns:
Lookup Key, arg0, ...arg9, and returned value.
arg0 through arg9 are only there as hints to the data input person
Ie,
Key = message.UserDeletedSomething
arg0 = User doing the deletion
arg1 = The thing being deleted
returned value = %0 has deleted %1.
-Mike
This archive was generated by hypermail 2.0.0 : Thu Jun 23 2005 - 11:48:54 EDT