The bug was first mentioned at https://en.wikipedia.org/wiki//Wikipedia:Village_pump_(technical)#Image_caption_showing_up_as_link?
Tests indicate it happens when the file name has quotation marks. In the example, VisualEditor changed

[[File:NYC Bus with "masks required" sign.jpg|thumb|New York City transit bus. 177th Street near Devoe Ave, Bronx, NY. Route sight reads, "Masks Required"]]

to

[[File:NYC Bus with "masks required" sign.jpg|thumb|New York City transit bus. 177th Street near Devoe Ave, Bronx, NY. Route sign reads, "Masks Required"|link=File:NYC_Bus_with_%22masks_required%22_sign.jpg|alt=]]

The user only changed "sight" to "sign" in the caption.

(This is similar to T193253, which we tried fixing previously, but that patch caused other dirty diffs.)

It should add |alt= parameters, and everyone should (almost) always fill in the blank.

@Jonesey95, how often is the |link= problem turning up?

I don't know how often the link= problem is turning up. The devs could probably do some sort of database search to look for VE edits that added link=, which people should almost never be adding.

As for the blank alt= option (it is confusing to refer to it as a parameter, since the image options do not work like template parameters), VE should not add it if the human editor did not ask for it to be added. I don't use VE, so I don't know if the editor is presented with some way to provide a value for the alt= option while modifying the image caption.

The same problem occurs in ruWP. https://ru.wikipedia.org/w/index.php?title=Надписи_из_деревьев&diff=next&oldid=108444834 Our bot periodically cleans it up.
See the fourth picture - https://ru.wikipedia.org/w/index.php?title=Надписи_из_деревьев&oldid=108499780 The link parameter text is added with percent-encoding, which is why the link is visible in the article instead of the file description!

I also saw similar problems when reviewing the corrupted diffs caused by T259855, where VisualEditor wasn't involved. That made it look like there's an underlying issue in Parsoid, and I found the task about it: T108504.

Let's wait for that to be fixed, and see if it also fixes the bug in VisualEditor.

Looks like Parsoid has put in a fix so hopefully there is nothing more for us to do here.

In T257581#6354082, @Sunpriat2 wrote:

The same problem occurs in ruWP. https://ru.wikipedia.org/w/index.php?title=Надписи_из_деревьев&diff=next&oldid=108444834 Our bot periodically cleans it up.

May I ask which bot and how often it runs? Checking its contributions would be a good way to confirm whether this issue has been fixed by the Parsoid changes.

FWIW, I just copied the File wikitext from the original bug report to my sandbox on en.WP, then edited it with VE, changed one word in the caption, and saved it. I did not get a link= or alt= parameter, which means I am no longer able to reproduce the bug. Here's the diff:

https://en.wikipedia.org/w/index.php?title=User%3AJonesey95%2Fsandbox&type=revision&diff=979666625&oldid=979666566

In T257581#6481957, @matmarex wrote:

In T257581#6354082, @Sunpriat2 wrote:

The same problem occurs in ruWP. https://ru.wikipedia.org/w/index.php?title=Надписи_из_деревьев&diff=next&oldid=108444834 Our bot periodically cleans it up.

May I ask which bot and how often it runs? Checking its contributions would be a good way to confirm whether this issue has been fixed by the Parsoid changes.

@matmarex
I don't know about ruWP, but my bot (WikiCleanerBot) fixes this both in frWP and enWP. The same summary is used for all "internal links written as external links", so it's not only restricted to the link= problem in images

• On frWP, look for edits with "Lien interne écrit comme un lien externe" in the edit summary, like here or here.
• On enWP, look for edits with "Internal link written as an external link" in the edit summary, like here.

I mostly run those fixes as part of my dump analysis process, so it's usually twice a month (a few days after the 1st and the 20th).

You can also look at problems found in my dump analysis, both on enWP and frWP (but they contain only problems not reported by CheckWiki or that my bot wasn't able to fix).

Thanks @NicoV!

I wrote two queries to check your bot's edits on enwiki and frwiki, and it has actually made remarkably fewer edits with these summaries in September than before. The fix was only deployed on September 14 so I'm not sure if that's really related or just a random occurence (also, I'm assuming you already did the second run this month?). I guess we'll see next month whether the numbers go down further.

Thanks @matmarex

I already ran my bot twice this month, but one thing that can also partly explain the difference is that in August, I ran it very late (like 30th of August instead of 22nd or 23rd), so it fixed some that would usually be fixed in the beginning of the next month.

In T257581#6494846, @matmarex wrote:

Thanks @NicoV!

I wrote two queries to check your bot's edits on enwiki and frwiki...

Nice, Bartosz.

In T257581#6495821, @NicoV wrote:

Thanks @matmarex

I already ran my bot twice this month, but one thing that can also partly explain the difference is that in August, I ran it very late (like 30th of August instead of 22nd or 23rd), so it fixed some that would usually be fixed in the beginning of the next month.

@NicoV: considering what you shared in the quoted comment above, I was thinking we'll leave this task open and re-run the queries @matmarex wrote after 31-Oct to confirm the issue is indeed fixed. How does that sound to you?

@ppelberg Seems ok to me

@ppelberg and @matmarex
Is the Parsoid fix supposed to handle also this kind of edits? Because it was done on Septembre 30th, 2 weeks after Parsoid fix has been deployed, and there are still many "link=" added by VE (but to new images). My bot fixed it for the pass on the October 1st dump.

Related: T264533

If needed, a few more recent edits:
https://en.wikipedia.org/w/index.php?title=Miss_Universe_Cambodia_2019&diff=983133739&oldid=982344028
https://en.wikipedia.org/w/index.php?title=Miss_Cambodia&diff=983135015&oldid=983132050
https://en.wikipedia.org/w/index.php?title=Ministry_of_Mining_and_Energy_(Serbia)&diff=982383906&oldid=953995112
https://en.wikipedia.org/w/index.php?title=Ministry_of_Health_(Serbia)&diff=982383040&oldid=964534644
https://en.wikipedia.org/w/index.php?title=Ministry_of_Education,_Science_and_Technological_Development_(Serbia)&diff=982381908&oldid=953989723
https://en.wikipedia.org/w/index.php?title=Ministry_of_Agriculture,_Forestry_and_Water_Economy_(Serbia)&diff=982380534&oldid=961787908
https://en.wikipedia.org/w/index.php?title=Minister_without_portfolio_(Serbia)&diff=982652098&oldid=949141558
...

@NicoV Thanks, that is helpful.

I think all of the recent issues you point out are actually caused by T193253 – that is, the erroneous markup is added when copy-pasting the image from another page, rather than when editing the caption of an image (like in this bug). I looked at them more closely:

In T257581#6559865, @NicoV wrote:

https://en.wikipedia.org/w/index.php?title=Miss_Universe_Cambodia_2019&diff=983133739&oldid=982344028
https://en.wikipedia.org/w/index.php?title=Miss_Cambodia&diff=983135015&oldid=983132050

Edits by the same user in related articles, the affected images appear multiple times, so they were likely copy-pasted.

https://en.wikipedia.org/w/index.php?title=Ministry_of_Mining_and_Energy_(Serbia)&diff=982383906&oldid=953995112
https://en.wikipedia.org/w/index.php?title=Ministry_of_Health_(Serbia)&diff=982383040&oldid=964534644
https://en.wikipedia.org/w/index.php?title=Ministry_of_Education,_Science_and_Technological_Development_(Serbia)&diff=982381908&oldid=953989723
https://en.wikipedia.org/w/index.php?title=Ministry_of_Agriculture,_Forestry_and_Water_Economy_(Serbia)&diff=982380534&oldid=961787908
https://en.wikipedia.org/w/index.php?title=Minister_without_portfolio_(Serbia)&diff=982652098&oldid=949141558

Edits by the same user in related articles, the affected image appear multiple times here as well, so it was likely copy-pasted.

In T257581#6515190, @NicoV wrote:

Is the Parsoid fix supposed to handle also this kind of edits?

At first I thought this might be a different problem, since it did not obviously look like a copy-paste – but I checked the user's other contributions, and in their next edit, they deleted an identical table from their sandbox, so the first edit was likely a copy-paste of the content from there.

I re-ran the queries from T257581#6494846:

So, that no longer looks like a drop…

(note that some of the numbers for previous months dropped – this is not a mistake, and it must be a result of articles with these edits being deleted)

I'm still fairly confident that we fixed this particular issue (per my own testing and T257581#6482369), but it seems that other problems like T193253 are responsible for more of broken wikitext than I was hoping.

I think we should close this task, and I'm going to continue working on T193253.