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 more'. 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 mechanically. 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. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]