Re: Localization priority stack

[Andrei Tulai <at...@emforium.com>]

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" <at...@emforium.com>
To: dev@ofbiz.apache.org
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

Re: Localization priority stack

[Bob Morley <rm...@emforium.com>]

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?


Adrian Crum wrote:
> 
> 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.
>>>
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Localization-priority-stack-tp24763078p24850919.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Localization priority stack

[Adrian Crum <ad...@hlmksw.com>]

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.
>>
> 

Re: Localization priority stack

[Bob Morley <rm...@emforium.com>]

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.
> 

-- 
View this message in context: http://www.nabble.com/Localization-priority-stack-tp24763078p24849922.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.