Community
Participate
Working Groups
20040802 Unneccessary NON-NLS uses the same preference as non externalized Strings. As the severity of these two options is so different we should have two preferences. The Platform UI team has non externalized Strings set to error so we have to reset our error settings everytime we load from HEAD.
This support got added in JDT/Core with build 2nd August 2005. Martin, can you please add the UI for this and a quick fix. We should add the UI for M1, quick fix can come later if difficult. Question to Olivier: the build notes state that the setting is ignore by default, but according to Tod the setting is derived from the unexternalized string setting. Any comments.
By default, the preference for externalized string literals is set to ignore. So this is why I said the detection of unnecessary non-nls tags is disabled by default. I will clarify the build notes. We indeed reuse the same preference as the externalized string literals. The reason for that is that these two features are related. One is to detect the missing externalized string literals and one is to detect the non-nls tags left behind. I don't think this deserves two different options. If you have some errors, fix them and they won't come back.
I understand your argument but we have over 2000 unneccessary NON-NLS in our code (which we should fix). I assume it will be much worse for other products with a larger code base. As much as I hate adding extra preferences this should be another preference for backwards compatibility - I suspect many teams turn unexternalized String to error as they ship on multiple languages.
I will add a new option for this. No rebuild will be requested. For this week, simply turn off "externalize string literal". Martin, I'll let you know when the new option is ready.
Further information as to why this bugs us so much: all UI projects have the "Usage of non-externalized strings" preference set to error.
We won't add a new option. But this detection will be postponed after 3.2 M1.
I'd vote for another option: I think not nls-ing something can be seen as more severe than having a superfluous non-nls in the code (or the other way around ;-)
non-nls tags should be accurate. Right now you can have more tags than the ones you really need. This new feature (see bug 49876) can be used to achieve accurancy between the externalized string literals and the non-nls tags. Existing errors should be fixed. It is a one time fix. Also the tool to externalize string literals should be updated to get rid of superfluous tags.
Will this tool be available for 3.2 M1? I don't relish the thought of manually editing thousands of files to remove extraneous NLS tags.
See also Bug 105816.
I am working on a tool to get rid of unnecessary non-nls tags automatically. It will be available on the JDT/Core dev page.
I over-reacted in comment #9. There are only 100+ errors from this change, which is fairly easy to edit by hand.
(In reply to comment #9) > Will this tool be available for 3.2 M1? I don't relish the thought of > manually editing thousands of files to remove extraneous NLS tags. I am testing the tool right now. It will be available in the JDT/Core dev page after some more testing. Do you volunteer for beta-testing? :-)
(In reply to comment #13) > Do you volunteer for beta-testing? :-) Sure.
I get this one back. It has nothing to do with JDT/UI.
I would also be enclined to provide an extra option, to provide maximal configurability. Now UI could choose to only present a combined setting if it wanted (setting the 2 options at once under the cover). Now, we can see reaction of users to one shared option before we provide 2 options adding complexity.
If we start with one setting we should start with one in core as well. Since changing the settings can be done via API as well we can end in situations where the two settings have different values and what does UI present then ?
I will release after M1 a version that is using only one option. If this is not good enough, then we will add a second one. My point of view is that this adds unnecessary complexity for nothing. The purpose of the actual option is to provide accuracy in the nls tagging. This was not achieve before this new detection.
Closing as WONTFIX since for now we reuse the nls option.
