geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [i18n] Hardcoded message strings
Date Mon, 25 Aug 2003 10:45:43 GMT

On Sunday, Aug 24, 2003, at 18:17 Europe/London, Bill de hÓra wrote:

> Simon Brooke wrote:
>> FWIW my opinion is that message localisation should happen as close 
>> to the point where it's printed as possible, so definitely the 
>> printing machine. The other thing is I'm at present dealing with a 
>> number of quite large systems which have been built without thought 
>> to i18n and to which I'm now retrofitting i18n. The method I decided 
>> to use was to use the english language strings as keys into the 
>> resources files which contain other-language variants. I'm now 
>> convinced that was a mistake, and that I should have replaced all 
>> strings with short tokens, which would have been translated into 
>> locale language by a resource file. To be explicit I would now have 
>> three types of keys
>> 	ERR1234 would be an error key, something thrown by an exception which
>> 	 	actually representa failure of the computation.
>> 	MESS1234 would be a message key (used for things like menu
>> 		items, widget names, prombpt strings etc)
>> 	INFO1234 would be an 'informational' key, something thrown by an 
>> exception
>> 		 but expected to be caught.
> Fwiw, I think this is a very good idea and worth adding to the codiing 
> conventions. I came to a similar conclusion last week working on 
> something unrelated to Geronimo. The pattern I'd been seeing in 
> .properties were prefixed keys :
> err.<blah>
> info.<blah>
> print.<blah>
> conf.<blah> (sometimes I hack quick configurations together with 
> string tables)
> But inconsistently applied across projects.

IBM uses a more terse flavour: it only uses a single character for the 
type (I/E/W/A - alert), then a few letters for the product name, then a 
numeric code.

I think it would be a good idea to break down such labels as to the 
package that threw them. So you'd have info.o.a.g.mail.blah, 
err(or).o.a.g.mail.blah etc and so forth. I also think that a 
non-numeric code is advisable, so that it is easier for the (human) 
developer to understand the message:

throw new 

That way, it's easier to 'guess' what the message is than a number, 
which can be mistyped or may not mean anything.

>> This has the downside that it makes the code less easy to read (you 
>> can't see the error messages in the code) but the upside that it 
>> makes the resource files infinitely easier to maintain.
> I don't see this as a downside. Once you start using format strings at 
> all you can argue the indirection makes the code harder to read -  the 
> fact you've consistently applied a naming scheme (one much like 
> logging) doesn't make it worse.

Or you could combine the best of both worlds :-)


View raw message