On Sat, Apr 01, 2017 at 03:28:31PM +0200, Thomas Koenig wrote:
> Hi Jerry,
>
> > Minor patch to had translation marks.
> >
> > Regression tested. OK for Trunk?
>
> OK.
>
> I would think that adding _(...) to a string needing
> translations is both obvious and simple; I think we can
> pre-approve such patches.
It actually is not obvious and is even wrong.
You have:
switch (isym->standard)
{
case GFC_STD_F77:
symstd_msg = _("available since Fortran 77");
break;
case GFC_STD_F95_OBS:
symstd_msg = _("obsolescent in Fortran 95");
break;
...
}
...
if (!silent && isym->standard != GFC_STD_GNU)
gfc_warning (0, "Intrinsic %qs (is %s) is used at %L",
isym->name, _(symstd_msg), &where);
...
/* Otherwise, fail. */
if (symstd)
*symstd = _(symstd_msg);
So, the above means the strings are translated twice (say if in theory
you translate from english to language X and that translation, when
used as english, translated again to language X means something different,
you get wrong message. Furthermore, the above composition of a message
from separately translated parts is very translation unfriendly, consider
if in language Y the "is available since Fortran 77" is translated with
the word "is" somewhere in the middle.
Fix for the double translation is easy, use G_("...") instead of _("...")
on the string literals and then _() where it is, the G_ marks it for
translation but nothing else, and _() actually translates it, but as it
has no string literal in it, doesn't mark anything for translation.
For the construction of diagnostics from separate parts, it is harder,
especially if we don't want to introduce further -Wformat-security warnings.
For construction of a message from parts, it is of course fine if the %s
or %qs provided strings are language keywords that aren't meant to be
translated.
Jakub
