[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: comments/string changes and issues with dpkg's messages

Jacob Sparre Andersen writes ("Re: comments/string changes and issues with dpkg's messages"):
> 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.

You seem to assume that all errors that dpkg encounters are due to
either mistakes on the part of the user, or due to bugs in dpkg.  This
not even slightly the case.

Just a few other sources of errors, as examples:
 * Broken packages
 * Parts of the system unrelated to dpkg being misconfigured
 * The system being operationally broken in some way
   (out of file descriptors, out of processes, out of swap ...)
 * Hardware faults

Furthermore, it is not, in general, possible to say at any particular
point in the code whether a particular error is likely to be due to
one thing or another.  Most errors are unexpected and the programmer
generally thinks `I hope this doesn't happen and if it does that the
exact details will be sufficient for someone to make it not happen any

It is true that dpkg contains some error messages which are
sufficiently (a) rare, and (b) technical in nature, that translating
them is not a good idea.  But you can't identify those messages

To really know whether a message whose English is complex or technical
is unhelpfully worded, or ought not to be translated, is something
that you need detailed technical knowledge to decide.


Reply to: