Re: [PATCH v3 7/7] git-sh-setup: don't mark trees not used in-tree for i18n

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 27.03.22 um 13:15 schrieb Ævar Arnfjörð Bjarmason:
> 
> 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.

I can buy this argument. But then this must be a separate commit with
this justification.

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

This does not sound convincing at all, but rather like "I want the code
to be so, and here is some handwaving to justify it". What is wrong with
the status quo?

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

Translator's time is your concern? No translator sifts through 5000
strings on every release. There are tools that show only new strings to
translate. A text is translated once and then it lies under the radar
until someone changes it. Don't tell me that is time-consuming. On the
other hand, there is a lot of *reviewer* time that you are spending with
changes like this. *That* should be your concern.

-- Hannes



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux