| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Solaris versus our NLS files |
| Date: | 2025-12-10 16:14:42 |
| Message-ID: | 638279.1765383282@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Burd | 2025-12-10 16:31:36 | Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB barriers |
| Previous Message | Peter Eisentraut | 2025-12-10 16:02:14 | Re: Solaris versus our NLS files |