On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
> I don't know whether after the switch C++ xgettext is being invoked
> explicitly with -C or --c++, or whether we are still relying on xgettext
> to pick the language based on the file extension. This is probably
> another reason why we might want to rename files to use apppropriate
> extensions. In the meantime, we might want to explicitly specify the
> language for the input source file.
>
> po/exgettext only looks whether the parameter name ends with 'msgid'.
And uses --language=c, --language=c++ and --language=GCC-source depending
on the source files and functions in question. The issue is both whether
the awk code properly handles C++ function declarations to identify the
parameter, and whether whatever way it passed the identified function name
to xgettext (if it does identify the function) results in xgettext (with
whatever language it uses) handling the call correctly.
> | > @@ -379,15 +375,15 @@
> | > switch (code)
> | > {
> | > case INTEGER_TYPE:
> | > - pp_string (pp, (TYPE_UNSIGNED (t)
> | > - ? M_("<unnamed-unsigned:")
> | > - : M_("<unnamed-signed:")));
> | > + pp->translate_string (TYPE_UNSIGNED (t)
> | > + ? "<unnamed-unsigned:"
> | > + : "<unnamed-signed:");
> |
> | may need each case of the conditional expression to be marked for
> | extraction for translation, or to be separated into two separate calls
> | using "if" (we've had that issue before with conditional expressions in
> | diagnostics).
>
> Hmm, why would that be needed now, and not before?
> (not that I am found of the conditional, but only by curiosity.)
Previously, each string was inside a separate call to M_() - the strings
themselves were the msgid parameters. Now, the msgid parameter is not a
single string but a more complicated expression and xgettext may not
handle such expressions properly the way it handles having just a single
string as parameter.
--
Joseph S. Myers
jos...@codesourcery.com
