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

[Randy Hudson <hudsonr@xxxxxxxxxx>]

In my message class, the constant's
value is evaluated at runtime. so:

public static final String LABEL_HELLO;

static {
        LABEL_HELLO
= lookupTranslationByKey("hello key");
}

I just noticed that in the new proposal,
constants aren't constant. I think it is possible to declare the fields
as final, but still overwrite them using reflection.  See Field#setAccessible(boolean).
 Perhaps only non-static finals can be modified this way.

Perhaps a singleton approach would make
sense.  The call to NLS.initializeMessages() could be right there
in the message class.

-Randy

Bob Foster <bob@xxxxxxxxxx>
Sent by: platform-core-dev-admin@xxxxxxxxxxx

02/23/2005 12:21 PM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-core-dev] New platform NLS support

John Arthorne wrote:
> The property files are still around (mainly because this is a convenient
> and familiar format for translators).  I said the only *extra*
work was 
> to define the field for the key.  As before, the key must also
exist in 
> the properties file.  This is where the "opportunity for
tooling" comes 
> in to help keep these files in sync :)

I'm still missing a piece. Translation is typically done after the fact,
without access to the source code or requiring a re-compilation. 
Further, the selection of which national resource to use must be 
dynamic. It sounds very much like in this scheme key names are constants
in the code, like:

public static final String KEY1 = "hello";

How does this change to "bonjour" when I am in France?

Bob Foster

_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev