Community
Participate
Working Groups
I heard Bundle-ContactAddress is not included in the list of translatable headers in PDE. However I think it should, as the contact address for each locale could be different.
Created attachment 92590 [details] Patch My 0.02$...
BTW it is a UI bug rather than a Build one! :)
As Benjamin says, this is UI. However, consider the generation of individual source bundles. When generating a source bundle, we copy the Bundle-Vendor and Bundle-Name from the original bundle. If you think that Bundle-ContactAddress should also be copied into the generated source bundle, please open another bug on pde/build.
Thanks for the quick patch. Har, this is one of those obscure OSGi header that I bet Simon doesn't even use ;)
waaaaaaittttt a minute. Shouldn't Bundle-ContactAddress be an email address? how is an email address translatable? Tom, what's the status quo from OSGi land?
perhaps it is a different email address in different countries? ie @us.ibm.com vs @fr.ibm.com or something
Obscure indeed, Chris; I never use it. Regarding the value... section 3.2.1.4 of the spec has this to say: Bundle-ContactAddress: 2400 Oswego Road, Austin, TX 74563 The Bundle-ContactAddress header provides the contact address of the vendor. But then, section 6.1.12.4 has this to say: public static final String BUNDLE_CONTACTADDRESS = “Bundle-ContactAddress” Manifest header (named “Bundle-ContactAddress”) identifying the contact address where problems with the bundle may be reported; for example, an email address. There's the chance that people want a different contact address (physical or email) for each locale, but I've never heard of anyone doing that.
omg Austin, TX? Is that BJ's old address ;p?
(In reply to comment #7) > There's the chance that people want a different contact address (physical or > email) for each locale, but I've never heard of anyone doing that. > There's a chance that noo-ne will ever use it (if Simon don't, who will!), but it seems reasonable to allow translation for this header :)
I'm clearly the yard-stick regarding the use of PDE/OSGi features. The reality being that I'm just an enthusiastic user that's found that if you ask nicely you'll often get what you want, especially from the PDE team. But, as they say, "In PDE we do tooling, but our business is people!"
Thanks guys for the effort. But the more I think about it, I should maybe not have filed this request. You can always provide a translated value for that header without PDE putting a rather annoying warning symbol on your project just because you did not localize this text. I always wondered why I should have to translate the Bundle-Vendor name. And then the quick-fix will create a plugin.properties instead of using the Bundle-Localization default OSGI-INF/l10n/bundle.properties that already exists in the project. But that might be another bug. Anyway thanks for the quick response :) As for usage of this header. We use it in case of an error to create an automatic email sending it to the address given in the bundles header without user interaction.
Thanks Philip. I'm late to the discussion. Any header in the bundle manifest can be translated but the specification does have the following caveat. <spec> All headers in a bundle's manifest can be localized. However, the Framework must always use the non-localized versions of headers that have Framework semantics. </spec> For example, Bundle-SymbolicName, Bundle-Version, Import-Package, Export-Package ... have semantic meaning and the framework must always use the non-translated values of these types of headers. The Bundle-ContactAddress has no semantic meaning and could be translated. I agree with Philip's last comment, PDE should not force all translatable headers to be translated. Nothing in PDE is preventing you from providing translation keys to your headers. Chris, is it your intent to flag all translatable headers? If so then you will have to keep a list of headers that have semantic meaning and not flag these. This list is relatively constant for the Framework headers, but other specifications have headers that have semantic meaning also. For example, DS has the Service-Component header. Developers are free to define their own headers also that may have semantic meaning. I'm not sure if it is possible to do this without adding a way to configure the headers with semantic meaning.
Yes, maybe there could be a way in PDE to configure *which* headers it should warn you to be translated. Even project based maybe. But after all more often I turn of the translation warnings altogether if they keep annoying me and make my project look "unclean" with all the warning symbols.
What's with Benjamin's patch? Is it going to be included in one of the next I-builds? Or do you guys have a more configurable solution planned? Like a list of headers that should be translated that can be modified in the PDE preferences rather than being hard-coded?
It seems reasonable to include this one for 3.5M1 However, we should address the need for possibly configuring which manifest headers should be translatable... this is another enhancement IMHO
created 239445 for the configurable translatable bundle-headers
Thanks, committed to HEAD. > 20080724
Created attachment 108355 [details] mylyn/context/zip
