| Loading NL fragments [message #250594] |
Tue, 08 June 2004 13:13  |
Eclipse User |
|
|
|
In eclipse 2.x, translated .properties files used to be packaged in NL
fragments such that all the .properties files are placed into a single JAR
file in the fragment root. This does not seem to work in 3.0.
In 3.0, the Platform.getResourceBundle(Bundle) method does search
fragments for the .properties files, however it does not peek inside JAR
files since it does not utilize a classloader for the search. So, one way
that the translated .properties files can be loaded in 3.0, is if that JAR
file is unzipped into the fragment root. Another way that I got the
properties files to load is to write my own classloader delegating to the
Bundle and then passing that classloader to java.util.ResourceBundle...but
I am sure that this is not the right way to go...and it does not handle
translatable string-references from the plugin.xml files.
So, my questions are:
1. Will the Platform API change to handle .properties files packaged in
JAR files in a fragment? Or would the NL fragments have to be migrated in
some way?
2. Is there a possibility that the Platform API will support a way to load
arbitrary .properties files (i.e. files named other than
"plugin.properties")?
Thanks.
|
|
|
|
| Re: Loading NL fragments [message #251025 is a reply to message #250619] |
Wed, 09 June 2004 10:54  |
| Eclipse User |
|
|
|
Thanks so much for the help.
However, what you've described is exactly what I have (and it was working
in Eclipse 2.x).
My nl fragment, containing translated plugin.properties files, registers
it's jar file in the <library> tag in its fragment.xml. My plugin, in
turn, contains a default plugin.properties file (which is in English).
This default plugin.properties file is not part of a jar file, so it does
not need to be registered in a <library> tag. So, having this setup, the
translations are never loaded...instead, the default plugin.properties
file is loaded, both when using the Platform.getResourceBundle(Bundle) API
call, and when referencing a string from the plugin.xml file using the
'pluginName="%someKey"' notation.
And again, unzipping the jar file into the fragment's root did fix the
problem. Writing my own classloader which delegates to Bundle and passing
it to java.util.ResourceBundle.getBundle() method, also did fix the
problem. But these two methods are just hacks, and cannot be used in
production.
Am I missing anything else in my setup? Is there anything new that I
should take into account? Or is this a bug in 3.0?
Thanks,
------------------------------------------------------------ -------------
Rich Kulp wrote:
> The only properties files that you use getResourceBundle for is for
> plugin.properties.
> All of the other properties files for your code should be in <library>
> jars, both in the base plugin and in the fragments, and then
> ResourceBundle.getBundle() should be used to get those properties files.
> That way they can be in jars in the nl fragments and they will be found.
> However, looking at the code, Platform.getResourceBundle(bundle) should
> still be able to find the plugin.properties files within the fragments
> libraries (as long as the jars are in <library> statements). I haven't
> actually tested it, but it should work.
> Also, it turns out this is very expensive if done from code. Every time
> you call Platform.getResourceBundle() it re-loads the properties files
> from disk. They aren't cached. They have cached them from within the
> plugin.xml (i.e. when referenced through plugin xml such as
> pluginName="%somekey"). So it is best that you don't store any NLS
> properties in the plugin.properties files except for those needed by the
> plugin.xml itself. Any other ones should be stored in properties files
> within your jars. That way those will be cached for you.
|
|
|
|
| Re: Loading NL fragments [message #251112 is a reply to message #251092] |
Wed, 09 June 2004 13:47 |
| Eclipse User |
|
|
|
No, I am trying to get it working without having to hack.
The Platform.getResourceBunde(Bundle) API call *should* be able to handle
JAR files. Also, I don't think the suggested hack would work for string
references from within plugin.xml...such as 'pluginName="%someKey"'.
So, basically, the Eclipse platform has to be able to load translations
from a JAR file, without the end-developer having to code anything at all.
------------------------------------------------------------ --------------
Sam Mesh wrote:
> Use IPluginDescriptor.find() - it is NL aware.
> AFAIK, in 3.X there is no IPluginDescriptor - find the equivalent.
|
|
|
Powered by
FUDForum. Page generated in 0.03912 seconds
Home