Daniel Shahaf wrote:
> To be clear, I described two solutions:
> 1. wdiff3
> 2. Having the translator run plain old 'svn diff -r N:M' and eyeball the output.
> I agree that #1 is a blue sky idea --- more precisely, one with a non-
> trivial bootstrap cost --- and as such it is reasonable to reject it,
> following "don't let the best be the enemy of the good".
> #2, however, doesn't have a high bootstrap cost, and I am not sure whether
> you considered it or glossed over it. If you've considered it and still
> prefer the paragraphisation approach, that's fine; I just wanted to make
> sure it hadn't gotten overlooked.
I considered that translators of Subversion might not have their
translation tools and environments set up so that it is *easy* to run
'svn diff' on the relevant file-and-line hunk on demand, at the time
when their translation tool work flow leads them to look at a particular
string. Doing it manually is all very well for a one-off, such as 'svn
help merge' which is (AFAIK) the longest string in the project, for
someone who is familiar enough with finding the relevant revisions and
so on, but I considered that manually running the right diff and finding
the right bit of its output is a PITA if you want to use it frequently
to look at another string and another string and another.
> The decision lies, as always, with
> the people who do the work.
Exactly. And they have told us this before, e.g. dev@ 2017-02-05 Andreas
Stieger "Re: translations",
>> Therefore I plan to go ahead, if there are no strong objections.
> None here.
Received on 2018-03-08 11:34:22 CET