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

[Bob Foster <bob@xxxxxxxxxx>]

Sorry. Should have read that more carefully. Funny how one sees what one 
expects to see, the pattern "public static final String" being so deeply 
ingrained.

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.)

Bob Foster

DJ Houghton wrote:
>>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?
>>
>
>
> The static field is not final and does not have a value set in code...we
> set the value at runtime.
>
> See the following doc for more info:
>
> 
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/3.1/message_bundles.html