Bagas Sanjaya <bagasdotme@xxxxxxxxx> writes: > 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.
