Re: plpgsql is not translate-aware

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Actually this is wrong -- since the library is going to run with
> > "postgres" text domain, we need to add the files to the backend's
> > nls.mk:
>
> Can't we give it its own text domain? It seems fundamentally wrong
> for a plug-in language to require core support for its messages.
> (Now that I think about it, that may have been the reason we don't have
> localization for it already.) I suppose this must be possible,
> since e.g. glibc manages to have its own messages separate from
> whatever app it's linked with.

What glibc does is use dgettext() instead of plain gettext(), so they
are able to pass the domain along the message. See here, at the bottom:
http://github.com/bneumeier/glibc/tree/master/include/libintl.h
where _libc_intl_domainname is defined as "libc" elsewhere.

I guess one way to go about this is to add some way to pass the domain
from the caller, i.e.

ereport(ERROR,
(errdomain("plpgsql"),
errmsg(" ... ")))

but it seems a bit fragile, if only because it's easy to forget to add
it to new code, and easy to overlook a message that should have it.

Another idea would be to redefine errmsg() and friends within the
plpgsql sources, but that seems worse because every other library will
need to do the same.

Refinement of the previous idea: maybe we can add a compiler flag, to be
set in Makefiles, that defines the domain and passes it down to
EVALUATE_MESSAGE.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support