Diagnostics that should not be translated

Diagnostics that should not be translated

[Roland Illig]

Hi,

the gcc.pot file currently contains more than 12000 messages to be
translated, which is a very high number. Many of these messages are
diagnostics, and they can be categorized as follows:

* errors in user programs, reported via error ()
* additional info for internal errors, reported via error ()
* internal errors, reported via gfc_internal_error ()
* others

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.

Therefore the internal errors should not be translated at all.
https://gcc.gnu.org/codingconventions.html#Diagnostics currently
mentions a few ways of emitting diagnostics, but there is no way to
produce untranslated diagnostics. Therefore I'd like to have a new
function error_no_i18n that is used instead of error for nonfatal
internal errors, like this:

@code{error_no_i18n} is for diagnostics that are printed before invoking
internal_error. They are not translated.

(I don't care about the exact function name, though. :))

Regards,
Roland

Re: Diagnostics that should not be translated

[Martin Sebor]

On 03/12/2017 04:51 PM, Roland Illig wrote:
> Hi,
>
> the gcc.pot file currently contains more than 12000 messages to be
> translated, which is a very high number. Many of these messages are
> diagnostics, and they can be categorized as follows:
>
> * errors in user programs, reported via error ()
> * additional info for internal errors, reported via error ()
> * internal errors, reported via gfc_internal_error ()
> * others
>
> 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.
>
> Therefore the internal errors should not be translated at all.
> https://gcc.gnu.org/codingconventions.html#Diagnostics currently
> mentions a few ways of emitting diagnostics, but there is no way to
> produce untranslated diagnostics. Therefore I'd like to have a new
> function error_no_i18n that is used instead of error for nonfatal
> internal errors, like this:
>
> @code{error_no_i18n} is for diagnostics that are printed before invoking
> internal_error. They are not translated.

AFAIK, internal errors are reported using the internal_error
or internal_error_no_backtrace APIs.

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.

There are 20-some-odd functions to report diagnostics in GCC
(counting those in diagnostic-core.h).  I haven't used them all
or even understand all their differences and use cases yet so
I would rather no add more to the list if it can be helped.

Martin

Re: Diagnostics that should not be translated

[Richard Earnshaw (lists)]

On 15/03/17 02:43, Martin Sebor wrote:
> On 03/12/2017 04:51 PM, Roland Illig wrote:
>> Hi,
>>
>> the gcc.pot file currently contains more than 12000 messages to be
>> translated, which is a very high number. Many of these messages are
>> diagnostics, and they can be categorized as follows:
>>
>> * errors in user programs, reported via error ()
>> * additional info for internal errors, reported via error ()
>> * internal errors, reported via gfc_internal_error ()
>> * others
>>
>> 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.
>>
>> Therefore the internal errors should not be translated at all.
>> https://gcc.gnu.org/codingconventions.html#Diagnostics currently
>> mentions a few ways of emitting diagnostics, but there is no way to
>> produce untranslated diagnostics. Therefore I'd like to have a new
>> function error_no_i18n that is used instead of error for nonfatal
>> internal errors, like this:
>>
>> @code{error_no_i18n} is for diagnostics that are printed before invoking
>> internal_error. They are not translated.
> 
> AFAIK, internal errors are reported using the internal_error
> or internal_error_no_backtrace APIs.
> 
> 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.
> 

I think sorry messages need to be translated: the user has hit a
limitation in the compiler that they need to be aware of (such as
unsupported option combination).

R.

> There are 20-some-odd functions to report diagnostics in GCC
> (counting those in diagnostic-core.h).  I haven't used them all
> or even understand all their differences and use cases yet so
> I would rather no add more to the list if it can be helped.
> 
> Martin
> 

Re: Diagnostics that should not be translated

[Roland Illig]

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.

Regards,
Roland

Re: Diagnostics that should not be translated

[Martin Sebor]

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:

   https://gcc.gnu.org/wiki/DiagnosticsGuidelines

Martin