public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Roland Illig <roland.illig@gmx.de>, gcc@gcc.gnu.org
Subject: Re: Diagnostics that should not be translated
Date: Wed, 15 Mar 2017 16:46:00 -0000	[thread overview]
Message-ID: <fc4ab9d7-6f5c-742c-dc77-9b615507ff42@gmail.com> (raw)
In-Reply-To: <620d071b-f13a-0be8-6967-481a6a065032@gmx.de>

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

      reply	other threads:[~2017-03-15 16:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-12 22:51 Roland Illig
2017-03-15  2:43 ` Martin Sebor
2017-03-15 10:59   ` Richard Earnshaw (lists)
2017-03-15 16:07   ` Roland Illig
2017-03-15 16:46     ` Martin Sebor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc4ab9d7-6f5c-742c-dc77-9b615507ff42@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=roland.illig@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).