765614 - Diffs show more changed content than needed

Status: RESOLVED FIXED

(support.mozilla.org :: Knowledge Base Software, task, P2)

Description

[Thomas Schwecherl]

Attachment: English diff of "Troubleshoot Firefox issues using Safe Mode" during localization to German

Many diffs show too much red/green content so that the localizer thinks there are tons of changes - but in reality the changes are small or easy to add. -> mental hurdle to make a change because the localizer thinks "oh no, so many changes ... not much time now, will do it later ...".

Added picture shows the problem.
The red/green content could be half of what is shown.

1) The changed words "not permanent" > "temporary" should be red/green and the other text should not be highlighted.

2) The new text added to the two paragraphs at the bottom of the picture should be highlighted with green, but the old text which has not changed should have no color.

Benefit:
It would make the diff better readable and more efficient for localizers!

Comment 1

[Ricky Rosario [:rrosario, :r1cky]]

Making this a 2pter to research diff tools, choose one and put it in.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

The problem here is that we're showing differences at a line scoping, but those articles have really really really long lines with minor differences between them.

As I recall, Mediawiki syntax is such that it prefers really really really long non-word-wrapped lines. For example, list items can't span lines. If the Kitsune wiki syntax is the same, then that's a pain in the ass.

We should check to see if difflib supports highlighting the different characters inside a line. So the line would show up just like now in red and green, but the characters inside the line that are different would be a lighter red/green making it easier to distinguish.

If it doesn't, then I think we're going to have to switch diffing libraries or (ick) write our own. I've done some diff work in the past. It's not hard in the sense that it's a problem domain that has a series of good algorithms with decent time/shortness tradeoffs, but it'll take a while to do.

Comment 3

[Ricky Rosario [:rrosario, :r1cky]]

I am secretly hoping to be able to use gogle-diff-match-patch lib clientside:
http://code.google.com/p/google-diff-match-patch/

I think it will be much better, try out the demo here:
http://neil.fraser.name/software/diff_match_patch/svn/trunk/demos/demo_diff.html

And it will save us cpu cycles on the server side!

Comment 4

[Will Kahn-Greene [:willkg] ET needinfo? me]

Adding s= sprint information to whiteboard.

Comment 5

[Ricky Rosario [:rrosario, :r1cky]]

I have the basic diff working, but it needs a lot of love to look better and be more useful. Dropping to next sprint.

Comment 6

[Ricky Rosario [:rrosario, :r1cky]]

Attachment: Compare old diff to new (WIP) diff

Here's a screenshot of the progress I've made to improve the diffs and better highlight the actual changes. On the top is the current diff and on the bottom is the new/future diff.

Comment 7

[Ricky Rosario [:rrosario, :r1cky]]

This is in a pull request: https://github.com/mozilla/kitsune/pull/925

As a side note, this should have been at _least_ a 3pter. There was a ton of evolving to get to where I ended up.

Comment 8

[Ricky Rosario [:rrosario, :r1cky]]

Landed on master:
https://github.com/mozilla/kitsune/commit/c7ce9e223e767db9def5740ad486b9674c72f792

Comment 9

[Ricky Rosario [:rrosario, :r1cky]]

Deployed just now.