Pierre,
this will be my last response to this thread to clear some points and
let the interested readers draw their own conclusions.
See my responses inline.
Regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 30.01.22 um 18:32 schrieb 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
I consider a viewpoint the project's viewpoint if a majority of
participating contributors have expressed a similar viewpoint. This is
called lazy consensus.
There have been several voices who argumented for this viewpoint but to
this day, I have seen noone else argumenting for your viewpoint. I have
given some examples of discussions and rejected contributions in the
past message. It's your problem that you cannot accept decisions against
your own viewpoint.
That there have been contributions and/or commits in the past does not
prove anything except that those cases might have been overseen or
simply not thought about. We all make mistakes.
This has happened just recently, where Jacques merged some of those
questioned PR's. Instead of correcting your own work, you refused to do
so and Jacques did it for you afterwards to return to a reasonable use
of specified labels.
Good for you that he was so kind to do what would have been your job.
[..]
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:
[...]
It makes perfect sense that the translations provided in OOTB OFBiz are
constant throughout all applications.
And yet, it proves nothing.
As said several times before, context matters and the use case matters.
OOTB OFBiz is neutral in it's terminology here. It would make no sense
to translate those labels in different terminology.
A product in OFBiz can have a lot of characteristics and they have their
own names in different businees domains. Just some examples from custom
projects who use the following terms for a product ID / Produkt-Nr. in
German:
Produkt-Nr., Artikel-Nr., Bauteil-Nr., Material-Nr., Achs-Artikel-Nr.,
Ersatzteil-Nr., ...
And those names are not necessarily equal in different applications for
the same customer on the same OFBiz instance. Thats my experience.
Would it be reasonable to change "Produkt ID" to some of the examples
above? No! Because it would only fit for some users, not for all users.
Hence it's perfectly fine to keep it neutral and consistent throughout
OOTB OFBiz.
And it's easy to translate "Produkt ID" to "Artikel-Nr." or something
else throughout all applications, if you want to use exactly the same
term in every application. Just a few seconds with search & replace and
you are done. But if you cut that feature and start to have only one
label for ALL occurences throughout ALL applications, you would have to
re-introduce the specified labels to gain back this flexibility.
Not acceptable.
So, I think we will start an initiative to correct those cases who
accidently introduced such a state. Thanks for the hint.
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.
Your are throwing smoke candles here. I did not say anything like that.
And I do not see what the ASF License has to do with the points I made.
Those are far-fetched arguments so broad that they are always right. But
they have nothing to do with the topic.
I said, in different contexts, that we should not cut down existing,
valuable features and that we should always consider backwards
compatibility and/or migration plans for users.
I am supporting OFBiz users for long time periods, my oldest active
customer working with me for nearly 20 years. I do care about existing
users and feel responsible to keep up a stable, reliable and constant
software base. I am sure I am not alone with that approach.
Those customers are running serious businesses. Apache OFBiz is a
serious piece of great software.
This project is not a playground where the number of commits is
counting. Quality, flexibility, stability, scalabilty counts and this
needs thorough decisions and discussions.
It seems that you are eager to just get your changes into the codebase
without caring for an existing user base or the above points. You seem
to not even care about extra work others have to do as a result of your
contributions.
That's your choice but don't expect me or fellow contributors to accept
those approaches. It won't work.
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.
I am using the arguments I believe in. That's common in dicussions with
different viewpoints.
I'm sorry that you don't like them, but I guess you will have to deal
with it.
Met vriendelijke groet,
Pierre Smits
[...]
On Sun, Jan 30, 2022 at 12:09 PM Michael Brohl <[email protected]>
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
