Re: [bug fix] multibyte messages are displayed incorrectly on the client - Mailing list pgsql-hackers

From MauMau
Subject Re: [bug fix] multibyte messages are displayed incorrectly on the client
Date
Msg-id BBC72D617E0A4973A13783B09DD5CDB7@maumau
Whole thread Raw
In response to Re: [bug fix] multibyte messages are displayed incorrectly on the client  (Noah Misch <noah@leadboat.com>)
Responses Re: [bug fix] multibyte messages are displayed incorrectly on the client
Re: [bug fix] multibyte messages are displayed incorrectly on the client
List pgsql-hackers
From: "Noah Misch" <noah@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().

Regards
MauMau




pgsql-hackers by date:

Previous
From: "MauMau"
Date:
Subject: Re: [bug fix] "pg_ctl stop" times out when it should respond quickly
Next
From: David Rowley
Date:
Subject: Re: WITHIN GROUP patch