Date: Tue, 17 Jan 95 21:13:22 MST From: terry@cs.weber.edu (Terry Lambert) To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Cc: wollman@halloran-eldar.lcs.mit.edu, freebsd-hackers@freefall.cdrom.com Subject: Re: CVS stuff Message-ID: <9501180413.AA00168@cs.weber.edu> In-Reply-To: <9501172251.AA25223@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jan 17, 95 05:51:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 1) If Pierro, for instance, takes over maintenance of csh, > > BZZZZT! Individuals don't maintain programs, the FreeBSD community at > large does. OK, you are defining the community as English speaking. I personally do not have a problem with this from a usage standpoint (being an English speaker). I have a problem with this architecturally, but am willing to live with it if that's the way it's going continue to be. > > The whole point of an error message is to provide sufficient information > > to the user that they don't *have* to contact the maintainer, IMO. > > I don't seem to be getting through to you, Terry, and I can't seem to > understand what is so difficult about the idea that, in a distributed > community of users dispersed throughout the world, it is more > important to be able to communicate with other people about your > problems than to have those problems reported in fifteen different > languages. This isn't a difficult idea, and I get it. I understand the idea of a common language, like English for air traffic control. On the other hand, I see the problem of multilingual error reporting to a maintainer as a straw man, unless you explicitly limit your audience to English speakers (either native or secondary). The only time you cause a real problem (other than the "I'm sorry, could you repeat that in English, I don't speak Urdlu" traffic) is when you have a non-English speaker reporting the problem to an English-only speaker. And the answer to that is "Sorry, I can't understand a thing you said". In which case the problem is not one that's going to get solved anyway, especially if all you have to go on is a bunch of text in a language you can't read and an error message with multiple potential causes. > While we're at it: this is a volunteer effort. Who is going to sit > down and perform the tedious (and, I believe, counterproductive) task > of translating five gazillion error messages, in both user and kernel > code, into some language or other, and then constantly watching for > program changes to keep them up-to-date? I think the answer is > `nobody'. There are /far/ more important things to do (like improving > the existing documentation and fixing bugs), and---most > significantly---there are /far/ more interesting things to do. I wouldn't suggest kernel code, simply because the kernel has to be up to do an indirect reference to a catalog, and if it's generating errors, it's not up. The "up to date" problem is one based on the message catalog maintenance, and is solved by an update protocol -- a particular procedure used in causing the error catalog to be updated. Simply combining an origin and update time stamp on the catalog with a no-reuse policy for obsoleted messages would resolve the issue entirely. Oh, and I'd be willing to work on the English, Japanese and French, and if no one else wante to, German (and maybe Greek -- I'm very, very rusty). The error messages are part of the documentation, IMO. > > An > > error message is a mechanism for reporting a condition over which the > > user has control but the program does not. An error like: > > > Error: PI is 3.1415926 > > > Is useless, since what the hell is the user supposed to be able to do > > about that? > > This is a phony straw-man. Try again, with a real example from a > current program. Well, I already gave the "Command not found" message being given to an Italian user who doesn't speak English. > > If the "Lingua Franca" of BSD is to be English, fine, but don't cloud > > the air with BS and hand-waving instead of just stating the decision, > > and if that *is* the decision, be prepared to back it. > > There isn't any ``decision'' to be made; that is the situation now, > and any change would be counterproductive and unlikely in the extreme. No, this is just like multiplatform support. "There isn't any ``decision'' to be made; Intel only is the situation now, and any change would be counterproductive and unlikely in the extreme". > You should be the one to talk about BS and hand-waving, Terry. I'll let that slide. I don't want both sides breaking down into ad-hominim attacks. Please address the issues. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501180413.AA00168>