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