Updated the https://gerrit.wikimedia.org/r/c/mediawiki/core/+/981354 patch, if that is merged we could turn on validation on enwikibooks and eowiki. Folks who add logstash traces, if you could add the wiki prefix which shows the error that would be helpful.

I can't find the code in Parsoid which actually sets the title element (!). It was originally thought that the title element would be a good way to convey the title metadata, but as @Legoktm points out there's some additional sanitization which happens with the value on its way to title which complicates this. This isn't really an issue for 'modern' parsoid since we communicate the title via ParserOutput/ContentMetadataCollector metadata, not the title element. The actual page title (as opposed to displaytitle) is passed in a <meta> element in the head. Perhaps we should be passing displaytitle that way as well.

The RESTBASE API has been deprecated, please use https://api.wikimedia.org/wiki/Core_REST_API/Reference/Pages/Get_HTML

An example: https://en.wikipedia.org/wiki/Liverpool_F.C.

Latest version of the patch makes it a configuration option, $wgSortedCategories, which is false by default. It adds a query parameter &sortcat=1 which will sort the categories, which will facilitate the Content-Transform-Team's visualdiff testing by ensuring that differences in category order don't obscure other page differences.

It's been almost 30 days already. I don't think we're going to do this, we're just going to wait for the pages to expire.

I think what's going on is that VE is reloading the content area w/o doing a full reload of the page, and VE isn't using the ArticleParserOptions hook appropriately to get the proper 'useParsoid' status.

Also related:

• https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/761494
• T373257: Pick wikitext syntax for wikifunction calls, T373253: Develop semantic / distinct representation for wikifunctions output in Parsoid DOM

We also need to determine "how much processing" is done on the /arguments/ to the wikifunction invocation before this preflight request is done. Obviously we can fire it off fastest if the arguments are just raw strings extracted from wikitext. But if we need to do wikitext expansion on the arguments, that might slow down the preflight.

The MVP default would be "don't cache", which already has support in core (ParserOutput::setCacheTime(-1)).

Current status: this task is not considered a blocker for our current rollouts on wikivoyage, which are relatively small wikis, but we plan to schedule more work on this task before we proceed to rollouts on larger wikis. Child task T365371: ParserMigration: Add "report visual bug" link is the major remaining task here. The indicator is still very useful to our team for debugging purposes, but T372789: Compact Parsoid indicator for ParserMigration for wikivoyage is prototyping a more compact form more suited for our current deployments on wikivoyage, and I've filed T373472: Make ParserMigration indicator optional to hide it entirely for most users.

See also T372789: Compact Parsoid indicator for ParserMigration for wikivoyage where we are prototyping a more compact indicator for wikivoyage.

I think the initial proposal from wikifuntions was {{#function|...}} but I don't know what the arguments are.

I was going to propose that the API was a hook, so the "request and response format" is just the method parameters and return value for hook.

Section links match by the ID from the TOCData, I bet parsoid's TOCData got confused. You should be able to check this by asking for the section info using the parse API.

Patch has been merged and beta is verified fixed.

I can reproduce on my local wiki, when I have the translate extension installed:

$ echo '<translate>[[mw:Extension:Foo|Bar]]</translate>' | php maintenance/run.php parse.php --parsoid
parse.php: warning: reading wikitext from STDIN. Press CTRL+D to parse.

Test page: https://meta.wikimedia.org/wiki/User:Cscott/T373374

Hm. The page_touched property of pages doesn't quite do what we need it to. Consider a page [[Foo]] which contains:

{{1x|{{Bar}}}}

Now, Foo's backlinks contain Template:1x and Template:Bar, and if either of them is edited, [[Foo]]'s page_touched will be bumped as well.

In initial exploration, it was discovered to be quite difficult to plumb through precise reasons for each update (eg, "update to section X of revision Y of page Z" or "update because of an update template A included by template B included by page C").

Maybe related, maybe not: when I log in to a new wiki I'm not always seeing my preferences (including the "rendered with Parsoid") applied. The thing I notice most is user interface language, which often is still in the wiki's content language. I have to manually reload to get a render with English as the interface language (which is a global preference).

A counterargument to "fixing this in code" is that the stylesheet in question applies to a bunch of different hlists, some of which *will* be generated from wikitext.

(Also as a matter of timing, adjusting the site CSS to fix the line breaks can be done immediately as an edit and doesn't require a code change + deploy, etc. Counterargument for that is that we're concerned that this same pattern might exist on other wikis, and we don't want to have to deal with editing the CSS in a dozen places.)

In T372889#10086597, @Izno wrote:

I'm feeling kind of puzzled here. What's the reticence to adjusting the output in ParsoidCite to add \ns in reasonable places? As I noted, normal wikitext lists work as expected before and after, as does (obviously) Cite before. ParsoidCite's output is also pretty fully in your power to adjust, rather than having a bunch of edge cases like wikitext does.

@lzno which side of the <li> do you want the pipe to stick to? Just make the content: ... clause include a &nbsp; on the side where you don't want a break.

Another note for the future: https://meta.wikimedia.org/wiki/Global_message_delivery/Targets#Global_delivery_lists points to the various village pumps.
https://meta.wikimedia.org/wiki/Distribution_list/Global_message_delivery#Wikivoyage especially will probably be useful.

This can be fixed in the CSS like this:

.mw-parser-output .hlist-pipe dd::after, .mw-parser-output .hlist-pipe li::after {
  content: " | ";
  font-weight: normal;
  white-space: break-spaces;
}

See the added white-space rule there, which ensures that the list items can be broken at the separators between them.

This seems to be a CSS styling issue, and not a Parsoid/PCS bug. The root cause is this CSS rule:

.content .infobox > caption, .content .infobox > tbody {
  display: flex;
  flex-flow: column nowrap;
}

The flex layout has special handling for the children of the parent container (in this case the <caption>) but there are no children of the caption. Instead, any <span> or other tags, like <b> or <i>, are treated as the children and given a flex box layout inside of the caption.

The problem doesn't exist on https://en.wikipedia.org/api/rest_v1/page/html/I'm_Glad_My_Mom_Died and the underlying HTML from Parsoid is:

I<span typeof="mw:Entity">'</span>m Glad My Mom Died <span class="Z3988" title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&amp;rft.genre=book&amp;rft.btitle=&amp;rft.author=%5B%5BJennette+McCurdy%5D%5D&amp;rft.date=August+9%2C+2022&amp;rft.pub=%5B%5BSimon+%26+Schuster%5D%5D&amp;rft.pages=320"></span>

So it appears to be related to how PCS is handling the <span typeof="mw:Entity">?

I believe @Arlolra is using "old" Vector, which shows this appearance. I tested with "new" Vector, which does not.

Some more information:

> $services = \MediaWiki\MediaWikiServices::getInstance();
> $l = $services->getLanguageFactory()->getLanguage('eo');
> $mwf = new \MediaWiki\Parser\MagicWordFactory($l, $services->getHookContainer());
> $x = $mwf->newArray(['img_left','img_width']);
> $x->getBaseRegex();
= [
    "(?i:(?!))",
    "(?P<a_img_left>maldekstra)|(?P<b_img_left>maldekstre)|(?P<c_img_left>left)|(?P<a_img_width>\$1ra)|(?P<b_img_width>\$1px)",
  ]
> $x->matchVariableStartToEnd('maldekstra');
= [
    "img_left",
    false,
  ]
> $x = $mwf->newArray(['img_width','img_left']);
> $x->getBaseRegex();
= [
    "(?i:(?!))",
    "(?P<a_img_width>\$1ra)|(?P<b_img_width>\$1px)|(?P<a_img_left>maldekstra)|(?P<b_img_left>maldekstre)|(?P<c_img_left>left)",
  ]
> $x->matchVariableStartToEnd('maldekstra');
= [
    "img_width",
    "maldekst",
  ]

Note that the precedence of options is pretty much arbitrary, it just *happens* that img_width is added after other options. Parsoid is a bit more principled here, always preferring literal parameters to parameterized (prefix) parameters.

These should be a tracking category or a linter entry, not a log.