Re: PRI?64 vs Visual Studio (2022)

On 12/15/2025 12:28 PM, Tom Lane wrote:
> It'd be great to not need the assumption of es_ES being installed.
> However, I tried making a POSIX.po file and setting lc_messages to
> POSIX, and it didn't work. The msgfmt infrastructure seemed unfazed
> and installed a .mo file under $sharedir/locale/POSIX/LC_MESSAGES as
> I'd expect, but no translation happened (this on a Linux box). Same
> with 'C'. It did work if I set lc_messages to 'C.utf8', which is a
> known name according to this box's "locale -a", but this doesn't give
> me a warm feeling about this approach being a lot more portable than
> what we have. Any ideas?

My answer did not feel like it was right, so I checked multiple versions
and realized there is a check.

char *
DCIGETTEXT (const char *domainname, const char *msgid, ...)
{
// Get the locale name
categoryvalue = guess_category_value (category, categoryname);

if (categoryvalue != NULL
&& !(categoryvalue[0] == 'C' && categoryvalue[1] == '\0')
&& strcmp (categoryvalue, "POSIX") != 0)
{
// Only do translation if NOT "C" and NOT "POSIX"
retval = _nl_find_msg (...);
}

// For "C" and "POSIX", skip directly to returning msgid
return (char *) msgid;
}

C.utf8 works because it is not "C" so is treated as a real locale. Now
that I'm back into that code...looking it over in more detail to see
what might work...

--
Bryan Green
EDB: https://www.enterprisedb.com