Strings must be externalized

[joverbey]

Let's use this issue to coordinate string externalization.

To start:

• @acalvert and @aggrand will externalize the refactorings they worked on, including the corresponding Eclipse Refactoring classes
• @joverbey will work on Intro ACC Loop and everything else in the Core package
• @galanite will externalize the CLI package

[joverbey]

If you encounter a format string, you can probably translate it as-is, but here is the "correct" way to substitute strings in translations

From CEditorMessages.properties:

EditorUtility_concatModifierStrings= {0} + {1}

Code in EditorUtility (elements of the String[] array bind to {0} and {1} in the obvious order):

return NLS.bind(CEditorMessages.EditorUtility_concatModifierStrings, new String[] {modifierString, newModifierString});

This is more important when the order of words might change in translation (e.g., "blue horse" in English vs. "caballo azul" in Spanish, although I don't know what horses have to do with refactoring).

[acalvert]

I know we discussed this, but how should we handle strings in IllegalArgumentException/IllegalStateException contructors?
i.e., throw new IllegalStateException("loop is null")

Also, what about the English text in toString methods?

[joverbey]

If the end user will see it during normal operations, it should be externalized. Typically, an IllegalStateException would only be thrown due to a programming error—it should never happen in production—in which case you don't need to externalize the string. Same for toString() methods: if the end user will see them in a message box or something, they should be externalized, but if they're just for debugging, it's not necessary.

[joverbey]

@aggrand could you please externalize Unroll, Interchange, and Distribute? Thx.

[acalvert]

@aggrand I actually just made a few changes to Distribute, so I can do that one