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 I18NException("info.org.apache.geronimo.mail-authentication.failed")
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 :-)
Alex.
