I've run UCDetector [1] 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 before localisation begins.

I think it should be safe to remove these fields, since any direct usage will be caught by the compiler as soon as we try to remove it (and wouldn't have been listed by UCDetector anyway, unless it is completely broken), and it would be extremely unlikely for anyone to access a Messages field by reflection.

If you want to run UCDetector yourself, select one or more plugin projects (not features, not non-Java projects), select UCDetector/Detect unnecessary code, and wait. I recommend configuring Eclipse's Problems view to show problems of type "UCDetector Marker (References)" whose description contains 'Field "'. The relevant problems are of the form 'Field SomethingMessages.SOME_KEY" has 0 references'.

[1] http://ucdetector.sourceforge.net/

EDIT:

Forget about UCDetector for this! It looks like Eclipse's built in feature "Find Broken Externalized Strings" is much better for this specific case. Not to mention a lot faster!

Looking through the results, I'm getting an idea what Max meant about false positives, because some properties files are used both through a Messages accessor class and directly via ResourceBundle, sometimes by concatenating prefixes to construct the keys. Like Eclipse, I assumed that wouldn't happen to a bundle which has a Messages accessor class, but I was obviously wrong.

I would suggest switching to "Find Broken Externalized Strings", because (unlike UCDetector) it can handle properties files accessed through old-style Messages classes with getString() methods.

You can run Source/Find Broken Externalized Strings against a package, project, or group of projects. I've cleaned up as well as I can, and reviewed the supposedly "undefined keys". Here is the resulting list of resourcebundles with at least 20 suspected unused keys:

archives:
ArchivesUIMessages.properties - org.jboss.ide.eclipse.archives.ui/src/main/org/jboss/ide/eclipse/archives/ui (43 matches)
(accessor class org.jboss.ide.eclipse.archives.ui.ArchivesUIMessages)

common:
JavaUIMessages.properties - org.jboss.tools.common.model.ui/src/org/jboss/tools/common/model/ui/util (69 matches)
XmlEditorMessages.properties - org.jboss.tools.common.text.xml/src/org/jboss/tools/common/text/xml/ui (49 matches)

hibernate:
HibernateConsoleMessages.properties - org.hibernate.eclipse.console/src/org/hibernate/eclipse/console (60 matches)
(accessor class org.hibernate.eclipse.console.HibernateConsoleMessages)

jst:
messages.properties - org.jboss.tools.jst.web/src/org/jboss/tools/jst/web/messages (29 matches)
(accessor class org.jboss.tools.jst.web.messages.xpl.WebUIMessages)
TilesEditorMessages.properties - org.jboss.tools.jst.web.tiles.ui/src/org/jboss/tools/jst/web/tiles/ui/editor (74 matches)

vpe:
messages.properties - org.jboss.tools.vpe/src/org/jboss/tools/vpe/messages (23 matches)
(accessor class org.jboss.tools.vpe.messages.VpeUIMessages)

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). 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. Thanks!