Bugzilla – Full Text Bug Listing
| Summary: | Mock 3.2 : Extension Point Description in the New Extension dialog not translated | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Kit Lo <kitlo> | ||||||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | baumanbr, camle, caniszczyk, cdeadmin, curtis.windatt.public, Karice_McIntyre, platform-releng-inbox, steven.wasleski, Tod_Creasey, wassim.melhem | ||||||||
| Version: | 3.2 | Keywords: | helpwanted | ||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | stalebug | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Kit Lo
Created attachment 39074 [details]
ExtensionPointDescriptionFromPDE.doc.user
Created attachment 39075 [details]
ExtensionPointDescription in New Extension dialog
the content of pde.doc.user or any doc plugins is not relevant to how schemas are located. The description you see in the wizard is retrieved from the extension point schema. The schemas are located in the source plug-ins that we ship (e.g. org.eclipse.rcp.source, org.eclipse.pde.source). are we shipping translated schemas? If so, how and where? No, we don't translate the schemas. well, there you go. We can't do anything about this then. I find it surprising that the extension point html docs themselves are being translated, not the schemas. After all, the html docs are generated via an ant task by reading and transforming the schemas. Note that even if we translate the schemas, where would they go, and would we need to start putting $nl$ in the schema attribute of <extension-point> elements? >Note that even if we translate the schemas, where would they go, and would we
need to start putting $nl$ in the schema attribute of <extension-point>
elements?
You gave me the answer why we don't translate the schemas :-)
what's the plan here? I am going to close as nothing can be done unless schemas are translated. Could we leave this bug open but defer it for consideration to 3.3? The field that shows the description from the schema is new for 3.2. This is the first time we have had interesting fields (from a translation point of view) extracted from the schema for use in the UI. We have historically not translated content from the source plugins (the schemas come from the source plugins) because they are considered ISV only plugins that are not generally seen by end users. PDE is a bit different than most other features in that all of its end users are ISVs. I don't believe we have the time to completely think through all the ramifications of starting to translate this stuff for 3.2. sure. We actually had this functionality in 3.1.x but via a context menu item in that same wizard. In 3.2, we made it more visible for a better workflow. Also note that another use of schema-related information directly in the UI is in tooltips as you hover over attribute names in the manifest editor. This function has existed since 3.0 Screenshot to follow. Created attachment 39837 [details]
tooltip
Tooltip content is extracted from schema
*** Bug 143294 has been marked as a duplicate of this bug. *** After taking a look at the source code, I think the problem is in org.eclipse.pde.internal.core.SourceLocationManager. In my 3.3 M5 environment, the following list is returned by getExtensionLocations(): eclipse\plugins\com.ibm.icu.source_3.6.0.20061215\src eclipse\plugins\org.eclipse.cvs.source_1.0.0\src eclipse\plugins\org.eclipse.jdt.source_3.3.0.v20070205-180-GKeyrSg2mvoVKQM\src eclipse\plugins\org.eclipse.pde.source_3.3.0.v20061114-080-87cMNDNcOD-KLPM\src eclipse\plugins\org.eclipse.platform.source.win32.win32.x86_3.3.0.v2007020-6BKMZVNUaZs1qhM\src eclipse\plugins\org.eclipse.platform.source_3.3.0.v2007020-6BKMZVNUaZs1qhM\src eclipse\plugins\org.eclipse.rcp.source.win32.win32.x86_3.3.0.v20070116-fFIEHGCmfQISbVP\src eclipse\plugins\org.eclipse.rcp.source_3.3.0.v20070116-fFIEHGCmfQISbVP\src If it could find all the src folders in the NL fragments too, then the translated schemas could be loaded. For example, I expect the extension locations list to be something like this: eclipse\plugins\com.ibm.icu.source.nl1_3.6.0.v20070228\nl\zh\HK\src eclipse\plugins\com.ibm.icu.source_3.6.0.20061215\src eclipse\plugins\org.eclipse.cvs.source.nl1_1.0.0.v20070228\nl\zh\HK\src eclipse\plugins\org.eclipse.cvs.source_1.0.0\src eclipse\plugins\org.eclipse.jdt.source.nl1_3.3.0.v20070228\nl\zh\HK\src eclipse\plugins\org.eclipse.jdt.source_3.3.0.v20070205-180-GKeyrSg2mvoVKQM\src eclipse\plugins\org.eclipse.pde.source.nl1_3.3.0.v20070228\nl\zh\HK\src eclipse\plugins\org.eclipse.pde.source_3.3.0.v20061114-080-87cMNDNcOD-KLPM\src eclipse\plugins\org.eclipse.platform.source.win32.win32.x86.nl1_3.3.0.v20070228\nl\zh\HK\src eclipse\plugins\org.eclipse.platform.source.win32.win32.x86_3.3.0.v2007020-6BKMZVNUaZs1qhM\src eclipse\plugins\org.eclipse.platform.source.nl1_3.3.0.v20070228\nl\zh\HK\src eclipse\plugins\org.eclipse.platform.source_3.3.0.v2007020-6BKMZVNUaZs1qhM\src eclipse\plugins\org.eclipse.rcp.source.win32.win32.x86.nl1_3.3.0.v20070228\nl\zh\HK\src eclipse\plugins\org.eclipse.rcp.source.win32.win32.x86_3.3.0.v20070116-fFIEHGCmfQISbVP\src eclipse\plugins\org.eclipse.rcp.source.nl1_3.3.0.v20070228\nl\zh\HK\src eclipse\plugins\org.eclipse.rcp.source_3.3.0.v20070116-fFIEHGCmfQISbVP\src Can we fix this in 3.3? yes, now that the schemas are being translated, this problem can be fixed. where can we download the translations from? I can go ahead and look at this one for 3.3M7 We don't have the schemas translated yet. I just want to confirm if PDE is planning to fix that in 3.3, then we will send them for translation. the layout in comment 15 would work. Each NL fragment must declare an org.eclipse.pde.core.source extension though like the following: <extension point = "org.eclipse.pde.core.source"> <location path="$nl$/src" /> </extension> Wassim, NL fragment does not have a plugin.xml that we can specify the "org.eclipse.pde.core.source" extension point. I tried changing the extension point for org.eclipse.rcp.source to:
<extension point = "org.eclipse.pde.core.source">
<location path="$nl$/src" />
</extension>
but org.eclipse.pde.internal.core.SourceLocationManager#getExtensionLocations() is still not picking up the translated schemas in org.eclipse.rcp.source.nl1/nl/<locale>/src .
Do we need to add some more code in getExtensionLocations() to do that?
Kit, I believe you can put this in the fragment's fragment.xml file. I created the fragment.xml file and added the "org.eclipse.pde.core.source" extension point. SourceLocationManager#getExtensionLocations() still didn't find the translated schema files until I did the following 2 things: 1) use "org.eclipse.core.contenttype_3.2.100.v20070319" folder name instead of just "org.eclipse.core.contenttype" in the src folder 2) change <location path="$nl$/src" /> to <location path="nl/zh/HK/src" /> Files and folders sent for translation do not have version numbers (or else the files will be considered new every time). Can PDE look for folders without the version number too? For 2), PDE probably needs to add code to support $nl$ location path name. There are hundreds of schema files in Eclipse SDK and other Eclipse projects. The volume is quite high. We need to resolve the schema source searching problems ASAP if we want the schema files translated in 3.3. I'm raising the severity to major. Problem #1 in comment #23 would affect the way we package and build the schema files. For the schema source location path extension point problem, I'm wondering why we can't add $nl$ to the English schema source extension point, for example in eclipse\plugins\org.eclipse.rcp.source. If there is a reason for that, a change has to be added to the NL build tool to add this extension point. Hi Kit, Just to be clear, no matter what route we take, PDE will have to do some work to support it. $nl$ is not supported yet. Now, as for what we should do: I think the easiest thing would be for the plug-in, not the fragment, to change its source location from 'src' to '$nl$/src'. PDE would expand the nl variable and look for the schemas in the plug-in and its NL fragment and locates the best match. Incidentally, why not 'src/$nl$'? cc the releng team to comment on how easy it would be to change this in the build. Also, folders must have a version number. Otherwise, if the product ships with multiple versions of a plug-in, which is common, it can be a mess. also a reminder about comment 6: Schema files are used to generate the HTML files for the sdk. You would no longer need to translate the html files directly once the schemas get translated. Technically there should not be new UI strings in maintenance releases. Therefore, the NL packs should work for all maintenance releases of a major Eclipse release (like 3.3.*). If we add the version number to the translated schema folder names, the NL packs will not work on maintenance releases. We need to think of a solution to that. According to the "Locale specific files" description at http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/product_def_nl.htm , "Each file should have exactly the same file name, but be located in subdirectories underneath the nl sub-directory in the fragment's root." Therefore, I think the plug-in should change its source location from 'src' to '$nl$/src'. >Schema files are used to generate the HTML files for the sdk. You would no longer need to translate the html files directly once the schemas get translated. Are you referring to the "Extension Points Reference" section of the on-line doc? But, those HTML files are not generated dynamically during runtime. How can we load the translated schemas and generate the HTML files during runtime? >Are you referring to the "Extension Points Reference" section of the on-line
>doc? But, those HTML files are not generated dynamically during runtime. How
>can we load the translated schemas and generate the HTML files during runtime?
the HTML files are generated at build time from the schemas via an ant task. The ant task is called pde.convertSchemaToHTML and is found in the org.eclipse.pde.core plug-in.
So once the schemas get translated, you can use this ant task to generate the HTML files and put them in the doc plug-ins.
>the HTML files are generated at build time from the schemas via an ant task.
>The ant task is called pde.convertSchemaToHTML and is found in the
>org.eclipse.pde.core plug-in.
Actually, we may need something in reverse. The "Extension Points Reference" HTML files have been translated for many releases. But, the schema files have never been translated before. Could the PDE team provide an ant task to convert the HTML files back to schema files? If that could be done, we could save a lot of translation work of the schema files.
An HTML -> .exsd conversion is not possible. Kit, what's the plan here? We need to wrap up by M7. Two things to note: 1. It's not very likely that all plug-ins in Europa will start pre-pending $nl$ to their source location paths at this point in the cycle. PDE will need to assume an implicit "$nl$/" as a prefix for all schema paths. This will be more costly of course, since we will be searching in more places than we need to. 2. We need to come up with a reasonable solution for the version in the paths. I don't think anyone will doing the $nl$ prepending on a schema file - it is just something that is generally used by the implementation a file lookup (like images). Wassim I think you would need to do it in your support immplicitly should we decide to support it. The question is if schemas schould be translated at all or are they like javadoc that is only in English? This is a hard call because if we think this is like javadoc we should leave it - I am not convinced that there is a lot of utlility in the translation of it. >The question is if schemas schould be translated at all or are they like javadoc that is only in English? Tod, not sure if you are aware, the problem is a PDE dialog is pulling info from the schema files. See https://bugs.eclipse.org/bugs/attachment.cgi?id=39075&action=view If we don't translate the schemas, mixed languages will be displayed in the PDE dialog. That looks really bad. re comment 32: To me, schema descriptions are like Javadoc. re comment 4: These descriptions also appear when you hover in tooltips/infopops as you hover over certain elements in the editor form pages and source pages. Similarly, English javadoc appears in the java editor when you hover over Java elements. Why is it ok for the tooltip to show English? Also, if it's that one small area in the New Extension wizard that is solely causing this crisis, as useful as it may be, perhaps we should contemplate removing it. >Why is it ok for the tooltip to show English? Actually, that's another reason why we have to translate the schemas. I didn't mention that only to give Tod a simplified answer. >Also, if it's that one small area in the New Extension wizard that is solely causing this crisis, as useful as it may be, perhaps we should contemplate removing it. Personally, that solution is okay with me. But, we need other people's opinions. However, if we go with this, we also have to think how to solve the English tooltips for elements in the editor form pages and source pages. >we also have to think how to solve the English tooltips for elements in the >editor form pages and source pages.
Kit, I still don't understand why the English Javadoc everywhere you look/hover in the Java editor is not a problem... Isn't that the same thing?
The main problem reported in the report is the intermixing of English extension point description with translated UI. End-users do not know the implementation. They do not know the paragraph of extension point description is being pulled from the schema file. If we think the extension point description will provide values to the end-users, we should think of a way to extract the info, and also have the mechanism to load the translations ready. That should be the main goal of this bug. I agree that schemas are similar to Javadocs. "Ideally", Javadocs should be translated too. (Once again, "ideally".) But, because of resource constraints and the fact that a lot of the info in Javadocs are very technical and hence may not be easy to translate. We chose not to translate them. I think I can apply the same argument to the tooltips for elements in the editor form pages and source pages. Chris, this might be something that is nice to have if we can figure out the details. Looks like an interesting problem, but there is not enough time/resources for 3.4. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug is marked as stale for some time. If it is still relevant for the current release, please reopen and remove the stalebug whiteboard tag. |