Andrus Adamchik <andru..bjectstyle.org> wrote:
> As you correctly noticed, there is no special support for attribute
> localizing in Cayenne. And your suggestion for the possible solution
> seems very reasonable. So I'd like to add this idea to Cayenne roadmap.
> Until this gets implemented, I guess localization can be done at the
> DataObject level by manually creating locale-aware "delegating"
> getters.
>
> As I personally don't have much experience in working with localized
> database schemas, I wonder how many people actually care about
> localized DB data (just to prioritize this I guess)? I can see how it
> can be useful for "configuration" tables used to build app labels,
> dropdowns, and such. Still most "dynamic" data is probably entered in
> just one language for each record, no matter how many total languages
> application supports.
I'd think that localization would be handled outside of the database level
as well as by one record per language entry. (or even one table per
language)
In my limited localization experience, I simply look up the appropriate
message by the message key and "language" attribute.
ie,
message_key
locale
description
SELECT description FROM localization_table WHERE locale = 'en' AND
message_key = 'error.required'
--or--
message_key
description
SELECT description FROM localization_table_EN WHERE message_key =
'error.required'
Overriding the methods in the child class are exactly how I believe that
this should be done.
public void getDescription()
{
super getDescription(Locale.getDefault());
}
public void getDescription(Locale locale)
{
// query to get the correct record here
}
Using a separate file for each localization/language is how Struts appears
to handle file-based localization.
By keeping each localization separate, you have the ability to outsource the
generation of any particular localization.
Not only do you lose that separation with a one-record-for-all-Locale
methodology, but you have to change your database schema each time you add a
new locale instead of just creating a new table.
-Mike
> On Jul 31, 2004, at 2:55 PM, nirvdru..egativetwenty.net wrote:
> > Hi,
> >
> > I was wondering what solutions people were using for localizing
> > particular
> > attributes for a given relation. I was hoping Cayenne had some
> > transparent support for doing so, but I haven't been able to find any.
> >
> > Thinking out loud, this would add a new option to the ObjectModeler,
> > and
> > from there you could a) mark an attribute as localizable, b) specify
> > the
> > default locale and c) indicate which additional locales columns should
> > be
> > created for (the new columns would take the default name and append the
> > locale identifier, as Java does with property files).
> >
> > The generated base classes would then retrieve the value from the
> > correct
> > column based upon the current locale. It could have an additional
> > method
> > that takes in a specific locale as well.
> >
> > The basic idea being that if I have a field named "description", and
> > provide different values for english, french, and german, I still make
> > the
> > call to getDescription() (or getDescription(locale)). This way, the
> > actual column names are mostly transparent.
> >
> > Anyone else have any thoughts on this? Is there a way of doing such
> > already (other than overriding & overloading methods in the child
> > class)?
This archive was generated by hypermail 2.0.0 : Tue Aug 24 2004 - 16:43:19 EDT