This is the mail archive of the
mailing list for the GCC project.
Re: Translation breaks IDE
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Frédéric Marchal <fmarchal at perso dot be>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 17 Mar 2017 09:30:40 -0400
- Subject: Re: Translation breaks IDE
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dmalcolm at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9BEB567EA7
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9BEB567EA7
- References: <8012377.DiHZInmtXg@port-fma> <CAFiYyc2rjxjgvghsKtiNV-PmRPoSzuFOcDPCu8QJ1FLwSSEOPQ@mail.gmail.com>
On Fri, 2017-03-17 at 12:20 +0100, Richard Biener wrote:
> On Fri, Mar 17, 2017 at 9:48 AM, Frédéric Marchal <firstname.lastname@example.org>
> > Hi,
> > I gave my partial French translation a field trial this week and it
> > didn't went
> > well. QtCreator can't see error messages any more if they are
> > translated.
> > QtCreator identifies errors and warnings by parsing gcc output:
> > file.c:24:5: error: …
> > file.c:25:3: warning: …
> > But if "error" and "warning" are translated it becomes impossible
> > to sort out
> > the messages.
> > What can be done to help IDEs with translated messages?
> > Is it possible to add some --ide-mode flag or some environment
> > variable that
> > would prefix every message with untranslated hard coded tags that
> > could be used
> > by IDEs? I'm thinking about something along the line:
> > (E):file.c:24:5: <same message as now for errors, with translation>
> > (W): for warnings
> > These two could be put to use immediately because QtCreator already
> > do
> > something similar with MSVC. It just lacks something as the above
> > mechanism to
> > do it with gcc.
> > And it might be possibly to add other categories that could be used
> > later such
> > as:
> > (F): for fatal errors
> > (N): for notifications and informations
> > (I): included by
> > (C): candidates for overloaded functions
> > (H): "called from here" or "in this context"
> > (!): internal error
> > This list certainly needs more thinking and IDE folks could give
> > more insight
> > but you see were I'm heading.
> I think a IDE mode ("machine interface") would be fine. We already
> -fdiagnostics-parseable-fixits for example, generalizing this to sth
> -fdiagnostics-mi would be nice.
This all sounds a lot like:
Paraphrasing myself from that RFE: given that many IDEs can already
parse LANG=C output, presumably you'd want a command-line flag that
suppresses just the translation of "error" and "warning" etc, so that
instead of output of the form:
/tmp/test.cc: 関数 ‘int x2()’ 内:
/tmp/test.cc:3:4: エラー: some translated message here
x0 x3 = x3.
/tmp/test.cc:1:7: 備考: some other translated message here
/tmp/test.cc: In function ‘int x2()’:
/tmp/test.cc:3:4: error: the same *translated* message here
x0 x3 = x3.
/tmp/test.cc:1:7: note: again, the message is still translated here
i.e. that the content of the messages themselves should still be
translated, even when in some kind of IDE mode; it's just the
"error"/"warning" etc boilerplate that shouldn't be.
I can implement this for gcc 8.
What should the diagnostic be called?