[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gcc warning in argmatch

From: Bruno Haible
Subject: Re: gcc warning in argmatch
Date: Fri, 20 Oct 2006 15:38:37 +0200
User-agent: KMail/1.9.1

Paul Eggert wrote:
> I guess I thought it was specified.  The gettext manual says something
> like this under "xgettext Invocation":
>    `--keyword[=KEYWORDSPEC]'
>         Additional keyword to be looked for (without KEYWORDSPEC means not
>         to use default keywords).
>         If KEYWORDSPEC is a C identifer ID, `xgettext' looks for strings
>         in the first argument of each call to the function or macro ID.
> and I took the "strings" to mean that if the first argument contains
> multiple strings, all will be found.

This is indeed the current behaviour, but it's a broken one since

1) it also extracts "foo" in cases like this:
        _(sizeof "foo" == 3 ? "C++" : "C")

2) it fails to combine singular and plural correctly if you use this
   construct inside ngettext.

This behaviour may need to be changed in the future. Therefore I'm
documenting a little more of the current xgettext behaviour, but not all
of it.

*** gettext.texi        20 Oct 2006 12:55:53 -0000      1.114
--- gettext.texi        20 Oct 2006 13:27:44 -0000
*** 1962,1972 ****
--- 1962,1986 ----
  instead of merely using @samp{#include <libintl.h>}.
+ The marking keywords @samp{gettext} and @samp{_} take the translatable
+ string as sole argument.  It is also possible to define marking functions
+ that take it at another argument position.  It is even possible to make
+ the marked argument position depend on the total number of arguments of
+ the function call; this is useful in C++.  All this is achieved using
+ @code{xgettext}'s @samp{--keyword} option.
+ Note also that long strings can be split across lines, into multiple
+ adjacent string tokens.  Automatic string concatenation is performed
+ at compile time according to ISO C and ISO C++; @code{xgettext} also
+ supports this syntax.
  Later on, the maintenance is relatively easy.  If, as a programmer,
  you add or modify a string, you will have to ask yourself if the
  new or altered string requires translation, and include it within

You can now interpret the "looks for strings" phrase as "looks for
multiple adjacent string tokens".

> Other code does rely on the current behavior, even if it is
> unspecified.  E.g., GNU nohup has code like this:
>       error (0, 0,
>            _(ignoring_input
>              ? "ignoring input and appending output to %s"
>              : "appending output to %s"),
>            quote (file));
> and no doubt I can find other examples.
> I could scout through the code I help maintain and change it to avoid
> the unspecified behavior

Thanks. It is not necessary _now_, but it may become necessary when
xgettext needs to change its behaviour (I hope not).

> 2006-10-19  Paul Eggert  <address@hidden>
>       * gettext.texi (Mark Keywords): Allow some nontrivial expressions
>       (but not all expressions) to be marked.  xgettext already supports
>       this; we're just documenting it.

Sorry, I can't accept this patch. What you would be documenting here
does not scale to ngettext. Also it would invite people to play with
complex syntax also in other languages; but the Perl parser in xgettext
doesn't understand and will probably never understand comma expressions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]