Re: [PATCH 2/2] request-pull: mark translatable strings

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 17, 2021, 16:37 UTC
Message-ID: <xmqq7dffi2ed.fsf@gitster.g>
In-Reply-To: <187b4b89-e037-6103-08f4-870ce8f1e4fd@gmail.com>

Bagas Sanjaya <bagasdotme@gmail.com> writes:

Show 16 quoted lines

> On 17/09/21 03.30, Junio C Hamano wrote:
>> So a good middle ground may be
>>   - allow translation, like these patches attempt
>>   - introduce the command line option "--l10n=<value>" and
>>     the requestpull.l10n configuration variable that gives the
>>     default for the option:
>>     - when it is set to 'true', end-user's local taken from the
>>       environment is used as the target for translation.
>>     - when it is set to 'false', translation is turned off.
>>     - when it is set to any other value, the locale is set to the
>>       value of that variable (imagine a Japanese developer
>>       contributing to a German project).
>> perhaps?   I dunno.
>> 
>
> I'm leaning towards second option.

I didn't give that many options for there to exist the second one, though ;-)

> However, I proposed that --l10n and corresponding config
> requestpull.l10n just take locale value set, and defaults to English 
> (en_US or C) if empty.

I do not quite see merit in that tweak over what I outlined before, though.

But all of the above depends on the assumption that it is a good use of our engineering bandwidth to make request-pull localizable, and more importantly if the "C locale is much more appropriate than the local one when it comes to request-pull" is important enough to make it behave quite differently from other subcommands in our toolbox.

To put it differently, my "I dunno" above still stands---I am not sure if that is a _good_ middle ground, even though it is a middle ground.

Thanks.