Community
Participate
Working Groups
Stefan's initial contribution of the NLS tooling will go here.
Created attachment 106671 [details] Initial code contribution Here's the initial code contribution. The code was written by me from scratch. The icons have been taken from the Eclipse SDK. The code currently requires Java 1.5. It runs well with Ganymede (Eclipse 3.4).
Created attachment 106672 [details] Short description with screenshots Short description with screenshots
Created attachment 106673 [details] Binary plugin Binary plugin
Great! I had such tooling support on my todo-list once I got to know the internals of the IDE more. It always bugged me that I am not informed about untranslated texts that exist in the base bundle file but are non-existant in others. Now I understand, that if the key does not exist in "bundle_ru.properties" it is searched in "bundle.properties"? What I first had imagined was a "pimped" properties file editor, that does all the escaping for me in the background on "save". But your approach is also interesting. I have to see it in action. It's about time NLS tooling is improved in Eclipse!
Created attachment 107405 [details] Initial code contribution (updated) This update adds lazy loading. Only the currently displayed locales will be loaded. This greatly improves loading performance and memory consumption when a large number of resource bundles is contained in the workspace. Added validation for escape sequences when editing entries. Bug fix: The \ character could not be escaped.
Created attachment 107406 [details] Binary plugin (updated)
moving to the Babel project... someone needs to file a CQ for the contribution to get things started
Isn't Babel project purely web based? Such editor seem more appropriate for the PDE tools.
The Babel project does have a plug for Eclipse called the 'message editor' checked into CVS. I have not personally used the message editor, but the idea (as I understand it) is to allow users to change/translate menus,buttons and other text in Eclipse from within Eclipse. I don't think the plug in has gotten allot of attention in recent months, but it is still there and working to some extent. I would say currently the main focus on the Babel team has been to setup web based system to allow the community at large to help translate Eclipse, but the scope of the project could be a bit broader if we had more Eclipse plugin developers on the project.
As Gabe says, Babel already has plug-ins that cover this area. This has been discussed on the Babel developers list and the consensus was that this work should be contributed into the Babel project and that the plug-ins should be merged. There is quite some work needed on these plug-ins, in particular the needs to integrate with the Babel web servers. There is barely enough resource to support one effort, let alone two efforts split across Babel and PDE. There have already been discussions on how the best parts of both can be merged. I cannot find a CQ so I assume none has yet been submitted. Stefan, are you a committer and can you submit the CQ? If not I will be happy to submit it. Is the attachment to comment #7 the latest?
Nigel, I am not a committer. The most recent code is found in the attachment to comment #6. The attachment to comment #7 contains only the binary plugin.
I have submitted CQ 2573 for this contribution.
Created attachment 109894 [details] Initial code contribution (with fixed copyrights) Fixed copyright headers to show my name instead of "IBM Corporation".
Thanks, Stefan. I think I can now commit this to the repository, pending confirmation from legal. The next stage will then be to merge the stuff. Some ideas have been discussed on the Babel list server. Chris Aniszczyk said he had some ideas, which would be very much appreciated. Any other ideas or comments on the merging would be appreciated. One problem I see is that Pascal's editors are based on one per property file, and Stefan's is project wide. How do we, in the UI, allow both scopes? Should we open the editor based on the current selection, which may be every project in the workspace or may be a single property file?
Let me know when the code is committed and I can't start toying with it. I'm happy to see things move along. It would also be nice to update the Babel site to at least point towards this tooling or talk about it. Currently, when you go to the Babel site, all you know about is the cool translations tool online, but not about the plug-ins.
(In reply to comment #16) > It would also be nice to update the Babel site to at least point towards this > tooling or talk about it. Currently, when you go to the Babel site, all you > know about is the cool translations tool online, but not about the plug-ins. > I have often thought the Babel site should have some information about the Plug-ins that are (or will be) available for Eclipse. Maybe you could open a bug against Babel to add this information, even better if you could come up with what this NLS plug-in can/will do so we can promote it correctly. Since I only work on the web based end of things that is all I really know about (at the moment).
How about something like this on the main Babel page to replace the last paragraph: "The project will include tools and activities that are needed to adapt the Eclipse deliverables to properly run in multiple locales and to translate selected Eclipse projects into multiple different languages (French, Japanese, German, etc). The project tools can also be used for translation of RCP applications. These tools include both a web server through which translations may be contributed, plug-ins that aid developers in the preparation of resource bundles, and a plug-in that allows end-users to contribute translations from within the target application. The project could eventually include tools to aid in the following areas: Enablement testing (e.g. can the software run in different language environments and handle multiple scripts, etc.), translatability testing (is it ready for translation?), translation testing (is the translation acceptable?), and more." I have modified the wiki pages to include a page on the Message Bundle Editor plug-in. This page is very short at present but I will expand it to include Stefan's contribution. We clearly should have a link to the wiki from the web page, though I am not sure if the main page should contain links directly to the pages for each of the two plug-ins, or just a single link to the main page (wiki.eclipse.org/babel). I don't think it really matters as long as it is clear which link one needs to follow to get to the message editor plug-in wiki page. I would have opened a new bug but I am sure Gabe can update the web page is less time than it would take to open another bug :-)
Stefan's code has been checked into CVS. Instructions on installing the plug-in can be found at http://wiki.eclipse.org/Babel_/_Message_Bundle_Editor.
(In reply to comment #19) > Stefan's code has been checked into CVS. Instructions on installing the > plug-in can be found at http://wiki.eclipse.org/Babel_/_Message_Bundle_Editor. Phew, I felt kind of lost since I saw no new plug-ins but after synchronizing against CVS, I see that Stefan's code was committed directly into the org.eclipse.babel.editor plug-in. Is there any particular reason as to why this was done? Also, the plug-in no longer compiles out-of-the-box for me because the project's settings have not been updated to be 1.5 compliant since Stefan's code requires Java 5.
Thanks for pointing out that the .settings from Stefan's code was not checked-in. The original Babel editor plug-in had no .settings and it was explicitly ignored in .cvsignore. I missed this because I work mostly from Package Explorer. I suppose I should use the Navigator view more. I have checked in the settings from Stefan's code. The reason the code was committed into the existing Babel resource editor plug-in is that the consensus was that the plug-ins be merged (as mentioned in comment #11). Stefan's model needs to be merged to take advantage of the back-end features provided by Pascal's code. The UI needs to be merged so that users don't get confused between the two. The Babel team does not at present have sufficient developer resource to maintain two competing plug-ins. Putting the two contributions into the same plug-in is only the first step of this process. We want user feedback on how the UI can best be unified, and we won't get good feedback if we had two plug-ins and users are using just one plug-in, not aware or familiar with the other.
(In reply to comment #21) > I have checked in the settings from Stefan's code. The project is still no good because the project is still configured to use a J2SE-1.4 JRE instead of a J2SE-1.5 JRE. Altering the project's compiler settings does not affect which libraries the compiler should build the project against. > Putting the two contributions into the same plug-in is only the first step of > this process. We want user feedback on how the UI can best be unified, and we > won't get good feedback if we had two plug-ins and users are using just one > plug-in, not aware or familiar with the other. Fair enough.
As Stefan's code has been checked in, I am resolving this bug. There may be a wish for work to further integrate the contribution but such work would be best tracked using separate bug reports.
