Localization priority stack
Locked
 
|
Hi,
We are trying to implement a way to allow users to customize descriptions in the enumeration tables. One barrier is the fact that the resource bundle takes priority over the value of the description in the database. What we would like to do is change it such that the description values in the database will initially be NULL. If this is the case, then we would pull the localized value from the resource bundle. If it is not the case, then we would use the value in the database. If we ever attempt to get something from the resource bundle and fail to find the value in the user's current locale, we would then grab the default system locale value. Now we know this would affect all the fields that are being localized at the entity level, but are wondering if anyone suspects this will affect anything else adversely. Alternatively, we could also add a new layer onto this stack that represents user preferences. And we could use this to specify custom descriptions for the user. And this would then take priority over the resource bundle. Thanks in advance, Andrei Tulai |
|
|
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. ----- Original Message ----- From: "Andrei Tulai" <[hidden email]> To: [hidden email] Sent: Friday, July 31, 2009 5:04:09 PM GMT -05:00 US/Canada Eastern Subject: Localization priority stack Hi, We are trying to implement a way to allow users to customize descriptions in the enumeration tables. One barrier is the fact that the resource bundle takes priority over the value of the description in the database. What we would like to do is change it such that the description values in the database will initially be NULL. If this is the case, then we would pull the localized value from the resource bundle. If it is not the case, then we would use the value in the database. If we ever attempt to get something from the resource bundle and fail to find the value in the user's current locale, we would then grab the default system locale value. Now we know this would affect all the fields that are being localized at the entity level, but are wondering if anyone suspects this will affect anything else adversely. Alternatively, we could also add a new layer onto this stack that represents user preferences. And we could use this to specify custom descriptions for the user. And this would then take priority over the resource bundle. Thanks in advance, Andrei Tulai |
|
|
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?
|
|
|
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. >> > |
|
|
There are two general issues with it not being database driven -- one is that you can not leverage the database's ability to sort/filter (because the localized value is not available) and the second is that the localized values are hard-coded and can not be changed by the user of the system.
I speak more to #1 in this list -- here is an example: <field name="agreementTypeId" title="${uiLabelMap.AccountingAgreementTypeId}"> <drop-down allow-empty="true"> <entity-options description="${description}" entity-name="AgreementType"/> </drop-down> </field> I think a reasonable standard practice would be to include the element "entity-order-by" in entity-options, and use the "description" field. The trouble with this approach is you would be ordering by the database description that ultimately will be replaced by the defined localized values for the AgreementType.Description attribute. To me there are two possible solutions -- one is to have the localized description available to the entity-options logic; and the second is to do some post-processing on the options to apply an application level sort (with the localized description form the GenericEntity's get method). The #2 from above is obvious; if a user in the system does not like the description of the agreement type, they can not change this without requesting an application change. For us (with multi-tenancy) this is not reasonable. I did some searching and have not found anything on this in the past ... is this because #1 is a minor annoyance and #2 is not something folks in the community would be interested in. I think we have to do this either way, but we would like to contribute it back if there is community interest / direction. Thoughts?
|
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |