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 >
