Bug 321577 - [rename][nls tooling] allow to rename externalized string
Summary: [rename][nls tooling] allow to rename externalized string
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2010-08-03 07:45 EDT by Michael Seele CLA
Modified: 2011-01-06 04:03 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Seele CLA 2010-08-03 07:45:45 EDT
Please provide a way to contribute to the RenameJavaElementAction.

We're developing on a new feature for jinto (See http://www.guh-software.de/jinto_en.html for further notices) where the user can rename it's resource bundle keys. We can detect which strings are resource bundle key's and which are not. We want to contribute when the users clicks "Refactor > Rename..." on a string. But this seems to be not possible for now. The only thing what happens is that a dialog that pops up with the following message: "Operation unavailable on the current selection.\nSelect a Java project, source folder, resource, package, compilation unit, type, field, method, parameter or a local variable" (Invoked by RenameJavaElementAction:161).
Please give us a chance to detect if we want to handle this rename action.
Comment 1 Markus Keller CLA 2010-08-09 05:41:55 EDT
We don't want to open up the Rename action for general contributions. A better way to implement this would be a Rename Property Key refactoring in JDT. We already have rename support for Eclipse-style NLS'd keys (Rename Field with the NLS participant), and it would be nice to have that extended to String-style keys.

NLSKeyHyperlinkDetector already has all the code to detect and resolve the key in the properties file, so this has to be extracted and reused in a new rename refactoring processor. The element of the refactoring will be a new API type that represents a properties key (basically a "properties file / key" pair).

Would you like to work on this?