Yup, we have the info we need to fix caller sites and the patch above turns it off.

There is also https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-deploy-1-7.0.0-1-2024.09.04?id=3VIgvpEBa-PL6vFem9kr for "translate-has-languages-tag" which has a very low frequency, but probably also a boolean from the translate extension.

Comes from https://codesearch.wmcloud.org/deployed/?q=is-translation&files=&excludeFiles=&repos= and as expected, it is a boolean value.

Yes, these are warnings @Jdforrester-WMF logged yday (as part of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1070326 ) to help us better fix the underlying issue -- the code works around it for now, but just is a noisy log. My recommendation is to filter out this warning and proceed. FYI. @cscott

We understand the need to replicate legacy parser behavior and that it should work in all namespaces. Parsoid's design is different because it has many other requirements besides rendering a page: support HTML editing without dirty diffs, supporting richer markup for tools, and more recently, we have been exploring T363421: Prototype selective HTML updates in Parsoid which can lead to pages being updated upto 5x faster when a dependent template is edited. So, given the overall requirements, we have made design decisions in the past to enable us to meet those goals. I say all that as a preamble to indicate that there are tradeoffs and if a particular wikitext use case is not used often, it is not unreasonable to look for alternatives.

How common is this pattern where wikitext strings are stictched together across <noinclude> / <includeonly> blocks? Parsoid currently doesn't support it (by design) - it treats contents of <noinclude> / <includeonly> blocks are self-contained. We can revisit that design decision if really necessary -- but before we take that on, we would like to understand if this pattern is specific to a few pages on a this wiki and if there are alternative wikitext formulations that can work instead.

Some questions: I suppose that is enforced by editors writing categories in the desired order at the end of the article? But, if a template in the middle of the article (or an infobox) adds a category, I imagine it shows up wherever it showed up in text, right? So, to Scott's question, it is not quite a set, but it an ordered list with the output being generate in textual order?

Ya, I don't think this is a generic hlist issue -- Parsoid's HTML for wikitext lists already include the newline (the newline found in source wikitext) -- so I am not sure the hlist issue affects anything else. If it were, we would have heard this long back because hlist is used on lots of wikis.

https://en.wikipedia.org/wiki/Special:LintErrors/fostered-transparent now exists.

In T372574#10067385, @ABreault-WMF wrote:

@ssastry Maybe you can follow up restoring the cluster graphs from T371126#10067372

The extra noise has disappeared. The actual table reparse issues will be handled separately.

Looks like this is very specific to Cite references output (from the navbox) and the CSS expects a newline between the "</li><li>".

Looks fixed to me! \o/

Ooops merged the wrong way.

You are right indeed - that looks fixed with this morning's production rollout to group1 wikis!

I guess this will get fixed tomorrow when the train rolls out!

See the very first section ( Latest comment: 10 months ago1 comment1 person in discussion ) ... you can also see the diff in the TOC on the left (which is how I first noticed it).

Indeed. This is almost certainly a wontfix. For Parsoid, they should probably disable the nowrap CSS rule.

This is probably fixed - someone should verify and close it.

I am going to reopen this because of the discussion on the dupe task -- the patch that caused us to decline it does a slightly different thing (it looks at start of template) than what is needed (look at end of template). It is possible we arrive at the same result and decline it, but worth investigating a bit by starting off of Arlo's patch.

But, looks like I didn't look carefully when I looked at the gerrit patch. The phab task is indeed a duplicate, but the patch fixes the start-meta interruption (according to the commit message) vs the end-meta interruption that the phab task documents.

Not sure ... This test case is the other edge cases corresponding to the end-meta which you document in that commit message: "Similarly, this should be true for template end metas but there a newline might escape out of the template causing a dirty diff"