[jbosstools-dev] [i18n] NON-NLS warnings by module

[Sean Flanigan]

Hi Rob,

Thanks for cleaning up JMX!  I see you've even enabled NON-NLS errors.

You were asking on IRC about the 2 warnings in archives.  See 
/packaging-convert/src/org/jboss/tools/archives/JBossIDEtoTools.java

That package seems to be an odd-man-out (util rather than plugin), but 
it does live under trunk/archives, which is why it ended up in the results.

About the "dozen or more" errors: I don't think the String 
Externalization wizard always removes NON-NLS comments when 
externalizing a string.  Something like that, anyway.  And if something 
trigger code reformatting, Eclipse doesn't move the NON-NLS comments to 
follow the string.

So it's not hard for those warnings to accumulate.  Find Broken 
Externalized Strings can pick these things up, among other problems.

Sean.

On 06/09/2009 04:32 AM, Rob Stryker wrote:
> I was quite horrified to find JMX had 74 remaining errors. They've now
> been fixed.
>
> Interestingly, over a dozen or more of these errors were because NON-NLS
> was put on a line it didnt' need to be, rather than a string missing
> externalization.
>
> Max Rydahl Andersen wrote:
>>> G'day
>>>
>>> To help me gauge how much work is left in
>>> https://jira.jboss.org/jira/browse/JBIDE-3557, I have modified all
>>> the projects' .settings (in my local workspace) to enable NON-NLS
>>> (unexternalized string) warnings, and counted the number of warnings
>>> for each module.
>>>
>>> Here's a spreadsheet if anyone's interested:
>>>    http://spreadsheets.google.com/ccc?key=r8p7PNL8gpWp61vrYehBjVw
>> ouch - you make it looks so clear that i hurts...
>>> I would ask for help to count these warnings automatically as part of
>>> the Hudson build, but it's probably not worth the effort for a
>>> temporary issue.  (Tracking for all sorts of warnings might be
>>> though...)
>> Yes, I got a long list of warnings/errors I would like to enable
>> *cross* project but I haven't found a good way of doing that (beyond
>> adding a .settings file to every project which is very much overkill
>> and unmaintainable IMO)
>>
>> Nick - got any suggestions ?
>>
>>> However, I do think it would be worthwhile to enable NON-NLS *errors*
>>> in the Hudson build, progressively, as each module is cleaned up.
>>> This would help to ensure the module stays clean[1].  Does this sound
>>> possible/practical?
>> When we got the build separated out in modules i'm all for this - but
>> for now where eevery build depends on everything else to build this
>> would be too invasive at this point in time.
>>> Also, it would be a big help if everyone can keep an eye out for
>>> NON-NLS warnings when changing code (or writing new code).  This will
>>> save me having to go back to modules I've already finished, because
>>> unexternalized strings have crept in.  Thanks!
>> +1
>>
>> /max
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>


-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat