Re: Guideline translation definition and the application there of in service functions and widget element, o.a.

[Pierre Smits]

Thanks Michael, for your opinion and suggestions,

Re: "namely the intention to reuse labels from other applications instead
of using context related specified labels in the application itself"

This is not the project's viewpoint. It is your viewpoint. All the
contributors of this project have, across all the years this project has
been under the wings, made contributions that:
1. allowed for the reuse of labels from other components, and
2. applied labels from other components in specific screen, form and grid
widgets, ant templates

And privileged contributors have - without argument - merged those
contributions into the codebase (or before git committed patches that
included such). There is also evidence that a privileged contributor
suggested that a label, for a field in coming from the order component,
 should be included in CommonUiLabel.xml fo instead of having such in
OrderUiLabels.xml.

This all has been done in line with (what is perceived as)  consensus
within the community since the beginning of the project under the wings of
the ASF. Even nowadays, contributors adhere to the application of common
sense, instead of the viewpoint that label definition and application is
either black or white.

Reuse of 'whatever is available' (from other components) is common across
the entirety of what is in the ofbiz-framework repository, wether it is
regarding screens, forms, requests, services, including fields and their
translation definitions.
This is understood and shared by all contributors. Your viewpoint is,
however, dogmatically singular, whenever you participate a discussion.

The only consensus within the community on the subject of reuse is, that
*nothing* from components in the ofbiz-plugins repository is reused

   1. in a component in the ofbiz-framework repository, or
   2. in another component in the ofbiz-plugins repository.


Re: " in English, you often can use the same translation but in other
languages,
words are very different based on the context.

This argument is flawed.
As an example, the labels for 'productiId' in the various UILabel.xml files
in ofbiz-framework show for the German translation gives:

   - in AccountingUiLabels.xml. for label "FormFieldTitle_productId":
   Produkt ID
   - in AccountingUiLabels.xml for label "AccountingProductId": Produkt ID
   - in ManufacturingUiLabels.xml, for label
   "ManufacturingProductId": Produkt-Nr.
   - in PartyUiLabels.xml, for label "PartyProductId": Produkt ID
   - in ProductUiLabels.xml, for label "FormFieldTitle_productId": Produkt ID
   - in ProductUiLabels.xml, for label "ProductProductId": Produkt ID
   - in WorkEffortUiLabels.xml, for label
   "FormFieldTitle_productId": Produkt ID
   - in WorkEffortUiLabels.xml, for label "WorkEffortProductId": Produkt ID

with no 'specific' labels for the same field widget in any of the
components in the ofbiz-plugin repository.

It seems that none of the German contributors felt the need to have
different translations for the field with name 'productId' in the codebase.
This is, presumably, because the context for German contributors regardless
of which component the context is the same, being about the id of a product
(retrieved from a record in the underlying RDBMS).
In fact, for the majority of contributors, there is no difference in
'context' from component to component for this and similar fields,
warranting a different translation per component for such fields. Proving
that there is consensus within the community, that reusing existing labels
is ok. And that it is about applying common sense, not dogma.

Even when, in a form or grid, the field with name="productId" is to display
a combination of the values of the productId and the internalName of the
retrieved product record, the majority thought it ok to have it being
titled with the label for productId. Or didn't change the label, due to
lack of time or interest. Only one, some or all French contributors found
that in some (not all) of such productId scenarios, the translation of a
label for 'productId'  was not to be "ref. produit" but something else.
.
Re: "doing otherwise removes the flexibility for users to use
different translations
in different contexts. If you change the translation in this one place, it
will also be changed anywhere else"

Michael continues to bring up this argument that 'users' are limited in
their choices, when changes are implemented in the OFBiz code by the
contributors.  This argument makes Michael 'complain' about a variety of
improvements brought forward, including (but not limited to) correcting
labels, removal of labels not applied by the project and removal of
commented out code.

This argument is flawed by design. Users are not limited in anyway, because
this project - as per ASF directives-  provides the source code in the form
of releases. Those users you keep bringing up are thus not limited in their
choices. That is - without limitation-  the promise of Open Source
solutions from the ASF.

If user

Re: Guideline translation definition and the application there of in service functions and widget element, o.a.

[Michael Brohl]

Thanks Pierre,

the technical part looks good to me at first glance, I would though find 
it more appropriate to enhance the existing documentation set up by 
Adrian [1] instead of introducing another wiki page.


The last part contains suggestions to the reader which do not adhere to 
the projects view, namely the intention to reuse labels from other 
applications instead of using context related specified labels in the 
application itself. This was discussed between us and with other 
contributors many times in the past and you still insist to do it otherwise.


For reference, I point interested people to some of these discussions 
and issues from the past: [2] [3] [4]. There are more.


Some of the arguments to use specified labels instead of common labels 
and/or labels from other applications are:


- doing otherwise removes the flexibility for users to use different 
translations in different contexts. If you change the translation in 
this one place, it will also be changed anywhere else,


- even in a single installation of OFBiz, the same field might be 
translated differently between applications because they are used by 
different departments with their own terminology (true especially for 
bigger companies),


- in English, you often can use the same translation but in other 
languages, words are very different based on the context. Even the 
number of words differ,


- you would have to reference UI label maps from other applications 
which should be avoided because of (circular) dependencies. If we 
already have those situations, we should not extend it further.



So I propose that the project gives a clear understanding that

- specific labels should be used instead of common labels or reusing 
labels from other applications,


- new specific labels should be created instead of common labels be used,

- common labels CAN be used for action widgets like buttons (search, 
edit, delete) etc. which are the same in every context. This has to be 
checked though against languages


- changes in patches or pull requests, which do not align with those 
guidelines, should not be merged to the codebase.



Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


[1] 
https://cwiki.apache.org/confluence/display/OFBIZ/Internationalization?src=contextnavchildmode


[2] https://issues.apache.org/jira/browse/OFBIZ-10772 (and subtasks)

[3] 
https://issues.apache.org/jira/browse/OFBIZ-8110?jql=project%20%3D%20OFBIZ%20AND%20text%20~%20%22Maximise%20utilisation%20of%20common%20labels%22


[4] https://lists.apache.org/thread/47lz9mytw2p7zzryddogt1283kkmkz2c

Am 29.01.22 um 18:28 schrieb Pierre Smits:

Hi all,

Over the years, contributions of translation definitions and contributions
to apply or change translation definitions in field and other widgets have
led to heated right-vs-wrong debates between contributors in tickets and
elsewhere. In order to unify the community, to decrease the number of these
heated debates and bring us back to happy collaborating to improve OFBiz,
  I have writtena guideline regarding this subject.

This guideline can be found here:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199533364

I invite all to evaluate this guideline and provide feedback

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)
Proud contributor to the ASF since 2006
*Apache Directory , PMC Member*

Anyone could have been you, whereas I've always been anyone.


On Fri, Jan 28, 2022 at 4:24 PM Daniel Watford  wrote:


Hi Michael,

Yes, those labels were intentional. My view was that introducing common
labels in cases where there were previously no labels at all was an
improvement.

Had there already been specific labels in place, these would have been left
alone.

Summary of my review approach:
- Changing from application specific labels to common labels is unlikely to
be committed without good reason because of the risk of losing the original
application's intention when translated to different languages.
- Changes from no label at all to a common label seem reasonable since we
have the potential benefit of already existing generic translations from
the common label set.

Of course there will be exceptions to every rule, but in this case I
thought the changes appropriate and an improvement.

Thanks,

Dan.


On Fri, 28 Jan 2022 at 14:38, Michael Brohl 
wrote:


Hi Dan,

is this commit intentional?

It still has unwanted changes introducing titles with common labels
instead of specific labels (e.g. CommonLocation for jobLocation).

Regards,

Michael


Am 28.01.22 um 08:49 schrieb danwatf...@apache.org:

This is an automated email from the ASF dual-hosted git repository.

danwatford pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
   new b2dd912  Improve