|
|
|
|
|
|
Re: Using Plug-in properties API? [message #325798 is a reply to message #325792] |
Wed, 27 February 2008 13:45 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
|
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/msg67 801.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
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
Powered by
FUDForum. Page generated in 0.03584 seconds