public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Questions about gdb and gettext
@ 2002-06-23 13:33 Tom Tromey
  2002-06-23 14:33 ` Andrew Cagney
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Tom Tromey @ 2002-06-23 13:33 UTC (permalink / raw)
  To: Gdb List

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about gdb and gettext
  2002-06-23 13:33 Questions about gdb and gettext Tom Tromey
@ 2002-06-23 14:33 ` Andrew Cagney
  2002-06-23 21:52   ` Tom Tromey
  2002-06-24  3:32 ` Eli Zaretskii
  2002-06-24  5:18 ` Richard Earnshaw
  2 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2002-06-23 14:33 UTC (permalink / raw)
  To: tromey; +Cc: Gdb List

> 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.

FYI,

Look at add_setshow_boolean_cmd().  The general direction is for the 
generic commands to go away being replaced by more specific, stronger 
typed, and i18n frendly commands.

Andrew

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about gdb and gettext
  2002-06-23 14:33 ` Andrew Cagney
@ 2002-06-23 21:52   ` Tom Tromey
  2002-06-24  9:10     ` Andrew Cagney
  0 siblings, 1 reply; 8+ messages in thread
From: Tom Tromey @ 2002-06-23 21:52 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: Gdb List

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

>> 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.

Andrew> Look at add_setshow_boolean_cmd().  The general direction is
Andrew> for the generic commands to go away being replaced by more
Andrew> specific, stronger typed, and i18n frendly commands.

I looked at this.  In this case it looks like `help show foo' will
show a short doc string, while `help set foo' will show more text.  Is
this ok for all set/show commands?  If so, then I agree that emulating
this interface is fine.

Tom

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about gdb and gettext
  2002-06-23 13:33 Questions about gdb and gettext Tom Tromey
  2002-06-23 14:33 ` Andrew Cagney
@ 2002-06-24  3:32 ` Eli Zaretskii
  2002-06-24  5:18 ` Richard Earnshaw
  2 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2002-06-24  3:32 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Gdb List


On 23 Jun 2002, Tom Tromey wrote:

> I personally have a preference for marking everything.  I think it is
> easier to maintain, since the rule is easier to explain.

I agree.

> 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.

Agreed.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about gdb and gettext
  2002-06-23 13:33 Questions about gdb and gettext Tom Tromey
  2002-06-23 14:33 ` Andrew Cagney
  2002-06-24  3:32 ` Eli Zaretskii
@ 2002-06-24  5:18 ` Richard Earnshaw
  2002-06-24 11:17   ` Tom Tromey
  2 siblings, 1 reply; 8+ messages in thread
From: Richard Earnshaw @ 2002-06-24  5:18 UTC (permalink / raw)
  To: tromey; +Cc: Gdb List, Richard.Earnshaw


tromey@redhat.com said:
> 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. 

How would that save you having to mark the strings?  AFAICT it would just 
mean that you have to mark them with N_() rather than _().

Unless the strings are marked, gettext won't be able to extract them.

R.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about gdb and gettext
  2002-06-23 21:52   ` Tom Tromey
@ 2002-06-24  9:10     ` Andrew Cagney
  2002-06-24 15:12       ` Tom Tromey
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2002-06-24  9:10 UTC (permalink / raw)
  To: tromey; +Cc: Gdb List

> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> 
> 
>>> 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.
> 
> 
> Andrew> Look at add_setshow_boolean_cmd().  The general direction is
> Andrew> for the generic commands to go away being replaced by more
> Andrew> specific, stronger typed, and i18n frendly commands.

Sorry, I completly bleeped over the paragraph where you mentioned you 
had examined the setshow functions :-(

> I looked at this.  In this case it looks like `help show foo' will
> show a short doc string, while `help set foo' will show more text.  Is
> this ok for all set/show commands?  If so, then I agree that emulating
> this interface is fine.

Hmm, that is a human factors question, see below.

Anyway, for reference, I'll run through how each of the arguments came 
to be:

setshow looks like:

extern void add_setshow_boolean_cmd
(char *name,
enum command_class class,
int *var,
char *set_doc,
char *show_doc,
cmd_sfunc_ftype *set_func,
cmd_sfunc_ftype *show_func,
struct cmd_list_element **set_list,
struct cmd_list_element **show_list);

VS

	add_set_and_show
	(char *name,
	enum command_class class,

Yep.


	var_types var_type,
	void *var,

setshow has an explictily typed parameter:
	int *var;
or
	char **var;
so that -Werror, rather than good luck, can be relied on to ensure 
parameter types match.


	char *first_setline,
	char *first_showline,
	char *rest_of_docs,

I considered something like this but shyed away from it.  I don't know 
enough about international languages to trust that it is legitimate [I 
suspect it is].  I also noticed that while it makes sense for the set 
message to refer to arguments, I don't know if that is valid for a show 
message.

Hmm, the problem also can be that the standard of the set/show online 
doco has been slipping.  The message after the first line just needs to 
be better worded so that it is does apply to both the SET and SHOW cases.

What about having the three:
	set_doc
	show_doc
	sup_doc
(i.e. don't restrict it to the first line?).


	struct cmd_list_element **list)

A show list ends up being needed (well either that or some sort of 
magical gymnastics to guess where the corresponding show command should go).

I also needed to add an explicit set_func and show_func.  Otherwize the 
interface needs to return both the SET and SHOW versions of the command.

enjoy,
Andrew


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about gdb and gettext
  2002-06-24  5:18 ` Richard Earnshaw
@ 2002-06-24 11:17   ` Tom Tromey
  0 siblings, 0 replies; 8+ messages in thread
From: Tom Tromey @ 2002-06-24 11:17 UTC (permalink / raw)
  To: Richard.Earnshaw; +Cc: Gdb List

>>>>> "Richard" == Richard Earnshaw <rearnsha@arm.com> writes:

Tom> It isn't always necessary to mark every string in the source.
Tom> You can also tell the xgettext program that certain functions
Tom> implicitly translate their argument.  So, for instance, we could
Tom> set things up so that the first argument to `warning' and `error'
Tom> doesn't need any special marking.

Richard> How would that save you having to mark the strings?  AFAICT
Richard> it would just mean that you have to mark them with N_()
Richard> rather than _().

We would pass --keyword=error --keyword=warning to xgettext.

Tom

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about gdb and gettext
  2002-06-24  9:10     ` Andrew Cagney
@ 2002-06-24 15:12       ` Tom Tromey
  0 siblings, 0 replies; 8+ messages in thread
From: Tom Tromey @ 2002-06-24 15:12 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: Gdb List

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

Tom> 	char *first_setline,
Tom> 	char *first_showline,
Tom> 	char *rest_of_docs,

Andrew> I considered something like this but shyed away from it.  I
Andrew> don't know enough about international languages to trust that
Andrew> it is legitimate [I suspect it is].

To be honest, I don't know either.  There's a lot of languages out
there.

Andrew> What about having the three:
Andrew> 	set_doc
Andrew> 	show_doc
Andrew> 	sup_doc
Andrew> (i.e. don't restrict it to the first line?).

Suppose I'm marking strings.  What would I put into sup_doc?

Another choice would be to have "help show foo" print a single line
and then say "Use `help set foo' to get more information on this variable".
What do you think of that?

Tom

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2002-06-24 22:12 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-23 13:33 Questions about gdb and gettext Tom Tromey
2002-06-23 14:33 ` Andrew Cagney
2002-06-23 21:52   ` Tom Tromey
2002-06-24  9:10     ` Andrew Cagney
2002-06-24 15:12       ` Tom Tromey
2002-06-24  3:32 ` Eli Zaretskii
2002-06-24  5:18 ` Richard Earnshaw
2002-06-24 11:17   ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).