Researched the use of linter_params for the tag and template data, versus getting those fields directly from the new linter_template and linter_tag columns.
LinterErrorsPager fillQueryBuilder requests the original set of columns but does not use the configuration value "LinterUserInterfaceTagAndTemplateStage" to choose the new columns for template and tag values for each row.

I had Amal check to see if at the location the wikifeed was working as expected and it is. But from within the app, the feed is not displaying still for Amal, so maybe this bug is due to date/time or some other app issue.

Chromium render (Proton) upgraded from Node 12 to Node 18

I suspect this problem comes from ios app code
WMFFeedContentsource.m which uses wmf_midnightUTCDateFromLocalDate function and might better use wmf_midnightUTCDateFromUTCDate instead?

It looks like the most read date calculation will return either yesterday or two days ago if the API call uses the 'aggregated' parameter but if not it is possible that wikifeeds will select the current day or yesterday depending on what the server UTC is and when the request is made. If the 'aggregated' parameter is used, it should never select today. If we want to fix the non aggregated call, we could either make the code smarter about server UTC setting offsets, or just use the same -1 day hack and sometimes get the most read from two days ago instead of one, but never try to request most read from today.
I think this can be fixed to always only produce yesterdays most read from any server UTC time setting and request time with a bit more code.,

Fixed on this day, births, deaths and holidays requests in 983935

Jonesey95, thanks for pointing out that the action=info page parameter name for namespace was not updated to the new parameter name. I missed that :-(
It should be fixed in the next train deployment.

Jonesey95,
I am glad this new feature is being used and working properly. And thanks for looking into getting dependent tools and gadgets adapted to the new parameter format.

Jonesey95 and colleagues,
I am sorry this change has altered the URL parameter definitions for namespaces. I had no choice as the multiple namespace widget used in the Linter search forms I needed to use has its own URL parameter style.
The format is now: for Main (Article), Talk and User Talk, for example uses the parameter keyword

The multiple namespace selection feature is on the train and will be live on various wikis this week. I hope it better serves the needs of searching for lint errors and does not introduce any bugs. This is the last significant feature patch I will be working on for the Linter extension for a while beyond maintenance work and bug fixes as I transition to working on PCS and related caching subsystems.

Ah I did not know that, Isabelle requested I remove the translated strings as a cleanup process but if it will be done automatically, all the better.
Thanks

After going down a rabbit hole attempting to create namespace multiselection using checkboxes, based on how Search and RecentPage had coded it (as custom JS/CSS) only to hit an impass on formatting the checkboxes in a reasonable way as part of a larger HTMLForm, I switched to a new namespace multiselect capability recently added to mediawiki OOUI HTMLForm used by Special:Block. Bartosz pointed me at it (much WikiLove to Batrosz) and this new HTMLForm element works gloriously. The patch is now in review and will probably launch in Beta soon, then everywhere the following week.

Nearing completion of this task, final debugging and updating unit tests, creating new tests that exercise selecting multiple namespaces. The final bit of work will be to get the namespace checkboxes layout to look like other search pages that provide the same functionality.

The Special:LinterErrors page provides a with and without templates query filter providing this capability.

I am following the previous phab/gerrit path used to release parser migration back in 2017:
https://phabricator.wikimedia.org/T141586
https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/344276

In T231161#8831366, @ShakespeareFan00 wrote:

Another 'filter' that I think might be useful is specific to a Wikisource use case:-

And that is the ability to filter by the quality levels used by Extension:Proofread page for it's content model.

This means that I can focus attention on edits to page already "validated" or proofread and thus which have a greater chance of being transcluded elsewhere.

The current interface for Special LintErrors doesn't have a page quality filter, which means I am currently using a pywikibot script on PAWS to filter it down manually. This is not ideal...

Thanks Arlo, also had to create a recipient account and fix the recipientUser string to match and then things worked.

I can apply this change, but without commenting out lines 132-135 in SpecialContact.php like this, I cannot ever reach line 164, so unless I am missing something, this code is currently unreachable, or I cannot create a test environment condition with a logged out browser to reach it as a temporary user, which also maybe a configuration I have not set correctly in my local wiki instance:

If I understand this correctly, the code as is appropriately reports the IP address in a contact page email and is/maybe needed to aid in an IP block appeal exemption, and as such removing the IP here is not correct nor appropriate as part of the ongoing IPMasking issue. Let me know if I should close this ticket, or let others comment/review.

I think we should ship the large-tables lint suppressing code for the Parsoid rest API and then back it out once the replacement large-tables lint code is in production. This will help LintHint be usable again, later next week.

Hmm, nested tables create false positives, test coverage was inadequate.
Maybe we just drop a return at the start of the current large-tables lint code in Parsoid until this lint code gets rewritten?

For now, filtering in ParsoidHandler should help LintHint avoid being swamped with large-tables lints.
Next step I think is to implement inside Parsoid, a "internal" versus "exposed" or something like that flag that large-tables can use to hide these not WT errors, but useful diagnostic or research lints behind.