Re: [PATCH 4/6] send-pack: improve unpack-status error messages
- Date: Wed, 08 Mar 2017 09:19:22 -0800
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH 4/6] send-pack: improve unpack-status error messages
Jeff King <peff@xxxxxxxx> writes:
>> > 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
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.
*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