Re: Few untranslated error messages in OAuth

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Few untranslated error messages in OAuth
Date: 2025-11-27 18:24:21
Message-ID: 202511271739.s2yhaq556vq2@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

On 2025-Nov-13, Jacob Champion wrote:

> On Thu, Nov 13, 2025 at 3:08 PM Jacob Champion
> <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> > I'm writing up a patch that combines all of that.
>
> And here's what I have so far. I could use help double-checking the
> .po result; I'm not entirely sure my usage of update-po is correct.

I'm not sure what you think you might be doing wrong, but as far as I
can tell, the .po is being generated correctly.

> - v2-0001: combines Zhijie Hou's patch with the gettext_noop()
> suggestion from Alvaro and fixes the nls.mk omission
> - v2-0002: removes translation of multiplexer failures by adding an
> _internal macro
> - v2-0003: aligns oauth_json_set_error() with the prior commits

I gave these a quick look, and they look correct to me. I didn't test
the resulting libpq though.

There are a few single quotes in some messages, which we tend not to
use. I'd replace those with double quotes. Of those, as an example,
this one caught my attention for strange wording,
"internal error: field \"%s\" still active at end of object"
I think it means we haven't seen the closing quote at the end of the
field, right? Maybe say something like "unterminated field \"%s\" ..."?

There's also the strings in CHECK_MSETOPT and siblings macros missing
quotes -- should be
"failed to set \"%s\" on OAuth connection: %s"

> - v2-0004: tries to get jsonapi.c translated too
>
> Unfortunately v2-0004 doesn't work. It puts the messages into the
> translation files, but we use the _() macro throughout jsonapi.c,
> which isn't helpful for libpq because libpq uses its own text domain.
> This was an oversight in the work done for 0785d1b8b, I think, and it
> may need its own patchset unless someone has a really quick fix.

You're right, that's no good. We could try to define a new macro (maybe
jsonapi_gettext()) that does stock _() on backend but libpq_gettext() on
frontend ... but that wouldn't work nicely for frontend users other than
libpq. Maybe something like

#ifndef jsonapi_gettext
#ifdef FRONTEND
#define jsonapi_gettext(msg) libpq_gettext(msg)
#else
#define jsonapi_gettext(msg) gettext(msg)
#endif
#endif

so any callers that want a third definition can just define it
themselves in the compile line?

Thanks for your time on this,

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar
al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en
La Feria de las Tinieblas, R. Bradbury)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2025-11-27 18:25:50 Re: IPC/MultixactCreation on the Standby server
Previous Message Matthias van de Meent 2025-11-27 18:22:46 Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements