Last modified: 2012-01-30 15:35:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5072 - Paragraph splits and moves not identified in diffs
Paragraph splits and moves not identified in diffs
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
unspecified
All All
: Low enhancement with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 29385
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-24 02:05 UTC by Jean-Sébastien Girard
Modified: 2012-01-30 15:35 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jean-Sébastien Girard 2006-02-24 02:05:08 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.
Comment 1 SteveMcCluskey 2006-08-23 14:21:34 UTC
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.
Comment 2 SteveMcCluskey 2006-09-12 20:27:11 UTC
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
Comment 3 SteveMcCluskey 2008-03-30 01:57:57 UTC
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
Comment 4 Mark A. Hershberger 2011-05-27 21:37:19 UTC
wikiEdDiff is available as a gadget now. [[User:Cacycle/wikEd_help#wikEd_control_buttons]]

Think this is closed.
Comment 5 Helder 2011-05-27 21:57:08 UTC
(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.
Comment 6 Mark A. Hershberger 2011-05-28 02:23:15 UTC
(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.
Comment 7 Waldir 2011-12-02 19:01:21 UTC
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.
Comment 8 Nemo 2012-01-22 20:01:12 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links