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

On Mon, 2025-10-27 at 13:06 -0700, Jeff Davis wrote:
> On Mon, 2025-10-27 at 15:10 +0200, Álvaro Herrera wrote:
> > 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,
>
> I have attached .po files for the standard set of errnos (those
> recognized by strerror.c:get_errno_symbol()) on linux+glibc,
> linux+musl, freebsd, and mac.
>
> Windows and solaris/illumos are missing, and perhaps some other
> variations too (e.g. the other BSDs).

Is this going in the right direction?

And generally, is NLS translation of system messages wanted at all, or
are ASCII messages more convenient anyway (given that it's just a
simple text representation of errno)?

If we don't actually want translation of the system messages, then do
we want to take the part of this patch that switches to the C locale,
so that it consistently uses ASCII messages across platforms?

The status quo seems like an awkward middle ground, where the system
messages are only translated on some platforms (perhaps only glibc?);
and whether they are translated or not is independent of whether
Postgres was compiled with NLS, which can lead to partially-translated
messages.

For instance, on linux/glibc if NLS is not enabled, you can end up with
messages like:

ERROR: could not open file "/etc/shadow" for reading: Permission non
accordée

AFAICT it makes zero sense to translate the errno message but not
translate the more interesting Postgres message.

> > 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.
>
> I'm not familiar with the tooling in this area, but I can take a look
> into it. Would it affect packagers?

Would someone be willing to help here?

Attached new version; trivial rebase only.

>
Regards,
Jeff Davis