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. That way, you can have multiple language support when users from different countries use the same server? I have done (in other projects), multiple language support in Java, and it's quite simple to implement. -- Peter T Mount, peter@maidstone.gov.uk, peter@retep.org.uk JDBC FAQ: http://www.retep.org.uk/postgres Please note that this is from my works email. If you reply, please cc my home address. -----Original Message----- From: owner-pgsql-hackers@hub.org [mailto:owner-pgsql-hackers@hub.org]On Behalf Of Jose' Soares Da Silva Sent: Friday, May 22, 1998 10:59 AM To: hackers postgres Cc: general postgres Subject: [HACKERS] error messages not only English 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'
Peter Mount 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. That way, you > can have multiple language support when users from different countries use > the same server? Yes, this is nice. One note: server have to load from this table all messages in a language requested by user when switching to this language - it's not possible to read any table from elog() in most cases. Vadim
On Tue, 26 May 1998, Vadim Mikheev wrote:
> Peter Mount 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. That way, you
> > can have multiple language support when users from different countries use
> > the same server?
>
> Yes, this is nice. One note: server have to load from this table all messages
> in a language requested by user when switching to this language - it's not
> possible to read any table from elog() in most cases.
Hrmmm...one thing to note with any of this is that by 'hardcoding'
in the errormsg itself, it makes it difficult to 'internationalize' a
program...in that I can't run a single server on my machine that can
easily deal with a 'French' customer vs an 'English' one, vs a 'Japanese'
one...I'd have to recompile for each.
Vadim's other point, about putting this in the front end vs the
backend, I think, is more appropriate, that way it is application specific
vs server...
> > Peter Mount 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. That way, you > > can have multiple language support when users from different countries use > > the same server? > > Yes, this is nice. One note: server have to load from this table all messages > in a language requested by user when switching to this language - it's not > possible to read any table from elog() in most cases. Error messages in a system table. That is cool, and would be very easy to add/maintain. Would have to be loaded into C variables for use, however. -- 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)
> Hrmmm...one thing to note with any of this is that by 'hardcoding' > in the errormsg itself, it makes it difficult to 'internationalize' a > program...in that I can't run a single server on my machine that can > easily deal with a 'French' customer vs an 'English' one, vs a 'Japanese' > one...I'd have to recompile for each. > > Vadim's other point, about putting this in the front end vs the > backend, I think, is more appropriate, that way it is application specific > vs server... They could be over-ridden by any postgres backend. I would recommend the postmaster loading in the default, and any backend can change it. Have to get the exec() removed first. -- 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)
> Hrmmm...one thing to note with any of this is that by 'hardcoding' > in the errormsg itself, it makes it difficult to 'internationalize' a > program...in that I can't run a single server on my machine that can > easily deal with a 'French' customer vs an 'English' one, vs a 'Japanese' > one...I'd have to recompile for each. Oops, postmaster can't access any database tables, so each backend would have to load it. I would recommend dumping the default out with COPY as part of initdb, let the postmaster load that file, and backends can load their own. In fact, we may just keep them as COPY files, so they can be easily edited and loaded/unloaded. > > Vadim's other point, about putting this in the front end vs the > backend, I think, is more appropriate, that way it is application specific > vs server... -- 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)
The Hermit Hacker wrote: > > On Tue, 26 May 1998, Vadim Mikheev wrote: > > > > Yes, this is nice. One note: server have to load from this table all messages > > in a language requested by user when switching to this language - it's not > > possible to read any table from elog() in most cases. > > Hrmmm...one thing to note with any of this is that by 'hardcoding' > in the errormsg itself, it makes it difficult to 'internationalize' a > program...in that I can't run a single server on my machine that can > easily deal with a 'French' customer vs an 'English' one, vs a 'Japanese' > one...I'd have to recompile for each. > > Vadim's other point, about putting this in the front end vs the > backend, I think, is more appropriate, that way it is application specific > vs server... I didn't mean to put them in the front-end - this is another good idea :). Yes, we could let fe-libpq to read message corresponding to received error code in appropriate file on client side. Vadim
On Wed, 27 May 1998, Vadim Mikheev wrote: > The Hermit Hacker wrote: > > > > On Tue, 26 May 1998, Vadim Mikheev wrote: > > > > > > Yes, this is nice. One note: server have to load from this table all messages > > > in a language requested by user when switching to this language - it's not > > > possible to read any table from elog() in most cases. > > > > Hrmmm...one thing to note with any of this is that by 'hardcoding' > > in the errormsg itself, it makes it difficult to 'internationalize' a > > program...in that I can't run a single server on my machine that can > > easily deal with a 'French' customer vs an 'English' one, vs a 'Japanese' > > one...I'd have to recompile for each. This could be got round by using error numbers (which is now on the TODO list). Error messages that include data (like table names) could include them using fprintf style %d or %s parameters. > > Vadim's other point, about putting this in the front end vs the > > backend, I think, is more appropriate, that way it is application specific > > vs server... > > I didn't mean to put them in the front-end - this is another good idea :). > Yes, we could let fe-libpq to read message corresponding to received > error code in appropriate file on client side. In libpq, this could be added to PQerrorMessage(). This could attempt to get the native language error message from the DB, defaulting to either an english one, or just the error code (it would be a bad problem in this case). -- 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 Tue, 26 May 1998, Bruce Momjian wrote: > > > > Peter Mount 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. That way, you > > > can have multiple language support when users from different countries use > > > the same server? > > > > Yes, this is nice. One note: server have to load from this table all messages > > in a language requested by user when switching to this language - it's not > > possible to read any table from elog() in most cases. > > Error messages in a system table. That is cool, and would be very easy > to add/maintain. Would have to be loaded into C variables for use, > however. Why into C variables? You could have a function that returns the correct string for the error code, and have it default if it can't access the table. -- 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
> > Why into C variables? You could have a function that returns the correct > string for the error code, and have it default if it can't access the > table. So we run an internal SQL query to get the error message from a table? I guess we could do it, but the system state while in elog() is only partial. You would have to do the longjump, reset, then ru the query. -- 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)
Peter T Mount <psqlhack@retep.org.uk> writes:
> In libpq, this could be added to PQerrorMessage(). This could attempt to
> get the native language error message from the DB, defaulting to either an
> english one, or just the error code (it would be a bad problem in this
> case).
Um. libpq has its own error messages that it can generate --- the most
obvious ones being those about "failed to connect to postmaster"
and "lost connection to backend". How is it supposed to get a localized
equivalent message from the server in cases like that?
Bear in mind that libpq may be executing on a remote machine, so
"have it read the error message file directly" is not a usable answer.
regards, tom lane
On Tue, 26 May 1998, Bruce Momjian wrote: > > > > Why into C variables? You could have a function that returns the correct > > string for the error code, and have it default if it can't access the > > table. > > So we run an internal SQL query to get the error message from a table? > I guess we could do it, but the system state while in elog() is only > partial. You would have to do the longjump, reset, then ru the query. Ah, I see what you mean. The idea of using text files, could be a way round this. -- 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 Tue, 26 May 1998, Tom Lane wrote: > Peter T Mount <psqlhack@retep.org.uk> writes: > > In libpq, this could be added to PQerrorMessage(). This could attempt to > > get the native language error message from the DB, defaulting to either an > > english one, or just the error code (it would be a bad problem in this > > case). > > Um. libpq has its own error messages that it can generate --- the most > obvious ones being those about "failed to connect to postmaster" > and "lost connection to backend". How is it supposed to get a localized > equivalent message from the server in cases like that? > > Bear in mind that libpq may be executing on a remote machine, so > "have it read the error message file directly" is not a usable answer. I'd think these would be ones where the current messages wouldn't be translated, simply because translation is not possible at those points. -- 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