Re: PRI?64 vs Visual Studio (2022)

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, Peter Eisentraut <peter@eisentraut.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-11-19T21:30:07Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Test PRI* macros even when we can't test NLS translation.

  2. Avoid requiring Spanish locale to test NLS infrastructure.

  3. Drop support for MSVCRT's float formatting quirk.

  4. Drop support for MSVCRT's %I64 format strings.

  5. Use PRI?64 instead of "ll?" in format strings (continued).

  6. Use <stdint.h> and <inttypes.h> for c.h integers.

  7. Make float exponent output on Windows look the same as elsewhere.

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