Thread: Re: [HACKERS] 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
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'
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'