From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11496 invoked by alias); 25 Oct 2004 21:59:01 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11485 invoked from network); 25 Oct 2004 21:59:00 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 25 Oct 2004 21:59:00 -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 i9PLwttT003290 for ; Mon, 25 Oct 2004 17:59:00 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9PLwtr26481; Mon, 25 Oct 2004 17:58:55 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3BD521294B5; Mon, 25 Oct 2004 17:57:45 -0400 (EDT) Message-ID: <417D76D5.9000105@gnu.org> Date: Mon, 25 Oct 2004 21:59:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Eli Zaretskii , Baurjan Ismagulov Cc: gdb-patches@sources.redhat.com Subject: Re: an i18n sample References: <20041024104805.GA2369@ata.cs.hun.edu.tr> <01c4b9ff$Blat.v2.2.2$1ebcb860@zahav.net.il> In-Reply-To: <01c4b9ff$Blat.v2.2.2$1ebcb860@zahav.net.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00416.txt.bz2 >>- fprintf_unfiltered (gdb_stderr, "Type "); >>+ fprintf_unfiltered (gdb_stderr, _("Type ")); >> if (type == NULL) >>- fprintf_unfiltered (gdb_stderr, "(null)"); >>+ fprintf_unfiltered (gdb_stderr, _("(null)")); >> else >> type_print (type, "", gdb_stderr, -1); >>- error (" is not a structure or union type"); >>+ error (_(" is not a structure or union type")); > > > This fragment should be rewritten to use full sentences, like in > "Type (null) is not a structure or union type", instead of marking > each part separately. That way, a translator will be able to > translate the entire sentence as a single entity, rather than each > part. (Translating sentences in parts usually leads to bad > translations, unless the translator makes an effort to read the > source.) This isn't the first time we've seen an attempt to mark up GDB. Last time, unfortunatly, things became bogged down by the desire to fix i18n code problems _before_ marking things, and that let to the process becomming stalled (it's scope became too large so nothing happened), and eventually dropped. Lets try to avoid that mistake this time. Looking at the work, there are two tasks here: - mark up gdb's strings - fix i18n breakage Where there's a trivial tweak, perhaps commit it, but for more complex cases we should consider leaving them(1), comming back later. We'll soon hear about it - the i18n users will soon alert us to where english is still showing through. By doing this we can can limit the scope of the immediate task (so it can be completed), and then address the second over time. Hmm, should we require all strings to be "marked-up", using a new macro ``I_()'' for identity strings - ones that shouldn't be translated. If we do that I can ARI this letting us catch new code not marked up. Does that sound reasonable? Andrew PS: We could even mark the questionable cases up with D_() - deprecated - so that they are easier to find.