Diagnostics that should not be translated

Martin Sebor msebor@gmail.com
Wed Mar 15 16:46:00 GMT 2017

On 03/15/2017 10:07 AM, Roland Illig wrote:
> Am 15.03.2017 um 03:43 schrieb Martin Sebor:
>> Would using the existing internal_error{,no_backtrace}, and
>> sorry work for this? (I.e., not translating those.)  If my
>> count is right there are nearly 500 calls to these three in
>> GCC sources so I'm not sure that would put enough of a dent
>> in the 12K messages to translate but I'm even less sure that
>> adding yet another API would do even that much.
> In relative terms the 500 may seem like not so much, but in absolute
> terms they are still worth 1 to 3 days of translating work. Especially
> since many of the terms in the internal errors are not as carefully
> worded as the diagnostics targeted at the GCC user, and they contain
> lots of technical terms for which there is no obvious translation.
> For the German translation I took the easy path of making the German
> internal errors exactly the same as the English ones, so whether this is
> addressed or not won't make a difference for the upcoming release. It's
> just that I think the other translators shouldn't need to go through the
> same steps as I did.

I would suggest to open a request in Bugzilla then and explain
that internal_error{,no_backtrace} strings don't need to be
translated.  (From Richard's reply it sounds like the "sorry"
ones still do).

Personally, I think it's less work for everyone not to have to
worry about translating these so it seems like a win-win.  It
would be helpful to put in place some sort of a checker to catch
some of these problems (or unnecessary annotation if there's
consensus about your proposal) early, during development.

Since there have been a number of general suggestions recently
to improve how GCC deals with internationalization it might
also be helpful to summarize those that end up adopted to
the GCC Diagnostic Guidelines Wiki:



More information about the Gcc mailing list