Re: Solaris versus our NLS files

I wrote:
> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
>> I wonder how other gettext-using projects handle this on Solaris.

> I suspect that the answer for most non-Solaris-specific projects has
> been "use GNU gettext".

I poked into that and it seems a lot messier than I hoped. At least
on OpenIndiana, what's actually installed by the "GNU gettext" package
is just the GNU flavors of the gettext command line tools, not a
replacement libintl. There is a /lib/libintl.so.1, but forcing our
code to link to that doesn't change the problematic behavior. So
I feel that asking users to install GNU gettext is not going to be
a practical solution.

I notice in Oracle's docs [1] that creating symlinks in the install
tree is just one way to implement a mapping from locale names to
message catalogs: you can also do it at runtime by setting an
environment variable. So what I'm now theorizing is that users have
just learned to set that variable, which solves the problem across
all packages despite the lack of symlinks.

Hence, what I now propose to get my NLS-testing patch to work on
Solaris is for the test to forcibly set that environment variable
before invoking bindtextdomain:

/*
* Solaris' built-in gettext is not bright about associating locales
* with message catalogs that are named after just the language.
* Apparently the customary workaround is for users to set the
* LANGUAGE environment variable to provide a mapping. Do so here to
* ensure that the nls.sql regression test will work.
*/
#if defined(__sun__)
setenv("LANGUAGE", "es_ES.UTF-8:es", 1);
#endif
pg_bindtextdomain(TEXTDOMAIN);

This is surely a hack, but it's nicely localized and can be readily
undone if anyone comes up with a better answer.

I've verified that the attached v7 passes on current OpenIndiana.

regards, tom lane

[1] https://docs.oracle.com/cd/E36784_01/html/E39536/gnkbn.html