From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16345 invoked by alias); 21 Jun 2002 19:06:44 -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 16320 invoked from network); 21 Jun 2002 19:06:43 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 21 Jun 2002 19:06:43 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 361913E77; Fri, 21 Jun 2002 15:06:42 -0400 (EDT) Message-ID: <3D137942.4070807@cygnus.com> Date: Fri, 21 Jun 2002 12:06:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tromey@redhat.com Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: start of i18n References: <87elf0wnp2.fsf@fleche.redhat.com> <3D1360ED.6030201@cygnus.com> <874rfwwlw1.fsf@fleche.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00433.txt.bz2 > "Andrew" == Andrew Cagney writes: > I do know, from the last time I looked at gettextizing gdb (that > would have been April 98) that parts of gdb aren't i18n-safe. For > instance, add_show_from_set is not. This means that as part of the I recently added that to the ARI. That should at least help to stop it spreading. I suspect GDB is going to have some fun with ui-out. Some messages are not contigious strings but rather a concatenation of several strings. > Maintenance-wise there are also some things to be aware of. > Only the first one is difficult. > > * When new strings are added, they must be marked. > This is a coding style change and unfortunately isn't really > automatable. Hopefully checking it can be automated. Sounds like we'll be needing to be more careful with message formats and the like. > * You have to regenerate the primary message catalog whenever strings > are added, changed, or deleted. Should the primary catalogue even be kept in CVS (at least on the trunk)? Hmm, how do things handle a situtation where the primary catalogue gets changed but not the translated catalogs? Given that GDB is interactive it is likely going to see more string changes then say BINUTILS or GCC. > * You have to periodically send the master catalog to the appropriate > site so that translation teams can work on it. I know some projects > (Gnome) try to do a string freeze before a release so that the > translation teams can catch up. > > * You have to periodically incorporate new translation catalogs from > the translation teams into the source repository. > > > A couple other ways gdb could be made i18n-aware, plus my comments: > > * gdb could be aware of the encoding of strings in the inferior, and > convert to the correct output encoding when printing. In some > situations this might be nice. I don't plan to look at this. > > * In theory gdb commands could be translated. However, I think there > is some consensus that in general translating commands and arguments > is too difficult in practice. I don't think anybody is doing this, > so for now I think gdb should not either. (For instance: program > names and command-line arguments aren't translated, Emacs function > names aren't translated.) more fun! thanks, Andrew