After i18ning a big project most of the code was littered with i18n constructs. This reduced readibilty of the original business code (i18n understood as a orthogonal, non-business aspect) and made the code a lot less readable than before. To the point where lots of i18n was littered through Swing, display, logging and error code and the original business code was not understandable anymore.

With $ and _ as method names, the i18n part of the code fades away and no longer blocks the view to the really important code, the business one.

But of course I would strongly regiment the usage of static imports in my projects and control the code with checkers or reviews. The same goes for $ and _ as or in method names. As always, don’t be ideological, but use the best tools for the job. And if the best tool is $ as a method name, then you should use it I think. For people who can’t live with $() or _(), Messages still supports Messages.format().

@Tom: Yes. In projects there should be a i18n guide with i18n guidelines for keys, words, wording, grammar and style. And the guide should explain how i18n is done, so the developers know what $() means. For reading code from other projects (open source) the IDE helps as you said.

It’s not april fools day. Where’s the “I’m Kidding” at the end of the entry?