Re: i18n and internal errors

Eli Zaretskii
2005-02-12T11:32:17Z

> 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.