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 →
-
Test PRI* macros even when we can't test NLS translation.
- 462e2476525e 19 (unreleased) landed
-
Avoid requiring Spanish locale to test NLS infrastructure.
- 7db6809ced44 19 (unreleased) landed
-
Drop support for MSVCRT's float formatting quirk.
- 6b46669883fa 19 (unreleased) landed
-
Drop support for MSVCRT's %I64 format strings.
- 7ab9b34614c2 19 (unreleased) landed
-
Use PRI?64 instead of "ll?" in format strings (continued).
- a0ed19e0a9ef 18.0 cited
-
Use <stdint.h> and <inttypes.h> for c.h integers.
- 962da900ac8f 18.0 cited
-
Make float exponent output on Windows look the same as elsewhere.
- f1885386f624 12.0 cited
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