Re: [bug fix] multibyte messages are displayed incorrectly on the client
От | MauMau |
---|---|
Тема | Re: [bug fix] multibyte messages are displayed incorrectly on the client |
Дата | |
Msg-id | BBC72D617E0A4973A13783B09DD5CDB7@maumau обсуждение исходный текст |
Ответ на | Re: [bug fix] multibyte messages are displayed incorrectly on the client (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: [bug fix] multibyte messages are displayed incorrectly on the
client
Re: [bug fix] multibyte messages are displayed incorrectly on the client |
Список | 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 по дате отправления: