From: | "MauMau" <maumau307(at)gmail(dot)com> |
---|---|
To: | "Noah Misch" <noah(at)leadboat(dot)com> |
Cc: | <alvherre(at)2ndquadrant(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [bug fix] multibyte messages are displayed incorrectly on the client |
Date: | 2014-01-05 07:40:17 |
Message-ID: | BBC72D617E0A4973A13783B09DD5CDB7@maumau |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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().
Regards
MauMau
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2014-01-05 07:53:54 | Re: WITHIN GROUP patch |
Previous Message | MauMau | 2014-01-05 06:49:14 | Re: [bug fix] "pg_ctl stop" times out when it should respond quickly |