Bugzilla – Full Text Bug Listing
| Summary: | Review of the metadata translation support | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> |
| Component: | p2 | Assignee: | Dave Stevenson <dstevens> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ajtarter, john.arthorne, Kevin_McGuire, susan |
| Version: | 3.4 | Flags: | pascal:
review+
susan: review+ |
| Target Milestone: | 3.4 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Pascal Rapicault
Created attachment 93829 [details]
Initial patch for metadata localizations changes items 2 - 7
This patch incorporates changes for the following issues:
2) The name of the translation IU should not have _manifest_ in the name. Maybe
something like _translation_.
3) The host requirement should be on the org.eclipse.equinox.p2.iu namespace
instead of the org.eclipse.equinox.p2.eclipse.type
4) Each translation should have a capability indicating which language(s) it
contains the translation for.
5) Investigate the ability to put multiple languages in an IU. For example, the
key could be suffixed by the language.
6) A default translation IU needs to be identified such that even when the
language we are looking for is missing, we do not end up showing the key. For
example that could occur if the initial IU is authored in French but the system
is run in English and French translation is available.
7) See if the default translation can not be made available directly from the
IU being translated, thus reducing the number of IUs in the repo.
The queries used by the UI have not been fixed to get the translations (in progress) but I want to get additional testing of the metadata in various scenarios but nightly build.
Patch released in HEAD. Leaving open to release the rest of the query support on Monday. Created attachment 94301 [details]
Patch for UI query and dialog to get translated IU properties.
I have attached a patch with the changes to the query in IUPropertyUtils used by the UI to get translated properties for an IU. Also added a few more calls to getIUProperty() from the IUGeneralInfoPropertyPage.
aren't we done here? Not quite done. Still need to 1). support group IUs (ie. extract translations from features) which will be a bit of work; and 2). add the parameter to the metadata generator for specifying the default locale (trivial). *** Bug 227584 has been marked as a duplicate of this bug. *** Created attachment 99221 [details]
Patch for localization of group IUs generated from features
Pascal to review the patch for localization of group IUs Does the last patch contains everything necessary? I have built the resulting plug-ins and ran with it and the UI does not show the translations, instead it shows the key. It looks like the metadata is properly generated though. Created attachment 99406 [details]
Additional places in the UI that need localized values
Susan, I have run Dave's code and it works for me, however I would appreciate if you could take a look at the UI changes. I have released the patch with some additional tweak to translate the patches. In general, it looks good. But it looks like you may have missed one. IUDetailsLabelProvider.getToolTipText will retrieve the tooltip text according to a previously set property. This should also be run through the IUPropertyUtils. Also, it wasn't clear to me if provider and contact should be localized? The admin UI (IUPropertiesGroup) does not use localized strings and probably should. This is not critical for 3.4 but may confuse us when using admin UI? Created attachment 100028 [details]
UI patch with additional changes suggested by Susan
Using IUPropertyUtils.getProperty for IUDetailsLabelProvider and admin UI (IUPropertiesGroup), plus earlier UI changes.
Looks good, Dave. Ok to relase. Dave, should strings be translated in I20080513-2000 or are there still changes to be released and/or metadata to be dealt with? The support for processing the translations and generating localized metadata was in for I20080513-2000. However, I don't think the generated repos include translations - for example, the latest language packs available for download are from 3.2.1. I have been testing localization with the 3.2.1 translations and a back-door drop of 3.4 translations that Pascal had. When I connect to the eclemma update site (http://update.eclemma.org) and browse it the feature id is not translated in the User UI. I ask because when I look at the content of http://update.eclemma.org I see %featureName whereas I used to see the real name. I didn't know if that was related to this change, change in the site itself, the metadata generation, etc.... Also the eclipse update site is not a problem because it uses an older version of the generator (M7). I was working on a different bug where I needed to install Eclemma Java Code Coverage. I observed that the IU was shown as %featureName. I installed it. I restarted and opened the update dialog. In the installed list, the IU is shown as featureName (not %featureName). And in the available list, the IU is now shown as Eclemma Java Code Coverage. So in the available list it seems like timing? In the installed list not so sure what is going on. Both views use IUDetailsLabelProvider, but the installed list uses the default IUColumnConfig and the Available list uses its own. Dave, if I need to help here, let me know. Created attachment 100281 [details]
Correct handling of feature jars
An incorrect call to getDirPropertyLocalizations(..) instead of getJarPropertyLocalizations(..) in FeatureParser caused feature translation property files to be missed. Corrected that.
patch was reviewed and released by Pascal.
Full support for metadata translation is now implemented. Created bug 232173 to capture enhancement for specifying default locale as an argument to the metadata generator. |