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.

Got it, excellent, your on it :-)
Will add myself as a reviewer if not already included.
Thanks

Large-tables lint still requires a follow on patch to avoid a serious performance problem when tables greater than 1000 rows are encountered, looking at the number of rows and if under some threshold, checking them all, and over that threshold, looking at the first few rows and header row.

I believe it is riding this weeks train, it was in beta as of last thursday
to allow QA to test. Once group 2 deploys we should start seeing entries.
Shannon

I am researching and also cannot duplicate his false positives using:
https://en.wikipedia.beta.wmflabs.org/wiki/Special:LintErrors/missing-end-tag-in-heading

Hacked up a bit of test code in php to aid in the process of adapting the javascript snippet to be a linter rule in Parsoid using Parsoids DOM utils. Hoping Parsoid team members with more expertise in html pattern possibilities can comment on the snippet and this codes deficiencies or edge cases where it would fail to detect tables with more than 5 columns based on the html that can exist and be generated by Parsoid. This code can be run standalone :-)

I will look at this worthy request. It is easy to suppress a new category from being displayed in the Special:LintError page displaying all categories, but linter errors of the new category may still display using other search features. I will consult with folks further about how accessing these hidden lint rule "errors" should be handled, if they should be searchable using the search filter form, or only using a quarry database direct SQL query.

Not sure why me or Arlo were not pinged to act as a mentor, a year ago, I am just seeing this for the first time. While it may not be suitable as a task for the Outreach program, the issue itself looks like it should be triaged at a minimum and might be something I look into, placing it on my backlog.

Research so far:
Looking at what it will take to allow arbitrary namespace selection instead of single namespace with invert checkbox that selects all but the selected namespace.
appears to take a fair bit of code such as in SearchFormWidget.php and would require additional query adjustments.
Estimate this as a medium to hard (take a couple weeks) to get working and polished, and if javascript needs updating, additional time.
Wondering how important this capability is to the community.

Ah I see, will look at fixing all of these. Seems like there could be minor risk of breaking something so will test carefully.

This change appears to have been completed.
Cannot find references to Database::select(

Part of this should be resolved by T165538 - gerrit 761070 when content model changes.

Once RESTBase has be replaced, this issue should be resolved.
Need to verify this is resolved after that takes place.

Now that there is a linter_template text field in the database, adding features like this is now feasible.
Evaluating feature list value and prioritizing.

Hmm, I see.

As the Linter UI can select a single page by Title or Title Prefix, from the search form found under the category list in the main Special:LinterErrors page, my hope is that this provides an adequate report focussing on just one pages errors. Using it, I can navigate from the reports error links to the wiki page, fix the highlighted error, save and then return to the report and select the next error. While not as convenient as LintHint which inspires me, hopefully it is adequate for others who don't use LintHint.

Three new columns have been added to the Linter table, are being written in all production wikis and the linter_params data was migrated in old records to be the same as newly written records using maintenance scripts.

Question: does the current namespace selection and invert selection check box adequately cover this feature request sufficiently. It does allow the exclusion of talk namespace while including all others.

Field added, maintenance migrate run and results verified in Beta and production.

Each linter_cat category defines what linter_params content is relevant and many categories do not have tag or template data. I did some quick checks using Quarry and all looks good for categories that should and should not have content in those fields. Some of the checks are listed below:

Ah sorry, the logger interface was recommended. I wish I had known about its quirks and limitations. Live and learn. Next time I will just output to console.

There is logging in both scripts:

		$logger = LoggerFactory::getInstance( 'MigrateNamespaceChannel' );

. . .

			$logger->info( 'Migrated ' . $updated . " page IDs\n" );