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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 16, 2021, 20:30 UTC
Message-ID: <xmqqbl4stg91.fsf@gitster.g>
In-Reply-To: <YUNKIj44AlW0tkXk@danh.dev>

Đoàn Trần Công Danh  <congdanhqx@gmail.com> writes:

Show 9 quoted lines

> I would argue request-pull message shouldn't be translated.
>
> The person who creates the request may prefer to use a different
> language, let's say French, for day-to-day work.
>
> However, the recipients may not understand French, and prefer to
> receive English message.
>
> And this change break their workflow badly.

[jc: devil's advocate hat on]

While that may be true, it would be a nice-to-have if we had an option to help developers who usually work in $French when they contribute to a project where $French is the official tongue (assign any value other than English to variable $French).

[jc: devil's advocate hat off]

I haven't done or seen any official survey, but I would not be surprised if English were used as the official project language by the majority of projects that accept pull request messages.

In that sense, the output that gets translated for the user's usual locale by default, like the patch in question does, is misdesigned. The consequence of the design is that among those who do not usually run in C or en_XX locale, the number of people who will be forced to say

	LANG=C LC_ALL=C git request-pull ...

to override their usual local in order to send the untranslated message to their project that do not want translated requests would be far greater than those who can just say

	git request-pull ...

to send a message in local language to a local project.

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.