In T191925#4123308, @santhosh wrote:

One option would be to get these tools and runners into the upstream foma repo

@ssastry, The att->json conversion and processing in js might not be a general solution for js binding/integration because in practice, the morphology analysers(foma's main usecase) are very big. The compiled trasducers in binary formats grows to many magabytes. For example, http://wiki.apertium.org/wiki/Foma lists some real world transducers and their compilation time, RAM requirements and final sizes while explaining the usage. Some of them easily goes beyond 50MB. The reason for large sized transducers are the inclusion of lexicon subsets. Something to consider when we think aout upstreaming or making it a general solution.

I am going to boldy close this. The follow up tasks can happen as part of our regular followup and are not necessarily wikivoyage related.

This is a really old task and we've rolled out Parsoid to almost everywhere. Nothing to do here.

Graphs is on longer deployed and has been replaced by Charts.

This function has been marked internal. Closing.

This looks fixed.

That matches my intuition since we know this happens with ref tags (unused params with ref tags don't show up in references for Parsoid, but do in legacy) and I looked at the Infobox officeholder source briefly but didn't investigate. So, if we can confirm this (which I presume is a claude-generated analysis), I would say this is a non-issue and can be declined.

Here is a more complex case from the wiki. The first two lines aren't processed correctly by the 'cell-splitting' logic in TableFixups, but the last line is. Didn't investigate except cursorily to determine this.

{|
{{tr}} x || 96,40 || 0,78
{{tr}} y || 93,67 || 0,35
{{tr}} z || 93,67 || 0,35
|}

For https://en.wikipedia.org/wiki/Wab_Kinew, "View Source" for useparsoid=0 and useparsoid=1 shows that ext.pygments is included in the resource module list for the useparsoid=0 (legacy) case, but not in the Parsoid case. However, it is unclear why that is included because there are no code blocks on that page (looking at the wikitext and inspecting the HTML), and running visualdiff on that page locally shows no diffs either. So, that module doesn't seem to be used really on that page based on this inspection.

@DLynch and @Esanders FYI .. in case you get any complaints about dirty diffs from last week's train. We've since reverted that problematic patch and backported it as part of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1345604

My other thought was that DOMDiff should not be sensitive to order of parameters in data-mw.parts.params, but Scott correctly pointed out that we want to support edits where it is possible to reorder parameters in a transclusion. Given that requirement, we want to consider change in order a diff.

Actually, let me resolve it right away. :)

All good on my end. Feel free to resolve if you are happy with the scroll. Thanks!

Taking two random pages from ffwiki ( https://ff.wikipedia.org/wiki/Farayse_Choy and https://ff.wikipedia.org/wiki/Andara ), the page source has the CSS embedded in nowiki ... and if you look at the article histories (example), the page was created by an editor using Content Translation when the CSS was introduced as text.

In T438154#12328178, @Jgiannelos wrote:

I am very not familiar with FlaggedRevs but it looks like this might be problematic:

• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1330099/14/includes/frontend/FlaggablePageView.php
• This returns a status object and not the parser output which eventually is used as an argument for addPostProcessedParserOutput

This edit and this edit show that Parsoid no longer dirties this.