* [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®rtested 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®rtested 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®rtested 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®rtested 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).