Result of Source->Find broken externalized Strings is broken project

[jjohnstn]

• taken from https://bugs.eclipse.org/bugs/show_bug.cgi?id=569043
• see https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/172642

[jjohnstn]

@carstenartur FYI, as the reporter of the original bug, I have posted a new enhancement PR to be able to specify messages that are known to be used so they won't show up when you do a Find broken externalized Strings. I do this by adding a .usedproperties file to protect various messages in the .properties file (as opposed to just adding comments). I intend to add these files for JDT UI for 4.28 M3 and do the final removal for 4.29 M1 to give external projects ample time to discover any internal message being used that isn't marked as used (there are already a few of these). One of the offenders was FoldingMessages.java which was an old style messages file and message keys were built dynamically so it fooled the find action.

[carstenartur]

It's too long ago. I don't remember the details and I'm not sure that I have understood the reason for the malfunction already at the time I investigated.
Will orphaned strings like the ones from
https://bugs.eclipse.org/bugs/show_bug.cgi?id=296836
be found now? And will they be removed? Or are they kept purly for backwards compatibility with your new approach? From my point of view another option removing nls keys could be to change the bundle version range on dependent bundles which allows a real cleanup (deletion) in the bundle. And for the "keep backward compatibility case" in an ideal world everything that has to be kept because of backwards compatibility should be marked somehow lightweight as deprecated near the orphaned entry itself. But maybe I should rather try your approach first. Thanks for putting effort on the bug report!

[jjohnstn]

Orphaned messages with DO NOT REMOVE have been placed into the .usedproperties files I will commit soon so they will protected at least for the time-being.