ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux" <jacques.le.r...@les7arts.com>
Subject Re: Multiple UiLabels definitions
Date Wed, 05 Mar 2008 07:09:39 GMT
From: "Bruno Busco" <bruno.busco@gmail.com>
> Fine,
> thank you for the explanation (why not include this in the on-line
> documentation?)

Yes true, I will write something, thanks for suggestion 

Jacques
 
> So i have moved away from the xxUiLabels file the CommonLabels already
> defined (with the same content) in the CommonUiLabels file and submitted a
> patch with the issue: https://issues.apache.org/jira/browse/OFBIZ-1691
> 
> I limited only to Common Labels because CommonUiLabels, if i have
> understood, is the "base" that should always be included.
> For a deeper action (to reduce cross-application label definition) i think
> there should be a label naming convention policy to refer to (maybe it is
> already somewhere?)
> 
> Bruno
> 
> 
> 2008/3/4, Adrian Crum <adrianc@hlmksw.com>:
>>
>> The best approach to follow will be easy to see if you understand how
>> the UI labels system works.
>>
>> The basic concept of the multiple UI label property files is this: start
>> off with the most generic, most often used labels, then build upon that
>> with application-specific labels. The CommonUiLabels.xml file contains
>> labels common to all components. The EcommerceUiLabels.xml file contains
>> labels specific to the eCommerce component. Doing things this way
>> reduces redundancy and it allows an application to redefine labels found
>> in the common (or shared) label files.
>>
>> If a specific label appears in more than one property file, it is
>> because the label is being redefined. If you find a duplicate label that
>> doesn't change anything, then that is probably an oversight. The label
>> should be removed from the application-specific property file.
>>
>> If a specific label appears in more than one property file because it is
>> redefining a label in a shared property file, then the best thing to do
>> is add the missing language to the label in the application-specific
>> property file.
>>
>> In the EcommerceYourShoppingCartEmpty label example, it probably appears
>> in more than one file so that there won't be an inter-application
>> dependency. In other words, having that label present in
>> OrderUiLabels.xml eliminates the need for the Order Manager component to
>> load/use the ECommerceUiLabels.xml file. I'm only guessing here -
>> sometimes it is hard to tell what the original intention was.
>>
>> The bottom line is, it is better to add translations to property files
>> than it is to delete labels. Deleting duplicate labels makes sense at
>> first glance, but problems could come up if there was a specific reason
>> the duplication was needed.
>>
>> -Adrian
>>
>>
>> Bruno Busco wrote:
>> > 2008/3/3, Adrian Crum <adrianc@hlmksw.com>:
>> >> Bruno Busco wrote:
>> >>> Hi,
>> >>> while testing ecommerce application i have found that selecting the
>> >> ITalian
>> >>> language, some labels are displayed still in english.
>> >>> I was convinced that this was because of a missing translation but the
>> >>> reason was a little different:
>> >>>
>> >>> Some labels are defined in more than one resource file. For example
>> >>> "CommonQuickAdd" is both in EcommerceUiLabels.xml and in
>> >>> CommonUiLabels.xmlfiles.
>> >>> But while the CommonUiLabels.xml is complete, in the
>> >>> EcommerceUiLabels.xmlfile there is no italian label.
>> >>> So what I think that could happen is that OFBiz tries to have an IT
>> >> string
>> >>> from the EcommerceUiLabels.xml file (the first one), this is not found
>> >> and
>> >>> so it falls back to what is specified in (
>> locale.properties.fallback=en)
>> >>> BEFORE checking if the IT string is present in other resource files.
>> >>>
>> >>> I tryed to delete the incomplete <property key="CommonQuickAdd">
from
>> >> the
>> >>> EcommerceUiLabels.xml and now the italian string is correctly
>> displayed
>> >>> (because no fallback).
>> >>> Also defining (locale.properties.fallback=it) it works because now,
>> even
>> >> the
>> >>> CommonUiLabels.xml is looked for an italian string.
>> >>>
>> >>> I see four options for me to solve the problem:
>> >>> 1) Add all italian strings to EcommerceUiLabels.xml even if they are
>> >> already
>> >>> present in CommonUiLabels.xml (I don't like because of redundancy)
>> >>> 2) Remove all the Common*** labels from EcommerceUiLabels.xml (any
>> >>> drawbacks?)
>> >>> 3) Change to (locale.properties.fallback=it)
>> >>
>> >> #3 will generate "resource not found" errors. In effect you would be
>> >> saying "If you can't find the IT label, then fall back to the IT
>> label."
>> >>
>> >>
>> >> -Adrian
>> >>
>> >
>> > OK. I have removed all Common* labels that are defined in
>>
>> > CommonUiLabels.xmlfile from all the other files and it seems to work
>>
>> > now.
>> > But this is not enough because for instance
>> EcommerceYourShoppingCartEmpty
>> > label is present both in ECommerceUiLabels.xml AND in OrderUiLabels.xml.
>> > Should I remove the occurrence of this label from OrderUiLabels.xml ?
>> > In other words what is the naming convention to be observed?
>> > Could I follow the rule that all the labels that starts with AppName
>> must be
>> > only defined in the AppNameUiLabels.xml file?
>> >
>> > Bruno
>> >
>>
>

Mime
View raw message