public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH, fortran] Fix translation issue with character length * errors (PR fortran/79860)
@ 2017-03-15  0:32 David Malcolm
  2017-03-15  3:40 ` Jerry DeLisle
  0 siblings, 1 reply; 4+ messages in thread
From: David Malcolm @ 2017-03-15  0:32 UTC (permalink / raw)
  To: fortran; +Cc: David Malcolm

This diagnostic from fortran/resolve.c:

gfc_error ("Character-valued %s %qs at %L must not be"
           " assumed length",
           module_proc ? _("module procedure") : _("internal function"),
           sym->name, &sym->declared_at);

is problematic for translation, in particular, to German, where the
two alternatives have different gramatical form.

This patch reworks the message to avoid the issue.

Successfully bootstrapped&regrtested on x86_64-pc-linux-gnu.

OK for trunk? (either now in stage 4, or for next stage1?)

gcc/fortran/ChangeLog:
	PR fortran/79860
	* resolve.c (resolve_contained_fntype): Make error messages more
	amenable to translation.
---
 gcc/fortran/resolve.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 1fbc9f6..accb5a2 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -615,10 +615,11 @@ resolve_contained_fntype (gfc_symbol *sym, gfc_namespace *ns)
 	  gcc_assert (ns->parent && ns->parent->proc_name);
 	  module_proc = (ns->parent->proc_name->attr.flavor == FL_MODULE);
 
-	  gfc_error ("Character-valued %s %qs at %L must not be"
-		     " assumed length",
-		     module_proc ? _("module procedure")
-				 : _("internal function"),
+	  gfc_error (module_proc
+		     ? G_("Character-valued module procedure %qs at %L"
+			  " must not be assumed length")
+		     : G_("Character-valued internal function %qs at %L"
+			  " must not be assumed length"),
 		     sym->name, &sym->declared_at);
 	}
     }
-- 
1.8.5.3

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH, fortran] Fix translation issue with character length * errors (PR fortran/79860)
  2017-03-15  0:32 [PATCH, fortran] Fix translation issue with character length * errors (PR fortran/79860) David Malcolm
@ 2017-03-15  3:40 ` Jerry DeLisle
  2017-03-15 15:14   ` David Malcolm
  0 siblings, 1 reply; 4+ messages in thread
From: Jerry DeLisle @ 2017-03-15  3:40 UTC (permalink / raw)
  To: David Malcolm, fortran

On 03/14/2017 06:02 PM, David Malcolm wrote:
> This diagnostic from fortran/resolve.c:
> 
> gfc_error ("Character-valued %s %qs at %L must not be"
>            " assumed length",
>            module_proc ? _("module procedure") : _("internal function"),
>            sym->name, &sym->declared_at);
> 
> is problematic for translation, in particular, to German, where the
> two alternatives have different gramatical form.
> 
> This patch reworks the message to avoid the issue.
> 
> Successfully bootstrapped&regrtested on x86_64-pc-linux-gnu.
> 
> OK for trunk? (either now in stage 4, or for next stage1?)
> 

Hello David,

I am not familiar with this G_ notation.

G_("Character-valued internal .....

What does this do? Why just in this place?

Jerry

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH, fortran] Fix translation issue with character length * errors (PR fortran/79860)
  2017-03-15  3:40 ` Jerry DeLisle
@ 2017-03-15 15:14   ` David Malcolm
  2017-03-15 17:31     ` Jerry DeLisle
  0 siblings, 1 reply; 4+ messages in thread
From: David Malcolm @ 2017-03-15 15:14 UTC (permalink / raw)
  To: Jerry DeLisle, fortran

On Tue, 2017-03-14 at 20:40 -0700, Jerry DeLisle wrote:
> On 03/14/2017 06:02 PM, David Malcolm wrote:
> > This diagnostic from fortran/resolve.c:
> > 
> > gfc_error ("Character-valued %s %qs at %L must not be"
> >            " assumed length",
> >            module_proc ? _("module procedure") : _("internal
> > function"),
> >            sym->name, &sym->declared_at);
> > 
> > is problematic for translation, in particular, to German, where the
> > two alternatives have different gramatical form.
> > 
> > This patch reworks the message to avoid the issue.
> > 
> > Successfully bootstrapped&regrtested on x86_64-pc-linux-gnu.
> > 
> > OK for trunk? (either now in stage 4, or for next stage1?)
> > 
> 
> Hello David,
> 
> I am not familiar with this G_ notation.
> 
> G_("Character-valued internal .....
> 
> What does this do? Why just in this place?

(caveat: I'd forgotten all this, and re-read the code last week to
figure it out again; hopefully I got it right...)

Very short answer:

See gcc/ABOUT-GCC-NLS in the source tree.

Longer answer:

xgettext normally does the right thing, but ?: can confuse it, so we
need to help.  G_(literal) explicitly marks a string as needing to be
included in the .pot file (so that translators can translate it in the
various .po files), but not to be translated at runtime; the
diagnostics subsystem does the string lookup later on (and doesn't
bother for those warnings that aren't actually issued due to command
-line flags).

Much longer answer:

Various functions in the gcc source tree have a param named "msgid" or
"gmsgid".  This parameter name is "magic" in the sense that it's used
by $(srcdir)/po/exgettext when a maintainer regenerates gcc.pot (see
that target within gcc/Makefile.in).  po/exgettext calls xgettext to
detect such functions, and hence "knows" that the relevant params are
user-visible strings that need translation.

For example, in gcc/fortran/error.c, this definition:

  void
  gfc_error (const char *gmsgid, ...)
  {
    /* ...etc */
  }

has a "gmsgid" param, so xgettext "knows" that in any calls to
gfc_error that the first param will need to go in the gcc.pot file. 
 Also, because it's "gmsgid" and not "msgid" the strings get tagged
with "gcc-internal-format" in the .pot file, so the translators know
that the format strings support the gcc % codes.

xgettext's parser is smart enough to cope with simple string literals
and concatenations of non-macro literals, but it isn't smart enough to
cope with the ?: ternary operator.  Hence we need to wrap these
literals with G_() so that xgettext "knows" to add them to the .pot
file, and this macro is a no-op, so that the actual translation is
deferred at runtime to inside the diagnostic subsystem (within
 diagnostic_report_diagnostic aka report_diagnostic, after the code for
rejecting disabled warnings).

[AFAIK we have three programs parsing our source tree: the compiler
itself, plus gengtype, and xgettext, and, alas, these implicitly mean
we're coding to a hazily-defined subset of the implementation language;
are there others in our build process?]

Hope this is helpful
Dave

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH, fortran] Fix translation issue with character length * errors (PR fortran/79860)
  2017-03-15 15:14   ` David Malcolm
@ 2017-03-15 17:31     ` Jerry DeLisle
  0 siblings, 0 replies; 4+ messages in thread
From: Jerry DeLisle @ 2017-03-15 17:31 UTC (permalink / raw)
  To: David Malcolm, fortran

On 03/15/2017 08:14 AM, David Malcolm wrote:
> On Tue, 2017-03-14 at 20:40 -0700, Jerry DeLisle wrote:
>> On 03/14/2017 06:02 PM, David Malcolm wrote:
>>> This diagnostic from fortran/resolve.c:
>>>
>>> gfc_error ("Character-valued %s %qs at %L must not be"
>>>            " assumed length",
>>>            module_proc ? _("module procedure") : _("internal
>>> function"),
>>>            sym->name, &sym->declared_at);
>>>
>>> is problematic for translation, in particular, to German, where the
>>> two alternatives have different gramatical form.
>>>
>>> This patch reworks the message to avoid the issue.
>>>
>>> Successfully bootstrapped&regrtested on x86_64-pc-linux-gnu.
>>>
>>> OK for trunk? (either now in stage 4, or for next stage1?)
>>>
>>
>> Hello David,
>>
>> I am not familiar with this G_ notation.
>>
>> G_("Character-valued internal .....
>>
>> What does this do? Why just in this place?
> 
> (caveat: I'd forgotten all this, and re-read the code last week to
> figure it out again; hopefully I got it right...)
> 
> Very short answer:
> 
> See gcc/ABOUT-GCC-NLS in the source tree.
> 

Thankyou for clarifying.

OK to commit.

Jerry

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-03-15 17:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-15  0:32 [PATCH, fortran] Fix translation issue with character length * errors (PR fortran/79860) David Malcolm
2017-03-15  3:40 ` Jerry DeLisle
2017-03-15 15:14   ` David Malcolm
2017-03-15 17:31     ` Jerry DeLisle

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).