On Sun, Mar 27 2022, Johannes Sixt wrote:
> Am 26.03.22 um 18:14 schrieb Ævar Arnfjörð Bjarmason:
>> Partially revert d323c6b6410 (i18n: git-sh-setup.sh: mark strings for
>> translation, 2016-06-17).
>>
>> These strings are no longer used in-tree, and we shouldn't be wasting
>> translator time on them for the benefit of a hypothetical out-of-tree
>> user of git-sh-setup.sh.
>
> There is public documentation for these functions. Hence, you must
> assume that they are used in scripts outside of Git. Castrating their
> functionality like this patch does is unacceptable.
For require_clean_work_tree() the public documentation for this function
states that it will emit a specific error message in English, and you're
expected to Lego-interpolate a string that we'll concatenate with it:
[...]It emits an error message of the form `Cannot
<action>: <reason>. <hint>`, and dies. Example:
+
----------------
require_clean_work_tree rebase "Please commit or stash them."
So I think that marking it for translation like this as d323c6b6410 was
always broken in that it broke that documented promise.
But that's just an argument for keeping the require_clean_work_tree()
part of this patch, not require_work_tree_exists().
For that one and others in git-sh-setup we've never said that we'd
provide these translated (and to the extent we've implied anything about
the rest, have strongly implied the opposite with
require_clean_work_tree()'s docs).
Nothing will break for out-of-tree users as a result of this
change. When we added these functions and their documentation their
output wouldn't be translated, then sometimes it was, now it's not
again.
We need also need to be mindful of translator time, it's a *lot* of
strings to go through, and e.g. I've commented in the past on patches
that marked stuff in t/helper/ for translation.
Some hypothetical out-of-tree user is, I think, a much stronger
candidate for skipping translation than that.
Also keep in mind that we don't even translate in-tree contrib stuff
like contrib/subtree/ (the recent "not-really-contrib" scalar being an
exception).
So I really think this is fine as-is, don't you think that if someone
out-of-tree had such strong expectations about the human-readable
strings these emit that they'd have long since stopped using them and
provided their own replacements?
