Re: [platform-core-dev] New platform NLS support

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

That's a bit tricky because you would
then have multiple classes with the same name, loadable by the same class
loader.  Special magic in the platform class loaders would probably
be needed.  It's certainly possible with the new scheme to assign
the field ahead of time and avoid the initialization that currently happens
on load - for example if you were already shipping different versions of
your product for each language. I think a major value of plug-ins using
an Eclipse NLS API, is that if we come up with further optimizations later
on, they can be applied to the immediate benefit of all with little further
effort.

Also keep in mind that if you have no
attachment to the .properties file format, java.util.ResourceBundle allows
you to use a pure class-based system that does a language-specific class
lookup to load the bundle, as you suggest.  The Eclipse API is a middle
ground that has very good runtime memory characteristics but still retains
the .properties file format that is familiar and often favoured by translators.


Bob Foster wrote on 23/02/2005 01:12:08 PM:

> Did you consider allowing the message class to be loaded dynamically
at 
> startup, like fragment classes? This would require that translators
run 
> the tool and compile a class per properties file, but would reduce
the 
> need for runtime interpretation to zero. (The default class, if loaded,
> would simply do what it does now.)
>