From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: More message encoding woes |
Date: | 2009-04-01 17:36:40 |
Message-ID: | 8233.1238607400@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hiroshi Inoue <inoue(at)tpf(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2009-04-01 17:37:56 | Re: SSL over Unix-domain sockets |
Previous Message | David E. Wheeler | 2009-04-01 17:23:18 | Re: [HACKERS] string_to_array with empty input |