Community
Participate
Working Groups
The Eclipse product documentation states that when resolving file names in unpackaged plug-ins that contain a doc.zip archive, the doc.zip is checked first for the file. A plug-in and its fragments are supposed to be equivalent to one logical plug-in but this does not appear to be the case. The documentation for file lookup says: -------------- The help plug-in will look for this file as follows: look in doc.zip for the file /html/ref/ref1.html look for the file ref1.html in the /html/ref sub-directory structure underneath the plug-in directory. http://help.eclipse.org/help31/topic/org.eclipse.platform.doc.isv/guide/help_plugin_files.htm -------------- However, when the default locale file exists in a plug-in doc.zip and the translation exists in an NL fragment that is not in a doc.zip (but has the same Eclipse path) the translated file will not be resolved. This constraint is not defined anywhere in the Eclipse documentation, nor does it seem to be the desired behaviour. Perhaps it is an Eclipse platform or at least documentation bug? Workaround: The only work around I have tried to come up with is to ensure that all fragment files under the 'nl/<locale>' are packaged exactly the same as their corresponding plug-in. Aside: This also causes problems if a plug-in is unpacked (a plug-in directory) and fragments for that plug-in are JAR files. JAR files can not contain doc.zip archives, so the translated material is not found. Having an unpackaged primary plug-in is required in some environments so that the service provider can launch an IEHS with the -plugin_customization flag in the start string. This can lead to problems that would not be apparent following documentation.
Created attachment 54450 [details] sample plugin
Actually this is documented in the link you provided. Under the "National language and translated documentation" section it says "If you are using a doc.zip file, you should produce a doc.zip file for each locale and place it inside the correct locale directory." I recommend (to everyone) switching from using doc.zip files to jarred plug-ins, where you don't have to worry about this any longer. The doc.zip was invented specifically for help before you could jar plug-ins, and as you can see has some restrictions. Resolving as won't fix.
