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

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Дата
Msg-id 522DBF46.30308@gmx.net
обсуждение исходный текст
Ответ на Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: "MauMau"
Дата:
Сообщение: Is this a correct recommendation for Solaris 10 kernel settings?
Следующее
От: Vesa-Matti J Kari
Дата:
Сообщение: Re: Strange hanging bug in a simple milter