Re: Solaris versus our NLS files

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-12-11T14:50:47Z
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.

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.