i18n and internal errors

i18n and internal errors

[Mark Kettenis]

Hi folks,

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.

Mark

Re: i18n and internal errors

[Kevin Buettner]

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.

Kevin

Re: i18n and internal errors

[Eli Zaretskii]

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

Re: i18n and internal errors

[Andrew Cagney]

Eli Zaretskii wrote:
>>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.

Eli is correct.  Any normal user output (which includes internal-error) 
needs to be translated.

Of course there are the fringes - the output from "maint print symbols" 
for instance - where there is little return on the translation effort. 
I'm avoiding such code for the moment - something to debate later.

Andrew


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

Re: i18n and internal errors

[Eli Zaretskii]

> Date: Mon, 14 Feb 2005 12:40:10 -0500
> From: Andrew Cagney <cagney@gnu.org>
> Cc: Kevin Buettner <kevinb@redhat.com>, gdb@sources.redhat.com
> 
> Of course there are the fringes - the output from "maint print symbols" 
> for instance - where there is little return on the translation effort. 
> I'm avoiding such code for the moment

Fine with me.

Re: i18n and internal errors

[M.M. Kettenis]

"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

Re: i18n and internal errors

[Eli Zaretskii]

> From: "M.M. Kettenis" <m.m.kettenis@alumnus.utwente.nl>
> Date: Tue, 15 Feb 2005 02:10:01 +0000
> Cc: cagney@gnu.org
> 
> > 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.

True, but hopefully not by a lot.

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

We should indeed ask them to reproduce in the C locale, and if the bug
disappears, to translate the message(s) into English as best as they
can.

Re: i18n and internal errors

[Joel Brobecker]

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

FWIW, I agree.

-- 
Joel

Re: i18n and internal errors

[Paul Schlie]

> Kevin Buettner writes:
>> 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.

Arguably, translating text messages emanating from programming tools
which presume (if not for all practical purposes require) the users to be
familiar with English (as it's the basis of the programming languages the
tools themselves are being used to support the authoring/debugging of),
seems like a tremendous waist of time and effort to begin with.

(sorry, just felt compelled to state it; but don't wish to argue it)