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

From: Junio C Hamano <gitster@pobox.com>
To: "Đoàn Trần Công Danh" <congdanhqx@gmail.com>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>,
	git@vger.kernel.org, Ryan Anderson <ryan@michonline.com>,
	vmiklos@frugalware.org, bedhanger@gmx.de
Subject: Re: [PATCH 2/2] request-pull: mark translatable strings
Date: Thu, 16 Sep 2021 13:30:50 -0700	[thread overview]
Message-ID: <xmqqbl4stg91.fsf@gitster.g> (raw)
In-Reply-To: <YUNKIj44AlW0tkXk@danh.dev> (=?utf-8?B?IsSQb8OgbiBUcuG6p24g?= =?utf-8?B?Q8O0bmc=?= Danh"'s message of "Thu, 16 Sep 2021 20:44:18 +0700")

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

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