Improving the ngettext() patch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Improving the ngettext() patch
Дата
Msg-id 24546.1244062249@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Improving the ngettext() patch  (Sergey Burladyan <eshkinkot@gmail.com>)
Список 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
cannothave 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
%lubytes 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Emmanuel Cecchet
Дата:
Сообщение: Re: Locks on temp table and PREPARE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Locks on temp table and PREPARE