Re: Internationalized error messages

On Thu, Mar 08, 2001 at 11:49:50PM +0100, Peter Eisentraut wrote:
> I really feel that translated error messages need to happen soon.
> Managing translated message catalogs can be done easily with available
> APIs.  However, translatable messages really require an error code
> mechanism (otherwise it's completely impossible for programs to interpret
> error messages reliably).  I've been thinking about this for much too long
> now and today I finally settled to the simplest possible solution.
> 
> Let the actual method of allocating error codes be irrelevant for now,
> although the ones in the SQL standard are certainly to be considered for a
> start.  Essentially, instead of writing
> 
>     elog(ERROR, "disaster struck");
> 
> you'd write
> 
>     elog(ERROR, "XYZ01", "disaster struck");
> 
> Now you'll notice that this approach doesn't make the error message text
> functionally dependend on the error code.  The alternative would have been
> to write
> 
>     elog(ERROR, "XYZ01");
> 
> which makes the code much less clear.  Additonally, most of the elog()
> calls use printf style variable argument lists.  So maybe
> 
>     elog(ERROR, "XYZ01", (arg + 1), foo);
> 
> This is not only totally obscure, but also incredibly cumbersome to
> maintain and very error prone.  One earlier idea was to make the "XYZ01"
> thing a macro instead that expands to a string with % arguments, that GCC
> can check as it does now.  But I don't consider this a lot better, because
> the initial coding is still obscured, and additonally the list of those
> macros needs to be maintained.  (The actual error codes might still be
> provided as readable macro names similar to the errno codes, but I'm not
> sure if we should share these between server and client.)
> 
> Finally, there might also be legitimate reasons to have different error
> message texts for the same error code.  For example, "type errors" (don't
> know if this is an official code) can occur in a number of places that
> might warrant different explanations.  Indeed, this approach would
> preserve "artistic freedom" to some extent while still maintaining some
> structure alongside.  And it would be rather straightforward to implement,
> too.  Those who are too bored to assign error codes to new code can simply
> pick some "zero" code as default.
> 
> On the protocol front, this could be pretty easy to do.  Instead of
> "message text" we'd send a string "XYZ01: message text".  Worst case, we
> pass this unfiltered to the client and provide an extra function that
> returns only the first five characters.  Alternatively we could strip off
> the prefix when returning the message text only.
> 
> At the end, the i18n part would actually be pretty easy, e.g.,
> 
>     elog(ERROR, "XYZ01", gettext("stuff happened"));

Similar approaches have been tried frequently, and even enshrined 
in standards (e.g. POSIX catgets), but have almost always proven too
cumbersome.  The problem is that keeping programs that interpret the 
numeric code in sync with the program they monitor is hard, and trying 
to avoid breaking all those secondary programs hinders development on 
the primary program.  Furthermore, assigning code numbers is a nuisance,
and they add uninformative clutter.  

It's better to scan the program for elog() arguments, and generate
a catalog by using the string itself as the index code.  Those 
maintaining the secondary programs can compare catalogs to see what 
has been broken by changes and what new messages to expect.  elog()
itself can (optionally) invent tokens (e.g. catalog indices) to help 
out those programs.

Nathan Myers
ncm@zembu.com