On Sun, Jan 5, 2014 at 04:40:17PM +0900, MauMau wrote: > From: "Noah Misch" <n...@leadboat.com> > >I agree that English consistently beats mojibake. I question whether that > >makes up for the loss of translation when encodings do happen to match, > >particularly for non-technical errors like a mistyped password. The > >everything-UTF8 scenario appears often, perhaps explaining infrequent > >complaints about the status quo. If 90% of translated message users have > >client_encoding != server_encoding, then +1 for your patch's > >strategy. If the > >figure is only 60%, I'd vote for holding out for a more-extensive fix that > >allows us to encoding-convert localized authentication failure messages. > > I agree with you. It would be more friendly to users if more > messages are localized. > > Then, as a happy medium, how about disabling message localization > only if the client encoding differs from the server one? That is, > compare the client_encoding value in the startup packet with the > result of GetPlatformEncoding(). If they don't match, call > disable_message_localization().
I think the problem is we don't know the client and server encodings at that time. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
