Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 369122

Summary:

[nls tooling] Provide "convert to constant" option in Externalize wizard

Product:

[Eclipse Project] JDT

Reporter:

Miles Parker <milesparker>

Component:

Text

Assignee:

JDT-Text-Inbox <jdt-text-inbox>

Status:

ASSIGNED ---

QA Contact:

Severity:

enhancement

Priority:

CC:

daniel_megert, h.klene

Version:

3.7

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
A little demo of an enum property handling implementation	none

Description Miles Parker

2012-01-19 12:45:27 EST

I've been doing a number of major externalize sweeps recently, and I felt that a big piece was missing that it would be really neat to automate.

I take the externalize story not to be just "take out everything that might need to be translated" but "deal in a coherent way with all of the strings in your code base so that nothing is overlooked". In that case there is one important piece missing. When we go through the code by hand, we're also looking for strings that should be turned into constants. IMO, there are very few instances where we should not be doing this, as having random strings for configuration, file locations, etc.. littered around your code is a bad smell. So, what I'd like to see is:

An additional option for each entry: "Convert to Constant". In this case, the key would become the name of the constant. Obviously you wouldn't want to prefix the name of the key in this case.

Comment 1 Holger Klene

2012-07-09 12:33:18 EDT

Why not take it a step further and make an enum out of those constants? This will naturally identify the key with the constants name if you use super.toString() of the enum to look up your properties.

Especially you can encapsulate the properties completely granting access only through type-save enum constants. For more flexibility you could not only override toString(), but also add a toString(Object ... param) that allows for inserting numbers or anything e.g. via a String.format() call.

In addition, the static values() method allows for a natural way to check translations for completeness (without reflectively analyzing the class).

The only hindrance could be, that you cannot subclass an enum, once your project requires distributing the properties over several files. But then you can encapsulate the logic inside a common helper class and start a fresh enum for every file.

At first glance, this enum approach seemed overly bureaucratic to me myself. But the longer I'm using it, the better I like it. People are lazy and if you let them get away with just a String, why should they bother to create a constant especially, if they feel, the code might change and the string might be removed soon.

On the downside for now, eclipse does not support those translated enums. If you are used to reading the translations in the hover and navigating there by ctrl-click, you'll really miss those features. That is why I currently could not convince the team to switch to enums at work.

Comment 2 Holger Klene

2012-07-09 12:46:14 EDT

Created attachment 218451 [details]
A little demo of an enum property handling implementation