Обсуждение: Solaris versus our NLS files

I idly tried the NLS-testing patch at [1] on a Solaris image
(actually OpenIndiana), and was not really astonished to find that
it fails.  Everything compiles cleanly, but the test shows that no
message translation happens, and manual checking confirms that.

After some quality time with Google, I learned why: with Solaris's
apparently-locally-hacked version of gettext, it's not good enough
to have $INSTALLATION/share/locale/ subdirectories named like
"es", "fr", etc.  They have to be named after the
fully-spelled-out locale names like "es_ES.UTF-8".

At least Solaris is kind enough to let you do that with
symlinks [2], so that after

    cd $INSTALLATION/share/locale
    ln -s es es_ES.UTF-8

translation starts working for that particular value of
lc_messages.

This policy dictates making a rather large number of symlinks
in that directory, which we've never done TTBOMK.  It's a
bit sad that nobody has complained about this --- one must
conclude that the non-anglophone population of Solaris PG
users is nearly empty.

Anybody feel like doing something about this?  I'm not
super excited about it myself, but if we don't, it's
probably a blocker for adding the test proposed at [1].
We do have Solaris BF animals that would start failing.

            regards, tom lane

[1] https://www.postgresql.org/message-id/247596.1765300108%40sss.pgh.pa.us
[2] https://docs.oracle.com/cd/E36784_01/html/E39536/gnkbn.html

On Wed, Dec 10, 2025 at 10:22 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> After some quality time with Google, I learned why: with Solaris's
> apparently-locally-hacked version of gettext, it's not good enough
> to have $INSTALLATION/share/locale/ subdirectories named like
> "es", "fr", etc.  They have to be named after the
> fully-spelled-out locale names like "es_ES.UTF-8".

Is it really locally hacked, or is it just Sun's libc[1], which
invented gettext() in the first place, and then later added GNU's
extensions and .mo format after GNU's reimplementation became
widespread?  From some (very) limited research on the topic, one thing
that GNU's reimplementation added that Sun's never had is the ability
to open a .mo with the wrong encoding and transcode it.  Perhaps that
explains Sun's insistence on finding an exact match, and I guess that
might mean that you could get either mojibake or some kind of error if
you create codesetless symlinks (which I guess it would normally only
use when your locale's name doesn't have the codeset suffix, and then
I guess it would expect Latin-9 or whatever it thinks "es_ES" has)?

[1] https://github.com/illumos/illumos-gate/tree/master/usr/src/lib/libc/port/i18n

On Wed, Dec 10, 2025 at 10:54 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> if you create codesetless symlinks

Oops, wrote that too fast... you want to add the suffixes.  Well then
it's the other way around, and you'd have to generate new files with
the right encoding and suffixes (which means knowing which
combinations the target system has), instead of making symlinks, and
make sure that the "en_US" one is in the appropriate encoding, maybe?

On Wed, Dec 10, 2025 at 11:03:00AM +1300, Thomas Munro wrote:
> On Wed, Dec 10, 2025 at 10:54 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> > if you create codesetless symlinks
> 
> Oops, wrote that too fast... you want to add the suffixes.  Well then
> it's the other way around, and you'd have to generate new files with
> the right encoding and suffixes (which means knowing which
> combinations the target system has), instead of making symlinks, and
> make sure that the "en_US" one is in the appropriate encoding, maybe?

How about supporting only UTF-8 locales?

Nico
-- 

Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Dec 10, 2025 at 10:22 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> After some quality time with Google, I learned why: with Solaris's
>> apparently-locally-hacked version of gettext, it's not good enough
>> to have $INSTALLATION/share/locale/ subdirectories named like
>> "es", "fr", etc.  They have to be named after the
>> fully-spelled-out locale names like "es_ES.UTF-8".

> Is it really locally hacked, or is it just Sun's libc[1], which
> invented gettext() in the first place, and then later added GNU's
> extensions and .mo format after GNU's reimplementation became
> widespread?

Sorry, I was imprecise there.  This is Solaris' libc implementation:
configure reports

configure:18402: checking for library containing bind_textdomain_codeset
configure:18450: result: none required

and I don't see any libintl listed in "ldd postgres" either.

> From some (very) limited research on the topic, one thing
> that GNU's reimplementation added that Sun's never had is the ability
> to open a .mo with the wrong encoding and transcode it.  Perhaps that
> explains Sun's insistence on finding an exact match, and I guess that
> might mean that you could get either mojibake or some kind of error if
> you create codesetless symlinks (which I guess it would normally only
> use when your locale's name doesn't have the codeset suffix, and then
> I guess it would expect Latin-9 or whatever it thinks "es_ES" has)?

Like some other platforms, it flat out won't accept codeset-less
lc_messages settings:

postgres=# SET lc_messages = 'es_ES';
ERROR:  invalid value for parameter "lc_messages": "es_ES"
postgres=# SET lc_messages = 'es_ES.UTF-8';
SET
postgres=# select 1/0;
ERROR:  división por cero

This is with the symlink in place.  Yes I did try making a symlink
named "es_ES", but apparently there's some central source of truth
about what the valid locale names are.

It apparently is possible to install GNU gettext on top of Solaris,
although you then get into some fun about conflicts between GNU-
and OS-supplied headers.  But I've not tried that here.

If you're right about Sun not doing transcoding, then I guess we would
only need to create symlinks matching the encodings used in our .po
files, which'd remove the symlink bloat problem and replace it with
how-do-we-extract-that-encoding-name ... although it looks like all
but one is in UTF-8, so maybe we should just decree they have to be
in UTF-8?  The lone exception is src/bin/pg_config/po/nb.po, which
seems not to have been touched since 2013.

            regards, tom lane

On Wed, Dec 10, 2025 at 11:23 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If you're right about Sun not doing transcoding, then I guess we would
> only need to create symlinks matching the encodings used in our .po
> files, which'd remove the symlink bloat problem and replace it with
> how-do-we-extract-that-encoding-name ... although it looks like all
> but one is in UTF-8, so maybe we should just decree they have to be
> in UTF-8?  The lone exception is src/bin/pg_config/po/nb.po, which
> seems not to have been touched since 2013.

+1

On Wed, Dec 10, 2025 at 11:22 AM Nico Williams <nico@cryptonector.com> wrote:
> On Wed, Dec 10, 2025 at 11:03:00AM +1300, Thomas Munro wrote:
> > On Wed, Dec 10, 2025 at 10:54 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> > > if you create codesetless symlinks
> >
> > Oops, wrote that too fast... you want to add the suffixes.  Well then
> > it's the other way around, and you'd have to generate new files with
> > the right encoding and suffixes (which means knowing which
> > combinations the target system has), instead of making symlinks, and
> > make sure that the "en_US" one is in the appropriate encoding, maybe?
>
> How about supporting only UTF-8 locales?

Yeah, if nobody noticed this wasn't working at all, then it makes
sense to defer the generation of .mo files for non-UTF-8 codesets
until someone eventually does notice that it still doesn't work in
legacy locales and feels inclined to do something about it, ie
forever.  Tom's goal of having basic tests pass will be satisfied by
UTF-8-only.

Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Dec 10, 2025 at 11:22 AM Nico Williams <nico@cryptonector.com> wrote:
>> How about supporting only UTF-8 locales?

> Yeah, if nobody noticed this wasn't working at all, then it makes
> sense to defer the generation of .mo files for non-UTF-8 codesets
> until someone eventually does notice that it still doesn't work in
> legacy locales and feels inclined to do something about it, ie
> forever.  Tom's goal of having basic tests pass will be satisfied by
> UTF-8-only.

Right.  For the moment I only care about verifying that (a) some
translation happens and (b) the PRI* macros work as-expected.
Since we've already discovered platform-specific failures on both
points, this seems like a very worthwhile exercise.

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

            regards, tom lane

On 2025-Dec-09, Tom Lane wrote:

> If you're right about Sun not doing transcoding, then I guess we would
> only need to create symlinks matching the encodings used in our .po
> files, which'd remove the symlink bloat problem and replace it with
> how-do-we-extract-that-encoding-name ... although it looks like all
> but one is in UTF-8, so maybe we should just decree they have to be
> in UTF-8?  The lone exception is src/bin/pg_config/po/nb.po, which
> seems not to have been touched since 2013.

Hmm, where do you see that file?  It was removed by commit 3c70de2e12b9
from branch 12 in 2019, and has never existed since.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Los cuentos de hadas no dan al niño su primera idea sobre los monstruos.
Lo que le dan es su primera idea de la posible derrota del monstruo."
                                                   (G. K. Chesterton)

Álvaro Herrera <alvherre@kurilemu.de> writes:

> On 2025-Dec-09, Tom Lane wrote:
>
>> If you're right about Sun not doing transcoding, then I guess we would
>> only need to create symlinks matching the encodings used in our .po
>> files, which'd remove the symlink bloat problem and replace it with
>> how-do-we-extract-that-encoding-name ... although it looks like all
>> but one is in UTF-8, so maybe we should just decree they have to be
>> in UTF-8?  The lone exception is src/bin/pg_config/po/nb.po, which
>> seems not to have been touched since 2013.
>
> Hmm, where do you see that file?  It was removed by commit 3c70de2e12b9
> from branch 12 in 2019, and has never existed since.

That translation commit was on the REL_12_STABLE branch, after it was
cut from master (after rc1, even).  Looking more closely, the
post-branch translation updates deleted it from version 12, 13, 14, and
15, but not 16 onwards, and the file is still there in master:

https://git.postgresql.org/cgit/postgresql.git/tree/src/bin/pg_config/po/nb.po

- ilmari

On 2025-Dec-10, Dagfinn Ilmari Mannsåker wrote:

> Álvaro Herrera <alvherre@kurilemu.de> writes:

> > Hmm, where do you see that file?  It was removed by commit 3c70de2e12b9
> > from branch 12 in 2019, and has never existed since.
> 
> That translation commit was on the REL_12_STABLE branch, after it was
> cut from master (after rc1, even).  Looking more closely, the
> post-branch translation updates deleted it from version 12, 13, 14, and
> 15, but not 16 onwards, and the file is still there in master:

Oh.  Well, that's clearly a process failure, and the fix will require us
deleting that file on all branches from 16 and up anyway, so I have no
issues with the plan of requiring all message catalogs to be UTF-8.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"I can see support will not be a problem.  10 out of 10."    (Simon Wittber)
      (http://archives.postgresql.org/pgsql-general/2004-12/msg00159.php)

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> On 2025-Dec-10, Dagfinn Ilmari Mannsåker wrote:
>> That translation commit was on the REL_12_STABLE branch, after it was
>> cut from master (after rc1, even).  Looking more closely, the
>> post-branch translation updates deleted it from version 12, 13, 14, and
>> 15, but not 16 onwards, and the file is still there in master:

Hah, yeah, I failed to notice that there's a gap in which branches
have that file.  But it's definitely there in master.

> Oh.  Well, that's clearly a process failure, and the fix will require us
> deleting that file on all branches from 16 and up anyway, so I have no
> issues with the plan of requiring all message catalogs to be UTF-8.

Shall I just go delete those files, or is there more process that
ought to be observed here?

            regards, tom lane

Álvaro Herrera <alvherre@kurilemu.de> writes:

> On 2025-Dec-10, Dagfinn Ilmari Mannsåker wrote:
>
>> Álvaro Herrera <alvherre@kurilemu.de> writes:
>
>> > Hmm, where do you see that file?  It was removed by commit 3c70de2e12b9
>> > from branch 12 in 2019, and has never existed since.
>> 
>> That translation commit was on the REL_12_STABLE branch, after it was
>> cut from master (after rc1, even).  Looking more closely, the
>> post-branch translation updates deleted it from version 12, 13, 14, and
>> 15, but not 16 onwards, and the file is still there in master:
>
> Oh.  Well, that's clearly a process failure, and the fix will require us
> deleting that file on all branches from 16 and up anyway, so I have no
> issues with the plan of requiring all message catalogs to be UTF-8.

Digging a bit more in the history of **/nb.po, there seems to be a
policy that files that are less than 80% translated are removed¹, and I
guess this file was just below the threshold on the 12-15 branches, but
just above the threshold on master and 16+.  The Norwegian translation
seems unmaintained², so I vote³ for removing it completely.

- ilmari

[1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=a6667d96c5e4aca92612295d549541146dd6e74a
[2] https://git.postgresql.org/cgit/pgtranslation/messages.git/log/nb
[3] I am Norwegian, but I prefer to use computers in English

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

> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
>
>> Oh.  Well, that's clearly a process failure, and the fix will require us
>> deleting that file on all branches from 16 and up anyway, so I have no
>> issues with the plan of requiring all message catalogs to be UTF-8.
>
> Shall I just go delete those files, or is there more process that
> ought to be observed here?
>
>             regards, tom lane

Looking at the translations repo, there's 30 .po files (out of 530) that
are not UTF-8, but I guess only nb/pg_config.po meets the 80% threshold
and makes it into the main repo.  To avoid future breakage, should we
ask the translation team to convert those to UTF-8?

- ilmari

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:
> Looking at the translations repo, there's 30 .po files (out of 530) that
> are not UTF-8, but I guess only nb/pg_config.po meets the 80% threshold
> and makes it into the main repo.  To avoid future breakage, should we
> ask the translation team to convert those to UTF-8?

+1, they'd have to be on board with any all-UTF8 policy anyway.

            regards, tom lane

On 09.12.25 22:22, Tom Lane wrote:
> At least Solaris is kind enough to let you do that with
> symlinks [2], so that after
> 
>     cd $INSTALLATION/share/locale
>     ln -s es es_ES.UTF-8
> 
> translation starts working for that particular value of
> lc_messages.
> 
> This policy dictates making a rather large number of symlinks
> in that directory, which we've never done TTBOMK.

How would one know all the country codes to create links for?

Peter Eisentraut <peter@eisentraut.org> writes:
> On 09.12.25 22:22, Tom Lane wrote:
>> At least Solaris is kind enough to let you do that with
>> symlinks [2], so that after
>>     cd $INSTALLATION/share/locale
>>     ln -s es es_ES.UTF-8
>> translation starts working for that particular value of
>> lc_messages.

> How would one know all the country codes to create links for?

Yeah, I've been wrestling with that question.  The best idea
I have at the moment is to look at "locale -a" output to see
which country codes Solaris thinks there are for each language,
and duplicate that.  What's unclear is whether we should do
that on-the-fly to match the build machine, or do it once to
produce a curated list that could be subject to maintenance.
The former is like what we do to populate pg_collation
(although we do that at initdb not build time).  But the latter
seems like it might be wiser policy.

            regards, tom lane

On Wed, Dec 10, 2025 at 05:02:14PM +0100, Peter Eisentraut wrote:
> On 09.12.25 22:22, Tom Lane wrote:
> > At least Solaris is kind enough to let you do that with
> > symlinks [2], so that after
> > 
> >     cd $INSTALLATION/share/locale
> >     ln -s es es_ES.UTF-8
> > 
> > translation starts working for that particular value of
> > lc_messages.
> > 
> > This policy dictates making a rather large number of symlinks
> > in that directory, which we've never done TTBOMK.
> 
> How would one know all the country codes to create links for?

Does OpenIndiance really require this?  Oh, I guess it does:


https://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libc/port/i18n/gettext_util.c?r=00ae5933&fi=mk_msgfile#mk_msgfile

That's a bummer.

Well, a list of country codes can probably be hardcoded into PG's build.
Or... the installation packaging could check at install time what
locales are installed and create these symlinks (but this is
unsatisfying because what if the locales in question get installed after
PG?).

Maybe PG should contribute a fix to Illumos :joy:

Nico
-- 

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:
> Álvaro Herrera <alvherre@kurilemu.de> writes:
>> Oh.  Well, that's clearly a process failure, and the fix will require us
>> deleting that file on all branches from 16 and up anyway, so I have no
>> issues with the plan of requiring all message catalogs to be UTF-8.

> Digging a bit more in the history of **/nb.po, there seems to be a
> policy that files that are less than 80% translated are removed¹, and I
> guess this file was just below the threshold on the 12-15 branches, but
> just above the threshold on master and 16+.

There may actually be an update-process bug here, because according to
[1], pg_config's nb translation is below 70% in all current branches.
So src/bin/pg_config/po/nb.po should not be propagated to gitmaster
in any branch later than v12, yet here it is in the more recent
branches.  I'm suspecting a logic bug that fails to delete files
that should be deleted.

            regards, tom lane

[1] https://babel.postgresql.org

I wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> How would one know all the country codes to create links for?

> Yeah, I've been wrestling with that question.  The best idea
> I have at the moment is to look at "locale -a" output to see
> which country codes Solaris thinks there are for each language,
> and duplicate that.  What's unclear is whether we should do
> that on-the-fly to match the build machine, or do it once to
> produce a curated list that could be subject to maintenance.

It turns out to be a fairly minor patch to do it on-the-fly.
With the attached, I've gotten my NLS-testing patch to pass
on OpenIndiana.  We end up with this in $INSTALL/share/locale/:

drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 cs
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 cs_CZ.UTF-8 -> cs
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 de
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 de_AT.UTF-8 -> de
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 de_BE.UTF-8 -> de
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 de_CH.UTF-8 -> de
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 de_DE.UTF-8 -> de
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 de_LI.UTF-8 -> de
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 de_LU.UTF-8 -> de
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 el
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 el_CY.UTF-8 -> el
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 el_GR.UTF-8 -> el
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_AR.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_BO.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_CL.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_CO.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_CR.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_DO.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_EC.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_ES.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_GQ.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_GT.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_HN.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_MX.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_NI.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_PA.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_PE.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_PR.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_PY.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_SV.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_US.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_UY.UTF-8 -> es
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 es_VE.UTF-8 -> es
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_BE.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_CA.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_CF.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_CH.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_FR.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_GN.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_LU.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_MC.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_MG.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_ML.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_NE.UTF-8 -> fr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 fr_SN.UTF-8 -> fr
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 he
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 he_IL.UTF-8 -> he
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 id
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:18 id_ID.UTF-8 -> id
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 it
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 it_CH.UTF-8 -> it
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 it_IT.UTF-8 -> it
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 ja
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 ja_JP.UTF-8 -> ja
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 ka
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 ka_GE.UTF-8 -> ka
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 ko
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 ko_KR.UTF-8 -> ko
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 nb
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:18 nb_NO.UTF-8 -> nb
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 pl
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 pl_PL.UTF-8 -> pl
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 pt_BR
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 ro
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 ro_MD.UTF-8 -> ro
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 ro_RO.UTF-8 -> ro
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 ru
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 ru_MD.UTF-8 -> ru
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 ru_RU.UTF-8 -> ru
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 ru_UA.UTF-8 -> ru
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 sv
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 sv_FI.UTF-8 -> sv
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 sv_SE.UTF-8 -> sv
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 ta
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:18 ta_IN.UTF-8 -> ta
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:18 ta_LK.UTF-8 -> ta
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 tr
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 tr_TR.UTF-8 -> tr
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 uk
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 uk_UA.UTF-8 -> uk
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 vi
lrwxrwxrwx 1 tgl staff 2 Dec 10 18:19 vi_VN.UTF-8 -> vi
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 zh_CN
drwxr-xr-x 3 tgl staff 3 Dec 10 18:18 zh_TW

That's probably more links than we'd bother with in a curated
list, but it's not a huge number.

The attached patch only addresses the autoconf/make case.
I might be missing something, but so far as I can find,
meson wraps up the entire build/installation process for
translation files into a black box without user-serviceable
parts.  So the lack of translation on Solaris is their bug
to fix.

I'm inclined to commit this and call it good.  Probably
we should back-patch, too, despite the lack of field
complaints.

            regards, tom lane

diff --git a/src/nls-global.mk b/src/nls-global.mk
index 73a6db10a1d..b33e25ad9a4 100644
--- a/src/nls-global.mk
+++ b/src/nls-global.mk
@@ -123,8 +123,22 @@ ifneq (,$(LANGUAGES))
     done
 endif

+# On Solaris, we must make locale-named symlinks for each language directory,
+# else Sun's gettext implementation won't find the messages.  But we only
+# bother for UTF-8 locales, since our .mo files are in UTF-8 and Sun's gettext
+# can't do transcoding.  (With Sun's sh, the final "exit 0" is required to
+# prevent failure in case of the last grep invocation finding nothing.)
 installdirs-po:
-    $(if $(LANGUAGES),$(MKDIR_P) $(foreach lang, $(LANGUAGES), '$(DESTDIR)$(localedir)'/$(lang)/LC_MESSAGES),:)
+ifneq (,$(LANGUAGES))
+    $(MKDIR_P) $(foreach lang, $(LANGUAGES), '$(DESTDIR)$(localedir)'/$(lang)/LC_MESSAGES)
+ifeq ($(PORTNAME), solaris)
+    cd '$(DESTDIR)$(localedir)' && for lang in $(LANGUAGES); do \
+      for locale in `locale -a | grep "^$${lang}_.*UTF-8"`; do \
+        rm -f "$$locale" && $(LN_S) $$lang "$$locale" || exit 1; \
+      done ; \
+    done ; exit 0
+endif
+endif

 uninstall-po:
     $(if $(LANGUAGES),rm -f $(foreach lang, $(LANGUAGES),
'$(DESTDIR)$(localedir)'/$(lang)/LC_MESSAGES/$(CATALOG_NAME)$(SO_MAJOR_VERSION)-$(MAJORVERSION).mo),:)

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:
> Digging a bit more in the history of **/nb.po, there seems to be a
> policy that files that are less than 80% translated are removed¹,

BTW, while the wiki page does still say that, I have a vague idea
that the policy might have been changed later.  I dug in the archives
and could find only this inconclusive discussion:

https://www.postgresql.org/message-id/flat/CAECtzeV6dyu4jTOrorFW%3DB%3DEicyejWO7_Seew3Ch0%3D0wO%2BM-RQ%40mail.gmail.com

However, the actual state of affairs doesn't seem to match the 80%
rule.  I see in src/backend/po in the v18 branch:

de.po        99%
es.po        93%
fr.po        78%
id.po        45%
it.po        81%
ja.po        99%
ka.po        79%
ko.po        99%
pl.po        56%
pt_BR.po    77%
ru.po        99%
sv.po        99%
tr.po        60%
uk.po        90%
zh_CN.po    67%

I annotated these with translation percentages from
babel.postgresql.org, which are probably up-to-the-minute not
reflective of where it was at 18.0 release.  But there's no way
that id.po went from >= 80% to 45% since release, and there are
others that are well under 80%.

So I'm not sure what the active policy really is, but it's not 80%.

            regards, tom lane

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

On 10.12.25 17:14, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> On 09.12.25 22:22, Tom Lane wrote:
>>> At least Solaris is kind enough to let you do that with
>>> symlinks [2], so that after
>>>     cd $INSTALLATION/share/locale
>>>     ln -s es es_ES.UTF-8
>>> translation starts working for that particular value of
>>> lc_messages.
> 
>> How would one know all the country codes to create links for?
> 
> Yeah, I've been wrestling with that question.  The best idea
> I have at the moment is to look at "locale -a" output to see
> which country codes Solaris thinks there are for each language,
> and duplicate that.  What's unclear is whether we should do
> that on-the-fly to match the build machine, or do it once to
> produce a curated list that could be subject to maintenance.
> The former is like what we do to populate pg_collation
> (although we do that at initdb not build time).  But the latter
> seems like it might be wiser policy.

I wonder how other gettext-using projects handle this on Solaris.  Most 
of those will use a higher-level build system such as Automake or Meson, 
and I don't see any facilities there to expand languages into full 
locale names on installation.  So either this is broken for everyone 
else, too, or perhaps this is typically addressed on the packaging level 
(or there is some other explanation we're not seeing yet).  In either 
case, I doubt that fixing this locally in PostgreSQL is the most 
appropriate solution.

Peter Eisentraut <peter@eisentraut.org> writes:
> On 10.12.25 17:14, Tom Lane wrote:
>> Yeah, I've been wrestling with that question.  The best idea
>> I have at the moment is to look at "locale -a" output to see
>> which country codes Solaris thinks there are for each language,
>> and duplicate that.

> I wonder how other gettext-using projects handle this on Solaris.  Most 
> of those will use a higher-level build system such as Automake or Meson, 
> and I don't see any facilities there to expand languages into full 
> locale names on installation.  So either this is broken for everyone 
> else, too, or perhaps this is typically addressed on the packaging level 
> (or there is some other explanation we're not seeing yet).  In either 
> case, I doubt that fixing this locally in PostgreSQL is the most 
> appropriate solution.

I suspect that the answer for most non-Solaris-specific projects has
been "use GNU gettext".  I don't want to rely on that answer, though,
because it will break every one of our Solaris/illumos buildfarm
animals, all of which are linking to libc gettext:

checking for library containing bind_textdomain_codeset... none required

Now it does appear that they all have (portions of?) GNU gettext
installed:

checking for msgfmt... /usr/gnu/bin/msgfmt

and so does my OpenIndiana image, which apparently means that GNU
gettext is pulled in by "sudo pkg install build-essential", because
that's all I did to install stuff.  So maybe we should just say we
don't support the libc flavor of gettext on that platform, which
would require figuring out how to force linking to libintl instead.
I can look into that if it seems like a more acceptable solution.
I'm worried though that it amounts to adding a new dependency on
that platform.

            regards, tom lane

I wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> I wonder how other gettext-using projects handle this on Solaris.

> I suspect that the answer for most non-Solaris-specific projects has
> been "use GNU gettext".

I poked into that and it seems a lot messier than I hoped.  At least
on OpenIndiana, what's actually installed by the "GNU gettext" package
is just the GNU flavors of the gettext command line tools, not a
replacement libintl.  There is a /lib/libintl.so.1, but forcing our
code to link to that doesn't change the problematic behavior.  So
I feel that asking users to install GNU gettext is not going to be
a practical solution.

I notice in Oracle's docs [1] that creating symlinks in the install
tree is just one way to implement a mapping from locale names to
message catalogs: you can also do it at runtime by setting an
environment variable.  So what I'm now theorizing is that users have
just learned to set that variable, which solves the problem across
all packages despite the lack of symlinks.

Hence, what I now propose to get my NLS-testing patch to work on
Solaris is for the test to forcibly set that environment variable
before invoking bindtextdomain:

        /*
         * Solaris' built-in gettext is not bright about associating locales
         * with message catalogs that are named after just the language.
         * Apparently the customary workaround is for users to set the
         * LANGUAGE environment variable to provide a mapping.  Do so here to
         * ensure that the nls.sql regression test will work.
         */
#if defined(__sun__)
        setenv("LANGUAGE", "es_ES.UTF-8:es", 1);
#endif
        pg_bindtextdomain(TEXTDOMAIN);

This is surely a hack, but it's nicely localized and can be readily
undone if anyone comes up with a better answer.

I've verified that the attached v7 passes on current OpenIndiana.

            regards, tom lane

[1] https://docs.oracle.com/cd/E36784_01/html/E39536/gnkbn.html

From 0116f29fc2bb8c3b974e8d605b7523f448cc1d4d Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 12 Dec 2025 14:13:11 -0500
Subject: [PATCH v7] Add a regression test to verify that NLS translation
 works.

We've never actually had a formal test for this facility.
It seems worth adding one now, mainly because we are starting
to depend on gettext() being able to handle the PRI* macros
from <inttypes.h>, and it's not all that certain that that
works everywhere.  So the test goes to a bit of effort to
check all the PRI* macros we are likely to use.

(This effort has indeed found one problem already, now fixed
in commit f8715ec86.)

Discussion: https://postgr.es/m/3098752.1765221796@sss.pgh.pa.us
---
 src/test/regress/expected/nls.out   |  35 ++++++
 src/test/regress/expected/nls_1.out |  20 ++++
 src/test/regress/meson.build        |   2 +
 src/test/regress/nls.mk             |   5 +
 src/test/regress/parallel_schedule  |   2 +-
 src/test/regress/po/LINGUAS         |   1 +
 src/test/regress/po/es.po           | 159 ++++++++++++++++++++++++++++
 src/test/regress/po/meson.build     |   3 +
 src/test/regress/regress.c          |  77 ++++++++++++++
 src/test/regress/sql/nls.sql        |  19 ++++
 10 files changed, 322 insertions(+), 1 deletion(-)
 create mode 100644 src/test/regress/expected/nls.out
 create mode 100644 src/test/regress/expected/nls_1.out
 create mode 100644 src/test/regress/nls.mk
 create mode 100644 src/test/regress/po/LINGUAS
 create mode 100644 src/test/regress/po/es.po
 create mode 100644 src/test/regress/po/meson.build
 create mode 100644 src/test/regress/sql/nls.sql

diff --git a/src/test/regress/expected/nls.out b/src/test/regress/expected/nls.out
new file mode 100644
index 00000000000..5a650294eaf
--- /dev/null
+++ b/src/test/regress/expected/nls.out
@@ -0,0 +1,35 @@
+-- directory paths and dlsuffix are passed to us in environment variables
+\getenv libdir PG_LIBDIR
+\getenv dlsuffix PG_DLSUFFIX
+\set regresslib :libdir '/regress' :dlsuffix
+CREATE FUNCTION test_translation()
+    RETURNS void
+    AS :'regresslib'
+    LANGUAGE C;
+-- Some BSDen are sticky about wanting a codeset name in lc_messages,
+-- but it seems that at least on common platforms it doesn't have
+-- to match the actual database encoding.
+SET lc_messages = 'es_ES.UTF-8';
+SELECT test_translation();
+NOTICE:  traducido PRId64 = 424242424242
+NOTICE:  traducido PRId32 = -1234
+NOTICE:  traducido PRIdMAX = -5678
+NOTICE:  traducido PRIdPTR = 9999
+NOTICE:  traducido PRIu64 = 424242424242
+NOTICE:  traducido PRIu32 = 1234
+NOTICE:  traducido PRIuMAX = 5678
+NOTICE:  traducido PRIuPTR = 9999
+NOTICE:  traducido PRIx64 = 62c6d1a9b2
+NOTICE:  traducido PRIx32 = 4d2
+NOTICE:  traducido PRIxMAX = 162e
+NOTICE:  traducido PRIxPTR = 270f
+NOTICE:  traducido PRIX64 = 62C6D1A9B2
+NOTICE:  traducido PRIX32 = 4D2
+NOTICE:  traducido PRIXMAX = 162E
+NOTICE:  traducido PRIXPTR = 270F
+ test_translation
+------------------
+
+(1 row)
+
+RESET lc_messages;
diff --git a/src/test/regress/expected/nls_1.out b/src/test/regress/expected/nls_1.out
new file mode 100644
index 00000000000..9f1a2776e50
--- /dev/null
+++ b/src/test/regress/expected/nls_1.out
@@ -0,0 +1,20 @@
+-- directory paths and dlsuffix are passed to us in environment variables
+\getenv libdir PG_LIBDIR
+\getenv dlsuffix PG_DLSUFFIX
+\set regresslib :libdir '/regress' :dlsuffix
+CREATE FUNCTION test_translation()
+    RETURNS void
+    AS :'regresslib'
+    LANGUAGE C;
+-- Some BSDen are sticky about wanting a codeset name in lc_messages,
+-- but it seems that at least on common platforms it doesn't have
+-- to match the actual database encoding.
+SET lc_messages = 'es_ES.UTF-8';
+SELECT test_translation();
+NOTICE:  NLS is not enabled
+ test_translation
+------------------
+
+(1 row)
+
+RESET lc_messages;
diff --git a/src/test/regress/meson.build b/src/test/regress/meson.build
index 1da9e9462a9..4001a81ffe5 100644
--- a/src/test/regress/meson.build
+++ b/src/test/regress/meson.build
@@ -57,3 +57,5 @@ tests += {
     'dbname': 'regression',
   },
 }
+
+subdir('po', if_found: libintl)
diff --git a/src/test/regress/nls.mk b/src/test/regress/nls.mk
new file mode 100644
index 00000000000..43227c64f09
--- /dev/null
+++ b/src/test/regress/nls.mk
@@ -0,0 +1,5 @@
+# src/test/regress/nls.mk
+CATALOG_NAME     = regress
+GETTEXT_FILES    = regress.c
+GETTEXT_TRIGGERS = $(BACKEND_COMMON_GETTEXT_TRIGGERS)
+GETTEXT_FLAGS    = $(BACKEND_COMMON_GETTEXT_FLAGS)
diff --git a/src/test/regress/parallel_schedule b/src/test/regress/parallel_schedule
index cc6d799bcea..0931f1dcccf 100644
--- a/src/test/regress/parallel_schedule
+++ b/src/test/regress/parallel_schedule
@@ -76,7 +76,7 @@ test: brin_bloom brin_multi
 # ----------
 # Another group of parallel tests
 # ----------
-test: create_table_like alter_generic alter_operator misc async dbsize merge misc_functions sysviews tsrf tid tidscan
tidrangescancollate.utf8 collate.icu.utf8 incremental_sort create_role without_overlaps generated_virtual 
+test: create_table_like alter_generic alter_operator misc async dbsize merge misc_functions nls sysviews tsrf tid
tidscantidrangescan collate.utf8 collate.icu.utf8 incremental_sort create_role without_overlaps generated_virtual 

 # collate.linux.utf8 and collate.icu.utf8 tests cannot be run in parallel with each other
 # psql depends on create_am
diff --git a/src/test/regress/po/LINGUAS b/src/test/regress/po/LINGUAS
new file mode 100644
index 00000000000..8357fcaaed4
--- /dev/null
+++ b/src/test/regress/po/LINGUAS
@@ -0,0 +1 @@
+es
diff --git a/src/test/regress/po/es.po b/src/test/regress/po/es.po
new file mode 100644
index 00000000000..b3021d57e22
--- /dev/null
+++ b/src/test/regress/po/es.po
@@ -0,0 +1,159 @@
+# Spanish message translation file for regress test library
+#
+# Copyright (C) 2025 PostgreSQL Global Development Group
+# This file is distributed under the same license as the regress (PostgreSQL) package.
+#
+# Tom Lane <tgl@sss.pgh.pa.us>, 2025.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: regress (PostgreSQL) 19\n"
+"Report-Msgid-Bugs-To: pgsql-bugs@lists.postgresql.org\n"
+"POT-Creation-Date: 2025-12-08 13:57-0500\n"
+"PO-Revision-Date: 2025-11-19 19:01-0500\n"
+"Last-Translator: Tom Lane <tgl@sss.pgh.pa.us>\n"
+"Language-Team: PgSQL-es-Ayuda <pgsql-es-ayuda@lists.postgresql.org>\n"
+"Language: es\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: regress.c:202
+#, c-format
+msgid "invalid input syntax for type %s: \"%s\""
+msgstr "la sintaxis de entrada no es válida para tipo %s: «%s»"
+
+#: regress.c:839
+#, c-format
+msgid "test_inline_in_from_support_func called with %d args but expected 3"
+msgstr ""
+
+#: regress.c:847 regress.c:863
+#, c-format
+msgid "test_inline_in_from_support_func called with non-Const parameters"
+msgstr ""
+
+#: regress.c:854 regress.c:870
+#, c-format
+msgid "test_inline_in_from_support_func called with non-TEXT parameters"
+msgstr ""
+
+#: regress.c:903
+#, c-format
+msgid "test_inline_in_from_support_func parsed to more than one node"
+msgstr ""
+
+#: regress.c:914
+#, c-format
+msgid "test_inline_in_from_support_func rewrote to more than one node"
+msgstr ""
+
+#: regress.c:921
+#, c-format
+msgid "test_inline_in_from_support_func didn't parse to a Query"
+msgstr ""
+
+#: regress.c:1028
+#, c-format
+msgid "invalid source encoding name \"%s\""
+msgstr "la codificación de origen «%s» no es válida"
+
+#: regress.c:1033
+#, c-format
+msgid "invalid destination encoding name \"%s\""
+msgstr "la codificación de destino «%s» no es válida"
+
+#: regress.c:1078
+#, c-format
+msgid "default conversion function for encoding \"%s\" to \"%s\" does not exist"
+msgstr "no existe el procedimiento por omisión de conversión desde la codificación «%s» a «%s»"
+
+#: regress.c:1085
+#, c-format
+msgid "out of memory"
+msgstr "memoria agotada"
+
+#: regress.c:1086
+#, c-format
+msgid "String of %d bytes is too long for encoding conversion."
+msgstr "La cadena de %d bytes es demasiado larga para la recodificación."
+
+#: regress.c:1175
+#, c-format
+msgid "translated PRId64 = %<PRId64>"
+msgstr "traducido PRId64 = %<PRId64>"
+
+#: regress.c:1177
+#, c-format
+msgid "translated PRId32 = %<PRId32>"
+msgstr "traducido PRId32 = %<PRId32>"
+
+#: regress.c:1179
+#, c-format
+msgid "translated PRIdMAX = %<PRIdMAX>"
+msgstr "traducido PRIdMAX = %<PRIdMAX>"
+
+#: regress.c:1181
+#, c-format
+msgid "translated PRIdPTR = %<PRIdPTR>"
+msgstr "traducido PRIdPTR = %<PRIdPTR>"
+
+#: regress.c:1184
+#, c-format
+msgid "translated PRIu64 = %<PRIu64>"
+msgstr "traducido PRIu64 = %<PRIu64>"
+
+#: regress.c:1186
+#, c-format
+msgid "translated PRIu32 = %<PRIu32>"
+msgstr "traducido PRIu32 = %<PRIu32>"
+
+#: regress.c:1188
+#, c-format
+msgid "translated PRIuMAX = %<PRIuMAX>"
+msgstr "traducido PRIuMAX = %<PRIuMAX>"
+
+#: regress.c:1190
+#, c-format
+msgid "translated PRIuPTR = %<PRIuPTR>"
+msgstr "traducido PRIuPTR = %<PRIuPTR>"
+
+#: regress.c:1193
+#, c-format
+msgid "translated PRIx64 = %<PRIx64>"
+msgstr "traducido PRIx64 = %<PRIx64>"
+
+#: regress.c:1195
+#, c-format
+msgid "translated PRIx32 = %<PRIx32>"
+msgstr "traducido PRIx32 = %<PRIx32>"
+
+#: regress.c:1197
+#, c-format
+msgid "translated PRIxMAX = %<PRIxMAX>"
+msgstr "traducido PRIxMAX = %<PRIxMAX>"
+
+#: regress.c:1199
+#, c-format
+msgid "translated PRIxPTR = %<PRIxPTR>"
+msgstr "traducido PRIxPTR = %<PRIxPTR>"
+
+#: regress.c:1202
+#, c-format
+msgid "translated PRIX64 = %<PRIX64>"
+msgstr "traducido PRIX64 = %<PRIX64>"
+
+#: regress.c:1204
+#, c-format
+msgid "translated PRIX32 = %<PRIX32>"
+msgstr "traducido PRIX32 = %<PRIX32>"
+
+#: regress.c:1206
+#, c-format
+msgid "translated PRIXMAX = %<PRIXMAX>"
+msgstr "traducido PRIXMAX = %<PRIXMAX>"
+
+#: regress.c:1208
+#, c-format
+msgid "translated PRIXPTR = %<PRIXPTR>"
+msgstr "traducido PRIXPTR = %<PRIXPTR>"
diff --git a/src/test/regress/po/meson.build b/src/test/regress/po/meson.build
new file mode 100644
index 00000000000..e9bd964aa7f
--- /dev/null
+++ b/src/test/regress/po/meson.build
@@ -0,0 +1,3 @@
+# Copyright (c) 2022-2025, PostgreSQL Global Development Group
+
+nls_targets += [i18n.gettext('regress-' + pg_version_major.to_string())]
diff --git a/src/test/regress/regress.c b/src/test/regress/regress.c
index c27305cf10b..26ae0a6c787 100644
--- a/src/test/regress/regress.c
+++ b/src/test/regress/regress.c
@@ -48,6 +48,10 @@
 #include "utils/rel.h"
 #include "utils/typcache.h"

+/* define our text domain for translations */
+#undef TEXTDOMAIN
+#define TEXTDOMAIN PG_TEXTDOMAIN("regress")
+
 #define EXPECT_TRUE(expr)    \
     do { \
         if (!(expr)) \
@@ -1149,3 +1153,76 @@ test_relpath(PG_FUNCTION_ARGS)

     PG_RETURN_VOID();
 }
+
+/*
+ * Simple test to verify NLS support, particularly that the PRI* macros work.
+ */
+PG_FUNCTION_INFO_V1(test_translation);
+Datum
+test_translation(PG_FUNCTION_ARGS)
+{
+#ifdef ENABLE_NLS
+    static bool inited = false;
+
+    /*
+     * Ideally we'd do this bit in a _PG_init() hook.  However, it seems best
+     * that the Solaris hack only get applied in the nls.sql test, so it
+     * doesn't risk affecting other tests that load this module.
+     */
+    if (!inited)
+    {
+        /*
+         * Solaris' built-in gettext is not bright about associating locales
+         * with message catalogs that are named after just the language.
+         * Apparently the customary workaround is for users to set the
+         * LANGUAGE environment variable to provide a mapping.  Do so here to
+         * ensure that the nls.sql regression test will work.
+         */
+#if defined(__sun__)
+        setenv("LANGUAGE", "es_ES.UTF-8:es", 1);
+#endif
+        pg_bindtextdomain(TEXTDOMAIN);
+        inited = true;
+    }
+
+    ereport(NOTICE,
+            errmsg("translated PRId64 = %" PRId64, (int64) 424242424242));
+    ereport(NOTICE,
+            errmsg("translated PRId32 = %" PRId32, (int32) -1234));
+    ereport(NOTICE,
+            errmsg("translated PRIdMAX = %" PRIdMAX, (intmax_t) -5678));
+    ereport(NOTICE,
+            errmsg("translated PRIdPTR = %" PRIdPTR, (intptr_t) 9999));
+
+    ereport(NOTICE,
+            errmsg("translated PRIu64 = %" PRIu64, (uint64) 424242424242));
+    ereport(NOTICE,
+            errmsg("translated PRIu32 = %" PRIu32, (uint32) 1234));
+    ereport(NOTICE,
+            errmsg("translated PRIuMAX = %" PRIuMAX, (uintmax_t) 5678));
+    ereport(NOTICE,
+            errmsg("translated PRIuPTR = %" PRIuPTR, (uintptr_t) 9999));
+
+    ereport(NOTICE,
+            errmsg("translated PRIx64 = %" PRIx64, (uint64) 424242424242));
+    ereport(NOTICE,
+            errmsg("translated PRIx32 = %" PRIx32, (uint32) 1234));
+    ereport(NOTICE,
+            errmsg("translated PRIxMAX = %" PRIxMAX, (uintmax_t) 5678));
+    ereport(NOTICE,
+            errmsg("translated PRIxPTR = %" PRIxPTR, (uintptr_t) 9999));
+
+    ereport(NOTICE,
+            errmsg("translated PRIX64 = %" PRIX64, (uint64) 424242424242));
+    ereport(NOTICE,
+            errmsg("translated PRIX32 = %" PRIX32, (uint32) 1234));
+    ereport(NOTICE,
+            errmsg("translated PRIXMAX = %" PRIXMAX, (uintmax_t) 5678));
+    ereport(NOTICE,
+            errmsg("translated PRIXPTR = %" PRIXPTR, (uintptr_t) 9999));
+#else
+    elog(NOTICE, "NLS is not enabled");
+#endif
+
+    PG_RETURN_VOID();
+}
diff --git a/src/test/regress/sql/nls.sql b/src/test/regress/sql/nls.sql
new file mode 100644
index 00000000000..efeda8c5841
--- /dev/null
+++ b/src/test/regress/sql/nls.sql
@@ -0,0 +1,19 @@
+-- directory paths and dlsuffix are passed to us in environment variables
+\getenv libdir PG_LIBDIR
+\getenv dlsuffix PG_DLSUFFIX
+
+\set regresslib :libdir '/regress' :dlsuffix
+
+CREATE FUNCTION test_translation()
+    RETURNS void
+    AS :'regresslib'
+    LANGUAGE C;
+
+-- Some BSDen are sticky about wanting a codeset name in lc_messages,
+-- but it seems that at least on common platforms it doesn't have
+-- to match the actual database encoding.
+SET lc_messages = 'es_ES.UTF-8';
+
+SELECT test_translation();
+
+RESET lc_messages;
--
2.43.7