Re: About issue: Clean up labels between order and ecommerce application (OFBIZ-1780)

[Jacques Le Roux]

Hi Marco, all,

I would recommend everybody interested to check for his/her language. So far it seems that the lost concerns more english and
french. I will commit soon some labels back concerning this 2 languages when losts were obvious. Nevertheless Marco did a great job
and I think we should keep his work as there is only few lost labels. A way I recommend to check is to have a look at the diffs like
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/config/OrderUiLabels.xml?view=diff&r1=657465&r2=657466&pathrev=657466

Then you may appreciate the work done so far by Marco... I think though that we should wait before continuing that everybody has
taken the time to check and moreover I propose we consider to use Bruno proposition before going ahead on this.

For more information please see https://issues.apache.org/jira/browse/OFBIZ-1780 and
https://issues.apache.org/jira/browse/OFBIZ-1698

Thanks

Jacques

From: <[hidden email]>

> Hi to all,
>
> I put the attention on this issue at OFBiz community level to take a decision on how we can proceed on it.
>
> Before I start to clean the labels between Order and Ecommerce application there was a lot of confusion done in the past after the
> conversion from property languages files to xml files.
>
> I spent one week to work on it and it was not my intention to create issues to anyone.
>
> I have simply merges the languages strings in the higher priority file (EcommerceXXX) and deletes the entry from the lower
> priority file (OrderXXX).
> So when I have found double definition for me the good one was in the EcommerceUiLabels.xml  but as you can imagine I cannot
> understand all the languages I cannot see those differences.
>
> So seems that merging by keys is not valid for all the languages and it can cause lost of correct translations.
>
> Another important things I have done I have checked every single labels scanning the sources and move from Ecommerce to Order xml
> file if the labels was shared and in this case I have also renamed the label from EcommerceXXX to OrderXXX and all the references
> to those labels.
>
> I have seen that for Italian language seems to me better than previously but probably not for French language.
>
> This cleaning task is not still completed because now there are some OrderXXX labels duplicated into both files and we have to
> decide which has the correct traslations in case of duplication.
> Seems to me that OrderUiLabels.xml file is the correct one and EcommerceUiLabels.xml files is the wrong one for OrderXXX labels
> but I didn't know if we have some exception for fr and th languages.
>
> So I would like to know from the community if it's the right direction (and continue the cleaning of labels) or I have to revert
> back everything because I do not want to do something by myself not accepted by OFBiz community.
>
> Thanks
> Marco
>
>
>

[Jacques Le Roux]

I guess the main reason for french labels is that the previous work concerning eCommerce and Order has been very poorly done
regarding architectecture (on the other hand most of the translation was well done). Some labels were defined only in Order though
those labels were existing (already at the time done?) in eCommerce. Since recently a person helps me to add/fix some french labels
in OFBiz, this person has added "new" labels in eCommerce despite they were already defined in Order (but we were not aware). It
turns that some labels previously defined were better translated and I prefer to keep them. So it's maybe only an issue for french
labels (though I found few english labels lost also and I put them back too). So for other languages I suggest to only throw a quick
glance, at 1st sight they seemed good...

So it was not an overriden issue as I supposed before, and Marco was right as eCommerce labels can't be overidden by Orders's due to
labels hierarchy.

HTH, sorry to annoy everybody with this..

Jacques

From: "Jacques Le Roux" <[hidden email]>

> Hi Marco, all,
>
> I would recommend everybody interested to check for his/her language. So far it seems that the lost concerns more english and
> french. I will commit soon some labels back concerning this 2 languages when losts were obvious. Nevertheless Marco did a great
> job and I think we should keep his work as there is only few lost labels. A way I recommend to check is to have a look at the
> diffs like
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/config/OrderUiLabels.xml?view=diff&r1=657465&r2=657466&pathrev=657466
>
> Then you may appreciate the work done so far by Marco... I think though that we should wait before continuing that everybody has
> taken the time to check and moreover I propose we consider to use Bruno proposition before going ahead on this.
>
> For more information please see https://issues.apache.org/jira/browse/OFBIZ-1780 and
> https://issues.apache.org/jira/browse/OFBIZ-1698
>
> Thanks
>
> Jacques
>
> From: <[hidden email]>
>> Hi to all,
>>
>> I put the attention on this issue at OFBiz community level to take a decision on how we can proceed on it.
>>
>> Before I start to clean the labels between Order and Ecommerce application there was a lot of confusion done in the past after
>> the conversion from property languages files to xml files.
>>
>> I spent one week to work on it and it was not my intention to create issues to anyone.
>>
>> I have simply merges the languages strings in the higher priority file (EcommerceXXX) and deletes the entry from the lower
>> priority file (OrderXXX).
>> So when I have found double definition for me the good one was in the EcommerceUiLabels.xml  but as you can imagine I cannot
>> understand all the languages I cannot see those differences.
>>
>> So seems that merging by keys is not valid for all the languages and it can cause lost of correct translations.
>>
>> Another important things I have done I have checked every single labels scanning the sources and move from Ecommerce to Order xml
>> file if the labels was shared and in this case I have also renamed the label from EcommerceXXX to OrderXXX and all the references
>> to those labels.
>>
>> I have seen that for Italian language seems to me better than previously but probably not for French language.
>>
>> This cleaning task is not still completed because now there are some OrderXXX labels duplicated into both files and we have to
>> decide which has the correct traslations in case of duplication.
>> Seems to me that OrderUiLabels.xml file is the correct one and EcommerceUiLabels.xml files is the wrong one for OrderXXX labels
>> but I didn't know if we have some exception for fr and th languages.
>>
>> So I would like to know from the community if it's the right direction (and continue the cleaning of labels) or I have to revert
>> back everything because I do not want to do something by myself not accepted by OFBiz community.
>>
>> Thanks
>> Marco
>>
>>
>>
>

[Bruno Busco]

I think that in order to keep things simple and maintaneable we should avoid
that a label is overwritten in two different UiLabels files to have a
different and more specific text.
If we do like this it will be an easy job to automatically check for label
duplication.

Otherwise it will happen that someone could override the label in his own
language having all other languages remaining untouched and so looking as a
full duplication.

Whenever a slightly different label (or a more detailed one) is needed, a
different label must be defined.

Even the Python script contained in
https://issues.apache.org/jira/browse/OFBIZ-1698 does not check that a
duplicated label is exactly the same in all its language texts; it simply
assumes that is a duplicated label and just tryes to collect all available
language strings before removing the duplication.

- Bruno

2008/5/19 Jacques Le Roux <[hidden email]>:

> I guess the main reason for french labels is that the previous work
> concerning eCommerce and Order has been very poorly done regarding
> architectecture (on the other hand most of the translation was well done).
> Some labels were defined only in Order though those labels were existing
> (already at the time done?) in eCommerce. Since recently a person helps me
> to add/fix some french labels in OFBiz, this person has added "new" labels
> in eCommerce despite they were already defined in Order (but we were not
> aware). It turns that some labels previously defined were better translated
> and I prefer to keep them. So it's maybe only an issue for french labels
> (though I found few english labels lost also and I put them back too). So
> for other languages I suggest to only throw a quick glance, at 1st sight
> they seemed good...
>
> So it was not an overriden issue as I supposed before, and Marco was right
> as eCommerce labels can't be overidden by Orders's due to labels hierarchy.
>
> HTH, sorry to annoy everybody with this..
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>
>  Hi Marco, all,
>>
>> I would recommend everybody interested to check for his/her language. So
>> far it seems that the lost concerns more english and french. I will commit
>> soon some labels back concerning this 2 languages when losts were obvious.
>> Nevertheless Marco did a great job and I think we should keep his work as
>> there is only few lost labels. A way I recommend to check is to have a look
>> at the diffs like
>>
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/config/OrderUiLabels.xml?view=diff&r1=657465&r2=657466&pathrev=657466
>>
>> Then you may appreciate the work done so far by Marco... I think though
>> that we should wait before continuing that everybody has taken the time to
>> check and moreover I propose we consider to use Bruno proposition before
>> going ahead on this.
>>
>> For more information please see
>> https://issues.apache.org/jira/browse/OFBIZ-1780 and
>> https://issues.apache.org/jira/browse/OFBIZ-1698
>>
>> Thanks
>>
>> Jacques
>>
>> From: <[hidden email]>
>>
>>> Hi to all,
>>>
>>> I put the attention on this issue at OFBiz community level to take a
>>> decision on how we can proceed on it.
>>>
>>> Before I start to clean the labels between Order and Ecommerce
>>> application there was a lot of confusion done in the past after the
>>> conversion from property languages files to xml files.
>>>
>>> I spent one week to work on it and it was not my intention to create
>>> issues to anyone.
>>>
>>> I have simply merges the languages strings in the higher priority file
>>> (EcommerceXXX) and deletes the entry from the lower priority file
>>> (OrderXXX).
>>> So when I have found double definition for me the good one was in the
>>> EcommerceUiLabels.xml  but as you can imagine I cannot understand all the
>>> languages I cannot see those differences.
>>>
>>> So seems that merging by keys is not valid for all the languages and it
>>> can cause lost of correct translations.
>>>
>>> Another important things I have done I have checked every single labels
>>> scanning the sources and move from Ecommerce to Order xml file if the labels
>>> was shared and in this case I have also renamed the label from EcommerceXXX
>>> to OrderXXX and all the references to those labels.
>>>
>>> I have seen that for Italian language seems to me better than previously
>>> but probably not for French language.
>>>
>>> This cleaning task is not still completed because now there are some
>>> OrderXXX labels duplicated into both files and we have to decide which has
>>> the correct traslations in case of duplication.
>>> Seems to me that OrderUiLabels.xml file is the correct one and
>>> EcommerceUiLabels.xml files is the wrong one for OrderXXX labels but I
>>> didn't know if we have some exception for fr and th languages.
>>>
>>> So I would like to know from the community if it's the right direction
>>> (and continue the cleaning of labels) or I have to revert back everything
>>> because I do not want to do something by myself not accepted by OFBiz
>>> community.
>>>
>>> Thanks
>>> Marco
>>>
>>>
>>>
>>>
>>
>

[Jacques Le Roux]

From: "Bruno Busco" <[hidden email]>
>I think that in order to keep things simple and maintaneable we should avoid
> that a label is overwritten in two different UiLabels files to have a
> different and more specific text.
> If we do like this it will be an easy job to automatically check for label
> duplication.

+1000, I totally agree : simple is beautiful. We don't need complexity at this level. Or someone has to explain me why...

> Otherwise it will happen that someone could override the label in his own
> language having all other languages remaining untouched and so looking as a
> full duplication.

Yup !

> Whenever a slightly different label (or a more detailed one) is needed, a
> different label must be defined.

+1

> Even the Python script contained in
> https://issues.apache.org/jira/browse/OFBIZ-1698 does not check that a
> duplicated label is exactly the same in all its language texts; it simply
> assumes that is a duplicated label and just tryes to collect all available
> language strings before removing the duplication.

Yes, it would be difficult and error prone to create a script for that. We just need to skim and make the remaining by hand. I
should do it this week (I really want to get rid of all that, it's a real mess)

Jacques

> - Bruno
>
> 2008/5/19 Jacques Le Roux <[hidden email]>:
>
>> I guess the main reason for french labels is that the previous work
>> concerning eCommerce and Order has been very poorly done regarding
>> architectecture (on the other hand most of the translation was well done).
>> Some labels were defined only in Order though those labels were existing
>> (already at the time done?) in eCommerce. Since recently a person helps me
>> to add/fix some french labels in OFBiz, this person has added "new" labels
>> in eCommerce despite they were already defined in Order (but we were not
>> aware). It turns that some labels previously defined were better translated
>> and I prefer to keep them. So it's maybe only an issue for french labels
>> (though I found few english labels lost also and I put them back too). So
>> for other languages I suggest to only throw a quick glance, at 1st sight
>> they seemed good...
>>
>> So it was not an overriden issue as I supposed before, and Marco was right
>> as eCommerce labels can't be overidden by Orders's due to labels hierarchy.
>>
>> HTH, sorry to annoy everybody with this..
>>
>> Jacques
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>
>>  Hi Marco, all,
>>>
>>> I would recommend everybody interested to check for his/her language. So
>>> far it seems that the lost concerns more english and french. I will commit
>>> soon some labels back concerning this 2 languages when losts were obvious.
>>> Nevertheless Marco did a great job and I think we should keep his work as
>>> there is only few lost labels. A way I recommend to check is to have a look
>>> at the diffs like
>>>
>>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/config/OrderUiLabels.xml?view=diff&r1=657465&r2=657466&pathrev=657466
>>>
>>> Then you may appreciate the work done so far by Marco... I think though
>>> that we should wait before continuing that everybody has taken the time to
>>> check and moreover I propose we consider to use Bruno proposition before
>>> going ahead on this.
>>>
>>> For more information please see
>>> https://issues.apache.org/jira/browse/OFBIZ-1780 and
>>> https://issues.apache.org/jira/browse/OFBIZ-1698
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>> From: <[hidden email]>
>>>
>>>> Hi to all,
>>>>
>>>> I put the attention on this issue at OFBiz community level to take a
>>>> decision on how we can proceed on it.
>>>>
>>>> Before I start to clean the labels between Order and Ecommerce
>>>> application there was a lot of confusion done in the past after the
>>>> conversion from property languages files to xml files.
>>>>
>>>> I spent one week to work on it and it was not my intention to create
>>>> issues to anyone.
>>>>
>>>> I have simply merges the languages strings in the higher priority file
>>>> (EcommerceXXX) and deletes the entry from the lower priority file
>>>> (OrderXXX).
>>>> So when I have found double definition for me the good one was in the
>>>> EcommerceUiLabels.xml  but as you can imagine I cannot understand all the
>>>> languages I cannot see those differences.
>>>>
>>>> So seems that merging by keys is not valid for all the languages and it
>>>> can cause lost of correct translations.
>>>>
>>>> Another important things I have done I have checked every single labels
>>>> scanning the sources and move from Ecommerce to Order xml file if the labels
>>>> was shared and in this case I have also renamed the label from EcommerceXXX
>>>> to OrderXXX and all the references to those labels.
>>>>
>>>> I have seen that for Italian language seems to me better than previously
>>>> but probably not for French language.
>>>>
>>>> This cleaning task is not still completed because now there are some
>>>> OrderXXX labels duplicated into both files and we have to decide which has
>>>> the correct traslations in case of duplication.
>>>> Seems to me that OrderUiLabels.xml file is the correct one and
>>>> EcommerceUiLabels.xml files is the wrong one for OrderXXX labels but I
>>>> didn't know if we have some exception for fr and th languages.
>>>>
>>>> So I would like to know from the community if it's the right direction
>>>> (and continue the cleaning of labels) or I have to revert back everything
>>>> because I do not want to do something by myself not accepted by OFBiz
>>>> community.
>>>>
>>>> Thanks
>>>> Marco
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

[Adrian Crum]

Jacques Le Roux wrote:

> From: "Bruno Busco" <[hidden email]>
>> I think that in order to keep things simple and maintaneable we should
>> avoid
>> that a label is overwritten in two different UiLabels files to have a
>> different and more specific text.
>> If we do like this it will be an easy job to automatically check for
>> label
>> duplication.
>
> +1000, I totally agree : simple is beautiful. We don't need complexity
> at this level. Or someone has to explain me why...

A good example is the Asset Maintenance component - which reuses screens
from the Accounting component, but changes some terminology so that it
makes more sense to a maintenance person. In that case, the UI labels
used in the Accounting component screens are redefined in Asset Maintenance.

-Adrian

[Bruno Busco]

Adrian,
thank you, now I see what the label overriding is used for !

In this case I would suggest to have all the overriding labels to be
contained in a specific UiLabel file (that could for example be called
_AppName_OverrideUiLabels.xml).
This could be a standard method to be used in every case a label must be
overridden.

In the Asset Maintenance component there will be a AssetMaintUiLabels.xml
file that will define all NEW labels for the component (no duplication is
admitted here) and a AssetMaintOverrideUiLabels.xml file with all overridden
labels (all label must be duplication of existing ones here).

May be this solve our problem.

-Bruno


2008/5/19 Adrian Crum <[hidden email]>:

> Jacques Le Roux wrote:
>
>> From: "Bruno Busco" <[hidden email]>
>>
>>> I think that in order to keep things simple and maintaneable we should
>>> avoid
>>> that a label is overwritten in two different UiLabels files to have a
>>> different and more specific text.
>>> If we do like this it will be an easy job to automatically check for
>>> label
>>> duplication.
>>>
>>
>> +1000, I totally agree : simple is beautiful. We don't need complexity at
>> this level. Or someone has to explain me why...
>>
>
> A good example is the Asset Maintenance component - which reuses screens
> from the Accounting component, but changes some terminology so that it makes
> more sense to a maintenance person. In that case, the UI labels used in the
> Accounting component screens are redefined in Asset Maintenance.
>
> -Adrian
>

[Adrian Crum]

Or maybe we could assume the components in the specialpurpose folder
intend to override labels and just ignore those UI label files.

-Adrian

Bruno Busco wrote:

> Adrian,
> thank you, now I see what the label overriding is used for !
>
> In this case I would suggest to have all the overriding labels to be
> contained in a specific UiLabel file (that could for example be called
> _AppName_OverrideUiLabels.xml).
> This could be a standard method to be used in every case a label must be
> overridden.
>
> In the Asset Maintenance component there will be a AssetMaintUiLabels.xml
> file that will define all NEW labels for the component (no duplication is
> admitted here) and a AssetMaintOverrideUiLabels.xml file with all overridden
> labels (all label must be duplication of existing ones here).
>
> May be this solve our problem.
>
> -Bruno
>
>
> 2008/5/19 Adrian Crum <[hidden email]>:
>
>> Jacques Le Roux wrote:
>>
>>> From: "Bruno Busco" <[hidden email]>
>>>
>>>> I think that in order to keep things simple and maintaneable we should
>>>> avoid
>>>> that a label is overwritten in two different UiLabels files to have a
>>>> different and more specific text.
>>>> If we do like this it will be an easy job to automatically check for
>>>> label
>>>> duplication.
>>>>
>>> +1000, I totally agree : simple is beautiful. We don't need complexity at
>>> this level. Or someone has to explain me why...
>>>
>> A good example is the Asset Maintenance component - which reuses screens
>> from the Accounting component, but changes some terminology so that it makes
>> more sense to a maintenance person. In that case, the UI labels used in the
>> Accounting component screens are redefined in Asset Maintenance.
>>
>> -Adrian
>>
>

[David E Jones]

On May 19, 2008, at 8:56 AM, Adrian Crum wrote:

> Jacques Le Roux wrote:
>> From: "Bruno Busco" <[hidden email]>
>>> I think that in order to keep things simple and maintaneable we  
>>> should avoid
>>> that a label is overwritten in two different UiLabels files to  
>>> have a
>>> different and more specific text.
>>> If we do like this it will be an easy job to automatically check  
>>> for label
>>> duplication.
>> +1000, I totally agree : simple is beautiful. We don't need  
>> complexity at this level. Or someone has to explain me why...
>
> A good example is the Asset Maintenance component - which reuses  
> screens from the Accounting component, but changes some terminology  
> so that it makes more sense to a maintenance person. In that case,  
> the UI labels used in the Accounting component screens are redefined  
> in Asset Maintenance.

This is an interesting use of label overriding, but I'm not sure I  
like it... If the meaning of some text somewhere is different from the  
meaning implied by the previously used label then my preference would  
be to see a different label.

The labels are really meant for enabling translation and not so much  
for overriding text. They can certainly be used that way, but if it  
obfuscates meaning them over time it may make things more difficult to  
understand and maintain.

That's just my thought though... either way I don't want to see us  
paint ourselves into a corner with something like this.

-David

[Adrian Crum]

David,

I agree with you. I'm not the original author of that code, so I don't
know what the original intent was. My reply was based on some of the
work I've done updating the Asset Maintenance component.

-Adrian

David E Jones wrote:

>
> On May 19, 2008, at 8:56 AM, Adrian Crum wrote:
>
>> Jacques Le Roux wrote:
>>> From: "Bruno Busco" <[hidden email]>
>>>> I think that in order to keep things simple and maintaneable we
>>>> should avoid
>>>> that a label is overwritten in two different UiLabels files to have a
>>>> different and more specific text.
>>>> If we do like this it will be an easy job to automatically check for
>>>> label
>>>> duplication.
>>> +1000, I totally agree : simple is beautiful. We don't need
>>> complexity at this level. Or someone has to explain me why...
>>
>> A good example is the Asset Maintenance component - which reuses
>> screens from the Accounting component, but changes some terminology so
>> that it makes more sense to a maintenance person. In that case, the UI
>> labels used in the Accounting component screens are redefined in Asset
>> Maintenance.
>
> This is an interesting use of label overriding, but I'm not sure I like
> it... If the meaning of some text somewhere is different from the
> meaning implied by the previously used label then my preference would be
> to see a different label.
>
> The labels are really meant for enabling translation and not so much for
> overriding text. They can certainly be used that way, but if it
> obfuscates meaning them over time it may make things more difficult to
> understand and maintain.
>
> That's just my thought though... either way I don't want to see us paint
> ourselves into a corner with something like this.
>
> -David
>
>

[Jacques Le Roux]

Thanks for the explanation Adrian,

Yes, this seems a simple way of doing it

Jacques

From: "Adrian Crum" <[hidden email]>

> Or maybe we could assume the components in the specialpurpose folder
> intend to override labels and just ignore those UI label files.
>
> -Adrian
>
> Bruno Busco wrote:
>> Adrian,
>> thank you, now I see what the label overriding is used for !
>>
>> In this case I would suggest to have all the overriding labels to be
>> contained in a specific UiLabel file (that could for example be called
>> _AppName_OverrideUiLabels.xml).
>> This could be a standard method to be used in every case a label must be
>> overridden.
>>
>> In the Asset Maintenance component there will be a AssetMaintUiLabels.xml
>> file that will define all NEW labels for the component (no duplication is
>> admitted here) and a AssetMaintOverrideUiLabels.xml file with all overridden
>> labels (all label must be duplication of existing ones here).
>>
>> May be this solve our problem.
>>
>> -Bruno
>>
>>
>> 2008/5/19 Adrian Crum <[hidden email]>:
>>
>>> Jacques Le Roux wrote:
>>>
>>>> From: "Bruno Busco" <[hidden email]>
>>>>
>>>>> I think that in order to keep things simple and maintaneable we should
>>>>> avoid
>>>>> that a label is overwritten in two different UiLabels files to have a
>>>>> different and more specific text.
>>>>> If we do like this it will be an easy job to automatically check for
>>>>> label
>>>>> duplication.
>>>>>
>>>> +1000, I totally agree : simple is beautiful. We don't need complexity at
>>>> this level. Or someone has to explain me why...
>>>>
>>> A good example is the Asset Maintenance component - which reuses screens
>>> from the Accounting component, but changes some terminology so that it makes
>>> more sense to a maintenance person. In that case, the UI labels used in the
>>> Accounting component screens are redefined in Asset Maintenance.
>>>
>>> -Adrian
>>>
>>
>

[Jacques Le Roux]

Of course we should also not allow this overriding mechanism in main applications (ie non hot-deploy and specialpurpose) as
suggested Bruno

If someone disagree please explain...

Jacques

From: "Jacques Le Roux" <[hidden email]>

> Thanks for the explanation Adrian,
>
> Yes, this seems a simple way of doing it
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>> Or maybe we could assume the components in the specialpurpose folder intend to override labels and just ignore those UI label
>> files.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>> Adrian,
>>> thank you, now I see what the label overriding is used for !
>>>
>>> In this case I would suggest to have all the overriding labels to be
>>> contained in a specific UiLabel file (that could for example be called
>>> _AppName_OverrideUiLabels.xml).
>>> This could be a standard method to be used in every case a label must be
>>> overridden.
>>>
>>> In the Asset Maintenance component there will be a AssetMaintUiLabels.xml
>>> file that will define all NEW labels for the component (no duplication is
>>> admitted here) and a AssetMaintOverrideUiLabels.xml file with all overridden
>>> labels (all label must be duplication of existing ones here).
>>>
>>> May be this solve our problem.
>>>
>>> -Bruno
>>>
>>>
>>> 2008/5/19 Adrian Crum <[hidden email]>:
>>>
>>>> Jacques Le Roux wrote:
>>>>
>>>>> From: "Bruno Busco" <[hidden email]>
>>>>>
>>>>>> I think that in order to keep things simple and maintaneable we should
>>>>>> avoid
>>>>>> that a label is overwritten in two different UiLabels files to have a
>>>>>> different and more specific text.
>>>>>> If we do like this it will be an easy job to automatically check for
>>>>>> label
>>>>>> duplication.
>>>>>>
>>>>> +1000, I totally agree : simple is beautiful. We don't need complexity at
>>>>> this level. Or someone has to explain me why...
>>>>>
>>>> A good example is the Asset Maintenance component - which reuses screens
>>>> from the Accounting component, but changes some terminology so that it makes
>>>> more sense to a maintenance person. In that case, the UI labels used in the
>>>> Accounting component screens are redefined in Asset Maintenance.
>>>>
>>>> -Adrian
>>>>
>>>
>>

[Jacques Le Roux]

I can't agree more. However this creative way of using labels is interesting. Else we will have to create a new way for transversal
reuse of forms if labels have to be changed...

I thought we should keep this discussion in dev ML, but maybe it's better to let a chance to everybody to be aware...

Jacques

From: "David E Jones" <[hidden email]>

> On May 19, 2008, at 8:56 AM, Adrian Crum wrote:
>
>> Jacques Le Roux wrote:
>>> From: "Bruno Busco" <[hidden email]>
>>>> I think that in order to keep things simple and maintaneable we  should avoid
>>>> that a label is overwritten in two different UiLabels files to  have a
>>>> different and more specific text.
>>>> If we do like this it will be an easy job to automatically check  for label
>>>> duplication.
>>> +1000, I totally agree : simple is beautiful. We don't need  complexity at this level. Or someone has to explain me why...
>>
>> A good example is the Asset Maintenance component - which reuses  screens from the Accounting component, but changes some
>> terminology  so that it makes more sense to a maintenance person. In that case,  the UI labels used in the Accounting component
>> screens are redefined  in Asset Maintenance.
>
> This is an interesting use of label overriding, but I'm not sure I  like it... If the meaning of some text somewhere is different
> from the  meaning implied by the previously used label then my preference would  be to see a different label.
>
> The labels are really meant for enabling translation and not so much  for overriding text. They can certainly be used that way,
> but if it  obfuscates meaning them over time it may make things more difficult to  understand and maintain.
>
> That's just my thought though... either way I don't want to see us  paint ourselves into a corner with something like this.
>
> -David

I agree with David, also I didn't like to overriding the labels  
between applications.

To be me clear I like to give a simple example that I didn't like:
in AccountingUiLabels.xml the label  
AccountingFixedAssetMaintIntervalQuantity has the meaning "Interval  
Quantity"
in AssetMaintUiLabel.xml the same label  
AccountingFixedAssetMaintIntervalQuantity has the meaning "Meter  
Reading"

I prefer that in this case it was :

AccountingFixedAssetMaintIntervalQuantity --> "Interval Quantity"
AssetMaintFixedAssetMaintIntervalQuantity --> "Meter Reading"

I suggest that all the labels inside an xml file will be start with  
the same prefix (example all the labels in OrderUiLabels will have a  
Order as prefix).

If we will use this simple rules we will have more maintaneable and  
reusing of existing labels between different applications.

Thanks
Marco


Il giorno 19/mag/08, alle ore 18:54, David E Jones ha scritto:

>
> On May 19, 2008, at 8:56 AM, Adrian Crum wrote:
>
>> Jacques Le Roux wrote:
>>> From: "Bruno Busco" <[hidden email]>
>>>> I think that in order to keep things simple and maintaneable we  
>>>> should avoid
>>>> that a label is overwritten in two different UiLabels files to  
>>>> have a
>>>> different and more specific text.
>>>> If we do like this it will be an easy job to automatically check  
>>>> for label
>>>> duplication.
>>> +1000, I totally agree : simple is beautiful. We don't need  
>>> complexity at this level. Or someone has to explain me why...
>>
>> A good example is the Asset Maintenance component - which reuses  
>> screens from the Accounting component, but changes some terminology  
>> so that it makes more sense to a maintenance person. In that case,  
>> the UI labels used in the Accounting component screens are  
>> redefined in Asset Maintenance.
>
> This is an interesting use of label overriding, but I'm not sure I  
> like it... If the meaning of some text somewhere is different from  
> the meaning implied by the previously used label then my preference  
> would be to see a different label.
>
> The labels are really meant for enabling translation and not so much  
> for overriding text. They can certainly be used that way, but if it  
> obfuscates meaning them over time it may make things more difficult  
> to understand and maintain.
>
> That's just my thought though... either way I don't want to see us  
> paint ourselves into a corner with something like this.
>
> -David
>

[David E Jones]

On May 19, 2008, at 12:51 PM, Marco Risaliti wrote:

> I agree with David, also I didn't like to overriding the labels  
> between applications.
>
> To be me clear I like to give a simple example that I didn't like:
> in AccountingUiLabels.xml the label  
> AccountingFixedAssetMaintIntervalQuantity has the meaning "Interval  
> Quantity"
> in AssetMaintUiLabel.xml the same label  
> AccountingFixedAssetMaintIntervalQuantity has the meaning "Meter  
> Reading"
>
> I prefer that in this case it was :
>
> AccountingFixedAssetMaintIntervalQuantity --> "Interval Quantity"
> AssetMaintFixedAssetMaintIntervalQuantity --> "Meter Reading"

Or perhaps "AssetMaintFixedAssetMaintMeterReading" as they do mean  
different things (BTW, not sure if "Meter Reading" is the best term  
for whatever this is applied to, but I guess that's irrelevant for the  
discussion...).

-David

> I suggest that all the labels inside an xml file will be start with  
> the same prefix (example all the labels in OrderUiLabels will have a  
> Order as prefix).
>
> If we will use this simple rules we will have more maintaneable and  
> reusing of existing labels between different applications.
>
> Thanks
> Marco
>
>
> Il giorno 19/mag/08, alle ore 18:54, David E Jones ha scritto:
>
>>
>> On May 19, 2008, at 8:56 AM, Adrian Crum wrote:
>>
>>> Jacques Le Roux wrote:
>>>> From: "Bruno Busco" <[hidden email]>
>>>>> I think that in order to keep things simple and maintaneable we  
>>>>> should avoid
>>>>> that a label is overwritten in two different UiLabels files to  
>>>>> have a
>>>>> different and more specific text.
>>>>> If we do like this it will be an easy job to automatically check  
>>>>> for label
>>>>> duplication.
>>>> +1000, I totally agree : simple is beautiful. We don't need  
>>>> complexity at this level. Or someone has to explain me why...
>>>
>>> A good example is the Asset Maintenance component - which reuses  
>>> screens from the Accounting component, but changes some  
>>> terminology so that it makes more sense to a maintenance person.  
>>> In that case, the UI labels used in the Accounting component  
>>> screens are redefined in Asset Maintenance.
>>
>> This is an interesting use of label overriding, but I'm not sure I  
>> like it... If the meaning of some text somewhere is different from  
>> the meaning implied by the previously used label then my preference  
>> would be to see a different label.
>>
>> The labels are really meant for enabling translation and not so  
>> much for overriding text. They can certainly be used that way, but  
>> if it obfuscates meaning them over time it may make things more  
>> difficult to understand and maintain.
>>
>> That's just my thought though... either way I don't want to see us  
>> paint ourselves into a corner with something like this.
>>
>> -David
>>
>

Yes, exactly probably "AssetMaintFixedAssetMaintMeterReading" is more  
readable and appropriate.

Another different example can be the following label:

AccountingFixedAssetIdents --> Identifications

on AccountingUiLabels.xml and AssetMaintUiLabels.xml

in my opinion in this case I will delete it from  
AssetMaintUiLabels.xml and use it from the first one (reusing of  
labels between different applications).

Also because in the main-decorator of assetmaint application there was  
already the following actions:

<property-map resource="AssetMaintUiLabels" map-name="uiLabelMap"  
global="true"/>
<property-map resource="AccountingUiLabels" map-name="uiLabelMap"  
global="true"/>
<property-map resource="PartyUiLabels" map-name="uiLabelMap"  
global="true"/>
<property-map resource="ProductUiLabels" map-name="uiLabelMap"  
global="true"/>
<property-map resource="WorkEffortUiLabels" map-name="uiLabelMap"  
global="true"/>
<property-map resource="CommonUiLabels" map-name="uiLabelMap"  
global="true"/>

So as you can see there are a lot of confusion and seems to me that  
the cleaning of labels is something that we cannot skip or we cannot  
consider it.

Marco

Il giorno 19/mag/08, alle ore 21:00, David E Jones ha scritto:

>
> On May 19, 2008, at 12:51 PM, Marco Risaliti wrote:
>
>> I agree with David, also I didn't like to overriding the labels  
>> between applications.
>>
>> To be me clear I like to give a simple example that I didn't like:
>> in AccountingUiLabels.xml the label  
>> AccountingFixedAssetMaintIntervalQuantity has the meaning "Interval  
>> Quantity"
>> in AssetMaintUiLabel.xml the same label  
>> AccountingFixedAssetMaintIntervalQuantity has the meaning "Meter  
>> Reading"
>>
>> I prefer that in this case it was :
>>
>> AccountingFixedAssetMaintIntervalQuantity --> "Interval Quantity"
>> AssetMaintFixedAssetMaintIntervalQuantity --> "Meter Reading"
>
> Or perhaps "AssetMaintFixedAssetMaintMeterReading" as they do mean  
> different things (BTW, not sure if "Meter Reading" is the best term  
> for whatever this is applied to, but I guess that's irrelevant for  
> the discussion...).
>
> -David
>
>
>> I suggest that all the labels inside an xml file will be start with  
>> the same prefix (example all the labels in OrderUiLabels will have  
>> a Order as prefix).
>>
>> If we will use this simple rules we will have more maintaneable and  
>> reusing of existing labels between different applications.
>>
>> Thanks
>> Marco
>>
>>
>> Il giorno 19/mag/08, alle ore 18:54, David E Jones ha scritto:
>>
>>>
>>> On May 19, 2008, at 8:56 AM, Adrian Crum wrote:
>>>
>>>> Jacques Le Roux wrote:
>>>>> From: "Bruno Busco" <[hidden email]>
>>>>>> I think that in order to keep things simple and maintaneable we  
>>>>>> should avoid
>>>>>> that a label is overwritten in two different UiLabels files to  
>>>>>> have a
>>>>>> different and more specific text.
>>>>>> If we do like this it will be an easy job to automatically  
>>>>>> check for label
>>>>>> duplication.
>>>>> +1000, I totally agree : simple is beautiful. We don't need  
>>>>> complexity at this level. Or someone has to explain me why...
>>>>
>>>> A good example is the Asset Maintenance component - which reuses  
>>>> screens from the Accounting component, but changes some  
>>>> terminology so that it makes more sense to a maintenance person.  
>>>> In that case, the UI labels used in the Accounting component  
>>>> screens are redefined in Asset Maintenance.
>>>
>>> This is an interesting use of label overriding, but I'm not sure I  
>>> like it... If the meaning of some text somewhere is different from  
>>> the meaning implied by the previously used label then my  
>>> preference would be to see a different label.
>>>
>>> The labels are really meant for enabling translation and not so  
>>> much for overriding text. They can certainly be used that way, but  
>>> if it obfuscates meaning them over time it may make things more  
>>> difficult to understand and maintain.
>>>
>>> That's just my thought though... either way I don't want to see us  
>>> paint ourselves into a corner with something like this.
>>>
>>> -David
>>>
>>
>

[Adrian Crum]

David E Jones wrote:

>
> On May 19, 2008, at 12:51 PM, Marco Risaliti wrote:
>
>> I agree with David, also I didn't like to overriding the labels
>> between applications.
>>
>> To be me clear I like to give a simple example that I didn't like:
>> in AccountingUiLabels.xml the label
>> AccountingFixedAssetMaintIntervalQuantity has the meaning "Interval
>> Quantity"
>> in AssetMaintUiLabel.xml the same label
>> AccountingFixedAssetMaintIntervalQuantity has the meaning "Meter Reading"
>>
>> I prefer that in this case it was :
>>
>> AccountingFixedAssetMaintIntervalQuantity --> "Interval Quantity"
>> AssetMaintFixedAssetMaintIntervalQuantity --> "Meter Reading"
>
> Or perhaps "AssetMaintFixedAssetMaintMeterReading" as they do mean
> different things (BTW, not sure if "Meter Reading" is the best term for
> whatever this is applied to, but I guess that's irrelevant for the
> discussion...).
>
> -David

Then we're back to the problem of reusing the accounting screens. The UI
label used in the accounting screen is
AccountingFixedAssetMaintIntervalQuantity. So creating a new label in
asset maint will require creating a new screen.

I planned on working on the asset maint screens after I'm done with my
framework stuff. Some of the forms were C&P from accounting to asset
maint instead of using the extend feature - maybe because extend had a
bug in it (which has been fixed). I'll try to remove the UI label
redefinitions in the process.

-Adrian

[David E Jones]

On May 19, 2008, at 1:55 PM, Adrian Crum wrote:

> David E Jones wrote:
>> On May 19, 2008, at 12:51 PM, Marco Risaliti wrote:
>>> I agree with David, also I didn't like to overriding the labels  
>>> between applications.
>>>
>>> To be me clear I like to give a simple example that I didn't like:
>>> in AccountingUiLabels.xml the label  
>>> AccountingFixedAssetMaintIntervalQuantity has the meaning  
>>> "Interval Quantity"
>>> in AssetMaintUiLabel.xml the same label  
>>> AccountingFixedAssetMaintIntervalQuantity has the meaning "Meter  
>>> Reading"
>>>
>>> I prefer that in this case it was :
>>>
>>> AccountingFixedAssetMaintIntervalQuantity --> "Interval Quantity"
>>> AssetMaintFixedAssetMaintIntervalQuantity --> "Meter Reading"
>> Or perhaps "AssetMaintFixedAssetMaintMeterReading" as they do mean  
>> different things (BTW, not sure if "Meter Reading" is the best term  
>> for whatever this is applied to, but I guess that's irrelevant for  
>> the discussion...).
>> -David
>
> Then we're back to the problem of reusing the accounting screens.  
> The UI label used in the accounting screen is  
> AccountingFixedAssetMaintIntervalQuantity. So creating a new label  
> in asset maint will require creating a new screen.

It's an interesting conundrum... it is probably more work to create a  
screen just for this than it is worth...

-David


> I planned on working on the asset maint screens after I'm done with  
> my framework stuff. Some of the forms were C&P from accounting to  
> asset maint instead of using the extend feature - maybe because  
> extend had a bug in it (which has been fixed). I'll try to remove  
> the UI label redefinitions in the process.