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.

@Whatamidoing-WMF Should the feedback link go here? https://www.mediawiki.org/wiki/Talk:VisualEditor/Diffs

Correction: this isn't specific to historical diffs

In T170235#3448693, @Esanders wrote:

Just to be clear, this behaviour should not be happening and should go away once T170269 is fixed.

That does @Deskana's suggestion but not @matmarex's...

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.

Oops, should've tagged: rGVED81a4760ea38c: VisualDiff: Refactor for historical diffs

In T169325#3477128, @Schnark wrote:
I'm wondering whether it is really necessary that the diff tells you exactly where each of the paragraphs moved.

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.

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...

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?

Sorry, I meant any template that isn't visible when just reading the article.

@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.

Is this good to close now?

Yeah that's the culprit

@Mooeypoo No worries, I'll look into it - thanks for the pointers.

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?

I'm having trouble replicating this - has it been fixed?

Some thoughts:

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...

The above commit addresses step 1 but not step 2 yet.

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!

This was caused by deciding a content branch node with content length 0 was modified to an alien node.

@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

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...

@ArgonSim @Trizek-WMF Thanks for the examples. (The second gallery on the French page works because it has prefixes, but not the first gallery. The above patch fixes the no-prefix case.)

Yes indeed - thanks for pointing that out. It was a problem with any gallery without prefixed filenames (see T151433).

Is the spec at P2506 still what we're aiming for? (At the moment I'm working on T150621 to work with the current patch set.)

This is a nasty one - we should allow the same image multiple times, and don't want to delete the duplicates in existing galleries.

Yes we can do it technically, but only around text changes since <del> and <ins> should only contain text.

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).

+1 to rich text caption editing. See T149602

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.

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.

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.

How about AnnotationStore?

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?

Is it better to do this in OO.ui.mixin.DraggableElement? If so perhaps something more generic than square brackets should be used.

@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?