"Joseph S. Myers" <jos...@codesourcery.com> writes:
| On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
|
| > Instead of defining the same macro several times in different
| > translation units, we can just make it a function and use it where
| > needed.
|
| Have you made sure that po/exgettext still extracts the relevant messages
| for translation (I'm not sure how good it is at identifying C++ functions
| with arguments called gmsgid, or how good xgettext then is at identifying
| relevant C++ function calls)? In particular, even if other cases get
| identified properly, conditional expressions such as
I trusted xgettext documentation that says that it handles C++ input
source files.
Looking at the documentation, I notice this:
By default the language is guessed depending on the input
file name extension.
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'.
|
| > @@ -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.)
-- Gaby
