This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Questions about gdb and gettext


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]