From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2250 invoked by alias); 4 Nov 2004 16:21:58 -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 2131 invoked from network); 4 Nov 2004 16:21:55 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 4 Nov 2004 16:21:55 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (rwcrmhc12) with SMTP id <2004110416215101400031obe> (Authid: schlie); Thu, 4 Nov 2004 16:21:52 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Nov 2004 16:21:00 -0000 Subject: Re: GDB 6.4 and translations From: Paul Schlie To: Daniel Jacobowitz CC: Eli Zaretskii , Message-ID: In-Reply-To: <20041104152243.GA28361@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2004-11/txt/msg00038.txt.bz2 > From: Daniel Jacobowitz > > On Thu, Nov 04, 2004 at 12:52:43AM -0500, Paul Schlie wrote: >> No, I don't think you're missing anything. I was simply speculating, being >> ignorant of GDB's longer term internationalization plans, that it may be >> wise to try to avoid the potential complications associated with the default >> use of Unicode left/right quote character codes as tentatively chosen to be >> used in GCC 4.0 quoted output message text on unicode supported platforms; >> as although it may seem aesthetically pleasant, it's likely to create >> otherwise unnecessary complications in circumstances where interface, >> status, warning, and/or error messages may be parsed by subsequent tools >> which may not be unicode aware. > > And I think you're just as wrong here as you were when you said this on > the GCC list. - I accept that I may simply be wrong, or minimally perceiving it to be more significant than it may be; but please too accept that you may be simply wrong, or minimally perceiving it to be less significant issue than it may be. > Eli, the background is that GCC has adopted a new mechanism (the 'q' > qualifier to its internal diagnostics machinery, which takes > printf-like formats). This allows GCC to output Unicode quotes when > using the untranslated (i.e. English) messages - if the current locale > supports them. A user with UTF-8 locales and non-UTF-8 terminals > complained, and Paul also objected on machine-parseability grounds. So > fix your locale and move on... I think the nicety of providing the > quote characters the user's locale requested is a very nice touch. - I too like the quoted format specifiers, but as above, simply don't see any value to hard-coding alternative typographical quote characters; as even many text display programs simply substitute left and right matching quotes in a context dependant way when the text is displayed, without the necessity to hard code them; which is typically how it's done, as most keyboards for example only have one quote character key, and seem to be able to specify typographically neutral text which can be displayed as desired without much difficulty. >> Where given your statements, it doesn't seem to be part of GDB's present >> plans, which I suspect is good; but still suspect that any translated >> message text containing ASCII symbols which are anticipated to be >> potentially utilized by other programs for whatever purpose, should likely >> retain the original ASCII symbol codes in the text were possible by default >> (even on Unicode platforms) to prevent potential subsequent complications, >> if there's a choice in the matter. > > People do still parse the CLI. They will no matter what we tell them. > Well, it's never been intended as a machine parseable interface (that's > what MI is for nowadays), so if they have to add locale workarounds I'm > entirely unsympathetic. - I guess time will tell... > -- > Daniel Jacobowitz Thanks, -paul-