Why doesn't the existing entity localization work?
-Adrian
Bob Morley wrote:
In my opinion there are lots of good reasons to get the localization
information into the database. Most of my thoughts revolve around being
able to properly sort values in a dropdown, being able to properly filter
values in a dynamic grid (if a dropdown was not used), etc.
Here is a high-level proposal for evaluation --
1) Create an entity to represent the localized data in a resource bundle.
Change the start-up procedure to seed this entity from the system's resource
bundles -- this may be driven from the default-resource-name in the entity
model, or perhaps just do all resource bundles
2) Enhance the entity model to allow attributes to be marked for "database
localization" or something like that.
3) Enhance the APIs of GenericDelegator / GenericHelper to support retrieval
with locale; this would involve joining to the table from #1 for the
attributes marked in #2. It must have fallback support and best match
support for the locale.
4) Update GenericEntity "get" method to not perform resource lookup on
attributes that have been marked for database localization.
There are other issues here -- support a localized entity cache, extending
various simple method elements to support providing a locale OR just using
the context's locale, etc.
Perhaps there is not a lot of value here or someone has a much better way to
solving these problems?
Andrei Tulai wrote:
Actually, what do you guys think of moving the resource bundles to the
database. This would allow the flexibility of editing or adding new
localized values for various values that we define editable in the system.
This could be stuff like product categories or classifications. We could
also then store locales in the database, and form a hierarchy that could
allow fallback to a parent locale if the requested localized value is not
available.
I realize caching would likely be an issue that needs to be handled
specifically here.
