geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill de hÓra <b...@dehora.net>
Subject Re: [i18n] Hardcoded message strings
Date Sun, 24 Aug 2003 17:17:26 GMT
Simon Brooke wrote:

Simon,

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


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


Bill de hÓra



Mime
View raw message