mailing list of musl libc
 help / color / mirror / code / Atom feed
From: u-wsnj@aetey.se
To: musl@lists.openwall.com
Subject: Re: libintl: stubs or working functions?
Date: Fri, 20 Mar 2015 10:20:52 +0100	[thread overview]
Message-ID: <20150320092052.GQ23636@example.net> (raw)
In-Reply-To: <20150319175443.GF23507@brightrain.aerifal.cx>

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



  reply	other threads:[~2015-03-20  9:20 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-05  9:36 Рысь
2015-03-06 22:24 ` Rich Felker
2015-03-08  9:22   ` Рысь
2015-03-09  0:56     ` Rich Felker
2015-03-15 12:33       ` Рысь
2015-03-15 23:54         ` Rich Felker
2015-03-16  4:18           ` Рысь
2015-03-16 13:04             ` Szabolcs Nagy
2015-03-16 13:35               ` Szabolcs Nagy
2015-03-16 13:41             ` Szabolcs Nagy
2015-03-17  1:40               ` Рысь
2015-03-17  2:01                 ` Rich Felker
2015-03-17  6:59                   ` Рысь
2015-03-17 15:02                     ` Szabolcs Nagy
2015-03-17 15:38                       ` Rich Felker
2015-03-17 18:51                         ` Wermut
2015-03-18 14:10                         ` u-wsnj
2015-03-18 14:26                           ` Jens Gustedt
2015-03-19  8:29                           ` Justin Cormack
2015-03-19  8:55                             ` Jens Gustedt
2015-03-19 12:41                             ` u-wsnj
2015-03-19 17:25                               ` stephen Turner
2015-03-20  1:58                                 ` Weldon Goree
2015-03-20  3:11                                   ` Rich Felker
2015-03-19 17:54                               ` Rich Felker
2015-03-20  9:20                                 ` u-wsnj [this message]
2015-03-20 20:27                                   ` Rich Felker
2015-03-18  7:15                       ` Рысь
2015-03-24  3:59                     ` Рысь
2015-03-16  9:27           ` Szabolcs Nagy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150320092052.GQ23636@example.net \
    --to=u-wsnj@aetey.se \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).