Diagnostics that should not be translated

Richard Earnshaw (lists) Richard.Earnshaw@arm.com
Wed Mar 15 10:59:00 GMT 2017

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).


> 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

More information about the Gcc mailing list