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

Bagas Sanjaya [off-list ref] writes:

On 17/09/21 03.30, Junio C Hamano wrote:

quoted

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.