LogStrings have to have unique ids. LocalStrings do not. Right?
It seems that it would be better to fail hard if there is a mistake
between the two files.
Tom
On 8/4/2010 1:52 PM, Byron Nevins wrote:
> What we ought to do is search both files. Anything is better than
> getting an unresolved string at runtime. When a string gets
> moved/upgraded/downgraded from one file to the other we will almost
> certainly forget something now and then and have bugs.
>
> We should be able to do this:
>
> 1) Logger looks through all the LogStrings files. If it can't be
> found it looks through all the LocalStrings files before giving up.
> 2) LocalString helper code looks in the opposite order
>
> Perhaps file an RFE
>
> Anybody have opinions?
>
>
> On 8/4/2010 7:36 AM, Bobby Bissett wrote:
>> Hi all,
>>
>> Just sanity checking: Using StringManager or Strings to get i18n'd
>> text requires LocalStrings.properties, while LogDomains requires
>> LogStrings.properties. Is that correct?
>>
>> So if I want to i18n my log calls but also provide some non-log text
>> (e.g., useful info in toString() method), then I need 2 separate
>> properties files?
>>
>> This didn't occur to me until I tried using Strings.java in some code
>> that already had a logger....
>>
>> Thanks,
>> Bobby
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>