Skip site navigation (1) Skip section navigation (2)

Re: Opinions about wording of error messages for bug#3883?

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, pgtranslation-translators(at)pgfoundry(dot)org
Subject: Re: Opinions about wording of error messages for bug#3883?
Date: 2008-01-30 00:56:23
Message-ID: 20080130005623.GK27546@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:

> I would like to export this routine and have it be used by all four
> commands, instead of duplicating this logic everywhere.  However,
> that brings up the question of whether the error messages are
> generic enough for all four commands; and if not, how we want them
> to read.  I'm tempted to rephrase both messages along the line of
> 
> 	cannot %s \"%s\" because ...
>
> where the first %s is replaced by a SQL command name, viz ALTER TABLE,
> CLUSTER, etc.  I'm not sure how nice this is for translation though.

I suggest
	cannot execute \"%s\" on \"%s\" because ...

> Also, with 8.3 release being so close, it's likely that any change would
> not get reflected into translations before release.  I don't think
> that's a showstopper because these messages should hardly ever be seen
> by normal users anyway; but maybe it's a consideration.

I wouldn't worry about that at this point.  We didn't declare a string
freeze anyway ...

It will likely be fixed in 8.3.1 for translations where it matters
anyway, if the translator is not able to do it for 8.3.  (That's
currently only fr, de and es -- currently even tr is a bit behind).

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-01-30 01:31:07
Subject: Re: Opinions about wording of error messages for bug #3883?
Previous:From: Tom LaneDate: 2008-01-30 00:40:46
Subject: Opinions about wording of error messages for bug #3883?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group