Re: More message encoding woes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: More message encoding woes
Date
Msg-id 8233.1238607400@sss.pgh.pa.us
Whole thread Raw
In response to Re: More message encoding woes  (Hiroshi Inoue <inoue@tpf.co.jp>)
Responses Re: More message encoding woes  (Hiroshi Inoue <inoue@tpf.co.jp>)
List pgsql-hackers
Hiroshi Inoue <inoue@tpf.co.jp> writes:
> Heikki Linnakangas wrote:
>> I just tried that, and it seems that gettext() does transliteration, so 
>> any characters that have no counterpart in the database encoding will be 
>> replaced with something similar, or question marks.

> It doesn't occur in the current Windows environment. As for Windows
> gnu gettext which we are using, we would see the original msgid when
> iconv can't convert the msgstr to the target codeset.

Well, if iconv has no conversion to the codeset at all then there is no
point in selecting that particular codeset setting anyway.  The question
was about whether we can distinguish "no conversion available" from
"conversion available, but the test string has some unconvertible
characters".
        regards, tom lane


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: [GENERAL] string_to_array with empty input
Next
From: Martijn van Oosterhout
Date:
Subject: Re: SSL over Unix-domain sockets