On 9/9/13 10:25 AM, Tom Lane wrote:
> Peter Eisentraut <pete...@gmx.net> writes:
>> My suggestion in this matter is to disable gettext processing when
>> LC_CTYPE is set to C. We could log a warning when LC_MESSAGES is set to
>> something and LC_CTYPE is set to C. Or just do the warning and keep
>> logging. Something like that.
>
> Meh. Seems that would only prevent one specific instance of the general
> problem that strerror can fail to translate its result. Other locale
> combinations might create the same kind of failure.
True. There isn't much we can do, really. If your LC_MESSAGES and
LC_CTYPE don't get along, you get what you asked for. This isn't
specific to PostgreSQL:
$ LC_CTYPE=C LC_MESSAGES=ja_JP.utf8 ls --foo
ls: ???????????`--foo'??
???? `ls --help' ????????.
> More generally, though, is strerror actually using gettext at all, or
> some homegrown implementation? As I said upthread, I would expect that
> gettext("foo") returns the given ASCII string "foo" if it fails to create
> a translated version. This is evidently not what's happening in strerror.
That is correct. It returns the original string if it cannot find a
translation or the character conversion of the translation fails. But
the character conversion to "US-ASCII//TRANSLIT" does not fail. It just
produces an undesirable result. If you patch the gettext source to
remove the //TRANSLIT, you will get the result you want.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
