Thank you to everyone who has looked at
and helped with the cleanup.
At the risk of stretching the friendship, I've come to realise that I
should have used "Find Broken Externalized Strings". It finds even more
candidates, but I would recommend concentrating on the files which have
large numbers of unused strings. Having to translate two or three
unused messages is one thing, but translating 20 or 30 unused messages
is definitely best avoided!
I've added a list of the seven most "broken" resourcebundles to
JBIDE-4044. I would appreciate it if you could have another look!
To get the exact list of affected strings, you will need to run
Source/Find Broken Externalized Strings against the relevant package (or
your whole workspace if you like), but here's the summary:
(accessor class org.jboss.ide.eclipse.archives.ui.ArchivesUIMessages)
org.hibernate.eclipse.console/src/org/hibernate/eclipse/console (60 matches)
(accessor class org.hibernate.eclipse.console.HibernateConsoleMessages)
org.jboss.tools.jst.web/src/org/jboss/tools/jst/web/messages (29 matches)
(accessor class org.jboss.tools.jst.web.messages.xpl.WebUIMessages)
org.jboss.tools.vpe/src/org/jboss/tools/vpe/messages (23 matches)
(accessor class org.jboss.tools.vpe.messages.VpeUIMessages)
I'm sure a lot of these are false positives, but even so, it would be
helpful to have explanatory comments in the affected properties files.
Max Rydahl Andersen wrote:
On first glance it looks very much like false positives - create the
jira and we'll look into it.
> I've run UCDetector  against the codebase, and it has found 294
> fields in *Messages classes which have 0 references. I've attached a
> list (views well in oocalc). I'd like to remove them, along with their
> corresponding resourcebundle properties, to reduce the number of
> translatable strings.
> UCDetector also finds lots of unused methods and classes (which may be
> referencing even more obsolete strings), but I'm wary of false
> positives, so I won't try to tackle them. But if anyone else wants to
> run UCDetector against their code, I would appreciate it! (Or I could
> export a larger TSV file if you don't feel like installing UCDetector.)
> 1. Is removing those messages a bad idea, for some reason I can't think of?
> 2. Should I do this under JBIDE-3557, or should I create a new task,
> perhaps a sub-task?
>  http://ucdetector.sourceforge.net/
Senior Software Engineer
Engineering - Internationalisation