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.
