RT-testing of a78e700 is clear (logs & regression-testing script).

@cscott probably, we would probably want to refresh Subbu's patch above https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/837147

Marking as invalid as baseconfig is not related to production Parsoid usage.

Strong hypothesis: this happens when CommonsMetadata is involved in the rendering of the page.
Specifically, the DataCollector::verifyAttributionMetadata runs getText, which on VE content is considered Parsoid content, which converts back and forth between content and PageBundle, which loses the version number during that operation.

Looking at logs: T365678 has been filed already

Also reproducible by opening https://en.m.wikipedia.org/wiki/Leicester#Geography and reducing the window size on Firefox Linux desktop, whereas the desktop page works correctly (and just adds a horizontal scroll bar).

Well, it turns out it didn't get fixed in the train.
Still visible on commons and officewiki; however, testwiki does not seem to be impacted.
I looked into logs and couldn't find anything relevant.
I'm puzzled.

Most probably another version of https://phabricator.wikimedia.org/T365036, which should be fixed in the next train.

Patch 6fe99186fb7847dd271503e23fdd03ca32f1af0f is not deployable; on hold for decisions.

No Parsoid deployment that week, closing as resolved.

This is indeed fixed, thanks @Aklapper :)

There are still issues, in particular the last one that's been linked to this task a month ago, but I'm closing the main one.

Should be fixed by https://gerrit.wikimedia.org/r/c/integration/config/+/1030054 (waiting for a few builds to go through to check)

Observation: changing the order of the Localization and ExecutePostCacheTransformHooks passes (putting "localization" after the hooks) does solve the issue. So as a "temporary fix", this might be an option.

Affected pages were modified. Closing the issue.

Some investigation about the expected number of affected pages, on wikis that have an equivalent to this specific template:

I'm not actively working on this just yet (until we decide to have a translate-enabled wiki in our deploy targets), but this feels like a good time to re-open this discussion.

I'm reasonably sure this one will be fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Kartographer/+/1020289 (which is not deployed yet on enwiki)

Incidentally, I finally reproduced it on my local wiki, while still avoiding Wikibase shenanigans, by modifying my local Template:Mapshape to provide a default QID for the map, which enabled me to pass the template without arguments.

Well this was a fun rabbit hole to fall into. Parsoid indeed does the right thing here, and the legacy output is incomplete. But the issue is not in Kartographer per se, it's in the interplay between templates and Kartographer.

I tend to agree on "the legacy code is the one behaving weirdly", mostly because it seems to only trigger in very, very specific instances. I'll poke again a bit because I would really like to understand why :D

I also can't say that I'm super convinced that the legacy parser is doing the right thing on these pages.

This is very annoying to reproduce, because it seems that it depends on ExternalData rendering in an annoying way. In particular, copy-pasting the page into a sandbox (like https://en.wikivoyage.org/wiki/User:IHurbainPalatin_(WMF)/sandbox?useparsoid=1) does reproduce the double-shading... but it also does so in the legacy parser. And, the only difference between that sandbox and the page is that I passed the wikidata QID explicitly in the mapshape template :/