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?

@Physikerwelt Do you feel strongly for or against any of the dependent bugs, about rearranging the menu on the math dialog? They've been open for a while without receiving comments and I'm tempted to close them for now unless anyone feels otherwise.

@Ricordisamoa Sorry I didn't notice your gerrit comment - not a dumb question at all.

I don't think the buttons make sense in this case because you can't predict a sensible increment step without knowing the rough size in advance, and even then having a larger step for a bigger size doesn't make much sense, because you could still want a size that is not a multiple of whatever the step happens to be.

It does have a scrollbar (on the right in @Ryasmeen's image (@DLynch do you have the latest version checked out?)) - but yes the input should be visible. Could automatically scroll down to the input, and/or collapse the symbol menu?

I'd be tempted to hold off for now given the limited browser support for MathML, which means we would have to maintain the SVG version anyway.

@Ozob Do you mean to notate div, grad and curl as follows:
\nabla \cdot \mathbf{A}
\nabla \mathbf{A}
and
\nabla \times \mathbf{A} ?