| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Solaris versus our NLS files |
| Date: | 2025-12-09 21:54:21 |
| Message-ID: | CA+hUKG+a_4Y8-b7ukGb9RDX93eeEEcKyZ_ziDOLK6eODRCanNg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 10, 2025 at 10:22 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-12-09 21:54:58 | Re: [Proposal] Adding callback support for custom statistics kinds |
| Previous Message | Melanie Plageman | 2025-12-09 21:42:21 | Re: Trying out read streams in pgvector (an extension) |