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

Jeff King [off-list ref] writes:

quoted

quoted

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.