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/
