Solaris versus our NLS files
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2025-12-09T21: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 →
-
Add a regression test to verify that NLS translation works.
- 8c498479d70f 19 (unreleased) landed
-
Translation updates
- 3c70de2e12b9 12.0 cited
-
Translation updates for 8.4 release.
- a6667d96c5e4 8.4.0 cited
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