From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | MauMau <maumau307(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, alvherre(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [bug fix] multibyte messages are displayed incorrectly on the client |
Date: | 2014-01-07 02:55:32 |
Message-ID: | 20140107025532.GA30539@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jan 5, 2014 at 04:40:17PM +0900, MauMau wrote:
> From: "Noah Misch" <noah(at)leadboat(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | David Johnston | 2014-01-07 03:00:24 | Re: Fixing bug #8228 ("set-valued function called in context that cannot accept a set") |
Previous Message | David Johnston | 2014-01-07 02:52:53 | Re: Fixing bug #8228 ("set-valued function called in context that cannot accept a set") |