Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
От | Tom Lane |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use. |
Дата | |
Msg-id | 9559.1227582679@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use. (Hiroshi Inoue <inoue@tpf.co.jp>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to
the UTF8 locale when in use.
|
Список | pgsql-hackers |
Hiroshi Inoue <inoue@tpf.co.jp> writes: > Tom Lane wrote: >> I'm not following this either. If the patch is really necessary then it >> seems it must be working around a bug in the Windows version of gettext, >> ie failure to distinguish CP932 from CP20932. Is that correct? > I'm afraid I don't understand what you mean exactly. > AFAIK the output encoding of Windows gettext is detemined by the > ANSI system code page which is usualy CP932(Shift_JIS) in Japan and > unrelated to the locale settings. If that's true then this code is presently broken for *every* locale under Windows, not only Japanese. To my mind the really correct thing to be doing here would be to call bind_textdomain_codeset in all cases, rather than trusting gettext to guess correctly about which encoding we want. As the comment notes, we have not attempted that because the codeset names aren't well standardized. But it seems to me that we could certainly find out what codeset names are used on Windows, and apply bind_textdomain_codeset all the time on Windows. That would make a lot more sense than ad-hoc treatment of UTF-8 and EUC-JP if you ask me ... regards, tom lane
В списке pgsql-hackers по дате отправления: