This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
nbbuild/misc/i18ncheck.pl is very old and crufty and also might be Unix-specific (Perl 5 impl). It has many known problems including false positives inside comments, etc. Suggest that it be reimplemented portably as an Ant task, using a nested <fileset> of Java sources to check, reporting any errors found using file:line syntax so that they can be hyperlinked (e.g. by the Ant <-> NB module). Use of org.apache.regexp.* would be fine, or it could be made more accurate using ANTLR or a similar proper parser (though need to investigate extra bins situation when using ANTLR). Should also add a target to nbbuild/monitor.xml to let it be run easily, scanning all production-quality NB sources.
In a discussion on nbdev, it was discovered that an older version of the i18ncheck.pl didn't find matches in one line comments while the new one does: ./<MyFileName>.java:179: // we "touch" the file. The difference in the script is minimal - it's the same as version 1.7 except that line 101 has the following $_ = $`+"\n";
It might also be nice to handle common patterns where the form editor generation doesn't let NOI18N comments: setFont, setDisabledTextColor, setMnemonic, etc.
Seems that Tim has written YABC (yet another bundle checker) in contrib somewhere.
The checker I wrote isn't really an I18N checker, and would be more appropriate as a GUI in a module (it's a standalone app because I was splitting property sheet across two packages, and it would take less time to write a nice tool for it than to grep and hand-edit the bundle keys that were no longer relevant out of the two files in question). So yes, I wasted time making it pretty, but it was kind of fun. What it does do is scan all the files in a directory, and give you a JTable of all the bundle keys with checkboxes checked for the ones that are actually used in some file. If you click save, it will delete the keys (and their comments) left unchecked (creating a backup Bundle.properties.deleted of them). And it does preserve ordering and comments (you can tell it to alphabetically resort if you want). It could be used in an ant task - though you could build one from it - just use my implementation of Properties (the difference with the JDK one being that it preserves order and comments in the file), and use the table model the JTable without sticking it in a GUI. Then just use the save action code from the GUI - it's the same thing you'd want to run for the task to do its actual work. You'd need to delete/bypass (maybe) the GUI that pops up a dialog if there are two different copies of the same key with different values to let the user choose which one to keep. The only thing is, I don't think this issue is actually about deleting bundle keys, is it?
There are two things that are needed: 1. Finding non-I18N strings and reporting them. 2. Finding unused bundle keys, usually forgotten after some refactoring. Each such instance should be reported as a possible error, with file and line number. IMHO both items should be treated at once. An Ant task would be fine, though a tasklist plugin would also be helpful.
Nice, but we do not plan to work on it in a future - wontfix