postgresql/src/pl/plpython/nls.mk

# $PostgreSQL: pgsql/src/pl/plpython/nls.mk,v 1.6.2.1 2009/09/03 21:01:24 petere Exp $
CATALOG_NAME	:= plpython
AVAIL_LANGUAGES	:= de es fr it ja pt_BR tr
GETTEXT_FILES	:= plpython.c
GETTEXT_TRIGGERS:= errmsg errmsg_plural:1,2 errdetail errdetail_log errdetail_plural:1,2 errhint errcontext PLy_elog:2 PLy_exception_set:2 PLy_exception_set_plural:2,3
Translation updates 2009-09-03 17:01:26 -04:00			`# $PostgreSQL: pgsql/src/pl/plpython/nls.mk,v 1.6.2.1 2009/09/03 21:01:24 petere Exp $`
Improve translatability of error messages for external modules by tweaking the ereport macro. Included in this commit are enough files for starting plpgsql, plpython, plperl and pltcl translations. 2008-10-09 13:24:05 -04:00			`CATALOG_NAME := plpython`
Translation updates 2009-09-03 17:01:26 -04:00			`AVAIL_LANGUAGES := de es fr it ja pt_BR tr`
Improve translatability of error messages for external modules by tweaking the ereport macro. Included in this commit are enough files for starting plpgsql, plpython, plperl and pltcl translations. 2008-10-09 13:24:05 -04:00			`GETTEXT_FILES := plpython.c`
Improve the recently-added support for properly pluralized error messages by extending the ereport() API to cater for pluralization directly. This is better than the original method of calling ngettext outside the elog.c code because (1) it avoids double translation, which wastes cycles and in the worst case could give a wrong result; and (2) it avoids having to use a different coding method in PL code than in the core backend. The client-side uses of ngettext are not touched since neither of these concerns is very pressing in the client environment. Per my proposal of yesterday. 2009-06-04 14:33:08 -04:00			`GETTEXT_TRIGGERS:= errmsg errmsg_plural:1,2 errdetail errdetail_log errdetail_plural:1,2 errhint errcontext PLy_elog:2 PLy_exception_set:2 PLy_exception_set_plural:2,3`