error messages not only English

That sounds like a good idea.

How about having them stored in a new system table (say pg_errormsg) which
contains each possible error in all the supported languages.

While this sounds good for end users, it is an absolute nightmare for somebody trying to
give support. Or what would you do if someone told you:
I get:
FEHLER: Des vastehts ihr nie, weu des Wiena Dialekt is.
and now my program won't respond anymore.

Anyway, we are still missing the first step in this direction: enumerate ERROR messages.

Andreas

Added to TODO.

Hi all,

I see that PostgreSQL mainly gives error messages in English, I see also that
in some cases there's the possibility to configure it to give messages in
other languages like global.c that may be configured to give messages in
German.
MySQL gives the possibility to configure it using an external file containing
the messages by specifying it using the parameter LANGUAGE=<language>
where <language> is one of the following:

czech
english
french
germany
italian
norwegian
norwegian-ny
polish
portuguese
spanish
swedish

It will be great if we could have also this feature on PostreSQL.
I'm available to help on translation to Portuguese, Spanish and Italian.
Jose'

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

On Fri, 22 May 1998, Bruce Momjian wrote:

Added to TODO.

Hi all,

I see that PostgreSQL mainly gives error messages in English, I see also that
in some cases there's the possibility to configure it to give messages in
other languages like global.c that may be configured to give messages in
German.
MySQL gives the possibility to configure it using an external file containing
the messages by specifying it using the parameter LANGUAGE=<language>
where <language> is one of the following:

czech
english
french
germany
italian
norwegian
norwegian-ny
polish
portuguese
spanish
swedish

It will be great if we could have also this feature on PostreSQL.
I'm available to help on translation to Portuguese, Spanish and Italian.

Hrmmm...create an 'include/utils/errmsg.h file that is a link created by
configure based on a --with-language=<insert your language here>...the
file would contain:

#define <ERRMSG TOKEN> "Error message in your language"

Then use the TOKEN with elog...

If we did something like this, we wouldn't have to convert all at once
either, just as we pick up a new one...

Hrmmm...create an 'include/utils/errmsg.h file that is a link created by
configure based on a --with-language=<insert your language here>...the
file would contain:

#define <ERRMSG TOKEN> "Error message in your language"

Then use the TOKEN with elog...

If we did something like this, we wouldn't have to convert all at once
either, just as we pick up a new one...

Also only a small set of error messages get sent to users. Most of them
are rarely used or are for debugging.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

On Fri, 22 May 1998, Bruce Momjian wrote:

Hrmmm...create an 'include/utils/errmsg.h file that is a link created by
configure based on a --with-language=<insert your language here>...the
file would contain:

#define <ERRMSG TOKEN> "Error message in your language"

Then use the TOKEN with elog...

If we did something like this, we wouldn't have to convert all at once
either, just as we pick up a new one...

Also only a small set of error messages get sent to users. Most of them
are rarely used or are for debugging.

True, but having those also in various languages makes us more
"admin friendly" *grin*

If this looks good, I'll setup the appropriate configure related
issues...let me know...

True, but having those also in various languages makes us more
"admin friendly" *grin*

If this looks good, I'll setup the appropriate configure related
issues...let me know...

One nice thing is that all the error messages are wrapped up in elog(),
so we can easily extract them, and make macros for them.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

On Fri, 22 May 1998, Andreas Zeugswetter wrote:

That sounds like a good idea.

How about having them stored in a new system table (say pg_errormsg) which
contains each possible error in all the supported languages.

While this sounds good for end users, it is an absolute nightmare for somebody trying to
give support. Or what would you do if someone told you:
I get:
FEHLER: Des vastehts ihr nie, weu des Wiena Dialekt is.
and now my program won't respond anymore.

Anyway, we are still missing the first step in this direction: enumerate ERROR messages.

We can have both of them for example:
-----------------------------------------------------------------------------
err no. message
-----------------------------------------------------------------------------
ERROR #342 - "Column number too big" -- English
ERROR #342 - "Numero de columna demasiado alto" -- Spanish
FEHLER #342 - "Die Spaltennummer ist zu gross" -- German
ERRO #342 - "Numero de coluna alto demais" -- Portuguese
ERRORE #342 - "Numero di colonna troppo alto" -- Italian
-----------------------------------------------------------------------------
Ciao, Jose'

The Hermit Hacker wrote:

Hrmmm...create an 'include/utils/errmsg.h file that is a link created by
configure based on a --with-language=<insert your language here>...the
file would contain:

#define <ERRMSG TOKEN> "Error message in your language"

^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Then use the TOKEN with elog...

If we did something like this, we wouldn't have to convert all at once
either, just as we pick up a new one...

Sometime ago we told about using error codes in elog (and put them to the
client) - this would very useful for non-interactive applications...

How about to implement this ?

Vadim

The Hermit Hacker wrote:

Hrmmm...create an 'include/utils/errmsg.h file that is a link created by
configure based on a --with-language=<insert your language here>...the
file would contain:

#define <ERRMSG TOKEN> "Error message in your language"

^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Then use the TOKEN with elog...

If we did something like this, we wouldn't have to convert all at once
either, just as we pick up a new one...

Sometime ago we told about using error codes in elog (and put them to the
client) - this would very useful for non-interactive applications...

How about to implement this ?

Added to TODO. The first part was already there:

* allow international error message support and add error codes

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Andreas Zeugswetter wrote:

Anyway, we are still missing the first step in this direction: enumerate ERROR messages.

BTW, are error codes in standard ?

Vadim

Yes, there is a preferred standard, it defines char(5) strings that correspond to specific errors.
It is in SQLSTATE in ESQL/C programs and conforms to X/Open and ANSI.
It consits of numbers and upper case letters only. The first 2 digits are the Class the, last 3
are the subclass. I think only the Class is in the norm.

e.g.: 02000 No data found or End of data reached
00000 Success.
0A000 Feature not supported

You get additional info through:
exec sql get diagnostics :num_rows_affected = ROW_COUNT [, :num = NUMBER, ...];

The integer SQLCODE + the sqlca structure is from an old ANSI norm:
0 Success
100 end of data
< 0 execution not successful

0 warning

Andreas
----------
Von: Vadim Mikheev[SMTP:vadim@krs.ru]
Gesendet: Dienstag, 26. Mai 1998 18:43
An: Zeugswetter Andreas SARZ
Cc: 'hackers@postgresql.org'; 'mimo@interdata.com.pl'
Betreff: Re: [HACKERS] error messages not only English

Andreas Zeugswetter wrote:

Anyway, we are still missing the first step in this direction: enumerate ERROR messages.

BTW, are error codes in standard ?

Vadim

Vadim writes:

Andreas Zeugswetter wrote:

Anyway, we are still missing the first step in this direction: enumerate ERROR messages.

BTW, are error codes in standard ?

Some are. There is also a format for standard severity levels etc.

On the internationalized message topic, how about storing all the messages
in a text file. This file would be opened (but not read) at startup by each
backend (and the postmaster). To change languages, just open a different
file. ELOG would scan the message file to get the message text corresponding
to an errog code. Since reading a pre-opened text file does not depend on
much of the system working, it should work even in the catastrophic cases.

To keep performance good for frequently issued messages, the backend could
keep an in memory LRU cache of a few dozen messages and only search the file
when the message was not in the cache. This cache could be a simple
sequentially searched array as error messages are not a real performance
influence except in extremely pathological cases.

-dg

David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"Of course, someone who knows more about this will correct me if I'm wrong,
and someone who knows less will correct me if I'm right."
--David Palmer (palmer@tybalt.caltech.edu)

On Tue, 26 May 1998, David Gould wrote:

Vadim writes:

Andreas Zeugswetter wrote:

Anyway, we are still missing the first step in this direction: enumerate ERROR messages.

BTW, are error codes in standard ?

Some are. There is also a format for standard severity levels etc.

On the internationalized message topic, how about storing all the messages
in a text file. This file would be opened (but not read) at startup by each
backend (and the postmaster). To change languages, just open a different
file. ELOG would scan the message file to get the message text corresponding
to an errog code. Since reading a pre-opened text file does not depend on
much of the system working, it should work even in the catastrophic cases.

Do you want me to post a brief outline on how Java does this? It uses
plain text files to handle internationalized messages, and can handle
regional dialects as well?

--
Peter T Mount peter@retep.org.uk or petermount@earthling.net
Main Homepage: http://www.retep.org.uk
************ Someday I may rebuild this signature completely ;-) ************
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk

Oh dear, even I'm answering myself now ;-)

On Tue, 26 May 1998, Peter T Mount wrote:

On Tue, 26 May 1998, David Gould wrote:

Vadim writes:

Andreas Zeugswetter wrote:

Anyway, we are still missing the first step in this direction: enumerate ERROR messages.

BTW, are error codes in standard ?

Some are. There is also a format for standard severity levels etc.

On the internationalized message topic, how about storing all the messages
in a text file. This file would be opened (but not read) at startup by each
backend (and the postmaster). To change languages, just open a different
file. ELOG would scan the message file to get the message text corresponding
to an errog code. Since reading a pre-opened text file does not depend on
much of the system working, it should work even in the catastrophic cases.

Do you want me to post a brief outline on how Java does this? It uses
plain text files to handle internationalized messages, and can handle
regional dialects as well?

Here goes:

Java 1.1 introduced Internationalization using Resource Bundles. Now these
could be either custom classes, or defined using Property Files (which are
more like what what were looking at here).

Anyhow, this is a brief description on how this works. I'm not
suggesting this is the way to go, but presenting this here as
something to base this on.

First, a few files:

# The file colours.properties is the default bundle.
# As I'm British, I've made my own locale the default (re: Colour)
colours=Colours
colours.red=Red
colours.green=Green
colours.blue=Blue

# The file colours.en.US.properties overides the default locale.
# As you can see it overides only one resource, as the other
# defaults are fine for this locale
colours=Colors

# The file colours.fr.properties handles the French locale
colours=Couleurs
colours.red=Rouge
colours.green=Vert
colours.blue=Bleu

When searching for a property, it follows the following algorithm:

basename_language_country_variant
basename_language_country
basename_language
basename

Entries found first take precedence. Only the lowest level needs to have
every possible entry.

There is a downside to this scheme (as far as PostgreSQL is concerned), in
that we could have several files open, although error handling isn't
something that needs to be too fast.

Now for formatted messages:

In Java, this is handled by the MessageFormat class. It takes a static
string, and inserts into the correct places additional strings to form the
final message.

ie:

In English: "Error at line {0} in file {1}."
In French: "Erreur: {1}: {0}."

--
Peter T Mount peter@retep.org.uk or petermount@earthling.net
Main Homepage: http://www.retep.org.uk
************ Someday I may rebuild this signature completely ;-) ************
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk

On Wed, 27 May 1998, Vadim Mikheev wrote:

Andreas Zeugswetter wrote:

Anyway, we are still missing the first step in this direction: enumerate ERROR messages.

BTW, are error codes in standard ?

Of course. And IMHO PostgreSQL should use them.
On "A Guide To The SQL Standard (C.J.Date) chapter 22 - Exception Handling"
there's an explanation of STATUS CODE. (SQLCODE and SQLSTATE values)

Jose'