Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
Date
Msg-id 9559.1227582679@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.  (Hiroshi Inoue <inoue@tpf.co.jp>)
Responses Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.  (Hiroshi Inoue <inoue@tpf.co.jp>)
List 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 by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
Next
From: Hiroshi Inoue
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.