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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 22, 2022, 15:33 UTC
Message-ID: <220622.86edzgln00.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqqbkuk7mdb.fsf@gitster.g>

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

Show 21 quoted lines

> Æ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...