Or maybe "if no namespaces follows -prefix, it throws an error message and refuses to search".

Yes, that or "Student newspapers" "reliable" -prefix:Wikipedia:Articles would work.

Another workaround, though highly specific to my needs, would be to make the English Wikipedia's 577,000 (and counting) AFD subpages be in a different namespace. ;-)

Thinking of enwiki specifically again: Is it possible to enable RCPatrol for only edits in certain namespaces, by newcomers and less experienced editors? The idea of getting to the end of the list is very powerful for some users. A smaller list might make that feasible.

Thinking about this idea as a way to introduce newcomers into RecentChanges patrolling, but not as the be-all and end-all of all patrolling, I'm thinking that this would help:

Thinking of enwiki particularly, I think that the data the community (as in, The Community™, meaning experienced metapedians and power users like me, rather less experienced editors) is how many edits are getting checked now. The easiest place to start is probably with Special:NewPagesFeed: how many New Page Patrollers are looking at an article during the first hours/days, but not marking it as patrolled? If there is evidence of duplication, then a duplication-reducing system might be desirable.

An infobox is already in the plan, and will be easy. I think we can get hCard microformats, though that might take some extra time or be partial.

In re "Communication criteria - does this need an announcement or discussion?"

We can't realistically give you JSON. Would something like https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Microformats/hcard work?

My intent is to not have two steps that each involve "wait a long time". I've no opinion on how to accomplish that.

I think that a &preload= approach will be sufficient. Fancier options can be built later, if we decide that we need them in the future.

YT is a primary source for some statements. For example, https://www.youtube.com/@MrBeast would support a statement like "The MrBeast YouTube channel has 478 million subscribers as of 20 April 2026".

This happens consistently, so the steps to reproduce are quite simple for me:

@Sdkb, I'll send a screen capture to you.

I believe these bits of the design have been settled:

Will this address the YouTube complication? Namely:

I agree that "Two sets of templates seems cleaner", and I think we should take the cleaner approach.

If you'd like some sample text for this, then https://en.wikivoyage.org/wiki/Wikivoyage:Words_to_avoid has a list of words that should always be flagged. There will be false positives (e.g., "best" is acceptable for the "Best Western hotel chain" or "voted best chowder"), but these should not be common. There are translations into other pages, e.g., https://fr.wikivoyage.org/wiki/Aide:Mots_%C3%A0_%C3%A9viter and it's simpler and shorter than the English Wikipedia's https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Words_to_watch

I think that, as a matter of mission and principle, we should try to support browsers longer than commercial sites do. For example, if the industry standard is 7 years, then we should aim for 10.

I usually don't want to preview my edit summaries, and I don't want to disable keyboard shortcuts like pressing Enter when I'm ready to post my edit.

Any changes on this point need to be compatible with the English Wikipedia's "barnstars" system.

The opening statement for the Wishlist proposal says "Most new users fail to create articles with higher probability of success because they don't understand how they can reference the information".

It's broken again. Edits like this can only be done manually.

This feels like it's gotten stalled. Is there any little thing that we can do to move this forward? Is it possible to do a tiny test run? By "test run", I'm imagining something like a one-time action that deletes only those thumbnails that are exactly n days old (e.g., 100 or 1000 days), and otherwise meet the criteria. Then we could check whether anything bad happened.

Update: Citoid is working for nytimes.com today.

@ovasileva and others: Please see https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Change_of_Mobile_View_Watchlist for a potentially urgent problem that's likely related to this.

Related to this, do we need to add a check for "too few"? There are many pages at the English Wikipedia that have 30+ "watchers" (so the number gets shown) but a single-digit number of watchers who are active editors. People can see "on 50 watchlists, but zero active editors are actually available" (officially, "There may or may not be a watching user visiting recent edits"). It might be better if it wasn't so easy to see that zero or only one person (probably you) were watching a page.

In T355914#9537231, @ovasileva wrote:

Another step in the process here would be to look at how the change would visually affect current layouts on enwiki and across wikis...

Right. It's a mess, the numbers need to be changed, and nobody will want to be responsible, e.g., for "taking away" the 320px and substituting the more immediately useful 300px, or for changing the prefs settings from 300px to 320px. That will require, at minimum, a series of meetings. A plausible temporary "fix" would be to run a one-time job that pregens a 250px (and probably 300px) copy of every image that's currently used, and then switch the wiki(s). After that, the images can all be processed at human scale, when they're added to the articles.

In re https://phabricator.wikimedia.org/T355914#9505896:

Same song, second verse. This hasn't worked for weeks.

@Guy_Macon, did you ever post those numbers?

A problem in the Modern skin has been reported: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Notification_look_change