[news.eclipse.platform] Re: Using Plug-in properties API?

[Paul Webster <pwebster@xxxxxxxxxx>]

Jan Kohnert wrote:
> Thanks for your answer Paul.
>
> Sadly I do not understand this best practice solution.
> Mainly because of two reasons.
> First:
> I've a product running on different language environments. The product 
> is set up at a customer by fitters having in general very view knowlage 
> about eclipse good practiceses. What they want is just one place where 
> every string used by the product is defined so that they can change it 
> to the customers wishes. It is not reasonable to let them scan each 
> package for property files just to performe a view minor tweaks.

You do not make them scan packages.  Adding new language packs in 
eclipse is done by way of fragments i.e. a small directory structure 
made entirely of the language property files and nothing else.

It's not difficult to find the 3 or 5 properties files in a small 
directory structure.

But this bullet isn't about "understanding" the practice, this is more a 
"why I think it might not work for me".

> Second:
> A parts name, a commands desciption,a menus entry and so on. There are 
> all somehow part of the UI. I define their names and descriptions within 
> the plugin.property file. Usage of translated versions of these strings 
> is done automaticly by eclipse. Why is custom generaded UI code (such as 
> view content) less important that it is nor a good practice to let it 
> participate on this very handy mechanism?

the plugin.properties file is for translating information available from 
the OSGi manifest and Equinox Extension Registry.  Now some extension 
points (like org.eclipse.ui.menus) take that information and use it to 
instantiate UI elements, and that's why they're translated there.

But it is not a properties file for translating whatever you want, just 
what comes out of the Extension Registry.  Technically, the Extension 
Registry has nothing to do with the UI (it just happens to be the 
extensible mechanism that all eclipse plugins use to allow contributions 
and to delay loading other plugins).

You can ask for API to access this file if you want ... but I suspect it 
will be marked as WONTFIX (since it's not an appropriate use of this file).

Plus eclipse provides a very handy mechanism ... the NLS class + a 
.properties file allows you to use constants in your ViewPart class 
(say) which are easily scanned and index by the JDT environment.  The 
Externalize Strings wizard will create the class and properties file for 
you, and by using these constants you can examine new strings that 
appear during maintenance without fear of missing them because you 
already have a number of strings in the class.  There are many benefits 
aside from this.


But if you really want to, check out 
http://dev.eclipse.org/newslists/news.eclipse.platform/msg67801.html ... 
it shows how to manually load the standard localization file from a 
bundle (amongst other things).

Later,
PW


--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/workbench.htm