Community
Participate
Working Groups
I am trying to set up NL fragments for plug-ins in my product, and the process is very tedious and time-consuming. Some PDE tooling is needed in this area. It would be good to provide a wizard that generates NL fragments for plug-ins en masse. In the wizard: 1. I would be able to select >= 1 plug-in(s) 2. Specify >= 1 locale(s) When I press Finish, PDE would generate 1 fragment per plug-in. - A fragment's symbolic name == the host's symbolicName + ".nl1". - The fragment's version would be the same as that of the host. - Fragment-Host's bundle-version range would be: "[1.0.0, 1.1.0)" if the host's version is 1.0.0 since translations need to be reviewed/updated with a minor release increment. As for the content of each fragment: - The fragment project created should be a simple project, not a Java project. - Assuming the Bundle-Localization header is set to "plugin", PDE would generate a plugin_<locale>.properties file at the root of the fragment for each specified locale and initializes its content by copying all keys from the host's properties file - Repeat the previous step for all properties files containing strings externalized from Java files. Here PDE would also generate the full folder structure for each properties file. cc Kit to see if he has more ideas.
as always, contributions are most welcome ;-)
Jeff, you know better than to invite a manager to code :)
Wassim, please take a look at the Eclipse Babel Project's proposal here http://www.eclipse.org/proposals/babel/ which has just passed the project creation review. PDE currently has some bits and pieces of functions to create NL packs, but not a wizard to bring a plug-in programmer through the whole process. Seeing that PDE is missing this wizard, that's exactly what we were proposing in the "Stream line the creation of National Language (NL) fragments" section of the Eclipse Babel Project proposal. We should coordinate to figure out what function should be added to PDE, and what should be provided by Babel, the Eclipse globalization project.
Kit, the specs in comment 0 would adequately address the 'streamlining' item on the Babel proposal. PDE is in a good situation to have intimate knowledge of plug-ins and manifests and fragments and JDT to get all the pieces in place for you in the fragments. After that, you can get on with the other tasks on your proposal.
won't happen in M3, moving to M4, sorry :(
setting to 3.4
I and a group of 3 students would like to take over this bug. We are starting our final year software engineering project this January and are working on an NL build tool to be committed to the Babel project. This would fit nicely into our project. We are being funded by IBM Ottawa. Chris and Brian, I'll need your acknowledgement so we could start with it beginning of January next year.
Hi Haytham, thank you very much for the offer. We always welcome any help we can get. I have only one slight concern. We are trying to get this into the 3.4 release. The last milestone in the plan (M5) will be on Feb. 8. To have time to review the patch and still test the rest of the build for the milestone, we would need to have this done by Feb 1. Do you think you guys can do this in that amount of time?
Brian, I am sure there will be at least 1 (possibly 2) milestones added. Heck, with a team of 4 people working on it, they will be done in half a day :)
> Heck, with a team of 4 people working on it, they will be done in half a day :) Maybe if they had a team made up of 4 Wassims ;-)
(In reply to comment #10) > > Heck, with a team of 4 people working on it, they will be done in half a day :) > Maybe if they had a team made up of 4 Wassims ;-) Haha I'm pretty sure we're no team of 4 Wassims here. Here's the picture, we could get this done if we were to focus solely on it, but we have to go through the whole software engineering development process in addition to documentation we will be providing to the professor for thr purpose of the course (and the larger Babel NL build tool we are working on). So not to give false promises, depending on the amount of work this wizard demands, M5 is hard to meet (we are fulltime students with 6 courses as well :D). Isn't there an M6 to be scheduled towards the end of March? If so and if this feature is not delivered into M5, we will gladly take over the bug to deliver for M6. We are more than happy to work on the feature but it all depends on whether you are willing to postpone this feature to M6 or not.
Let's just code and see where it goes with some patches to the bug. Brian and I will do our best to help guide you guys. By the way, welcome to PDE :)
Assigning to Haytham. When I was trying to create NL fragments by hand, I came very close to jumping out the window. I am looking forward to this feature.
>Isn't there an M6 to be scheduled There will more milestones being scheduled and M5 is not a code deadline but an API freeze i.e. API that's in M5 can't be changed afterwards but new stuff can be added.
Sounds good, we will start working on it in January and keep you guys posted about progress.
Created attachment 86531 [details] org.eclipse.pde.ui.patch Here's a basic patch to get you guys started. All this does is add a new action called "Internationalize..." with a system.out I recommend you guys replace the system.out with a wizard to do the actual internationalization :) Let me know if you need help.
Created attachment 86640 [details] Minor changes to the menubar paths and grouping
(In reply to comment #16) > Created an attachment (id=86531) [details] > org.eclipse.pde.ui.patch > Here's a basic patch to get you guys started. All this does is add a new action > called "Internationalize..." with a system.out > I recommend you guys replace the system.out with a wizard to do the actual > internationalization :) > Let me know if you need help. Thanks for the patch Chris, it really helped :) I found a few problems with the patch. I was receiving an invalid menu extension error when a project or MANIFEST.MF context menu is opened. In addition, when a project context menu is opened the grouping for the nl action wizards is inconsistent with what is set in the other views. I attached a patch with the minor fixes. Hopefully we will start laying out the design/classes we need in order to implement the wizard during this weekend and get your feedback on it...
Haytham, be careful of Chris. He may be trying to sabotage your work with bad patches :)
Hi, My name is Danny Borges and I'll be acting as Business Analyst on the project team Haytham previously mentioned. Our team has come up with a set of preliminary domain questions in hopes of refining our requirements. Chris or Brian, could you please assist us? 1. Do we retrieve the list of plug-ins from the user's workspace or from the Eclipse install? 2. Do we retrieve the list of locales from our own defined external file or does PDE provide a mechanism for doing so? 3. If no host properties file is present, should we create one by invoking the externalize strings wizard prior to generating locale-specific properties files? Also, please correct us if we're wrong, but we're assuming values in the host properties file will be copied to all locale-specific properties files with no alterations. 4. The bug says "generate full folder structure for each properties file". Could you please elaborate on what structure should be used? For example, we've found an image (http://www.eclipse.org/articles/Article-Speak-The-Local-Language/images/figure001.png) which shows a flat structure for several NL fragments and a tree structure for another? 5. Once NL fragments are generated, should they only be saved to the user's workspace? Thanks in advance.
> My name is Danny Borges and I'll be acting as Business Analyst on the project > team Haytham previously mentioned. Our team has come up with a set of > preliminary domain questions in hopes of refining our requirements. A pleasure to meet you David :) > 1. Do we retrieve the list of plug-ins from the user's workspace or from the > Eclipse install? I would say you would want to do both. > 2. Do we retrieve the list of locales from our own defined external file or > does PDE provide a mechanism for doing so? Why would you use an external file. In PDE, we do this in a few places: private static String[] getLocales() { Locale[] locales = Locale.getAvailableLocales(); String[] result = new String[locales.length]; for (int i = 0; i < locales.length; i++) { Locale locale = locales[i]; StringBuffer buffer = new StringBuffer(); buffer.append(locale.toString()); buffer.append(" - "); //$NON-NLS-1$ buffer.append(locale.getDisplayName()); result[i] = buffer.toString(); } return result; } I also opened bug 215232 to refactor this out in a common util method. > 3. If no host properties file is present, should we create one by invoking the > externalize strings wizard prior to generating locale-specific properties > files? Also, please correct us if we're wrong, but we're assuming values in the > host properties file will be copied to all locale-specific properties files > with no alterations. If no host properties file is present, I'd assume you would just create one yourself using similar code found in the externalize strings wizard. Your assumption is correct about the properties being copied. > 4. The bug says "generate full folder structure for each properties file". > Could you please elaborate on what structure should be used? For example, we've > found an image > (http://www.eclipse.org/articles/Article-Speak-The-Local-Language/images/figure001.png) > which shows a flat structure for several NL fragments and a tree structure for > another? I'll have to double check with the NL team, but I believe you have to create the folder structure if you're using anything but the standard plugin_*.properties... ie., images or help documents go there. This is what happens when you put the magical $nl$ in your plugin.xml > 5. Once NL fragments are generated, should they only be saved to the user's > workspace? Yes, all work should be done in the "work"-space :) I hope this provides you enough to get started with a patch so Brian and I can review and provide better feedback.
>I'll have to double check with the NL team, but I believe you have to create >the folder structure if you're using anything but the standard >plugin_*.properties... ie., images or help documents go there. This is what >happens when you put the magical $nl$ in your plugin.xml Translated "properties files" should be suffixed with the locale name. That's the standard Java Resource Bundle way of searching the translated resource bundles. Eclipse enhanced the searching capability for translated markup files (HTML/XML) since we cannot add any suffix to an HTML file name (like welcome.html -> welcome_ja.html) because that will break the links in the HTML files. When the special variable $nl$ is added to the search path, Eclipse will search the nl folders for the translated markup files.
We created a page to select the plug-ins to internationalize (workspace and external plug-ins) following similar format to the import plug-ins wizard. We passed the selected list of plug-ins onto the ExternalizeStringsWizard to externalize any non-externalized plug-ins. The final step is to open the last page prompting the user to select a list of locales from the total available locales. Since the number of locales is large, we are following a format similar to the first page where the user would have the full list of locales in the left TableViewer adding what they wish to the list of selected locales in the TableViewer to the right. This is the block of code we used for initializing the TableViewer for the list of plug-ins: fAvailableListViewer = new TableViewer(table); fAvailableListViewer.setLabelProvider(PDEPlugin.getDefault().getLabelProvider()); fAvailableListViewer.setContentProvider(new ContentProvider()); fAvailableListViewer.setInput(PDECore.getDefault().getModelManager()); fAvailableListViewer.setComparator(ListUtil.PLUGIN_COMPARATOR); We are facing a problem when trying to setInput for the table viewers on the locale page. The plug-ins TableViewer takes a PluginModelManager as input. We are unsure about what to pass as input for the Locale TableViewer, and about what functionality should this input be providing to the TableViewer since PluginModelManager seems to be highly specialized for plug-ins and it is difficult to extract what is needed for locales. Any tips would be appreciated asap.
Do you have a patch as a sample to work with? It's easier to work with code than words ;)
(In reply to comment #24) > Do you have a patch as a sample to work with? It's easier to work with code > than words ;) Yeah sure thing, I attached a patch with what we have so far. You might want to apply the previous patch I had uploaded before applying this one, since HEAD in our source control included that patch.
Created attachment 90235 [details] Locale page started
Hi Haytham, can you make sure your patch just works against HEAD? I'm having a difficult time applying the patch and just making sure things work against HEAD. The code within the patch looks promising!
Sure thing Chris, we're working on updating what we have to cvs head and generating a new patch. As soon as this is done we'll be adding the new patch to the bug. As a side note, I was wondering if PDE provides any specific mechanism to access the content of external plug-ins. In our case, we want to copy the contents of the plugin.properties file of an external plug-in not in the workspace (com.ibm.icu.source for example). In what we have right now, we are invoking an import on the external plugin into the workspace as a project, and hence we access the properties file and copy its content into the created fragment project. If there is some way to do that without using an import, it would be really helpful. Do you know of a better way to do that?
Created attachment 90711 [details] A patch partially implementing the proposed InternationalizationWizard Here's a patch which should apply cleanly to HEAD.
Guys, can we stick to Java 1.4? PDE has a required execution environment of 1.4 so we can't use the fancy Java 5.0 features like for each loops. How did you get PDE to compile properly as its BREE is set directly and should've complained when you used 5.0 features ;) The logic in org.eclipse.pde.internal.ui.nls.NLSFragmentsGenerator.internationalizePlugins() could be improved. Importing plug-ins into your workspace is crazy :) Every plug-in model should have a getInstalLocation() on it where you can get the location of the plug-in. From there, you can use typical Java IO file manipulation APIs to do things. Does that help? It looks like there's good progress being made. We just need to sync up so I can get things to compile against HEAD :) This time, we got the HEAD part right, we just missed on the VM level part ;) Thanks for the hard work guys!
Created attachment 90764 [details] Patch with 1.4 compliance This should work nicely against HEAD. It complies to java 1.4. Thanks for the tips Chris, we'll look into accessing the properties file for external plug-ins by standard java IO manipulation (for both jars and folders rather than importing plug-ins to the workspace. I hope with this patch you can address the issue we have relating to populating the TableViewer on the locale page. Thanks
(In reply to comment #31) Awesome Haytham, thanks! I will look at this ASAP and try to initially target it for M6. Note that I'm on vacation already and will be back next Wed so don't be upset if I don't reply immediately. I'm heading out for a week of snowboarding in Whistler :D If you have time when I come back, maybe we can setup a VNC/Netmeeting/Skype session and chat about things.
I also would like to participate in the summit. I will be in Prague next week though. So Skype is preferable. Failing that, we could fly Haytham in :)
(In reply to comment #33) > I also would like to participate in the summit. > I will be in Prague next week though. So Skype is preferable. Failing that, > we could fly Haytham in :) Although skype sounds intriguing, I would definitely prefer the "flying Haytham in" Wassim proposed ;) No worries Chris, we can have a chat session next week after you come back. Enjoy your flightS guys!
Created attachment 91762 [details] Most recent pde wizard patch Hi Chris, Here's the most recent patch we have (1.4 compliance and works nicely against HEAD). A few notes on the patch: - The finish button is hard-coded to be true for testing purposes now, so you can select the list of plug-ins and click finish and thos will be internationalized (the nl fragment projects are generated along with the locale properties files in 3 hard-coded languages for now). - As you suggested, we eliminated the importation mechanism and we are using file I/O to manipulate external plug-in contents. - A usability issue we detected is the fact that the manifest file for each created fragment is opened automatically, which would cause performance issues for a large subset of plug-ins being selected. NewProjectCreationOperation should be edited so that it does not call openFile((IFile) fModel.getUnderlyingResource()); in our case. Is it possible to add a constructor to that class, which we may use to set a value prompting the project creation operation not to open the created manifest file when internationalizing plug-ins? - Our only issue now is with populating the second page of the wizard with the locales (the table viewer issue previously mentioned), so it would be great to get your feedback on how to fix this.
Awesome Haytham! Now that I'm back from vacation I can continue to look at this :)
will review soon, currently at EclipseCon :( Sorry for the wait!
Created attachment 93695 [details] Patch implementing the desired features. As far as we can tell, here's a patch which implements the required functionality. It should apply cleanly to HEAD and, since we consider it done, any screwyness should be considered a bug. Your feedback would be appreciated (in particular Wassim/Chris).
Cool, something to review once M6 is out the door. You'll be the first feature in line for m7 :)
I've been watching this bug and had a few minutes this afternoon so I decided to give it a whirl. I had a few problems with the patch (changes to PDEUIMessages and the plugin.xml seem to be missing), but was able to get it running. On the surface this seems like a great addition, but I have a one big question. Why only copy the plugin.properties file to the new nl fragment? What if I am using bundle.properties instead? Or have utilized the Bundle-Localization manifest header and specified an entirely different location for the file? (The OSGi default is OSGI-INF/l10n/bundle.properties.) Also not being copied are any .properties files that contain externalized strings from the source code. This tool feels a bit useless when its scope of files copied to the fragment is so narrow.
Not having played around with the patch, I do agree with comment 40. As per the original description of this enhancement (comment 0), copying over properties files from the Java source folders is very important, as it is the most painful. As for the plug-in's localization files, there is no reason to hardcode "plugin.properties" in the logic (if it is in fact hardcoded). Just retrieve the value of Bundle-Localization header and append ".properties" to it.
Thank you Amber and Wassim for your feedback. We're working on addressing some of your issues as we speak. We have a quick question though. We're starting to wonder why it is someone would want to internationalize an external Eclipse plug-in [see comment 21], and not just workspace plug-ins. We don't see a potential use case right now, as after all, we believe a person interested in internationalizing an Eclipse plug-in would most likely already have the project in their workspace (i.e. project developers). The support for external plug-ins substantially complicates the tool... is it worth it?
The use cases are certainly real and valid. If I am creating NL-fragments for my product, I shouldn't need to import the entire universe into my workspace for it to work. A product contains hundreds and /or thousands of plug-ins at times, and all those imported plug-ins have a lot of Java code. So importing them comes at a big compiler cost. Having said that, I can see that supporting externally plug-ins is more work. However, if it is seen as substantial, then it may be that we are over-complicating the implementation. In any event, while the external plug-in use case is very important and real, there are only so many hours in the day and only a subset of that can be allocated toward this task. So saying that it only works on a workspace plug-in would be sufficient for 1.0 release. It would be a big improvement over what we have now. A deluxe full solution can always come after.
Thanks Wassim - great feedback. We'll have an updated patch as soon as possible...
I agree with Wassim that there are use cases for internationalizing external plug-ins, but would also forfeit that option in favor of the suggestions from my previous comment 40.
Created attachment 95610 [details] Addresses issues in comment #40 Here's a patch that addresses the issues raised in comment #40. This is accomplished by copying all of the properties files (other than build.properties) to the corresponding location in the newly created NL Fragment project and appending the locale string. In particular this strategy, captures OSGI-INF/bundle.properties just as easily as it gets properties that included in package directories (eg. org/eclipse/pde/internal/ui/PDEUIMessages.properties). We also copy over resource files. After consultation with some of the people at the Ottawa Lab we've decided that the resource filters should be as follows by default: Exclude java, class, property files, plugin.xml and anything in /bin Include other xml and html files. While not currently implemented we plan on allowing the user to configure the resource filters in a third, but provide the sane defaults discussed above. For those that don't have an up to date version of pde kicking around in their workspace, the output of running the current version of the tool on org.eclipse.jdt.ui (a plug-in external to the workspace) can be seen here: http://www.flickr.com/photos/zacherates/2404445386/sizes/o/ I do have a couple of questions: Does the output look sensible? Currently, when copying properties files from plug-ins in the workspace the resulting properties files end up under the source folder eg. /src/org/eclipse/pde/ui/PDEUIMessages.properties, whereas if the same plug-in was external, the properties files would end up in the root eg. /org/eclipse/pde/ui/PDEUIMessages.properties. Should the tool create source directories in the NL fragments for external plug-ins, eliminate the source directories in the NL fragments for the workspace plug-ins, or leave them as-is (inconsistent)? Does the resource filter scheme seem reasonable? It was suggested that the tool might simply ignore resources and force the developer to copy those resources to be translated by hand as the resource copying is possibly noisy and not nearly as valuable as copying the properties.
Just a heads up Chris, all four members of our team will be working over the summer at jobs which will contractually prevent us from contributing to the Eclipse project. Consequently, none of us will be available to fix issues with patch between the end of April and the beginning of September. Therefore, even if the Wizard is feature complete before M7 (and right now the only feature outstanding is the filters page) it might be advisable to push this to early 3.5 rather than trying to include it in Ganymede. Any thoughts?
If the wizard does not make it into Ganymede, I am going to be very sad and may switch to Netbeans.
(In reply to comment #47) > Just a heads up Chris, all four members of our team will be working over the > summer at jobs which will contractually prevent us from contributing to the > Eclipse project. Consequently, none of us will be available to fix issues with > patch between the end of April and the beginning of September. No problem. Thanks for your work. I will file an IPZilla CQ for this latest patch. Once that is done, we can commit it and work with it... if the CQ is done in time for M7 there should be no issues in putting it in. Thanks for your work! btw, Wassim, I will be sad (along with the EMF team) if bug 109137 doesn't get in and will switch to Netbeans ;d
I love this Internationalization wizard so much. It is exactly how I imagined it would be :) Nice work, everyone! However, I am a bit concerned about the wizard's esthetics. It looks a bit unpolished: 1. On the first page of the wizard: i. Mnemonics are missing ii. There is no need for a group for the name template. A simple label/text field would suffice. iii. Some words are uppercased when they shouldn't. It is quite inconsistent. Labels are typically written like sentences, where only the first letter of the first word is uppercased. [I know there is general inconsistency like that in the SDK, but at least in every wizard, the case is consistent). iv. 'Internationalize' is misspelled in the label of the right viewer. v. No need for a trailing period in the label next to the checkbox at the bottom. vi. The state of the checkbox has amnesia. It is not persisted from one invocation of the wizard to the next. vii. Replace 'asking' with 'warning' in the 'Overwrite .... without asking' button. 2. On the second page of the wizard: i. a lot of wasted real estate at the bottom. The viewers should take up the entire height. ii. the two lists really need icons to look prettier. Instead of finding the flag of every country :), I suggest using the globe icon that is associated with the html browser in Eclipse for every entry in the list. 3. General: i. The context help button (?) in the wizard does not work ii. The icon in the wizard banner is not appropriate. See if you can find a large version of the globe icon. iii. The context menu item 'Internationalize' should appear below 'Externalize Strings..." since it is a less common action.
I'm sorry but his will have to wait for 3.5 due to the IP due diligence process at Eclipse :( We don't have time to include this for 3.4 has M7 is feature freeze and is due early next week. Thanks for the contribution and this will be one of the first things we look at in 3.5 :)
Created attachment 116831 [details] Addresses issues in comment #50 This patch addresses the issues that Wassim raised. We had an issue earlier where labels weren't showing up, but against CVS PDE, they work fine.
Cool! Will review in 3.5M4!
The contribution looks good! I filed a CQ (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2819) to make sure it goes through the IP process. Once it gets approved, I will make some polish change and commit the patch for M4.
Thanks Chris, That's great to hear.
Aaron, you may need to confirm everyone who wrote this code and that they agree to the EPL. I've listed you and Haytham as the contributors.
Aaron and Haytham, can you confirm that: 1. They authored 100% of the code contribution (developed from scratch) 2. They are donating it to Eclipse under the EPL
We (Aaron, Haytham, Danny, Robbie) confirm that: * We authored the code from scratch. * We are donating the code to Eclipse under the EPL.
(In reply to comment #58) > We (Aaron, Haytham, Danny, Robbie) confirm that: > > * We authored the code from scratch. > * We are donating the code to Eclipse under the EPL. Aaron, is there any way you can get Haytham, Danny and Robbie to make this comment also on the bugzilla entry? The IP Team needs to hear from them individually.
(In reply to comment #59) > (In reply to comment #58) > > We (Aaron, Haytham, Danny, Robbie) confirm that: > > > > * We authored the code from scratch. > > * We are donating the code to Eclipse under the EPL. > Aaron, is there any way you can get Haytham, Danny and Robbie to make this > comment also on the bugzilla entry? The IP Team needs to hear from them > individually. I, Haytham, confirm that: * We authored the code from scratch. * We are donating the code to Eclipse under the EPL.
(In reply to comment #59) > (In reply to comment #58) > > We (Aaron, Haytham, Danny, Robbie) confirm that: > > > > * We authored the code from scratch. > > * We are donating the code to Eclipse under the EPL. > > Aaron, is there any way you can get Haytham, Danny and Robbie to make this > comment also on the bugzilla entry? The IP Team needs to hear from them > individually. > I, Danny, confirm that: * We authored the code from scratch. * We are donating the code to Eclipse under the EPL.
Thanks guys! That only leaves Robbie... anyone know where he is :)?
(In reply to comment #62) > Thanks guys! > That only leaves Robbie... anyone know where he is :)? He'll be back tonight and we'll make sure to have him confirm as well :)
I, Robbie, confirm that: *We authored the code from scratch. *We are donating the code to Eclipse under the EPL.
done. > 20091114 Thanks guys. The code was approved yesterday and I did some cleanup.
(In reply to comment #65) > done. > > 20091114 > Thanks guys. The code was approved yesterday and I did some cleanup. Our pleasure, we will see it in M4 ;)
