[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150320092052.GQ23636@example.net>
Date: Fri, 20 Mar 2015 10:20:52 +0100
From: u-wsnj@...ey.se
To: musl@...ts.openwall.com
Subject: Re: libintl: stubs or working functions?
On Thu, Mar 19, 2015 at 01:54:43PM -0400, Rich Felker wrote:
> > What I am after is seeing "EXXXXX" as a part of the message with any LANG,
> > including English:
> >
> > LANG=en: "No such file or directory (ENOENT)"
> > LANG=xx: "&((/&=(/%&/(&%/(/)(/&/ ENOENT"
> > ...
> The issues I'm somewhat concerned with are:
>
> - Does this interfere with proper flow of RTL text? In absence of bidi
> nesting chars, I would think the answer might be yes.
Regrettably I think it would. Then, I'd be fine with TNEONE :)
> - Does it result in ugly mix of unmatching fonts in UI, possibly even
> alterring line spacing?
Sometimes quite certainly, but I see this as an implementation issue
of the rendering systems, the inability to mix strings of different
"kinds of glyphs" is artificial.
> Keep in mind that error messages are not necessarily bugs to be
> reported upstream but may be informative to users directly. For
> example a GUI app could be reporting to the user that they file they
> tried to open is not accessible.
I want this even as an application user, without any bug reports
involved.
When an error code passes several layers before being shown to the user
it can "fall out of context" and become misleading.
I encountered ENOENT in a file related operation which indicated that a
different object than a "file or directory" was missing. It would take
less time to realize what happened have I thought about "which errcode
it was" as I finally did, not "why is the file missing".
In other words, I object to the need to mentally "translate back" before
trusting what the message literally says.
In the same way as virtually no one uses "internationalized/localized"
keywords in a programming language (certain spreadsheets come to my mind
as a terrible example of the opposite :) I'd like short and universal
identifiers for the errors, besides those messages oriented towards humans
with unspecified technical proficiency. This would somewhat impact all
users (one extra word per error message) but would improve the life of
some of the users and of many developers. May be I wish too much :)
Rune
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.
