Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150318141513.40161333@r2lynx>
Date: Wed, 18 Mar 2015 14:15:13 +0700
From: Рысь <lynx@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: libintl: stubs or working functions?

On Tue, 17 Mar 2015 16:02:34 +0100
Szabolcs Nagy <nsz@...t70.net> wrote:

> * ???????? <lynx@...server.ru> [2015-03-17 13:59:16 +0700]:
> > Attached is my draft of translated strings you mentioned to Russian.
> > Some strings I borrowed from glibc, but only few of them (things
> > like "Broken pipe" and similar). Certain translations may be
> > inaccurate, but mostly if I did not know context I did an
> > additional quick research by grepping man pages. I think this
> > should be additionally reviewed by russian subscribers.
> > 
> 
> i'm a bit worried about translated error messages, it's always a pain
> to understand bugreports with those
> 
> can we include the enum name?
> like
> 
> msgid "Permission denied"
> msgstr "asdf@# lkjk^& (EPERM)"

Why?

Should there be enforcement like "To report bugs, please do:
...
* Set LC_ALL=C environment variable to leave any translated error
strings back in English
"

I always did that for years.

And, if I remember, Rich wanted(?) to have a special locale where all
error strings are replaced with enum names, so programs will start to
print "program: /dev/full: ENOSPC". This is unrelated, just a
reminder :)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.