November 22, 2005
IntelliJ IDEA 5.1: i18n
Last week we have started the EAP program for IntelliJ IDEA 5.1 (sometimes also called 5.0.3). The main new feature of the version 5.1 is the support for localization (possibility to translate the IntelliJ IDEA user interface into different languages). The EAP builds already contain a mostly complete Japanese localization.
Besides the localization support, it includes a number of new features as well; since most of the team was working on internatialization (i18n) during the development of version 5.1, it shouldn't come as a surprise that most of the new features are also related to i18n. (In fact, working on these features was quite a lot of fun: mostly everyone came up with ideas on improving the i18n support, and took part in implementing them. As a result, we got a much closer collaboration of developers on a small area of code. Some of the new features are literally a patchwork of changes made by different people on the team.)
When you are doing i18n work on a product of IDEA's size, your first goal becomes reducing the number of strings you need to look at from the i18n point of view, as much as possible. The traditional approach of marking every single line containing a string that does not need to be localized with a comment (//non-nls, //noi18n or something like that) was far too inefficient for our project size. Because of this, we came up with the @NonNls annotation for smarter marking of non-localizable items, and greatly extended its applicability in version 5.1. (The complete rules of using @NonNls could probably fill an entire blog post by themselves...)
And the second goal is, of course, reducing the amount of work which needs to be done on every string which does need to be localized. Ideally, all that is needed is a simple Alt-Enter / Enter combination, but IDEA usually can't guess the most meaningful name for a property, so some typing is still required.
I'd like to highlight specifically two of the smarter features that we developed during our i18n work. The first is the "Annotate as @NonNls" quickfix.
The quickfix automatically looks at all the places where a @NonNls annotation can be added to remove the error, and allows to insert it with one click. In this example, you can annotate the parameter of the findFileByRelativePath method (if the string passed to this parameter is never something which needs to be translated), or annotate the homeDirectory variable (if the methods called on it can never accept something which needs to be translated). In this case, it's best to annotate the method parameter because the annotation will cover all other cases when a hard-coded string is passed to the method.
The second is the "I18nize concatenation" quickfix. Here's an example of the code before the quickfix:
And here's the same code after the quickfix, showing also the property created by the quickfix:
Notice how the constant part of the string got moved to a property, placeholders were automatically inserted for the variable parts, and even the apostrophes were correctly escaped according to the format string syntax.
Of course, the code template used by the quickfix is configurable, so if you use non-standard methods to load property strings or perform the formatting (as we do), you can configure it for your needs as well.
Smart, isn't it?
Posted by Dmitry Jemerov at November 22, 2005 11:27 PM