Community
Participate
Working Groups
Hi, Sean Flanigan did a lot of work [0] to flag some non-externalized strings in Eclipse plugins. I found out that it was possible for the Java compiler and PDE to flag non externalized strings as warnings or errors. By default they are ignored. Dear AC, please discuss the possibility to push the non-externalized strings flag as a warning from now on on I-Builds, and as an error for RC builds. [0]: http://dev.eclipse.org/mhonarc/lists/babel-dev/msg00598.html
This is a matter of policy between Babel and the projects participating on the Release Train. We cannot force every user of JDT / PDE to externalize Strings. Forwarding to cross-project for discussion. One idea to resolve this would be providing a *.epf file of default Preferences (including default warning levels) that projects should import and/or apply to their projects. Another idea is asking all projects to have a common set of flags / warnings defined on project level. Technically, bug 194414 or bug 245405 could help here. But I believe that the policy needs to be sorted out by the participating train projects / projects participating in Babel / the Planning Council first.
(In reply to comment #1) > This is a matter of policy between Babel and the projects participating on the > Release Train. We cannot force every user of JDT / PDE to externalize Strings. Certainly not. This would only happen on the headless builds for projects that participate to the release train. > > Forwarding to cross-project for discussion. > > One idea to resolve this would be providing a *.epf file of default Preferences > (including default warning levels) that projects should import and/or apply to > their projects. Another idea is asking all projects to have a common set of > flags / warnings defined on project level. > > Technically, bug 194414 or bug 245405 could help here. But I believe that the > policy needs to be sorted out by the participating train projects / projects > participating in Babel / the Planning Council first. > That all sounds good. I think the Planning Council would be the right entity to deal with this stuff. Not sure how to add that to their agenda for their next call though ? (the wiki page doesn't give the impression it is possible to add items for discussion)
Oisin, can you please have this examined during the next call of the Planning Council ?
I think things like this are best handled as "education" to the projects, that's its available, that it can be useful to most. Plus, I think our "requirements" should only be stated in terms of the end-goal ... and I think we already say strings must be externalized (or, NL ready). The actual method by with projects accomplish this is up to them. Antoine, if you prepare a "how to" wiki page, we can link to it from the list of requirements so teams can find it easier (even if in Eclipse 'help'?). That's my advice. But appreciate the suggestion ... and help!
(In reply to comment #4) Is this what was decided during the call ? Or just your advice ?
(In reply to comment #5) > (In reply to comment #4) > Is this what was decided during the call ? Or just your advice ? > Both. Some made comments how they "can't" use it for some code (or, isn't practical) mostly because it puts too much noise in files that have lots of strings that are "//NON-NLS". Some wondered if we should make is a "should do", but, we agreed we should keep requirements as "end results", and not methodology. But we all were looking for ways to raise the visibility of this issue, as well as Babel in general, so we thought an "education page" with information and pointers to other pages would help ... if you agree.
(In reply to comment #6) > > Some made comments how they "can't" use it for some code (or, isn't practical) > mostly because it puts too much noise in files that have lots of strings that > are "//NON-NLS". If noise is a concern in files that have many non-externalizable strings, then the @SuppressWarnings("nls") annotation applied to the class makes the text very quiet. Perhaps some improved support for this annotation in the Externalize Strings wizard would help?
(In reply to comment #7) > If noise is a concern in files that have many non-externalizable strings, then > the @SuppressWarnings("nls") annotation applied to the class makes the text > very quiet. > > Perhaps some improved support for this annotation in the Externalize Strings > wizard would help? Excellent suggestion - so I have just reported bug 263722. Thanks!
No action planned, see comment #6
