Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> 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.
