bug-gnulib
[Top][All Lists]
Advanced

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

Re: gcc warning in argmatch


From: Paul Eggert
Subject: Re: gcc warning in argmatch
Date: Thu, 19 Oct 2006 16:16:22 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Bruno Haible <address@hidden> writes:

> xgettext is not guaranteed to work in this situation. Basically, there
> are too many tokens between the _ and the strings. And there are two
> strings. Should xgettext extract the first or the second string? Or both?
> It is all unspecified.

I guess I thought it was specified.  The gettext manual says something
like this under "xgettext Invocation":

   `-k KEYWORDSPEC'
   `--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.

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, but how about if instead we simply clarify
the gettext specification to match the current xgettext behavior?
That is, we don't rely on having a C expression parser: we simply give
a spec that allows the above example code while not overspecifying
things.  Something like this, perhaps:

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.

*** gettext.texi.~1.113.~       Thu Oct 19 15:16:59 2006
--- gettext.texi        Thu Oct 19 16:14:33 2006
*************** don't verify that the translations are w
*** 1903,1910 ****
  @cindex marking strings that require translation
  
  All strings requiring translation should be marked in the C sources.  Marking
! is done in such a way that each translatable string appears to be
! the sole argument of some function or preprocessor macro.  There are
  only a few such possible functions or macros meant for translation,
  and their names are said to be marking keywords.  The marking is
  attached to strings themselves, rather than to what we do with them.
--- 1903,1910 ----
  @cindex marking strings that require translation
  
  All strings requiring translation should be marked in the C sources.  Marking
! is done in such a way that each translatable string appears within
! the argument of some function or preprocessor macro.  There are
  only a few such possible functions or macros meant for translation,
  and their names are said to be marking keywords.  The marking is
  attached to strings themselves, rather than to what we do with them.
*************** new or altered string requires translati
*** 1968,1973 ****
--- 1968,2014 ----
  @samp{_()} if you think it should be translated.  @samp{"%s: %d"} is
  an example of string @emph{not} requiring translation!
  
+ If multiple strings appear within a marking keyword's argument, they
+ should correspond to alternatives of a conditional expression that
+ evaluates to one of the strings, so that @code{xgettext} can handle
+ them properly without having to understand the semantics of the
+ expression.  For example, the following C code works with
+ @code{xgettext}:
+ 
+ @example
+ printf (gettext (append_flag
+                  ? "appending output to %s"
+                  : "writing output to %s"),
+         file_name);
+ @end example
+ 
+ @noindent
+ with roughly the same effect as:
+ 
+ @example
+ printf ((append_flag
+          ? gettext ("appending output to %s")
+          : gettext ("writing output to %s")),
+         file_name);
+ @end example
+ 
+ @noindent
+ In contrast, the following C code does not work with @code{xgettext},
+ as the strings @samp{appending}, @samp{writing} and @samp{ output to
+ %s} are not the values that are passed to @code{gettext}:
+ 
+ @example
+ /* This doesn't work with xgettext.  */
+ char buf[sizeof "appending output to %s"];
+ printf (gettext (strcat (strcpy (buf,
+                                  (append_flag
+                                   ? "appending"
+                                   : "writing")),
+                          " output to %s")),
+         file_name);
+ @end example
+ 
+ 
  @node Marking, c-format Flag, Mark Keywords, Sources
  @section Marking Translatable Strings
  @emindex marking strings for translation




reply via email to

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