Re: PRI?64 vs Visual Studio (2022)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PRI?64 vs Visual Studio (2022)
Date: 2025-11-19 22:23:53
Message-ID: 1689927.1763591033@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> 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.)

Just as proof-of-concept, this is approximately what I think we
should do to begin with.

The main thing that's likely wrong here is that I just manually
shoved a new entry into src/backend/po/es.po. I suspect that
the .po-extraction machinery would fail to pick up that string
because it's in src/test/regress/regress.c. We could hack it
to do that, or we could put the test function into some backend
file. I don't have much sense of which would be cleaner.

Lesser loose ends: I didn't bother fleshing out the test message
to cover all of the likely PRI* cases, and my Spanish probably
sucks. I'm also unsure if this will work as-is on Windows;
are the LC_MESSAGES settings the same there?

regards, tom lane

Attachment Content-Type Size
v1-0001-Simple-test-of-NLS-translation.patch text/x-diff 4.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2025-11-19 22:32:17 Re: Eagerly evict bulkwrite strategy ring
Previous Message Corey Huinker 2025-11-19 22:23:48 Re: vacuumdb: add --dry-run