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: