Windows (FormatMessage,
String.Format),
Java (MessageFormat)
and ICU (MessageFormat,
umsg) all
provide methods of formatting variables (dates, times, etc) and inserting them
at arbitrary positions in a string. This avoids the manual string concatenation
that causes severe problems for localization. The question is, where to do this?
It is especially important since the original code site that originates a
particular message may be far down in the bowels of a component, and passed up
to the top of the component with an exception. So we will take that case as
representative of this class of issues.
There are circumstances where the message can be communicated with a language-neutral
code, such as a numeric error code or mnemonic string key, that is understood
outside of the component. If there are arguments that need to accompany that
message, such as a number of files or a date/time, those need to accompany the
numeric code so that when the localization is finally at some point, the full
information can be presented to the end-user. This is the best case for localization.
More often, the exact messages that could originate from within the component
are not known outside of the component itself; or at least they may not be known
by the component that is finally displaying text to the user. In such a case,
the information as to the user's locale needs to be communicated in some way
to the component that is doing the localization. That locale information does
not necessarily need to be communicated deep within the component; ideally,
any exceptions should bundle up some language-neutral message ID, plus the arguments
needed to format the message (e.g. date/time), but not do the localization at
the throw site. This approach has the advantages noted above for JIT localization.
In addition, exceptions are often caught at a higher level; they don't end up
being displayed to any end-user at all. By avoiding the localization at the
throw site, it the cost of doing formatting, when that formatting is not really
necessary. In fact, in many running programs most of the exceptions that are
thrown at a low level never end up being presented to an end-user, so this can
have considerable performance benefits. |
