Community
Participate
Working Groups
Created attachment 183415 [details] Example application to demonstrate the problem When read the OSGi-Spec on this http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html Equinox is not handling the default locale appropriately. Let's assume we have a bundle with: OSGI-INF/l10n/bundle.properties OSGI-INF/l10n/bundle_de.properties A call to b.getHeaders(Locale.ENGLISH.toString()) must return the values from the de-Properties file! I know that this is strange but this is how the thing is speced and how ResourceBundle.getBundle() is working too. Please note that this change has a really big impact because it does NOT allow people to get english translations if their default locale is german and they have the german language packs installed! So if equinox changes this to follow the spec we need to ship with bundle_en.properties by default. You'll find a test bundle attached - I think the main error is BundleLocalization which makes the same error.
For better understanding here's the code parts: --- Bundle b = FrameworkUtil.getBundle(Application.class); BundleContext ctx = b.getBundleContext(); ServiceReference<BundleLocalization> ref = ctx.getServiceReference(BundleLocalization.class); BundleLocalization localization = ctx.getService(ref); Locale.setDefault(Locale.GERMAN); ResourceBundle resBundle = localization.getLocalization(b, Locale.ENGLISH.toString()); System.err.println(resBundle.getString("Bundle-Name")); System.err.println(b.getHeaders(Locale.ENGLISH.toString()).get("Bundle-Name")); --- This prints the english text though in reality it should print the german one!
I agree with your assessment and also think such a change in behavior will be quite bad given all of our bundles in eclipse use something like plugin.properties without specifying _en
What about adding a switch and e.g. Eclipse 4.0 could turn on this switch to get standard spec'ed behavior? We both agree that changing the behavior fo this API is a bad idea but having Equinox not following the OSGi-Spec is also. My very problem is that I have to spec how our e4 translation service should spec the language lookup and though I like the current Equinox behavior much more I'd also like to stay compatible with Standard Java's ResourceBundle spec.
(In reply to comment #3) > What about adding a switch and e.g. Eclipse 4.0 could turn on this switch to > get standard spec'ed behavior? > > We both agree that changing the behavior fo this API is a bad idea but having > Equinox not following the OSGi-Spec is also. I could also look to changing the specification if we think this behavior makes more sense for bundle manifest translations. > > My very problem is that I have to spec how our e4 translation service should > spec the language lookup and though I like the current Equinox behavior much > more I'd also like to stay compatible with Standard Java's ResourceBundle spec. Another option is to add a flag like you suggest but instead of a switch for overall behavior we could add a property that specifies what the default locale is for the .properties files that specify no locale (i.e. plugin.properties). For example, we could consider having something like the following: equinox.locale.map.default.to=en The name of the option is junk, but my intention is to have an option that allows you to specify what the implicit locale is for default properties files. For example, this would treat all plugin.properties files as if they were also plugin_en.properties files. We could default this to "en" and if you really wanted to override it you could. Otherwise we need to get every bundle to add an empty plugin_en.properties file to their bundle.
[...] > > > > My very problem is that I have to spec how our e4 translation service should > > spec the language lookup and though I like the current Equinox behavior much > > more I'd also like to stay compatible with Standard Java's ResourceBundle spec. > > Another option is to add a flag like you suggest but instead of a switch for > overall behavior we could add a property that specifies what the default locale > is for the .properties files that specify no locale (i.e. plugin.properties). > For example, we could consider having something like the following: > > equinox.locale.map.default.to=en > Ok. This sounds like a good plan. Should we discuss this with a greater audience? because even with this there might be people who are buffeled because their text language has changed.
(In reply to comment #4) > Another option is to add a flag like you suggest but instead of a switch for > overall behavior we could add a property that specifies what the default locale > is for the .properties files that specify no locale (i.e. plugin.properties). Makes sense. Should it default to 'en'?
(In reply to comment #6) > (In reply to comment #4) > > Another option is to add a flag like you suggest but instead of a switch for > > overall behavior we could add a property that specifies what the default locale > > is for the .properties files that specify no locale (i.e. plugin.properties). > > Makes sense. Should it default to 'en'? That is my suggestion. If you want it to default to nothing then you have to specify an empty string, I guess. Any suggestions on the configuration option? equinox.locale.map.default.to is really bad ;-)
(In reply to comment #7) > Any suggestions on the configuration option? > equinox.locale.map.default.to is really bad ;-) equinox.defaults.locale -- all defaults in a common namespace? equinox.locale.default
Perhaps the term "root" should be used. For example, plugin.properties is the root properties file. Maybe equinox.root.locale=en and "en" is the default if not specified. The term "default" is too easily confused with the default locale set by the VM or Locale.setDefault.
(In reply to comment #9) > Perhaps the term "root" should be used. For example, plugin.properties is the > root properties file. Maybe equinox.root.locale=en and "en" is the default if > not specified. The term "default" is too easily confused with the default > locale set by the VM or Locale.setDefault. +1 from me on this.
(In reply to comment #9) > Perhaps the term "root" should be used. For example, plugin.properties is the > root properties file. Maybe equinox.root.locale=en and "en" is the default if > not specified. The term "default" is too easily confused with the default > locale set by the VM or Locale.setDefault. I suggested 'default' because of Locale.[gs]etDefault, but you're completely right: it would likely cause confusion. +1 to "root" from me too.
Created attachment 184272 [details] Patch This patch adds a configuration option equinox.root.locale that defaults to "en". If set to empty string then the search order for the properties file is this bn + "_" + Ls + "_" + Cs + "_" + Vs bn + "_" + Ls + "_" + Cs bn + "_" + Ls bn + "_" + Ld + "_" + Cd + "_" + Vd bn + "_" + Ld + "_" + Cd bn + "_" + Ld bn Where bn is this bundle's localization basename, Ls, Cs and Vs are the specified locale (language, country, variant) and Ld, Cd and Vd are the default locale (language, country, variant). If Ls equals the value of equinox.root.locale then the following search order is used: bn + "_" + Ls + "_" + Cs + "_" + Vs bn + "_" + Ls + "_" + Cs bn + "_" + Ls bn bn + "_" + Ld + "_" + Cd + "_" + Vd bn + "_" + Ld + "_" + Cd bn + "_" + Ld bn If equinox.root.locale=en and en_XX or en is asked for then this allows the root file to be used instead of falling back to the default locale.
Patch released.
