From: "M.M. Kettenis" <m.m.kettenis@alumnus.utwente.nl>
To: Eli Zaretskii <eliz@gnu.org>, Kevin Buettner <kevinb@redhat.com>,
kettenis@gnu.org, gdb@sources.redhat.com
Cc: cagney@gnu.org
Subject: Re: i18n and internal errors
Date: Tue, 15 Feb 2005 04:55:00 -0000 [thread overview]
Message-ID: <731992780126277@weblx058.utsp.utwente.nl> (raw)
In-Reply-To: <01c510f5$Blat.v2.4$edb4acc0@zahav.net.il>
"Eli Zaretskii" <eliz@gnu.org> wrote:
> 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.
Yup, that's what I meant.
> 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.)
Hmm, that's a pretty darn convincing argument.
> 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.
Although line numbers might be a bit off compared to the current CVS version or even compared to the release.
> 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.
So we should update the bug reporting instructions to instruct users to run gdb with env LC_ALL="C". Hmm, hopefully that doesn't make the bug
disappear.
Mark
next prev parent reply other threads:[~2005-02-15 2:10 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
2005-02-14 20:38 ` Andrew Cagney
2005-02-15 0:52 ` Eli Zaretskii
2005-02-15 4:55 ` M.M. Kettenis [this message]
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=731992780126277@weblx058.utsp.utwente.nl \
--to=m.m.kettenis@alumnus.utwente.nl \
--cc=cagney@gnu.org \
--cc=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