From: "Frédéric Marchal" <fmarchal@perso.be>
To: gcc@gcc.gnu.org
Subject: Re: Translation breaks IDE
Date: Fri, 17 Mar 2017 16:36:00 -0000 [thread overview]
Message-ID: <4792803.pJHQirigYk@port-fma> (raw)
In-Reply-To: <1489757440.28956.61.camel@redhat.com>
On Friday 17 March 2017 09:30:40 David Malcolm wrote:
> This all sounds a lot like:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79423
That's exactly the problem I'm faced with. Thanks for pointing it out to me.
> 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:
>
> [with LANG=ja_JP.utf-8]
>
> /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
> class x0;
> ^~
>
> you get:
>
> /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
> class x0;
> ^~
>
> 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.
Right. We don't want to disable translation completely because the message is
displayed to the user and it must be displayed in the correct language.
Your solution is much better than the tag I proposed. With your solution, IDEs
don't have to change anything. The user can add the new command line option
and get the translation working again. That's great!
> I can implement this for gcc 8.
Debian Jessie is still using gcc 4.9, Debian Squeeze will use version 6.
QtCreator ships with version 5. Therefore, I expect it will take a long time
before gcc 8 is used in production. In the meantime, I'll mark the
translations for "error: " and "warning: " as fuzzy in the French po file along
with a comment explaining why.
> What should the diagnostic be called?
>
> -fdiagnostics-output-format=VALUE
> -fdiagnostics-mi
> -fide
If users are expected to add it manually to their IDE's environment, let's
keep it as simple and to the point as possible. Does it have to start with -f?
Can't it just be -ide? Or --ide-output-format?
At the very least, the name should be explicit enough. -fdiagnostics-mi
doesn't talk to me. I fail to see how it relates to a problem with IDEs
parsing messages…
Frederic
next prev parent reply other threads:[~2017-03-17 16:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-17 8:48 Frédéric Marchal
2017-03-17 11:20 ` Richard Biener
2017-03-17 13:30 ` David Malcolm
2017-03-17 16:36 ` Frédéric Marchal [this message]
2017-03-17 19:58 ` Andreas Schwab
2017-03-21 9:57 ` Florian Weimer
2017-03-21 10:55 ` Frédéric Marchal
2017-03-17 11:32 ` Janne Blomqvist
2017-03-17 12:17 ` Frédéric Marchal
2017-03-17 12:28 ` Jonathan Wakely
2017-03-17 16:36 ` Frédéric Marchal
2017-03-17 17:09 ` Gabriel Paubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4792803.pJHQirigYk@port-fma \
--to=fmarchal@perso.be \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).