We have lots of // $NON-NLS-1$ scattered throughout the codebase, which
IIRC is a tag that Eclipse uses for marking strings which aren’t to be
externalized. Now that we’re using Resource.getString() to handle all of
our i18n stuff, do these tags serve any purpose (beyond making my eyes
hurt)?
They do. Mostly, they identify strings that are keys into the i18n Properties, which of course don’t need to be translated. With the comments in place, it’s easy to know if a class has been i18n’d via Eclipse’s “Externalize Strings” action.
Really? Nearly all strings I’ve seen marked this way are not keys into the
i18n properties.
Is it possible to reverse the behavior, so that you mark strings which
need to be externalized? We have far, far more strings which shouldn’t
be externalized than ones which should.
The meaning of the $NON-NLS-1$,$NON-NLS-2$, etc. tags is that the matching string has been ‘fixed’ for externalisation. It is either a contant in a getString("…"), or is a string that does not need to be translated (e.g. “”, or “,”).
Eclipse has a tool that process the string and tags in a file and allows you to select and convert strings to getString() calls in bulk. It was a life saver when we first did the i18n.
Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@uws.edu.au
Do we still need them now that i18n is done? They produce an enormous amout
of clutter and make some code difficult to read because it can’t be formatted
nicely with those tags making the lines longer.
Yes, A little is done already. I did a few bits ‘by accident’ The i18n’d editor strings are in Editor.Properties. The tricky bits are all done, it’s just the hard grind of extracting all the strings.
Of course, doing it a little at a time, it helps to know where you are up to and what strings still need to be done.
All of which is what the $NON-NLS-x$ tags are for
Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@uws.edu.au