Last modified: 2012-01-30 15:35:48 UTC
When you break a paragraph, the entire text is marked as deletd and added, creating an annoying needless big chunk of red text,while only the added line breaks should really be indicated.
I'm adding to this bug, since it seems to be part of a larger problem: the article history diffs fails to track paragraph moves as well as splits. Since diffs are intended to help editors track changes, this failure represents a minor loss of function so I'm upgrading the severity from trivial to minor.
Further clarification: The essence of the problem is history/diffs loses track of moved paragraphs, and hence does not compare within the moved paragraph to identify changes that may have been made in the same edit as the move. When a new paragraph is inserted, history/diffs often compares the inserted paragraph with an old following paragraph, rather than comparing the old paragraph with the (often unchanged) version that is now in a new location. What we seem to need is a robust difference detector that can track moves of paragraphs or even lines, and then identify smaller changes in those moved segments. They must be around, they've been in word processors for years, and in Wiki's editing intensive environment they're long overdue. Thanks, Steve
It looks like there's a solution to this problem by installing User:Cacycle/wikEdDiff. It tracks changes through paragraph breaks and (apparently) catches moved sections of text as well. I wouldn't quite call this bug "fixed" until this is made a standard part of the Wikipedia difference display, but having it available is a big step in the right direction. Steve
wikiEdDiff is available as a gadget now. [[User:Cacycle/wikEd_help#wikEd_control_buttons]] Think this is closed.
(In reply to comment #3) > I wouldn't quite call > this bug "fixed" until this is made a standard part of the Wikipedia difference > display, but having it available is a big step in the right direction. I agree on this.
(In reply to comment #5) > (In reply to comment #3) > > I wouldn't quite call > > this bug "fixed" until this is made a standard part of the Wikipedia difference > > display, but having it available is a big step in the right direction. > > I agree on this. Should we make it possible to replace the built-in server-side wikidiff tool with this client side one? Or maybe encourage the developer to have his JS output replace server-side generated output? The wikiEdDiff author seems interested in getting a PHP-based solution to replace this JS-based one, but I'm not sure if that would be better (as far as server impact, which is what Wikimedia ops would be concerned with) than the C++-based one.
Reopening per comment #3 and comment #5 (and I also agree). And replying to comment #6: From the user perspective, I think either option would be an improvement to the current situation. Should the ops decide that a server-side implementation is unfeasible (without performance degradation), then the client-side gadget is a reasonable (but not as good) replacement. In any case, the client-side gadget would need to be bundled with MediaWiki, so that this bug can IMO be considered fixed.
There's already some code which could be used: see for instance this tool (screenshot at p. 8): http://www.fst.umac.mo/en/staff/documents/robertb/WikiSym2010-PeterRobert-Final.pdf Code is published in http://sourceforge.net/projects/weha/ , I was told in August 2010 that they were going to release it as an extension once ready but perhaps someone could already work on it.
