Improving the ngettext() patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Improving the ngettext() patch
Date: 2009-06-03 20:50:49
Message-ID: 24546.1244062249@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

After looking through the current uses of ngettext(), I think that it
wouldn't be too difficult to modify the patch to address the concerns
I had about it. What I propose doing is to add an additional elog.h
function

errmsg_plural(const char *fmt_singular, const char *fmt_plural,
unsigned long n, ...)

and replace the current errmsg(ngettext(...)) calls with this.
Similarly add errdetail_plural to replace errdetail(ngettext(...)).
(We could also add errhint_plural and so on, but right offhand these
seem unlikely to be useful.) The advantage of doing this is that
we avoid double translation and eliminate the current kluge whereby
usages in PL code have to be different from usages anywhere else.

I don't feel a need to touch the usages in client programs (pg_dump and
so on). In principle the double-translation risk still exists there,
but it seems much less likely to be a real hazard because any one client
program has a *far* smaller pool of translatable messages than the
backend does. Also, there's only one active text domain in a client
program, so the problem of needing to use dngettext in special cases
doesn't exist.

There are a few usages of ngettext() in the backend that are not tied
to ereport calls, but I think they can be left as-is. There's no
double-translation risk, and with so few of them I don't see much of
a risk of wrongly copying the usage in PL code, either.

Also: one thought that came to me while looking at the existing usages
is that there are several places that are plural-ized that seem
completely pointless; why are we making our translators work
harder on them? For example

ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_ARGUMENTS),
errmsg(ngettext("functions cannot have more than %d argument",
"functions cannot have more than %d arguments",
FUNC_MAX_ARGS),
FUNC_MAX_ARGS)));

It seems extremely far-fetched that FUNC_MAX_ARGS would ever be small
enough that it would make any language's special cases kick in. Or
how about this one:

#if 0
write_msg(modulename, ngettext("read %lu byte into lookahead buffer\n",
"read %lu bytes into lookahead buffer\n",
AH->lookaheadLen),
(unsigned long) AH->lookaheadLen);
#endif

I'm not sure why this debug support is still there at all, but surely
it's a crummy candidate for making translators sweat over. So I'd like
to revert these.

Comments, objections?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-06-03 21:01:31 Re: Locks on temp table and PREPARE
Previous Message Emmanuel Cecchet 2009-06-03 20:50:46 Re: Locks on temp table and PREPARE