Thread

Re: PRI?64 vs Visual Studio (2022)

Bryan Green <dbryan.green@gmail.com> — 2025-12-15T19:06:09Z

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