On 12/28/14, 2:56 AM, Craig Ringer wrote:
On 12/25/2014 02:35 AM, Euler Taveira wrote:
Hi,
Currently the same message goes to server log and client app. Sometimes
it bothers me since I have to analyze server logs and discovered that
lc_messages is set to pt_BR and to worse things that
On 12/30/2014 06:39 AM, Jim Nasby wrote:
How much of this issue is caused by trying to machine-parse log files?
Is a better option to improve that case, possibly doing something like
including a field in each line that tells you the encoding for that entry?
That'd be absolutely ghastly. You
On 12/25/2014 02:35 AM, Euler Taveira wrote:
Hi,
Currently the same message goes to server log and client app. Sometimes
it bothers me since I have to analyze server logs and discovered that
lc_messages is set to pt_BR and to worse things that stup^H^H^H
application parse some error
On Wed, Dec 24, 2014 at 1:35 PM, Euler Taveira eu...@timbira.com.br wrote:
Currently the same message goes to server log and client app. Sometimes
it bothers me since I have to analyze server logs and discovered that
lc_messages is set to pt_BR and to worse things that stup^H^H^H
application
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 24, 2014 at 1:35 PM, Euler Taveira eu...@timbira.com.br wrote:
Currently the same message goes to server log and client app.
...
I'm thinking to carry both translated and untranslated messages if we
ask to. We store the untranslated
Hi,
Currently the same message goes to server log and client app. Sometimes
it bothers me since I have to analyze server logs and discovered that
lc_messages is set to pt_BR and to worse things that stup^H^H^H
application parse some error messages in portuguese. My solution has
been a modified
