Horton

Re: Solaris versus our NLS files

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nico Williams <nico@cryptonector.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-12-10T21:22:19Z
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. Add a regression test to verify that NLS translation works.

  2. Translation updates

  3. Translation updates for 8.4 release.

I wrote:
> Encoding-specific behaviors might be worth testing later, but
> I'm not excited about that personally.

Despite that disclaimer, I experimented with the questionable nb.po
file on my OpenIndiana installation, and it seems to Just Work
after creating the nb_NO.UTF-8 -> nb locale symlink:

tgl@openindiana:~$ LANG=nb_NO.UTF-8 pg_config bogus
pg_config: ugyldig argument: bogus
Prøv «pg_config --help» for mer informasjon.

"od -c" confirms that that output is UTF-8 encoded:

tgl@openindiana:~$ LANG=nb_NO.UTF-8 pg_config bogus 2>&1 | od -c
0000000   p   g   _   c   o   n   f   i   g   :       u   g   y   l   d
0000020   i   g       a   r   g   u   m   e   n   t   :       b   o   g
0000040   u   s  \n   P   r 303 270   v     302 253   p   g   _   c   o
0000060   n   f   i   g       -   -   h   e   l   p 302 273       f   o
0000100   r       m   e   r       i   n   f   o   r   m   a   s   j   o
0000120   n   .  \n
0000123

I checked further, and found that nb.mo has been transcoded to UTF8!
So this case didn't require any runtime transcoding anyway.

It doesn't stop there though.  I soon realized that configure
had seized on GNU msgfmt not Sun's, and convert-to-UTF8 is
the default behavior of GNU msgfmt.  I then forced the build
to use /usr/bin/msgfmt, and confirmed that now nb.mo remains in
LATIN1.  But I still get exactly the above output!

So apparently, "Sun's gettext can't transcode" is obsolete
information.  It works fine in this setup, despite using symlinks that
may not be telling the truth about the encoding of the .mo files.

I also verified that I could get LATIN1 output from UTF-8 .mo files,
so long as LANG is set to a name that "locale -a" admits the existence
of and I add a matching symlink.  So we don't actually have to confine
our support for this to the UTF-8 locales.  But I'm inclined to just
do that much for now and wait to see if anyone complains.  (I agree
with Munro that that's likely to be never.)

This also means that this project doesn't require adoption of a
"UTF8-only" policy for our .po files.  I'm inclined to think that
such a policy might be a good idea anyway, but it's not forced by
wanting to support Sun's gettext().

			regards, tom lane