From: "Eli Zaretskii" <eliz@gnu.org>
To: Kevin Buettner <kevinb@redhat.com>
Cc: kettenis@gnu.org, gdb@sources.redhat.com
Subject: Re: i18n and internal errors
Date: Sat, 12 Feb 2005 11:57:00 -0000 [thread overview]
Message-ID: <01c510f5$Blat.v2.4$edb4acc0@zahav.net.il> (raw)
In-Reply-To: <20050211212415.1c7d28ad@ironwood.lan> (message from Kevin Buettner on Fri, 11 Feb 2005 21:24:15 -0700)
> Date: Fri, 11 Feb 2005 21:24:15 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> Cc: gdb@sources.redhat.com
>
> On Fri, 11 Feb 2005 21:53:41 -0500 (EST)
> Mark Kettenis <kettenis@gnu.org> wrote:
>
> > Should we really be marking internal errors for translation? I think
> > we shouldn't. These are all messages the end-user shouldn't be
> > seeing. Having them translated, makes it only more difficult for us
> > to fix bugs.
>
> I agree.
I don't.
Mark gave 2 reasons for not translating internal errors:
. end users should not see these messages
. having them translated makes it difficult to fix bugs
If I understand these reasons as Mark meant, they actually say: if an
end user sees and reports such a message in translated form, those of
us who don't understand the translated message will have difficulty
finding and fixing the bug.
If that's what Mark meant, then he obviously says that end users
_will_ see these messages. Messages that end users see should be
translated, so that the users will understand them easily. Fatal
messages should certainly be understood unequivocally, because it's
crucial that the user understands the situation on which she is asked
to act (dump core, continue, etc.)
As for the difficulty in fixing the bugs, the fatal messages typically
include a file name and a line number which point to the place where
the bug was caught. I think that alleviates some of the difficulties.
Also, it is customary for users to translate the messages into English
when reporting bugs (a case in point is messages from the OS utilities
that have some relevance to the bug being reported), since the users
generally understand that English is a better language to talk to
maintainers.
As another data point, none of the GNU projects in which I'm involved
decided not to translate messages about internal errors.
So, on balance, I think we should translate the internal error
messages.
next prev parent reply other threads:[~2005-02-12 11:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-12 3:51 Mark Kettenis
2005-02-12 6:26 ` Kevin Buettner
2005-02-12 11:57 ` Eli Zaretskii [this message]
2005-02-14 20:38 ` Andrew Cagney
2005-02-15 0:52 ` Eli Zaretskii
2005-02-15 4:55 ` M.M. Kettenis
2005-02-15 14:35 ` Eli Zaretskii
2005-02-12 13:40 ` Joel Brobecker
2005-02-12 19:57 Paul Schlie
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='01c510f5$Blat.v2.4$edb4acc0@zahav.net.il' \
--to=eliz@gnu.org \
--cc=gdb@sources.redhat.com \
--cc=kettenis@gnu.org \
--cc=kevinb@redhat.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox