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": <value xml:lang="de">Produkt ID</value> - in AccountingUiLabels.xml for label "AccountingProductId": <value xml:lang="de">Produkt ID</value> - in ManufacturingUiLabels.xml, for label "ManufacturingProductId": <value xml:lang="de">Produkt-Nr.</value> - in PartyUiLabels.xml, for label "PartyProductId": <value xml:lang="de">Produkt ID</value> - in ProductUiLabels.xml, for label "FormFieldTitle_productId": <value xml:lang="de">Produkt ID</value> - in ProductUiLabels.xml, for label "ProductProductId": <value xml:lang="de">Produkt ID</value> - in WorkEffortUiLabels.xml, for label "FormFieldTitle_productId": <value xml:lang="de">Produkt ID</value> - in WorkEffortUiLabels.xml, for label "WorkEffortProductId": <value xml:lang="de">Produkt ID</value> 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 users are not content with what contributors incorporate into the codebase, they have no grounds for complaints. Because of the following statement of each file included: Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. The OFBiz project distributes code under that license. And because they can modify the code they use as they see fit. So, please stop using that argument. Met vriendelijke groet, Pierre Smits *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without privileges) Proud contributor to the ASF since 2006 *Apache Directory <https://directory.apache.org>, PMC Member* Anyone could have been you, whereas I've always been anyone. On Sun, Jan 30, 2022 at 12:09 PM Michael Brohl <michael.br...@ecomify.de> wrote: > 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 <https://ofbiz.apache.org/> > since > > 2008 (without privileges) > > Proud contributor to the ASF since 2006 > > *Apache Directory <https://directory.apache.org>, PMC Member* > > > > Anyone could have been you, whereas I've always been anyone. >
