Further testing shows that the key words are "page " (including the trailing space) and "comment" (not commentary). I think that any image caption that matches the following regex will exhibit this bug:

/.*page .*comment.*/

https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=570113406#Third_section

Yet more testing confirms that this is confined to image captions.

If you edit or enter an image caption in VE with the words "page comment" in you can see the caption in that edit.

Saving and reentering VE exhibits odd behaviour - the caption of the image entered in VE is not visible as I predicted. However the edited caption of an image that was already present remains visible. This is confirmed on a subsequent round trip in and out of VE, but I can't test on other systems / browsers than Firefox 23/Linux

See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=570134743#Section_with_a_picture_of_Gloucester

The image of Gloucester Docks at the head of the section was the one with the edited caption. The image at the end of the preceding section (the prospect of Derby) was added in VE.

Cryptic C62 at en.wp reports that it's just "page " or "page=" that is required:
"Further further testing shows that the error is caused by "page " (including the space) followed by some text, or "page=" followed by any text or nothing."

The PHP parser recognizes the page option (see https://www.mediawiki.org/wiki/Help:Images#Syntax) only for PDF files that actually exist:

https://www.mediawiki.org/wiki/User:GWicke/TestPageOption

It does however accept the option 'page=2013 commentary'.

So to me it seems that we need to

1. only match 'page=' at the start of the potential option
2. only do so for PDF files that exist
3. but continue to accept mixed numerical / text page values.

Testing reveals that terminating an image caption with 'alt=', 'thumb=', or 'thumbnail=' also trips up the parser. That seems to be related to the img_attribute production in the peg grammar. Don't know why 'page ' triggers the bug yet, still looking...

Ah, the img_page option contains two aliases, "page=$1" and "page $1". I wonder why we are parsing options twice (one in PEG, once in the magic words localization code)...

Change 94446 had a related patch set uploaded by Cscott:
Fix parsing of image captions containing embedded image options.

https://gerrit.wikimedia.org/r/94446

Change 94446 merged by jenkins-bot:
Fix parsing of image captions containing embedded image options.

https://gerrit.wikimedia.org/r/94446

• Bug 54642 has been marked as a duplicate of this bug. ***