Tue, Sep 5
Ah it's because the reference name="bd-pratidin.com" is defined more than once in the page - so editing anything but the first one won't make a difference.
I don't think it's because there aren't visible changes on the page - the model of the page has still changed as far as the visual diff is concerned. I'm having trouble reproducing this behaviour locally, so I suspect it is not a visual diff problem.
I think I'd still be concerned about crowding the diff if the origin is highlighted, even if only a small excerpt is shown (see @Pginer-WMF's example C above)... But maybe we'd have to balance how common/bad this would be compared to how much there is to gain from knowing exactly where the origin was.
Tue, Aug 29
@Whatamidoing-WMF Should the feedback link go here? https://www.mediawiki.org/wiki/Talk:VisualEditor/Diffs
Aug 15 2017
Correction: this isn't specific to historical diffs
Aug 11 2017
Has this been resolved now?
Interesting. This is another one of those cases (like historical reference diffs) where we rely on the assumption that the diff is between a document and some changes to it that have just been made in visual editor.
Aug 10 2017
Oops, should've tagged: rGVED81a4760ea38c: VisualDiff: Refactor for historical diffs
Jul 31 2017
I'm wondering the same thing. I agree that it's nice to know exactly what happened for a simple move, but that for anything more complicated it's probably more useful just to be aware that some moves have happened.
Jul 24 2017
I'm not sure the moved content should be shown twice in its entirety - it could make the diff quite complicated in cases where multiple paragraphs or whole sections are moved, or where multiple moves are made...
Jul 18 2017
This was fixed by https://gerrit.wikimedia.org/r/#/c/355716/ - the preview now matches the editor.
I just tried reproducing both of these examples, but looks like it's fixed now?
Jul 15 2017
Sorry, I meant any template that isn't visible when just reading the article.
Jul 11 2017
Jul 10 2017
@Esanders Do you have any ideas about "columns setting changed"?
This is a bit more complicated than it looks - we don't have a way yet of describing changes for a newly inserted/deleted node - only changes to an existing node. We should think about other cases that this would apply to (e.g. invisible templates) and come up with a general solution.
Jun 26 2017
Is this good to close now?
May 17 2017
Yeah that's the culprit
@Mooeypoo No worries, I'll look into it - thanks for the pointers.
May 16 2017
May 9 2017
I'm having trouble replicating this, even when I search for "Sandbox". It could be that it's an odd case and the results have changed since... Is it still happening?
Mar 29 2017
Mar 22 2017
Mar 17 2017
Mar 14 2017
I'm having trouble replicating this - has it been fixed?
Feb 23 2017
Feb 21 2017
Feb 19 2017
The first example is fixed by correcting a few indices, but the second poses a more philosophical question about minimal-tree-diffing 2D matrices, so requires a bit more thinking...
Jan 25 2017
The above commit addresses step 1 but not step 2 yet.
Jan 24 2017
We also need to display node type changes. The boundary between the two is not always obvious in VE (e.g. <p> to <h1> is a type change, but <h1> to <h2> is an attribute change), so we should treat these as the same problem.
Yes, I'd like this to be user-oriented too!
Jan 14 2017
Jan 11 2017
Jan 10 2017
This was caused by deciding a content branch node with content length 0 was modified to an alien node.
Dec 12 2016
@ssastry The version that relies on HTML-based serialization hasn't been deployed yet, but there have been some recent changes around the prefixes.
Yes - very happy to do that
Dec 3 2016
I think this is because the space in the gallery dialog is narrower. After playing around a bit, setting a smaller row height seems to increase the probability of the images fitting better...
It would be less confusing if the gallery dialog disabled height, width, etc in the modes that they don't apply to.
There is a slightly complicated reason for this...
Dec 2 2016
Nov 30 2016
Yes indeed - thanks for pointing that out. It was a problem with any gallery without prefixed filenames (see T151433).
Nov 19 2016
Nov 17 2016
This is a nasty one - we should allow the same image multiple times, and don't want to delete the duplicates in existing galleries.
Nov 15 2016
Nov 13 2016
Nov 3 2016
Yes we can do it technically, but only around text changes since <del> and <ins> should only contain text.
Nov 2 2016
I'd like to consult design about this - I agree the red-green isn't ideal. The wikitext diff tool works with yellow and blue, although in a unified diff (as opposed to side-by-side) it might be difficult to tell what has been inserted/deleted, unless there are additional visual clues. <del> and <ins> tags could work on text diffs, but since they're inline we'd have to think of something else for block level diffs (e.g. removed paragraph, added list item).
Oct 31 2016
+1 to rich text caption editing. See T149602
Oct 14 2016
Oct 12 2016
How about making a description page, with a "use this image" button, similar to the one in the media dialog?
I'm not sure I agree with doing this, since media and galleries have such different functionalities. E.g. a media item is only chosen once, whereas galleries can be extended, pruned, rearranged, etc. The media display options are quite different from the gallery display options too, and a media item might not even be an image. I think a single dialog that incorporated all of this would lead to a confusing user experience, with too many alternative workflows and options being disabled according to whether whether media or gallery behaviour was required.
Making the dialog larger on search seems a sensible way forward. I guess it's helpful for the current images in the gallery to remain visible, to help avoid duplication.
Oct 5 2016
Agreed - T39931 is more about highlighting changed areas as you're editing, if I'm reading it correctly. This current task is more about offering a visual diff as an alternative to the wikitext diff you can currently request just before saving.
Sep 28 2016
Ok, that's what the patch in review does.
Although I've put a patch up for review, I'm not sure I completely agree with doing this. It might look a bit slicker to have some images already loaded, but I would guess that it would only be useful in a very small percentage of cases.
Sep 20 2016
How about AnnotationStore?
Aug 19 2016
Aug 18 2016
Aug 9 2016
There shouldn't be a limit, no. Have been trying to replicate this on production, but no success so far...
I'm having trouble replicating this on vagrant and on test2 (both Firefox). Anyone got any ideas?
Aug 4 2016
Is it better to do this in OO.ui.mixin.DraggableElement? If so perhaps something more generic than square brackets should be used.
Jul 6 2016
@matmarex Good point - I think the multiline input is useful for seeing the whole caption at once if it's long, but we could prevent entering line breaks?