Community
Participate
Working Groups
Created attachment 190650 [details] security.nls test bundle We have a case where we are unable to translate the fragment.xml file with another fragment. Consider the following scenario: Eclipse SDK has: - org.eclipse.equinox.security bundle - org.eclipse.equinox.security.macosx bundle org.eclipse.equinox.security.macosx: - has in its manifest: Bundle-Localization: fragment - provides a fragment.properties file with the default English translations We provide another fragment: org.eclipse.equinox.security.nls - has in its manifest: Bundle-Localization: nl_fragment - provides a nl_fragment.properties with its translations - also provides a fragment_fr.properties with translations for the fragment.xml for the macosx fragment When we start Eclipse (with -nl fr) and look in the Preferences (Preferences -> Security -> Secure Storage) and look in the Master Password Providers table, the contents are in English only. If we trace through the code, this list is being populate by going to the registry and calling #getLabel on the ConfigurationElement that is in the Extension Registry. I believe this should be translated at this point.
From my investigation, this appears related (dup?) to bug 285621. - put translations in the drop-ins folder - start Eclipse - we read the bundles and cache a bunch of values in the registry - values cached are English because the translations haven't been installed yet - then we process the dropins and install the translation bundle - Preference page values are shown in English - shut down - start up Eclipse - we check use the cached values so English is used again If you start the workspace with -clean (on the second start and beyond; after the nls bundle has been installed) then you will see the correct behaviour.
(In reply to comment #1) > From my investigation, this appears related (dup?) to bug 285621. > > - put translations in the drop-ins folder > - start Eclipse > - we read the bundles and cache a bunch of values in the registry > - values cached are English because the translations haven't been installed yet > - then we process the dropins and install the translation bundle > - Preference page values are shown in English > - shut down > - start up Eclipse > - we check use the cached values so English is used again > > If you start the workspace with -clean (on the second start and beyond; after > the nls bundle has been installed) then you will see the correct behaviour. This sounds more like bug230421 which should be fixed in 3.5 or later. In bug285621 the workaround should have been to restart the platform.
I confirmed that restarting the workspace with -clean solved the problem.
This is another flavor of bug230421. The difference is that the fragment being added from dropins is providing nls files for another fragment attached to the same host. The fix for bug230421 only checks if the fragment provides nls files for the host, not any of the other attached fragments. This check is done in org.eclipse.core.internal.registry.osgi.EclipseBundleListener.checkForNLSFiles(Bundle, Bundle) We can look for a proper fix for M7.
Created attachment 190913 [details] possible fix This fixes the bug for me. DJ can you give this a try and also review the fix? Thanks.
Created attachment 191166 [details] possible fix (w framework fix) There is a bug in the framework that prevents the previous patch from working when you start with a freshly unzipped (never run) eclipse installation. When you add the attached nls fragment to dropins and run eclipse for the first time the expected translations are still not present for the security preferences. This is because the framework keeps a cache of manifest translation ResourceBundle objects for each bundle. The cache for other attached fragments is not getting flushed when a newly attached fragment is resolved. So when the registry tries to load the translation files it is reusing the empty translation files it tried to look up before the fragment was attached. The fix is to flush the manifest localization cache for the other attached fragments.
Thanks, Tom. The patch looks good. And I've verified that it fixes both my test case as well as Kit's original test case (with the provided data).
Will this be fixed in 4.1 automatically?
Patch released. (In reply to comment #8) > Will this be fixed in 4.1 automatically? Equinox 3.7 (Indigo) feeds into both the 3.7 and 4.1 Eclipse Platform builds. This will be fixed in both the 3.7 and 4.1 versions of the Eclipse Platform.
Note that the fix to this bug introduced bug350946.
