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
