Re: [PATCH v2] i18n: mark message helpers prefix for translation

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jun 22 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I posted this patch[1] to do the same a while ago, except it also
>> translates the "BUG: " message:
>
> We should take this one, exactly because it does not touch BUG();
> the messages given to BUG() are not marked for translation, and
> translating only the "BUG:" prefix does not make much sense.
>
> When BUG messages are shown, it is better if they are conveyed back
> to us exactly.  It would be cumbersome to near-impossible, depending
> on the language, if a message was given back to me in a script that
> I do not even know how to type---I'd need to map it back via po/*
> files with "grep" to locate where the message came from.
>
> Besides, BUG messages are meant not to be seen.  We could discuss if
> it makes more sense to translate the messages and spend engineering
> resource to mark them with _() while massaging the messages to help
> deduping, but because the messages are meant primarily for identifying
> the locations and not explaining situation to human user, I do not see
> a huge benefit doing so.

I think this smaller change is fine, I was attempting to summarize the
difference in the approaches, and note that it would be useful if the
commit message communicated some of what you're pointing out here.

The change I have didn't translate the *content* of bug messages (which
we'd need to mark for translation, but we shouldn't do that), just the
"BUG: " prefix, and we'd still leave the file/line number in place.

It's probably going overboard, but it seemed harmless enough, and might
help us get reports we otherwise wouldn't see, as someone who doesn't
speak any English would get the hint.

I realize that git's userbase is fairly technical, and if you're finding
a bug in git you're likely to have some *basic* knowledge of English.

But I think it's good translation practice to not assume that, and to
make the software inviting to people who speak about as much English as
I speak Chinese, i.e. none.

If I was using software originally written in Chinese that had *.po
translations in a language I understood I'd be thoroughly confused if
one day it would tell me:

    昆虫 git.c:123：晦涩难懂的问题

Which I don't even understand one letter of, and I have no idea if it's
grammatically correct. It's just what I get from Google translate if I
ask it to translate "insect: obscure problem".

I'd probably try to copy/paste at least "昆虫", and get an even more
puzzling mention of "insect". Which is what many such users would be
likely to get if they were trying to find out what our "BUG" means, the
idiom of "[a] software bug" is jargon that would translate especially
badly.

So, wouldn't that be more helpful if I'd at least get:

    INTERNAL SOFTWARE ERROR git.c:123：晦涩难懂的问题

So that was the idea.

I know it's an uphill battle sometimes to convince people that there are
a) monolinguals that b) use complex software and c) whose native
language isn't the one we use on this ML. But these people do in fact
exist, and in quite large numbers I might add :)

I think our i18n effort should aim to target that lowest common
denominator, there's other lower hanging fruit, but since we were on the
subject...