Paul Eggert wrote:
> 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.
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 ----
@noindent
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 <[EMAIL PROTECTED]>
>
> * 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.
Bruno
