Re: Solaris versus our NLS files

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Solaris versus our NLS files
Дата
Msg-id 9e77ce39-34e5-47c5-8f62-aeb6669df4ff@eisentraut.org
обсуждение исходный текст
Ответ на Re: Solaris versus our NLS files  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Solaris versus our NLS files
Список pgsql-hackers
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.




В списке pgsql-hackers по дате отправления: