On Saturday 23 Aug 2003 8:38 pm, Thomas Hawtin wrote:
> Alex Blewitt wrote:
> > I think the only way of achieving this would be to have a
> > formatExceptionInLocale(Locale) method which could choose the
> > translation at print time, rather than at construction time.
>
> I guess getLocalizedMessage() should print a message localized for the
> environment it is called on, rather than the environment the exception
> was originally created in. The exception may o fcourse have been
> serialized. Then there's the question as to whether the message should
> be looked up on the constructing and printing machine.
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.
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.
--
[EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; my other religion is Emacs
