Community
Participate
Working Groups
Created attachment 198970 [details] Screen capture Build ID: I20110628-0800 Using some pseudo translations, we can see that some Java Content Type labels are unexternalized.
Looks like the pseudo translation pack is missing /org.eclipse.jdt.core/plugin.properties . When I add a /org.eclipse.jdt.core/plugin_DE.properties and then start with -nl DE, I see the modified strings.
Markus, I don't see the string in my jar: org.eclipse.jdt.core_3.7.0.v_B61.jar. Is my build too old? Can you give me the key name so I can search for the string?
Strange, I have these strings at the very end of I20110628-0800\plugins\org.eclipse.jdt.core_3.7.0.v_B61.jar\plugin.properties: javaPropertiesName=Java Properties File javaSourceName=Java Source File javaClassName=Java Class File jarManifestName=JAR Manifest File They are referenced in the plugin.xml like this: <extension point="org.eclipse.core.contenttype.contentTypes"> <!-- declares a content type for Java Properties files --> <content-type id="javaProperties" name="%javaPropertiesName" base-type="org.eclipse.core.runtime.text" priority="high" file-extensions="properties" default-charset="ISO-8859-1"/> <!-- Associates .classpath to the XML content type --> <file-association content-type="org.eclipse.core.runtime.xml" file-names=".classpath"/> <!-- declares a content type for Java Source files --> <content-type id="javaSource" name="%javaSourceName" base-type="org.eclipse.core.runtime.text" priority="high" file-extensions="java"/> ... The last change in these strings was in 2005.
Sorry about the previous comment. I got 2 bugs I just opened this morning mixed up :-). I see the strings in the jar now. I will investigate more. Thanks!
Looks like it's a loading problem. If I start with a fresh install of Eclipse and the language pack (for any language), and launch Eclipse in that language (for example, German), then the translations for Java Content Type labels are not loaded. Note that all other Content Type labels are displayed as translated. If I switch to launch Eclipse in English one time, then launch Eclipse in German again, then the translations for Java Content Type labels are loaded.
The org.eclipse.core.contenttype plug-in reads the content types.
Are there sample language packs that we can download to reproduce this problem? The ones on the Babel web site aren't for Indigo, but will they still show the issue?
I've been able to reproduce the problem locally and in single-user mode as well as in the shared install scenario. Oleg, does this issue sound familiar to you? I'm debugging it am in the extension registry code and it doesn't seem to be picking up the contribution on the first run. In this particular case there are 5 fragments to the host bundle (jdt.core) but I'm not sure if that is relavant.
(In reply to comment #8) > Oleg, does this issue sound familiar to you? Nope. This might be a problem with bundle resolution timing or order. As a debug point, for SDK the actual translation is done in the ResourceTranslator class from equinox.common. The bundle processing requests are coming through EclipseBundleListener#addBundle(). The registry relies on bundle resolution process and I think some time ago there were changes with STARTING state. May be that's what causes the issue? (Or fragments not being resolved at the time registry receives notification for the host bundle?)
Created attachment 199427 [details] Stack trace - error in fragment resolution The problem is in the fragment resolution. I can only duplicate the issue on the first Eclipse start; once the bundle info file is reconciled, all works as expected. I added translation packets into drop-in folder and used remote debugging to check the processing. In the attached call stack the ManifestLocalization#findInFragments() line: BundleFragment[] fragments = searchBundle.getFragments(); returns only 2 fragments ("org.eclipse.jdt.compiler.apt", "org.eclipse.jdt.compiler.tool") while in my case there should have been five (two fragments as above + plus three NLS fragments.) It seems that at the time the extension registry is activated, fragments added into drop-in folders are not resolved.
Created attachment 199460 [details] possible fix I think this may be a regression introduced by the fix to bug339211. We record if a host has been processed a bit premature. This prevents us from detecting that another fragment also being resolved actually provides translations to the host. The fix is to not record the host as processed until we have actually caused it to refresh. This fixes the problem for me.
(In reply to comment #10) > Created attachment 199427 [details] > Stack trace - error in fragment resolution > > The problem is in the fragment resolution. > It is a bug in the way the registry processes fragment resolution dynamically after the registry has been started.
(In reply to comment #12) > (In reply to comment #10) > > Created attachment 199427 [details] [details] > > Stack trace - error in fragment resolution > > > > The problem is in the fragment resolution. > > > > It is a bug in the way the registry processes fragment resolution dynamically > after the registry has been started. Hmm... The AbstractBundle#getFragments() returns 2 fragments while there are 5 fragments present. How is that right?
Patch looks good. Released to HEAD.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > Created attachment 199427 [details] [details] [details] > > > Stack trace - error in fragment resolution > > > > > > The problem is in the fragment resolution. > > > > > > > It is a bug in the way the registry processes fragment resolution dynamically > > after the registry has been started. > > Hmm... The AbstractBundle#getFragments() returns 2 fragments while there are 5 > fragments present. How is that right? I assume you mean at the time the registry is starting for the first time? At this point simple configurator already started and installed the bundles based on what was in the initial bundles.info. The initial bundles.info did not contain the NLS bundles. Remember the NLS bundles are installed using that darn dropins mechanism. Stuff from droppins does not get provisioned until the reconciler is run. Once the reconciler runs it installs the fragment NLS bundles and they get resolved. At this point the registry needs to be able to dynamically handle the resolution of the new fragments.
