[patch, fortran] PR38573 Missing markers for translation

[patch, fortran] PR38573 Missing markers for translation

[Jerry DeLisle]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

Minor patch to had translation marks.

Regression tested. OK for Trunk?

Jerry

2017-03-30  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/38573
	* intrinsic.c (gfc_check_intrinsic_standard): Adjust diagnostics.

[-- Attachment #2: pr38573.diff --]
[-- Type: text/x-patch, Size: 1516 bytes --]

diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index 2f60fe8..2e3b250 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -4575,39 +4575,39 @@ gfc_check_intrinsic_standard (const gfc_intrinsic_sym* isym,
   switch (isym->standard)
     {
     case GFC_STD_F77:
-      symstd_msg = "available since Fortran 77";
+      symstd_msg = _("available since Fortran 77");
       break;
 
     case GFC_STD_F95_OBS:
-      symstd_msg = "obsolescent in Fortran 95";
+      symstd_msg = _("obsolescent in Fortran 95");
       break;
 
     case GFC_STD_F95_DEL:
-      symstd_msg = "deleted in Fortran 95";
+      symstd_msg = _("deleted in Fortran 95");
       break;
 
     case GFC_STD_F95:
-      symstd_msg = "new in Fortran 95";
+      symstd_msg = _("new in Fortran 95");
       break;
 
     case GFC_STD_F2003:
-      symstd_msg = "new in Fortran 2003";
+      symstd_msg = _("new in Fortran 2003");
       break;
 
     case GFC_STD_F2008:
-      symstd_msg = "new in Fortran 2008";
+      symstd_msg = _("new in Fortran 2008");
       break;
 
     case GFC_STD_F2008_TS:
-      symstd_msg = "new in TS 29113/TS 18508";
+      symstd_msg = _("new in TS 29113/TS 18508");
       break;
 
     case GFC_STD_GNU:
-      symstd_msg = "a GNU Fortran extension";
+      symstd_msg = _("a GNU Fortran extension");
       break;
 
     case GFC_STD_LEGACY:
-      symstd_msg = "for backward compatibility";
+      symstd_msg = _("for backward compatibility");
       break;
 
     default:

Re: [patch, fortran] PR38573 Missing markers for translation

[Thomas Koenig]

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.

Regards

	Thomas

Re: [patch, fortran] PR38573 Missing markers for translation

[Jakub Jelinek]

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

Re: [patch, fortran] PR38573 Missing markers for translation

[Jerry DeLisle]

On 04/01/2017 06:40 AM, Jakub Jelinek wrote:
--- snip ---
> 
> 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
> 

Thank you for clarifications. Will change to G_(). I think this PR has been
hanging around a long time because we simply do not understand how these things
work. I posted because I did not think it was very obvious and was not all that
clear to me from the PR discussion.

Jerry

Re: [patch, fortran] PR38573 Missing markers for translation

[Jerry DeLisle]

--- snip ---
>> 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.
>>
--- snip ---

The other choice of course is to not split the messages and do one error message
per case.