From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2379 invoked by alias); 14 Feb 2005 17:41:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2327 invoked from network); 14 Feb 2005 17:41:46 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 14 Feb 2005 17:41:46 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1EHfet2022190 for ; Mon, 14 Feb 2005 12:41:46 -0500 Received: from localhost.redhat.com (vpn50-67.rdu.redhat.com [172.16.50.67]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1EHfeO22676; Mon, 14 Feb 2005 12:41:40 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D35327D79; Mon, 14 Feb 2005 12:40:11 -0500 (EST) Message-ID: <4210E27A.7060500@gnu.org> Date: Mon, 14 Feb 2005 20:38:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Eli Zaretskii , kettenis@gnu.org Cc: Kevin Buettner , gdb@sources.redhat.com Subject: Re: i18n and internal errors References: <200502120253.j1C2rfUc003498@copland.sibelius.xs4all.nl> <20050211212415.1c7d28ad@ironwood.lan> <01c510f5$Blat.v2.4$edb4acc0@zahav.net.il> In-Reply-To: <01c510f5$Blat.v2.4$edb4acc0@zahav.net.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00100.txt.bz2 Eli Zaretskii wrote: >>Date: Fri, 11 Feb 2005 21:24:15 -0700 >>From: Kevin Buettner >>Cc: gdb@sources.redhat.com >> >>On Fri, 11 Feb 2005 21:53:41 -0500 (EST) >>Mark Kettenis wrote: >> >> >>>Should we really be marking internal errors for translation? I think >>>we shouldn't. These are all messages the end-user shouldn't be >>>seeing. Having them translated, makes it only more difficult for us >>>to fix bugs. >> >>I agree. > > > I don't. Eli is correct. Any normal user output (which includes internal-error) needs to be translated. Of course there are the fringes - the output from "maint print symbols" for instance - where there is little return on the translation effort. I'm avoiding such code for the moment - something to debate later. Andrew > Mark gave 2 reasons for not translating internal errors: > > . end users should not see these messages > . having them translated makes it difficult to fix bugs > > If I understand these reasons as Mark meant, they actually say: if an > end user sees and reports such a message in translated form, those of > us who don't understand the translated message will have difficulty > finding and fixing the bug. > > If that's what Mark meant, then he obviously says that end users > _will_ see these messages. Messages that end users see should be > translated, so that the users will understand them easily. Fatal > messages should certainly be understood unequivocally, because it's > crucial that the user understands the situation on which she is asked > to act (dump core, continue, etc.) > > As for the difficulty in fixing the bugs, the fatal messages typically > include a file name and a line number which point to the place where > the bug was caught. I think that alleviates some of the difficulties. > > Also, it is customary for users to translate the messages into English > when reporting bugs (a case in point is messages from the OS utilities > that have some relevance to the bug being reported), since the users > generally understand that English is a better language to talk to > maintainers. > > As another data point, none of the GNU projects in which I'm involved > decided not to translate messages about internal errors. > > So, on balance, I think we should translate the internal error > messages. >