From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18221 invoked by alias); 23 Jun 2002 20:33:14 -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 18205 invoked from network); 23 Jun 2002 20:33:07 -0000 Received: from unknown (HELO gash2.peakpeak.com) (207.174.178.17) by sources.redhat.com with SMTP; 23 Jun 2002 20:33:07 -0000 Received: from fleche.redhat.com (ta0193.peakpeak.com [204.144.244.193] (may be forged)) by gash2.peakpeak.com (8.9.3/8.9.3) with ESMTP id OAA20318 for ; Sun, 23 Jun 2002 14:33:05 -0600 Received: by fleche.redhat.com (Postfix, from userid 1000) id D34DB4F80BA; Sun, 23 Jun 2002 14:46:20 -0600 (MDT) To: Gdb List Subject: Questions about gdb and gettext From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom X-Zippy: Why is everything made of Lycra Spandex? Date: Sun, 23 Jun 2002 13:33:00 -0000 Message-ID: <87bsa1pvtv.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-06/txt/msg00207.txt.bz2 I have a few questions about how to proceed with gettextizing gdb. I don't want to proceed until these questions are answered -- with gcc I spent a long time marking all the strings, only to have my work left unused after the fact. I don't want to go through that again. It isn't always necessary to mark every string in the source. You can also tell the xgettext program that certain functions implicitly translate their argument. So, for instance, we could set things up so that the first argument to `warning' and `error' doesn't need any special marking. However, it is likely that we'll still have to mark a substantial number of strings. I doubt it would be appropriate to claim that, say, the first argument to printf_filtered will be translated. (That's just a guess on my part though.) I personally have a preference for marking everything. I think it is easier to maintain, since the rule is easier to explain. However, I don't much care, and I'm sure we'd all prefer that the real gdb maintainers -- the ones who have to keep this stuff intact later on -- make the decision. So: how would you like to approach this problem? I spent a little time today looking at add_show_from_set. One idea I had was to make a new `add_set_and_show' function which would work something like this: add_set_and_show (char *name, enum command_class class, var_types var_type, void *var, char *first_setline, char *first_showline, char *rest_of_docs, struct cmd_list_element **list) The idea here is to factor out the first sentence into separate `show' and `set' sentences, and then keep the rest of the help text the same. I looked at add_setshow_auto_boolean_cmd. This approach is similar, except it reduces the amount of duplicated text. In the case of things like this, my current plan is to store the string in the command structure untranslated, and then translate when printing. This seems more efficient than translating a bunch of strings at startup, since most of those strings are never viewed during a given gdb invocation. So, we'd probably need a new field to store the first sentence of the documentation separately (this might actually reduce memory usage, if it matters, given that we're duplicating all of the help text for the `show' commands right now). Again, here I'm happy to take whatever approach the regular gdb maintainers prefer. It doesn't matter much to me personally. Tom