Resolved by virtue of hardcoding it; the general "this only works in english" will be addressed around T345568.

Also, I actually need three of them to trigger the issue:

echo -e '<translate><tvar name="plop"></tvar></tvar></tvar></translate>' | php ./bin/parse.php

Two seems fine, somehow.

Weeeeeeeeeeeeeeeeeeeeeeeell. That's interesting. I was going to say "you actually can't save that wikitext with Translate, because it will yell at you if you try to save that", and turns out, that's wrong. It will yell at you for unbalanced <translate> tags, but NOT for unbalanced <tvar> tags.

T347009 is closed as a deployment side effect issue. The same issue and the associated warnings are probably to be expected during group2 deployment.

Seems like a deployment side effect issue.

Sounds good to me.

Looks like there's was a spike essentially at the moment of group1 deploy on group1 wikis, there was like 840 of these between 18:00 and 18:15, and none out of that interval. It feels highly plausible that it's related to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/942499.

Removing https://phabricator.wikimedia.org/T347007 from blockers since it's on dewiki, it's not train-blocking.

Just added two blockers for time to have another opinion on them before deploying them to group2. I'm probably overly careful, but I'm worried about cache incompatibility on T347009 and about logspam (and possibly rendering issues) on T347007.

This has been deployed for a long while by now, and it doesn't seem to be breaking the world. There are still a few bugs, but they can/will be investigated in separate tickets.

Do translated pages have translation markup in them? (I think not?)

I think I prefer the idea of the extension dealing with annotations by calling a Parsoid extension API method.

Reopening because I don't know how to read logstash, it seems.

Doesn't seem to have triggered in the past 3 months, marking as resolved, please reopen if new occurrences arise.

Not guidelines per se, but https://www.mediawiki.org/wiki/Parsoid/So_you_want_your_extension_to_work_with_Parsoid and https://www.mediawiki.org/wiki/Parsoid/Extension_API#Mapping_existing_parser_hooks are hopefully a reasonable starting point.

Verified on beta - indicators are now processed on indicators. Will close after next deployment of Kartographer.

The URL rang a bell, and I wouldn't be surprised if it were another variation of https://phabricator.wikimedia.org/T260082.

First version of the patch is verified; still need to address some open questions in the patch, so moving back to In Progress column.

Few more instances of that one on Commons on June 14th 2023, e.g reqId: eb493356-b3b6-4b63-814c-e039e7df9764 Find reqId in Logstash

Mmmh. Error on 4 arguments passed, 4 expected - this is fishy.

This comes from

<translate>The parameter <tvar name=\"1\"><code>nowiki</code</tvar>> usually removes the link around the filepath (which can't be seen in this example).</translate>

First estimation: it's not "those many requests to that URL, it's "oops, we have an infinite loop situation going on here". So first, fixing that, and then understanding why it happens in the first place.

In T337275#8875033, @Arlolra wrote:

The issue to be determined is who else besides LintHint is accessing this API and whether they want to see 'large-table' lint records or not.

This hints at removing any logic from that endpoint for filtering lints (as in the patch above) and making the default to not emit them. Then, add a configuration so that they only get emitted when we're linting as part of a full page parse that is going to be recorded by the linter extension.

Neat, thank you! :)

As far as I remember, if the language is "local", we're not exporting anything out of Kartographer anyway - it's just a shorthand to not add any language code when resolving the map. Thanks for pointing that out!

I'm looking into streamlining languages for the Parsoid support of Kartographer. My not-so-hidden goal is to get rid of "target language" for Parsoid, and to be able to pass either "this is page language", "this is user language" or "this is specific language X".

Checked that data-mw="interface" has been replaced by the existence of "data-mw-kartographer" attribute on en.wikivoyage and en.wikipedia.

It was already the case that it used the same graph ID (that's why I had that test case on my local wiki ;) ), and yeah, that'd be my guess as well that this is what causing the issue. Identical graphs are not without their issues, see T312242 and related.
The hash on the data may not be necessary per se, but it feels like a reasonable solution to ensure ID unicity (... up to using the same data, but then the same graph would be rendered, so it "shouldn't be a problem™") and ID stability, I guess.

Indeed, updating back to mw:MediaLink seems to be enough for Parsoid to not have a dirty-diff there. It still displays a "modified-wrapper", but it round-trips without the accent as expected.