Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Date
Msg-id 522DBF46.30308@gmx.net
Whole thread Raw
In response to Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
List pgsql-hackers
On 9/6/13 10:37 AM, Tom Lane wrote:
> BTW: personally, I would say that what you're looking at is a glibc bug.
> I always thought the contract of gettext was to return the ASCII version
> if it fails to produce a translated version.  That might not be what the
> end user really wants to see, but surely returning something like "???"
> is completely useless to anybody.

The question marks come from iconv.  Take a look at what this prints:

iconv po/ja.po -f utf-8 -t us-ascii//translit

If you use GNU libiconv, this will print a bunch of question marks.
Other implementations will probably not understand //translit and just
fail the conversion.

I think the use of //translit by gettext is poor judgement, because my
experiments show that the quality of the results is poor and not useful
for a user interface.

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.




pgsql-hackers by date:

Previous
From: "MauMau"
Date:
Subject: Is this a correct recommendation for Solaris 10 kernel settings?
Next
From: Vesa-Matti J Kari
Date:
Subject: Re: Strange hanging bug in a simple milter