Expanding on bug 79596 (mentions only gfc_internal_error), as well as a discussion on a mailing list. From https://gcc.gnu.org/ml/gcc/2017-03/msg00049.html: > In my opinion, there is no point in having internal error messages > translated, since their only purpose is to be sent back to the GCC > developers, instead of being interpreted and acted upon by the GCC user. > By not translating the internal errors, the necessary work for > translators can be cut down by several hundred messages.
Confirmed. See also the related discussion in bug 79856.
I do not concur with this request. If a message might be visible to the end user, it is best to translate it. If gcc outputs an English message in the middle of otherwise translated messages such as "import_iso_c_binding_module(): Unable to create symbol for %s", it looks like the translator didn't do his job properly. I translated the above message as "import_iso_c_binding_module(): Impossible de créer le symbole pour %s" The end user may have no clue as to what the message means but, at least, he/she is insulted in his/her own language :-) I suggest instead that internal messages be identified as such. Some other messages begin with "Internal error". I would favor that solution for messages not meant to the end user.
That sounds like a valid point to me. Let me add David, the maintainer of GCC's diagnostic messages, to weigh in on this.
(In reply to Frederic Marchal from comment #2) > I suggest instead that internal messages be identified as such. Some other > messages begin with "Internal error". I would favor that solution for > messages not meant to the end user. Would this prefix be for the benefit of the user, or for translator? (or both?) I believe that everywhere we're using internal_error, the diagnostics machinery will add "internal compiler error: " as a prefix when the message is emitted to the user, and I believe this prefix is translated.
(In reply to David Malcolm from comment #4) > Would this prefix be for the benefit of the user, or for translator? (or > both?) > > I believe that everywhere we're using internal_error, the diagnostics > machinery will add "internal compiler error: " as a prefix when the message > is emitted to the user, and I believe this prefix is translated. The prefix was meant for the user. Roland's suggestion was to reduce the translators workload by removing technical messages from the translation as users aren't supposed to see them and much less understand them. My opinion was that it would be rude to display an untranslated message to the user. But, to spare users some head scratching when faced with a message they are not supposed to understand, I suggested to clearly identify such messages as intended to the gcc development team. If internal_error messages are already clearly identified as such, then all is well from my point of view but you may want to argue about how unlikely it is for a final user to ever see one internal_error.
(In reply to Frederic Marchal from comment #5) > My opinion was that it would be rude to display an untranslated message to > the user. But, to spare users some head scratching when faced with a message > they are not supposed to understand, I suggested to clearly identify such > messages as intended to the gcc development team. So we agree that translating the "internal compiler error:" prefix is enough? > If internal_error messages are already clearly identified as such, then all > is well from my point of view but you may want to argue about how unlikely > it is for a final user to ever see one internal_error. It happens all the time (it shouldn't, but we have bugs).
(In reply to David Malcolm from comment #4) > I believe that everywhere we're using internal_error, the diagnostics > machinery will add "internal compiler error: " as a prefix when the message > is emitted to the user, and I believe this prefix is translated. The avr backend uses the string "internal compiler error" in arguments to fatal_insn, which won't be handle uniformly: #: config/avr/avr.c:2939 msgid "internal compiler error. Bad address:" msgstr "" #: config/avr/avr.c:2980 msgid "internal compiler error. Unknown mode:" msgstr "" #: config/avr/avr.c:6387 config/avr/avr.c:6868 config/avr/avr.c:7283 msgid "internal compiler error. Incorrect shift:" msgstr "" I have no idea if those really are ICEs or if the string is inappropriate, but those messages should probably all have a space after the colon.
Two years later, I appear to be the only active translator. I translated all the messages. So, cutting down the number of messages is not an issue I feel overly concerned with :-) Removing the internal error translations means more work for you. Will it benefit gcc and attract more translators? I doubt it. 13k messages is pretty daunting. Shortening it by several hundred messages will not help much. You can certainly spend your time on a more productive task. Unless fellow translators show up and challenge my opinion, I believe you can close this bug or postpone it. As the one doing the job, the decision is entirely up to you :-)
(In reply to Frederic Marchal from comment #8) > Two years later, I appear to be the only active translator. I translated all > the messages. So, cutting down the number of messages is not an issue I feel > overly concerned with :-) I'm still there as the second active translator. I took a different strategy of translating the internal errors. I just prefixed each of them with "Interner Compilerfehler: " and then took the English text verbatim. I still think this is the best strategy since it provides a bit of information to the compiler user in their language, and provides the GCC developers with the original error message that can be quickly found in the source code. I never actually checked to see how these messages look like in practice. Is there a hidden command line option --force-internal-compiler-error somewhere? It should be quite hard to produce an ICE in any other way. If the prefix would now be doubled, I could as well remove it from all the "translated" German messages.