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

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.