Re: PRI?64 vs Visual Studio (2022) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PRI?64 vs Visual Studio (2022)
Date
Msg-id 1654112.1763587807@sss.pgh.pa.us
Whole thread Raw
In response to Re: PRI?64 vs Visual Studio (2022)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: PRI?64 vs Visual Studio (2022)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Nov 20, 2025 at 6:07 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:
>> You could feed the message catalog a translated string that differs from
>> the original in some simple way, say, by adding a constant prefix
>> "[translated]" or something like that.

> Oh, that's probably better than my nearby en.po + es.po suggestion.
> Combining the ideas, you could have just an en.po translation, but
> expected files to match "hello ..." and "[translated] hello ...".
> Though, hmm, I suppose that fails to fail if it didn't translate when
> it should have,

Yeah.  I think it's critical that the test be set up so that
failure-to-translate cannot look like a success.

I agree with the idea of just using a single test message that checks
all the PRI* macros we care about.  I don't think we need to invent a
whole new translation for this.  I'd be inclined to just get the
desired translated string pushed into one or two .po files in HEAD,
then we can start testing with those specific languages, and we're
good.  Over time the translators would presumably get translations
into other .po files, and then maybe we'd want to expand the set of
tested languages, or maybe that wouldn't really buy much.  (Managing
the encoding of the expected-file might be tricky if you got too
ambitious about that.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 10% drop in code line count in PG 17
Next
From: Tomas Vondra
Date:
Subject: Re: Parallel Apply