Opinions

Marcus Hirt marcus.hirt at oracle.com
Mon Feb 25 20:03:49 UTC 2019


Thanks for the input Christoph!

Since the only voices I've heard seem to be in favour of the second 
alternative, I'll prep a patch for review.

Kind regards,
Marcus

On 2019-02-25, 08:08, "Langer, Christoph" <christoph.langer at sap.com> wrote:

    Hi guys,
    
    > I think the tags have a value - for most bundles most strings should
    > be externalized, and getting a warning about it helps making sure
    > that the strings are indeed externalized, especially for newcomers
    > to the project. Having the NON-NLS tag shows that the developer made
    > a conscious decision about not externalizing the string.
    > 
    > For test bundles the strings should normally NOT be externalized,
    > hence (were it not for other considerations) I think we should
    > neither warn, nor need the macro. In other words, we would be
    > disabling a signal that carries no information (noise).
    > 
    > The other considerations in this case would be introducing project
    > specific warning/error settings for test bundles, and perhaps
    > confusing people about when to have and when to not have the tags.
    > 
    > I think the two choices to consider are:
    > * Keep using the NON-NLS tags in the test bundles
    >   (few project specific overrides (any existing),
    >    pointless tags in the test bundles)
    > * Stop using the NON-NLS tags in the test bundles
    >   (test project specific overrides,
    >    no tags in the test bundles)
    > 
    > I have no strong opinion either way either. The pros and cons are
    > distributed pretty evenly for me, with maybe a slight anti-noise
    > bias. Does anyone else have an opinion in the matter?
    
    I'd accept the project specific settings for the tests. I think NON-NLS tags are needed in the actual plugin projects but in the tests they are annoying.
    
    Disclaimer: It's an opinion from somebody who's just starting to do JMC development ��
    
    Best regards
    Christoph
    
    
    




More information about the jmc-dev mailing list