Re: [PATCH 2/3] sha1_name: get_sha1_with_context learns to follow symlinks

[David Turner <dturner@twopensource.com>]

On Fri, 2015-05-08 at 13:17 -0700, Junio C Hamano wrote:
> On Fri, May 8, 2015 at 12:45 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> >> +       if (flags & GET_SHA1_FOLLOW_SYMLINKS && flags & GET_SHA1_ONLY_TO_DIE)
> >> +               die(_("internal error: bad flags for get_sha1_with_context"));
> >
> > There may not be much value in marking an "internal error" string for
> > translation.
> 
> The whole point of this kind of messages is so that the end users,
> when they see it trigger, can notify us and then to allow us to
> identify which die() triggered.  It is not just "may not be much
> value in", but is actively unproductive to make it translatable,
> even if we ignore the cost to i18n/l10n teams to translate such
> messages.
>
> By the way, we would want to standardise the string before the
> colon, so that we can tell users "If you see an error message that
> begins with 'internal error:', please report that to us---it is a
> programming error".  I think the majority of existing code uses the
> string "BUG:" for that, and I do not mind using 'internal error:'
> for that purpose instead, but the important thing is to use just one
> single string thoughout the codebase, so that the "please report
> when you see this" message we give the users can be simple.

It appears that "BUG:" is preferred to "internal error:" by a margin of
2:1.  So I'll change it.  Fixing the remaining ~40 instances of
"internal error" would be a great project for someone new to git
development.

>From an i18n perspective, I think the correct thing to do would be to
i18n the "BUG" portion and nothing else.  That way, users can understand
what has happened, but if they report it upstream, git developers know
where in the code to look.  But this would probably be complicated to
implement, so maybe not worthwhile.