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)