https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #12 from Bruno Haible <bruno at clisp dot org> ---
(In reply to Jakub Jelinek from comment #10)
> Is it just about nice to have verification or does msgfmt etc. refuse to
> include translations which contain unknown format specifiers?
When msgfmt is invoked with option '-c' (without this option, it does not check
format strings) and a PO file contains an invalid translation of a string
marked with '#, gcc-internal-format' (for example with 4 %s instead of 3 %s
directives), the "msgfmt -c" invocation fails while still producing a .mo file.
The caller can inspect the exit code and thus ignore/delete the .mo file.
When the *msgid* contains a format directive that is unknown to msgfmt, or when
no '#, gcc-internal-format' marker is present on the message, the "msgfmt -c"
invocation does not complain; i.e. it accepts the message without doing
sensible checking.
The job of avoiding msgids with unknown format specifiers is with xgettext, at
POT file creation time. For example, processing this file
================= x.c =================
printf (gettext ("abc%Ns"));
=======================================
with 'xgettext x.c' produces a warning:
---------------------------------------
x.c:1: warning: Although being used in a format string position, the msgid is
not a valid C format string. Reason: In the directive number 1, the character
'N' is not a valid conversion specifier.
---------------------------------------
Similarly with gcc-internal-format, when the appropriate --keyword and --flag
options are used (provided through gcc's 'exgettext' script).
