This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: i18n and internal errors
- From: "M.M. Kettenis" <m dot m dot kettenis at alumnus dot utwente dot nl>
- To: Eli Zaretskii <eliz at gnu dot org>, Kevin Buettner <kevinb at redhat dot com>, kettenis at gnu dot org, gdb at sources dot redhat dot com
- Cc: cagney at gnu dot org
- Date: Tue, 15 Feb 2005 02:10:01 +0000
- Subject: Re: i18n and internal errors
"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