Created attachment 633922 [details] 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!
Priority: -- → P1
Whiteboard: u=contributor c=wiki
Target Milestone: --- → Future
Whiteboard: u=contributor c=wiki → u=contributor c=wiki p=
Making this a 2pter to research diff tools, choose one and put it in.
Whiteboard: u=contributor c=wiki p= → u=contributor c=wiki p=2
Priority: P1 → P2
Target Milestone: Future → 2012Q4
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.
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!
Adding s= sprint information to whiteboard.
Whiteboard: u=contributor c=wiki p=2 → u=contributor c=wiki p=2 s=2012.19
I have the basic diff working, but it needs a lot of love to look better and be more useful. Dropping to next sprint.
Whiteboard: u=contributor c=wiki p=2 s=2012.19 → u=contributor c=wiki p=2 s=2012.20
Created attachment 674959 [details] 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.
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.
Deployed just now.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.