Simetrical schreef:
I agree that inline diffs would be nicer, instead of
side-by-side.
Having it an HTML-rendered diff instead of a wikitext diff is useful
to some extent, but it hides information. It seems like it would be
relatively difficult to convey the fact that templates or images were
changed, for instance, and things like comments (which must be
included in diffs for proper usability) would also be an issue. Some
mechanism would have to be devised to convey that such invisible
changes took place. Possibly you could have an option to do a
wikitext diff instead, but that doesn't seem ideal to me. Doing it
one way that works well for everyone would be best if possible.
Why not both? Right now, we just render the new version of the article
right below the text diff. We could replace that with an inline diff.
As for performance, please note that Wikimedia uses a
diff engine
written in C++. One written in PHP would probably not be acceptable
on Wikipedia, from past experience (diffing used to eat a huge amount
of CPU).
CPU, and memory IIRC. PHP is very bad at allocating memory efficiently.
An inline diff implementation should:
* be written in C++ (and *possibly* have an *alternative* version in
PHP, as we have with the current diff system)
* probably be integrated with wikidiff2 so the two diffs are generated
simultaneously; this avoids calculating the differences between the same
set of revisions twice
* use the diff cache; this basically means a diff is only rendered once,
then cached
Roan Kattouw (Catrope)