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
