https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90152
Bug ID: 90152
Summary: untranslated strings in print_z_candidate
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From call.c:
const char *msg = (msgstr == NULL
? ""
: ACONCAT ((msgstr, " ", NULL)));
inform (cloc, "%s%<%D(%T, %T, %T)%> <built-in>", msg, fn,
candidate->convs[0]->type,
candidate->convs[1]->type,
candidate->convs[2]->type);
As a translator I have no idea what this first %s might be. It turns out that
by inspecting the call hierarchy, it can be, among others:
print_z_candidate (0, " after user-defined conversion:",
t->cand);
That's a string literal starting with two spaces (rather uncommon I think), and
in addition, this string is never translated, as it does not appear in gcc.pot.
If the msgstr can be translated as a self-contained unit of text in all the
languages into which GCC is translated (which as of 2019 are mainly French and
German), the proper fix is to surround these strings with _(...). If not, each
of these messages needs its own call to inform().
There's even a comment above print_z_candidate:
NOTE: Unlike most diagnostic functions in GCC, MSGSTR is expected
to have been run through gettext by the caller. This wart makes
life simpler in print_z_candidates and for the translators. */
Instead of this comment, it would be better to pass the untranslated msgstr to
print_z_candidate by enclosing the actual string literals with _(...). Then,
print_z_candidates could be run in a special test build in which there is an
arbitrary translation for each msgid. Then, gettext(msgstr) must be different
from msgstr itself.
