Translation breaks IDE

Translation breaks IDE

[Frédéric Marchal]

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.

Thanks,

Frederic

Re: Translation breaks IDE

[Richard Biener]

On Fri, Mar 17, 2017 at 9:48 AM, Frédéric Marchal <fmarchal@perso.be> wrote:
> 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 have
-fdiagnostics-parseable-fixits for example, generalizing this to sth like
-fdiagnostics-mi would be nice.

Richard.

> Thanks,
>
> Frederic
>

Re: Translation breaks IDE

[Janne Blomqvist]

On Fri, Mar 17, 2017 at 10:48 AM, Frédéric Marchal <fmarchal@perso.be> wrote:
> This list certainly needs more thinking and IDE folks could give more insight
> but you see were I'm heading.

Not my area of expertise, but it seems the Glorious Future (TM) in
this area is something called the "language server protocol", see
http://langserver.org/ . Though AFAIK nobody is working on GCC
integration so far.


-- 
Janne Blomqvist

Re: Translation breaks IDE

[Frédéric Marchal]

On Friday 17 March 2017 13:32:17 Janne Blomqvist wrote:
> On Fri, Mar 17, 2017 at 10:48 AM, Frédéric Marchal <fmarchal@perso.be> 
wrote:
> > This list certainly needs more thinking and IDE folks could give more
> > insight but you see were I'm heading.
> 
> Not my area of expertise, but it seems the Glorious Future (TM) in
> this area is something called the "language server protocol", see
> http://langserver.org/ . Though AFAIK nobody is working on GCC
> integration so far.

I was looking for a short term solution. Not something that might possibly be 
available in 20 years :-)

Translations are unusable from within an IDE until gcc offers some solution to 
let the IDE detects errors and warnings irrespective of the selected language.

Currently, every single translated gcc*.po file is affected (Spanish and 
Indonesian users would still see errors as "error" apparently translates to 
"error" in those languages).

Frederic

Re: Translation breaks IDE

[Jonathan Wakely]

On 17 March 2017 at 12:17, Frédéric Marchal wrote:
> On Friday 17 March 2017 13:32:17 Janne Blomqvist wrote:
>> Not my area of expertise, but it seems the Glorious Future (TM) in
>> this area is something called the "language server protocol", see
>> http://langserver.org/ . Though AFAIK nobody is working on GCC
>> integration so far.
>
> I was looking for a short term solution. Not something that might possibly be
> available in 20 years :-)

Changing GCC's output and getting IDEs to support it isn't exactly
short term either (and the suggested (E) additions look ugly IMHO).

> Translations are unusable from within an IDE until gcc offers some solution to
> let the IDE detects errors and warnings irrespective of the selected language.
>
> Currently, every single translated gcc*.po file is affected (Spanish and
> Indonesian users would still see errors as "error" apparently translates to
> "error" in those languages).

Or the translators decided not to translate those words, maybe for this reason.

Re: Translation breaks IDE

[David Malcolm]

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 <fmarchal@perso.be>
> wrote:
> > 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
> have
> -fdiagnostics-parseable-fixits for example, generalizing this to sth
> like
> -fdiagnostics-mi would be nice.

This all sounds a lot like:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79423

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.

I can implement this for gcc 8.

What should the diagnostic be called?

  -fdiagnostics-output-format=VALUE
  -fdiagnostics-mi
  -fide

etc

Dave

Re: Translation breaks IDE

[Frédéric Marchal]

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

Re: Translation breaks IDE

[Frédéric Marchal]

On Friday 17 March 2017 12:28:48 Jonathan Wakely wrote:
> On 17 March 2017 at 12:17, Frédéric Marchal wrote:
> > On Friday 17 March 2017 13:32:17 Janne Blomqvist wrote:
> >> Not my area of expertise, but it seems the Glorious Future (TM) in
> >> this area is something called the "language server protocol", see
> >> http://langserver.org/ . Though AFAIK nobody is working on GCC
> >> integration so far.
> > 
> > I was looking for a short term solution. Not something that might possibly
> > be available in 20 years :-)
> 
> Changing GCC's output and getting IDEs to support it isn't exactly
> short term either (and the suggested (E) additions look ugly IMHO).

The (E) and (W) tags would only be visible to the IDE. An IDE aware of that 
tag can easily strip it before displaying the message to the user. But, you 
are right and, beside, the solution proposed by David in his reply to this 
thread is much much better! IDEs don't have to change.

By short term, I mean within one year or two. Linux distributions are very 
slow at adopting newer compiler major versions. I don't expect to see gcc 8 in 
production any time soon.


> > Translations are unusable from within an IDE until gcc offers some
> > solution to let the IDE detects errors and warnings irrespective of the
> > selected language.
> > 
> > Currently, every single translated gcc*.po file is affected (Spanish and
> > Indonesian users would still see errors as "error" apparently translates
> > to
> > "error" in those languages).
> 
> Or the translators decided not to translate those words, maybe for this
> reason.

That's possible, but then, they both forgot to leave the translation unchanged 
for "warning: ".

That's the solution I'll apply with the French translation until the IDE 
compatibility option is available.

Frederic

Re: Translation breaks IDE

[Gabriel Paubert]

On Fri, Mar 17, 2017 at 12:28:48PM +0000, Jonathan Wakely wrote:
> On 17 March 2017 at 12:17, Frédéric Marchal wrote:
> > On Friday 17 March 2017 13:32:17 Janne Blomqvist wrote:
> >> Not my area of expertise, but it seems the Glorious Future (TM) in
> >> this area is something called the "language server protocol", see
> >> http://langserver.org/ . Though AFAIK nobody is working on GCC
> >> integration so far.
> >
> > I was looking for a short term solution. Not something that might possibly be
> > available in 20 years :-)
> 
> Changing GCC's output and getting IDEs to support it isn't exactly
> short term either (and the suggested (E) additions look ugly IMHO).
> 
> > Translations are unusable from within an IDE until gcc offers some solution to
> > let the IDE detects errors and warnings irrespective of the selected language.
> >
> > Currently, every single translated gcc*.po file is affected (Spanish and
> > Indonesian users would still see errors as "error" apparently translates to
> > "error" in those languages).
> 
> Or the translators decided not to translate those words, maybe for this reason.

For Spanish at least, "error" is the correct translation, although the
pronunciation is vastly different.

    Gabriel

Re: Translation breaks IDE

[Andreas Schwab]

On Mär 17 2017, Frédéric Marchal <fmarchal@perso.be> wrote:

> On Friday 17 March 2017 09:30:40 David Malcolm wrote:
>> 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? 

You can write --ide or --diagnostics-mi if you like.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Translation breaks IDE

[Florian Weimer]

On 03/17/2017 02:30 PM, David Malcolm wrote:
> 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:

It probably should be an environment variable, too, so that an IDE can 
set that before running make.  Otherwise, the programmer has to change 
the makefile manually, or this kind of IDE support is restricted to IDEs 
with integrated build systems.

Thanks,
Florian

Re: Translation breaks IDE

[Frédéric Marchal]

On Tuesday 21 March 2017 10:57:33 Florian Weimer wrote:
> On 03/17/2017 02:30 PM, David Malcolm wrote:
> > 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:
>
> It probably should be an environment variable, too, so that an IDE can
> set that before running make.  Otherwise, the programmer has to change
> the makefile manually, or this kind of IDE support is restricted to IDEs
> with integrated build systems.

That's a good idea.

A command line option can easily be passed to the compiler (at least in 
QtCreator) but the user has first to figure out that the errors and warnings are 
broken in the IDE because of a problem in the compiler and, then, that it can 
be fixed by passing a flag to the compiler!

With an environment variable, the IDE can set the variable once and for all. 
It won't break compilers that don't support it and it will start working as 
soon as gcc 4, 5, 6 and 7 are phased out (within 15 years or so :-) ).

I like the idea. It requires zero knowledge or action from the user.

Frederic