Re: Internationalized error messages - Mailing list pgsql-hackers

At 23:49 08/03/01 +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

snip

>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.

Most other DB's (I'm thinking of Oracle here) pass the code unfiltered to 
the client anyhow. Saying that, it's not impossible to get psql and other 
interactive clients to strip the error code anyhow.


>At the end, the i18n part would actually be pretty easy, e.g.,
>
>     elog(ERROR, "XYZ01", gettext("stuff happened"));
>
>
>Comments?  Better ideas?

A couple of ideas. One, if we have a master list of error codes, we need to 
have this in an independent format (ie not a .h file). However the other 
idea is to expand on the JDBC's errors.properties files. Being 
ascii/unicode, the format will work with just some extra code to implement 
them in C.

Brief description:
------------------------

The ResourceBundle's handle one language per file. From a base filename, 
each different language has a file based on:
        filename_la_ct.properties

where la is the ISO 2 character language, and ct is the ISO 2 character 
country code.

For example:

messages_en_GB.properties
messages_en_US.properties
messages_en.properties
messages_fr.properties
messages.properties

Now, here for the english locale for England it checks in this order: 
messages_en_GB.properties messages_en.properties messages.properties.

In each file, a message is of the format:

key=message, and each parameter passed into the message written like {1} 
{2} etc, so for example:

fathom=Unable to fathom update count {0}

Now apart from the base file (messages.properties in this case), the other 
files are optional, and an entry only needs to be in there if they are 
present in that language.

So, in french, fathom may be translated, but then again it may not (in JDBC 
it isn't). Then it's not included in the file. Any new messages can be 
added to the base language, but only included as and when they are translated.

Peter