The other way this could be fixed is by using a similar UI as Special:Search or Special:Watchlist, which allows selection of arbitrary namespaces.

Or implement tracking categories, as has been suggested for years. I don't know why we have these Special pages that make it harder to see and count the errors. The "edit" links are handy, but that's about it; LintHint provides those for pages anyway.

I'd like to able to do a "prefix" filter as well. On Wikisource, goups of Lint errors typically need to be fixed across a number of Page: for a given Index: and at present the Special:LintErrors page doesn't let me do that level of search "granularity".

Especially the ability to filter out talk namespaces would be useful. To have people spending time fixing signatures as a means to wheedle down lists so that they are workable is such a horrid focus on good editing time and effort. Nothing more frustrating to seeing people fixing low value talk pages that have zero effect on people who left the projects years ago.

It would also be nice if the wikis were able to be able to apply a default filter to allow a focus on what the community considers of value.

In T231161#8661943, @Sbailey wrote:

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.

No. When we say talk above it's a keyword for all talk namespaces, not just Talk:, which is why this task suggests either a UI like Special:Watchlist or Special:Search (which allow arbitrary selections of namespaces) as one potential solution to prioritizing the work associated with the content namespaces (which can be checked themselves if you would prefer not to make the UI bigger).

I personally would prefer arbitrary selection.

Hmm, I see.

The ability to specify partial title prefixes also fails to satisfy this use case.

I will explore how I might enable arbitrary selection of multiple namespaces as that doesn't seem too difficult to engineer from the UI or place unreasonable demands on compute/disk during the database query.

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.

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...

In T231161#8831366, @ShakespeareFan00 wrote:

Please file a different task for that.

Change 929801 had a related patch set uploaded (by Sbailey; author: Sbailey):

[mediawiki/extensions/Linter@master] WIP Implementing multiple namespace selection for Linter filters

https://gerrit.wikimedia.org/r/929801

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...

Once I get the multi-select for namespace deployed, I will look at "page quality filter" and see where that data exists in the database and if that conditional can be added to the current linter report query in a reasonable performance wise way.

In T231161#8932572, @Sbailey wrote:

Once I get the multi-select for namespace deployed, I will look at "page quality filter" and see where that data exists in the database and if that conditional can be added to the current linter report query in a reasonable performance wise way.

Note that that is filed as T337543

Also, note that T173943 is a related task about filtering counts by content namespaces.

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.

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.

Change 929801 merged by jenkins-bot:

[mediawiki/extensions/Linter@master] Implement multiple namespace selection for Linter filters

https://gerrit.wikimedia.org/r/929801

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.

It appears that this change has been rolled out to en.WP. Is the breakage of existing links like https://en.wikipedia.org/wiki/Special:LintErrors/missing-end-tag?namespace=0 (missing end tag errors in article space) intentional?

These links are used in multiple places, including in the very useful https://fireflytools.toolforge.org/linter/enwiki report. Please let us know if we will have to find and fix all of these links.

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

wpNamespaceRestrictions=0\r\n1\r\n3 --- for namespaces 0 1 and 3

https://en.wikipedia.org/wiki/Special:LintErrors/html5-misnesting?wpNamespaceRestrictions=0%0D%0A1%0D%0A3&titlecategorysearch=&exactmatch=1&tag=all&template=all&useskin=vector-2022

Please let me know if you find any problems with the result sets being incorrect.
I am sorry this broke the firefly tools. If I can be of assistance fixing any dependent tools, please ask and I will see what can be done quickly.

Regards,
Shannon

Thanks for the quick reply. We will see about getting the links updated. Thanks for this new namespace selection feature. I have already used it a couple of times to narrow the list of results, and it seems to work fine.

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.

It appears that the WMF may be on the hook for updating the format of the link called "View detailed information on the lint errors" on the "Page information" page for any page having Linter errors. See https://en.wikipedia.org/w/index.php?title=User:WOSlinker/lint14&action=info for a current example of one of these links. The results show pages in two namespaces instead of just the page in question.

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.

Change 972445 had a related patch set uploaded (by Sbailey; author: Sbailey):

[mediawiki/extensions/Linter@master] Update the namespace parameter name the link in action=info pages

https://gerrit.wikimedia.org/r/972445

Change 972445 merged by jenkins-bot:

[mediawiki/extensions/Linter@master] Update the namespace parameter name in the link in action=info pages

https://gerrit.wikimedia.org/r/972445