From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26232 invoked by alias); 4 Nov 2004 00:27:29 -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 26120 invoked from network); 4 Nov 2004 00:27:24 -0000 Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39) by sourceware.org with SMTP; 4 Nov 2004 00:27:24 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (rwcrmhc13) with SMTP id <20041104002723015008lnqce> (Authid: schlie); Thu, 4 Nov 2004 00:27:23 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Nov 2004 00:27:00 -0000 Subject: Re: GDB 6.4 and translations From: Paul Schlie To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2004-11/txt/msg00030.txt.bz2 Although I don't know if it's been considered or even an issue, but it may be worth trying to avoid the use of Unicode's typographical quote characters in otherwise ASCII message string output on even Unicode supported platforms by default; as the potential complications and/or confusions resulting from such a default choice may likely not be worth any perceived benefit; especially for text which may likely be subsequently parsed by tools likely benefiting, and/or depending on the use of plain old ASCII quote characters. (where even translated message text which can't be represented in ASCII, likely benefit from the use of plain old ASCII quote delimiters help keep it's subsequent machine parsing simple, and indifferent to the message's encoding) The above comment does not necessarily apply to documentation; although any text which is meant to represent program code should also likely limit its quote character use to plain old ' and " pairs by default, as expected by most programming language parsers; just as most mark-up languages assume for text designated as being intended as "code". Maybe the FSF should consider the specification of a policy which recognizes the difference between text intended primarily for human consumption, vs message text which may just as likely be parsed by integrated development tools, regardless of Unicode support.