Re: comments/string changes and issues with dpkg's messages
On 8/28/05, Scott James Remnant <scott@netsplit.com> wrote:
> On Sun, 2005-08-28 at 08:05 +0200, Christian Perrier wrote:
>
> > Quoting Denis Barbier (barbier@linuxfr.org):
> > > On Fri, Aug 26, 2005 at 09:00:04PM +0100, 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.
> >
> >
> > ...which I mostly agree, yes, and would probably make the dpkgPO file
> > less frightening to translators..:-)
> >
> > Scott, the above was obiously humor but it then confuses my mind..:-)
> > Do you actually agree with the messages better being *not*
> > translatable or do you prefer keeping the current situation?
> >
> 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.
Finaly, you reached at my dillema :)
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....
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.
The new restriction would be to always have the function name given as
a parameter and (I think I have seen that this type of message can' t
be always applied - Scott, could you confirm/infirm?)
Also there are some messages for
How do you feel about this approach?
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: