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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers