Re: NLS: use gettext() to translate system error messages

On 2025-Oct-23, Jeff Davis wrote:

> The attached patch changes "%m" replacements to use gettext for
> translation. That makes the overall translations more consistent,
> equally available on all platforms, and not dependent on LC_CTYPE
> (because gettext allows the encoding for gettext can be set separately
> with bind_textdomain_codeset()).

Hmm, interesting idea.  I think the most difficult part is obtaining the
source strings: we need to run your errno_translation.c program on _all_
platforms, merge the output files together, and then create a single
errstrings.po file with all the variations, to reside on our source
tree, which would be given to translators.

Also we need a separate step to create the final postgres.po by
catenating the existing postgres.po with the new errstrings.po; this
should not occur in the source tree but rather at install time, because
of course pg_dump.po is going to have to do the same, and we don't need
to make translators responsible for propagating translations from one
file to others; that occurs already to a very small scale with the
src/common files and I hate it, so I wouldn't want to see it happening
with this much larger set of strings.

BTW looking at the output of that program I realized that with
_GNU_SOURCE, there's strerrorname_np() which can be helpful to generate
the new file in a way that doesn't require you to have all these E
constants in the program.  Not sure if other platforms have equivalent
gadgets; but without that I get entries like

	#. (null)
	msgid "Object is remote"
	msgstr "El objeto es remoto"

the (null) bit should perhaps be avoided anyhow.

FWIW the last valid errno I get having patched to use strerrname_np() is
133.

	$ ./a.out 0 135
	#. 0
	msgid "Success"
	msgstr "Conseguido"

	...

	#. EHWPOISON
	msgid "Memory page has hardware error"
	msgstr "La página de memoria tiene un error de hardware"

	#. (null)
	msgid "Unknown error 134"
	msgstr "Error desconocido 134"

(I think the exit condition of that loop should be "i <= max_err",
otherwise it's confusing.)

> One downside is that there are more messages to translate -- one per
> errno that Postgres might plausibly encounter,

It's not all that many messages, and they only have to be translated
once, so I think this shouldn't be too much of an issue.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/