Community
Participate
Working Groups
When selecting 'File - Export' a wizard appears. On its first page I read: "Select an export destination:" Some of the choices are indeed locations (e.g.: File System, Archive). However, most of the choices below name something that I can export (Preferences, Breakpoints, Launch Configs, etc..) Naming the thing you want to export seems to be natural. Naming the destination leaves it up to my imagination what I will be exporting (e.g. 'Archive' is really very unspecific about that). The label should read "Select what you want to export:" (or similar) and all the contributions should consistently name what they can export and optionally where to (e.g. workspace files into archive) The situation is similar with the import wizards.
I agree that the wording is poor here. Not only that, but the layout is confusing, because at first glance it looks as if the destination is a location that should be specified in the filter box in addition to selecting a "type" of export. Destination is not involved at all on the first page, just the selection of what is to be exported. Subsequent pages will prompt for the destination/location or whatever else is needed to complete the export. So I think the work to be done here is rename the labels to prompt for "what you want to import/export." I'm not sure what the proper wording would be. (Kevin?) Perhaps What do you want to export? What do you want to import?
meant to cc: Kevin for input on the wording.
New Gerrit change created: https://git.eclipse.org/r/50775
New Gerrit change created: https://git.eclipse.org/r/50777
Gerrit change https://git.eclipse.org/r/50775 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=eeae4751330e1e02da006346a2ce010f6ec53f1b
Gerrit change https://git.eclipse.org/r/50777 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=fe2dae4ea9a424cf9d77b777624b72530fd266b0
Glad to see this fixed. Shouldn't those patches also be merged in the maintenance branch (small change, low risk, some good UX value...) ?
(In reply to Mickael Istria from comment #7) > Glad to see this fixed. > Shouldn't those patches also be merged in the maintenance branch (small > change, low risk, some good UX value...) ? The problem is that this changes the strings in two very prominent places and hence will look bad in all translated installations (everything translated except the new string which will appear in English). This is not something we want to do for SR1. The Help also needs to be updated in order to consider this bug done.
(In reply to Dani Megert from comment #8) > The problem is that this changes the strings in two very prominent places > and hence will look bad in all translated installations (everything > translated except the new string which will appear in English). This is not > something we want to do for SR1. So that means that this bug is corrected for the default language (English), other languages rely on Babel. Wouldn't it make sense to merge it anyway on maintenance (as it fixes an issue for people who use English - a lot of people), but to keep this Bugzilla open to track translations? > The Help also needs to be updated in order to consider this bug done. @Olivier @Alain: Is this something you can propose as a patch?
(In reply to Mickael Istria from comment #9) > (In reply to Dani Megert from comment #8) > > The problem is that this changes the strings in two very prominent places > > and hence will look bad in all translated installations (everything > > translated except the new string which will appear in English). This is not > > something we want to do for SR1. > > So that means that this bug is corrected for the default language (English), > other languages rely on Babel. > Wouldn't it make sense to merge it anyway on maintenance (as it fixes an > issue for people who use English - a lot of people), but to keep this > Bugzilla open to track translations? No. This is not critical enough to force a mixed GUI on non-English users.
(In reply to Mickael Istria from comment #9) > (In reply to Dani Megert from comment #8) > > The Help also needs to be updated in order to consider this bug done. > > @Olivier @Alain: Is this something you can propose as a patch? Sure, I can take the action. Do you now if the sample project used in the help (JaneQUser ) can be imported directly, without recreating it ?
New Gerrit change created: https://git.eclipse.org/r/57666
What about this bug ? In neon we have now : Select an import wizard Select an export wizard I attach the screenshot.. Must we update the babel project too ?
Created attachment 259075 [details] The export dialog in Neon
I have updated the help also, as requested by Dani, and committed it in the Gerrit change https://git.eclipse.org/r/57666
(In reply to Olivier Prouvost from comment #13) > What about this bug ? > > In neon we have now : > > Select an import wizard > Select an export wizard > > I attach the screenshot.. > > Must we update the babel project too ? Depends who "we" is. I think usually the committers don't do any translations in Babel.
Mass move to 4.6 RC1. We might push out more to 4.7.
Marking as fixed for 4.6 M1. Filed bug 493516 to track the remaining doc work.
