Re: [PATCH 4/6] send-pack: improve unpack-status error messages

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 8, 2017, 17:19 UTC
Message-ID: <xmqqtw733cv9.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170308054533.7wy52myrbpovyoet@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

>> > And finally, neither message was marked for translation. The
>> > message from the remote probably won't be translated, but
>> > there's no reason we can't do better for the local half.
>> 
>> Hmm, OK.
>
> I'll admit that I don't actually use the translations myself, being a
> native English speaker.  So I am just guessing that somebody for whom
> English is a second language would rather see the first half in a more
> intelligible format. That at least tells them what the second half _is_,
> so they might be able to search for the error with more context.
>
> If my guess is wrong, though, I'm happy to retract that part or bump it
> out to a separate patch.

I was merely undecided between "at least half is in my language" and "both are consistently untranslated" which one is easier to use by my highschool friends who do not grok English. And I still cannot decide.

When responding to a request-for-help that quotes messages that was translated, I would imagine we would need one extra "git grep" to find the message (without understanding that ourselves) from po/ for the original before running "git grep" to find the code that produced the message [*1*].

On the other hand, we get request-for-help from those having issues in a setup where the software running on the other side is not even ours, so I am (slightly) more inclined to agree that "half is in my language" is better than nothing.

Thanks.

[Footnote]

*1* If the translation came from us, that is. If I recall correctly, some distros do their own po/ and core Git developers are not likely to have them around, so "git grep" in our po/ may not see any hit.