Internationalized error messages - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Internationalized error messages
Date
Msg-id Pine.LNX.4.30.0103082319150.1061-100000@peter.localdomain
Whole thread Raw
Responses Re: Internationalized error messages
Re: Internationalized error messages
List pgsql-hackers
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"));


Comments?  Better ideas?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Use SIGQUIT instead of SIGUSR1?
Next
From: Tom Lane
Date:
Subject: Re: Use SIGQUIT instead of SIGUSR1?