Re: comments/string changes and issues with dpkg's messages
Eddy Petriºor wrote:
> Scott James Remnant wrote:
> > > Denis Barbier wrote:
> > > > Scott James Remnant wrote:
> > > > > Yes, because god forbid a developer should be able
> > > > > to understand what's going on when a user files a
> > > > > bug report.
> > > >
> > > > These ohshite messages tell nothing to end users, so
> > > > they are mostly useful for dpkg developers to deal
> > > > with bugreports, which is why they should not be
> > > > translatable.
Agreed. But they _should_ be accompanied by an explanation
telling the user that this error message should be included
in a bug report.
> > It's an interesting question, certainly; to my mind I
> > don't think it's any scarier to dump a scary english
> > message or a scary french one. The added advantage to
> > translating them is that the user might have the skill
> > to know what's going wrong and fix it, the disadvantage
> > is that I have to un-translate them when the error
> > reports come in.
If the user has the skill to fix something based on an error
message in his/her preferred language, I find it very
unlikely that this wouldn't also be the case with an error
message written in English. - At least in those cases where
the error message should result in a bug report. "Disk
full" and "file not found" are of course a different class
of errors.
> I suggest a reengineering of the ohshite function and the
> way it should be used; As I understood the error code will
> be returned, so the type of error is not a problem; a
> problem would be to identify the source of the error in
> the code, for debigging purposes.
>
> Thus, I propose that the error messages are as succint as possible and
> not translatable.
> Example:
>
> Instead of "Could not stat file for xyz"
> the message would be:
>
> error: xyz: stat
> or
> error in function xyz: stat
>
> so the only thing that should be translatable is "error", which should
> be printed within ohshite/ohshit....
I find this a very bad example. In most cases "could not
stat file" is just an incomprehensible way of writing "file
not found". But if the error _is_ due to an error in the
program and not due to incorrect use of the program, I do
agree that there is no point in translating the error
message.
I.e. error messages related to incorrect use of a program
should be fully translatable whereas error messages due to
errors in a program should be untranslatable (but
accompanied by translatable advice on bug reporting).
> The big problem with this approach is that the messages
> are more cryptical and not too useful, at first glance,
> while the advantage is the less amount of string to be
> translated.
If the _program_ fails, the user is lost anyway. The
important thing in that case is to help him/her report the
error as efficiently as possible.
Jacob
--
"Human beings just can't not communicate."
Reply to: