Project: JDT
Bug 119846 [nls tooling] "Externalize Strings" default behavior damages navigation to Java properties-file editor
Reported: 2005-12-08 07:03:05 | Status: resolved fixed

Have a String you wish to externalize, called LABEL (or STRING or BUTTON or TEXT, or the all-caps version of a String which just happens to be the name of a class on your class-path), in a class called, say FooClass. Run the externalize-Strings wizard (with all its default settings) on class "FooClass". The dialog will offer a prefix under "Enter common prefix for generated keys (optional)", which will be "FooClass", i.e., the SAME as the name of the class in which the String LABEL lives. Accept this apparently-sensible default suggestion. Now enter a key-suffix for your String; choose (as I often do) to use the not-all-caps name, i.e., in this case "Label". Run the wizard to completion (making sure you get a valid Messages.java and whatever.properties pair of files). Now, in class "FooClass" you should have a line of code that reads: String LABEL = Messages.getString("FooClass.Label"); //$NON-NLS-1$ If you now Ctrl-click upon the String-literal "FooClass.Label", you will NOT navigate to the whatever.properties file as expected. a) If you Ctrl-click upon the portion of the String literal "FooClass", you will simply navigate to the declaration of FooClass. b) If you Ctrl-click upon the portion of the String literal "Label", Eclipse will attempt to open the Label.class ... depending on your class-path, results will vary, but you will almost certainly get a choice, including org.eclipse.swt.widgets.Label -- note that this problem arises independently of whether there is a part-a problem (i.e., even if the user does NOT have a prefix, or has one that does NOT match any class-name). Simple fix for part-a would be for the default prefix to be the class-name slightly altered (e.g., with leading or trailing "_", or the like), especially if the alteration were some character that cannot possibly appear in a class-name, like "^". ("#" won't work, since that's a comment in a properties file.) *Simple* fix for part-b I cannot think of. (It's cool that one can navigate even from inside comments to classes with known names, like Label, so I see how the mere use of "Label" as the key-suffix has to have the stated result.) Maybe (1) allow any choice of key-suffix that is not a valid class-name, and (2) for any key-suffix that is a valid class-name, look up the user's choice of key-suffix on the classpath?

Files changed in fix:
org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/text/JavaSourceViewerConfiguration.java