Wikipedia:Village pump (technical)

Is there a way to search for edit summaries (e.g., all edit summaries in the mainspace during the last month)? I'd like to have a list of diffs in which the edit summary mentions WP:ONUS (the shortcut). WhatamIdoing (talk) 03:15, 10 March 2026 (UTC)

No easy or fast way. quarry:query/102943. A similar search in all namespaces is fairly badly polluted by instances of "REVISIONUSER". —Cryptic 03:35, 10 March 2026 (UTC)

Maybe REPLACE(comment_text, 'REVISIONUSER', '') LIKE '%ONUS%'. Legoktm (talk) 01:47, 11 March 2026 (UTC)

comment_text RLIKE '\\bONUS\\b' would've done it, but the query took close to ten minutes the first time - the copy on Quarry only seems fast because it was cached - so it didn't seem worth running again. —Cryptic 02:11, 11 March 2026 (UTC)

If you're into command-line stuff, there is a denormalized dump of every edit, broken down by month. See wikitech:Data Platform/Data Lake/Edits/MediaWiki history. It's not trivial to get your head around the data organization, and you need a cloud account to access, but it's good for things like this. I ran bzgrep ONUS 2026-02.enwiki.2026-0* which took a little under 5 minutes and found 1169 lines. If you want, I could email you a copy. RoySmith (talk) 12:05, 11 March 2026 (UTC)

If "a copy" means a human-readable text file, then I'd be very happy to have that in e-mail. WhatamIdoing (talk) 04:36, 14 March 2026 (UTC)

Thanks. In case anyone's curious, after removing false positives (mostly REVISIONUSER, but also words like bonus) and discussions where we are talking about WP:ONUS but not invoking it, there were ~353 uses left (during the first two months of this year). WhatamIdoing (talk) 22:37, 15 March 2026 (UTC)

Hi everyone,

Back in November we shared that the Reader Experience team was conducting an experiment to bring reading lists to the desktop and mobile web browser experience. We are back with updates and next steps.

We are experimenting with potential improvements to the reader experience because of declining pageviews to Wikipedia and fewer readers returning to the site. We think by strengthening the connection between existing readers and Wikipedia, we can help reverse these trends and help engage potential future editors. One way to build that relationship is by giving readers more ways to shape their reading experience. Reading lists will allow for that participation by giving logged-in readers the option to save articles they want to come back to later in a list accessible in their account. The feature is already highly utilized on the Apps, where it has contributed to improved reader retention.

The experiment went live on Arabic, Chinese, English, French, Indonesian, and Vietnamese wikis in November, where we collected data for eight weeks on mobile and desktop. The experimental feature included:

• Options for logged-in readers to save articles to a private list for reading later.
• Ability for logged-in readers to access their list and delete articles that are no longer relevant.

What did we find?

The feature had good engagement. Our primary success metric was the clickthrough rate (CTR) on the save article icon. CTR measures how often readers engage with the feature, helping us understand whether people notice it and choose to use it. Typical web CTR is between 1-5%, but can be much lower for features which require an active or participatory action from the user. On English Wikipedia, we observed a clickthrough rate of 0.88% for the “save” button in the reading list experiment. This aligned with our expectations for the feature. Because saving an article reflects a specific intent through participation — returning to that article later — we did not expect engagement rates comparable to more general navigation actions.

Readers create accounts, but need reading focused features to sustain them. Our experiment was intentionally limited to a fraction of all readers who are not editors so we wouldn’t interfere with existing editing and moderation workflows. As a result, very few people saw the feature, making the exposure rate of the experimental feature too low to give conclusive evidence on how reading lists on web affect user retention. This was a helpful finding for us: currently, readers who do not edit do not have much reason to have an account, since most logged-in features on Wikipedia are designed for editors. The test helped us better understand how reader-focused features may reach a distinct audience of account holders who engage with Wikipedia differently than editors. For this reason, we are trying out a beta feature before full rollout so we can learn more about user retention with this feature with a larger audience.

Reading list users are active readers. Additionally, we found that readers that engaged with the feature had much higher rates of internal referrals – that is, that is, they more frequently navigated to other pages on Wikipedia. While this relationship is correlational rather than causal, it suggests that readers who already tend to spend more time exploring Wikipedia find particular value in this feature.

What are we doing next?

Based on the results above, we believe that reading lists is a feature readers are interested in and would like to collect more data on how people use it. To do this, we are planning on releasing reading lists on the desktop and mobile websites as a beta feature for logged-in readers.

To increase exposure among readers we will enable the beta feature for all new accounts. Existing users will be able to turn reading lists on manually in the beta section of their user preferences. We will be collecting feedback via QuickSurveys on whether beta users find it to be useful.

We’re planning on the following timeline:

• Week of April 6: Release the feature on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias.
• April 6 - April 20: Monitor and fix any bugs.
• Week of April 20: Release to all other Wikipedias.

We encourage you to try out the beta feature and give us feedback on-wiki or via the survey. Additionally, we want to hear more from you. Do you have any other ideas for reading lists based on this information? Please share your thoughts and questions here. For more info, see our project page.

Thank you. EBlackorby-WMF (talk) 21:05, 10 March 2026 (UTC)

To support current active readers on the wikis in their goals of learning from Wikipedia, we want to experiment with allowing readers to save articles to a list for reading later, helping them organize their knowledge while also building a practice of content curation that could pave the way for future contributions to Wikipedia.

Back in the day, this would be called "browser bookmarks". sapphaline (talk) 21:31, 10 March 2026 (UTC)

Plenty of other websites have features to save posts or articles, perhaps because bookmarks are deemphasised in modern web browsers and people tend to use them less IME. In any case, I personally think anything that increases new editor intake is a good thing.  novov talk edits 00:48, 11 March 2026 (UTC)

@Mir Novov "People tend to use them less". How do you know that? I think bookmarks are great and I use them frequently, David10244 (talk) 02:21, 11 March 2026 (UTC)

Anecdotally, I notice a lot of younger browser users don't use bookmarks apart from a few generic favourited sites, and mainly rely on tabs or other functionality for content they wish to revisit.  novov talk edits 02:39, 11 March 2026 (UTC)

@Mir Novov I think a lot of that comes from the fact that so much browsing is done on mobile, and mobile bookmarks generally suck. --Ahecht (TALK
PAGE) 19:54, 11 March 2026 (UTC)

I don't even have bookmarks in the mobile browser I use (Firefox Focus). Prototyperspective (talk) 21:13, 11 March 2026 (UTC)

@Mir Novov From a statistician: "Anecdotes are not data".  :-) David10244 (talk) 16:31, 15 March 2026 (UTC)

Hello!! Hsuanwei from the WMF Reader Experience team here :) This feature is definitely akin to browser bookmarks! We’re framing this as a first step toward readers participating more on Wikipedia by personalizing their experience, which we hope will eventually lead some of them to become interested in editing. To the tabs point, one tendency we’ve noticed in our user research is that some readers want to be able to “hoard” their information in one easily accessible spot, even though they may not revisit or organize it later, similar to how some people keep 100 tabs open. Do you have any suggestions for how to build on this work to make it more engaging or interactive? HFan-WMF (talk) 23:49, 17 March 2026 (UTC)

Great news, thanks. However, I'm more interested in the Recommended Reading List which can recommend articles one may be interested in based on these saved lists or on specified interests/articles-of-interest. Please get them to desktop too. See Wish505: Show recommended articles on Wikipedia Main page on desktop & mobile web, not just in app. and give us feedback on-wiki or… I'm using the saved reading list during distraction-free book-reading-like Wikipedia reading during commute or similar occasions where I save articles when there's something in it I'd like to look at later or select from articles saved earlier when it's an article I'm interested in reading but eg it's long and not of importance (ie not for editing or any immediate info-need and just for curiosity). Far more users use mobile Web than the app so they should be able to use this feature too if they'd like to. On desktop, it can be an alternative to watching articles. Do you have any other ideas for reading lists based on this information I wonder whether some could be created dynamically based on some inputs like one's configured interests and a category. Enabling notes for these would be very useful too, similar to watchlisted pages. Prototyperspective (talk) 00:09, 11 March 2026 (UTC)

Excellent note, recommendations for articles to read based on what you’ve already saved is definitely something our team is interested in bringing to the web experience in the future. We’re also thinking about it as another way for editors to potentially organize articles for themselves, and for readers, as an easy entry point to starting to see Wikipedia as a place for participation. Readers are interested in collecting, organizing, and sharing information, so we see this work as a step toward providing that option to them. We’re starting with just “saving” articles for now, but we definitely envision a future where categories and interests can help shape the reading experience, allowing readers to feel a more personal connection to their reading. If reading lists could support recommendations, what kinds of signals would you want them to use: articles you’ve saved, categories, topics you follow, or something else? Also curious what the ideal experience would look like for you, like where you would want to see it and how often it should update? HFan-WMF (talk) 23:51, 17 March 2026 (UTC)

Most times I open wikipedia I log in and go to my watchlist to see what changes have been made to the watched pages. I will then look at those changes. If there have been a lot of changes to a page I might look at a few and leave the rest til later. Until recently the watchlist would still show that page with a black dot to show there were changes I hadn't seen. Recently the list has shown a white (unfilled) dot and I haven't found a way to alter it. Is there anything I can do? Is this a universal change, or have I made a change to "preferences" or something inadvertantly? Spinney Hill (talk) 09:27, 11 March 2026 (UTC)

@Spinney Hill Hi. I think I understand what you're describing, but I want to verify before I file a bug (or encourage you to file a bug, if you'd like). Please confirm this is an accurate description: In phab:F72822789, I'm showing two screenshots, where I've clicked on "1", and where you would expect that only "2" is marked as "seen". is that right? Also, do you (or anyone) have a more specific sense of when this behaviour changed (this week, last week, or longer)? With those clues, it should be sufficient to file a useful bug-report. [I searched, and can't see any existing tasks that precisely match.] Cheers, Quiddity (WMF) (talk) 18:33, 12 March 2026 (UTC)

I'm not sure if I understand you -If the list is the history of an article I have looked at 1628 1641 and 1649 and then done something else. What should happen when I go back to that history is the entries for 1653 and 1659 are shown as not looked at but recently they have been shown as looked at so its difficult to see where I have got to in the history. Does that make sense. It happened in the last week I think. Spinney Hill (talk) 18:50, 12 March 2026 (UTC)

I think I'm probably out of my depth here so I would rather you logged the bug. Spinney Hill (talk) 18:52, 12 March 2026 (UTC)

In the mean time the watchlst shows the article is shown as looked at instead of not looked at. I first noticed this on Haymarket Theatre Leicester when a large number of edits were made on the same day and I had only looked at ten of them. The sytem showed I had looked at them all Spinney Hill (talk) 20:23, 12 March 2026 (UTC)

@Spinney Hill: They shouldn't be a black dot, they should be green, per the message

Pages that have been changed since you last visited them are shown in bold with a green marker.

Black dots are for the diffs that you've visited.

I had the opposite - normally, diffs not looked at are bolded/green-dotted until I refresh the watchlist; today I found that some edits remained bold/green-dotted even though I had visited the diff. One page that this happened with was Wikipedia:Village pump (technical). --Redrose64 🌹 (talk) 22:02, 12 March 2026 (UTC)

@Redrose64 I believe that what we each see by default will vary, because there's a default gadget (but that is "(unavailable with the improved Watchlist user interface)") that adjusts those aspects.

@Spinney Hill & Redrose64: I've filed phab:T419918 with what I think is the most broadly-applicable description. I don't recall how exactly it worked before today, but hopefully that task will provide enough clues to unearth whatever is causing the change. Hope that helps. Quiddity (WMF) (talk) 22:59, 12 March 2026 (UTC)

Thanks for the above. I've never seen any green marker --green text yes. Spinney Hill (talk) 09:16, 13 March 2026 (UTC)

Was it one of Parkinson's Laws that "Improvement = deterioration)? Spinney Hill (talk) 09:20, 13 March 2026 (UTC)

Re: The bug: it has been identified and patched (thanks to matmarex), and will be fixed onwiki next week. (Details in the task on Phabricator)

Informal addendum, re: Parkinson's Laws: I'm not sure, but you've reminded me of this hacker-laws compilation that I recently found interesting/amusing (and it primarily links here to Wikipedia, which is nice). [Caveat that it's also rife with oversimplifications, of course!]. Closely related to our List of eponymous laws, but topically-focused and expanded. Quiddity (WMF) (talk) 18:47, 13 March 2026 (UTC)

Hutber's Law is the closest according to the Wp list. Thanks to everybody Spinney Hill (talk) 11:25, 17 March 2026 (UTC)

I fixed a missing bracket in a failed verification template with the weird result that the article text included [[Category:Articles with failed verification from March 2026}]]. I can't spot anything that I have done wrong (doesn't mean that hasn't happened), but I am guessing something else caused this. ThoughtIdRetired _TIR 09:52, 12 March 2026 (UTC)

@ThoughtIdRetired see the subsequent edit by AnomieBOT, I think that will explain it for you. Nthep (talk) 10:36, 12 March 2026 (UTC)

@ThoughtIdRetired: Or even the previous edit, which shows the |reason= parameter being dropped between the two closing braces instead of before them. --Redrose64 🌹 (talk) 22:18, 12 March 2026 (UTC)

Yes, that was my fat fingers on the keyboard, followed by a complete inability to spot the problem. I'll just slink away in embarrassment. ThoughtIdRetired _TIR 23:07, 12 March 2026 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:52, 16 March 2026 (UTC)

The cite template feature in the default toolbar of the source editor is broken. I have reported it at Wikipedia talk:RefToolbar#RefToolbar is broken. PrimeHunter (talk) 20:39, 12 March 2026 (UTC)

Fixed by Pppery. PrimeHunter (talk) 20:51, 12 March 2026 (UTC)

Not sure what happened exactly, but all transparent PNG images on wikipedia are now showing up blurry. You can see this particularly with Kratos (God of War), where both the infobox and lower image are blurry, despite previously being perfectly fine. Kung Fu Man (talk) 01:32, 13 March 2026 (UTC)

Seems to be effecting "png" formats as well beyond transparent ones. BGC OVA.png for example is blurry even on its preview page. It is also happening with some jpegs. Like this file (heads up, this file has some uhh imagery that is "unfortunate" to put it lightly.) here which is a jpeg which is also compressed on its own article and the preview page, but on clicking on it, it retains its quality. Andrzejbanas (talk) 14:24, 13 March 2026 (UTC)

This affects, from what I've seen, every jpg file whose width is less than 250 px. ภץאคгöร 23:24, 13 March 2026 (UTC)

Ah. Perhaps it's due to the recent change to allow only certain image widths to be served, instead of anything-you-like. See Wikipedia:Village pump (technical)/Archive 226#Tech News: 2026-05, bullet beginning Image thumbnails that are requested in non-standard sizes. --Redrose64 🌹 (talk) 23:41, 13 March 2026 (UTC)

Blurry thumbnails on sports uniform / kit template images

Hello,

I noticed that many uniform template images used in sports infoboxes (such as Template:Baseball uniform and Template:Basketball kit) recently started appearing blurry on article pages, even though the original files on Commons have not changed.

This affects files uploaded by multiple users, not just my own, and the issue seems to only occur in the thumbnails. When clicking the file and viewing it on Commons, the image appears sharp.

Examples where this occurs:

Files I uploaded:

United States national baseball team

Puerto Rico national baseball team

United States men's national basketball team

Files uploaded by other users:

Cuba national baseball team

Japan national baseball team

There are many more examples all related to this kit templates, and possibly to other types of images and templates in lower resolution.

The ones I noticed though are images are used in Template:Baseball uniform, Template:Basketball kit, and similar templates.

Since the originals are unchanged and only the thumbnails look blurry, this may be related to thumbnail rendering or a recent MediaWiki change.

Is this a known issue, and is there a way to restore the previous thumbnail quality? ANTbook365 (talk) 13:34, 13 March 2026 (UTC)

ANTbook365, see the post directly above. Regards KylieTastic (talk) 13:40, 13 March 2026 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:53, 16 March 2026 (UTC)

Doubt

Why do the images look very blurry when viewed in an article and as a file page, but they actually look HQ when the file is viewed like this ? Is this a new optimisation to improve performance or to tackle copyright restrictions? What is the reason behind images turning this blurry? Manick22 (talk) 12:35, 14 March 2026 (UTC)

@Manick22: It's a recent bug. See #Transparent PNGs appear broken on wikipedia. PrimeHunter (talk) 12:39, 14 March 2026 (UTC)

When will this be fixed? This one looks very blurry! Manick22 (talk) 12:46, 14 March 2026 (UTC)

After the weekend. —TheDJ (talk • contribs) 13:40, 14 March 2026 (UTC)

@TheDJ Oh, okay. Thanks for the reply! Manick22 (talk) 13:49, 14 March 2026 (UTC)

@TheDJ and PrimeHunter: It seems that not only png, the others file include jpg, jpeg, webp also have the same problem (the images look very blurry) and not only happen in english wikipedia, the chinese wikipedia have the same problems. Thanks. Stevencocoboy (talk) 07:28, 16 March 2026 (UTC)

Appears to now be fixed, though you may need to purge the page to force the image to get unstuck. --PresN 21:11, 16 March 2026 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:52, 16 March 2026 (UTC)

The link Rhoticity in English § /ɔː/–/ɔr/ merger (meant to be the target of Caught-court merger) takes me to /oʊ/–/ʊər/ merger instead. That link takes me to Effect of non-rhotic dialects on orthography, the link to which sends me straight to the references section. If this isn't apparent for you, try using these section links with the legacy Vector skin on a maximized Firefox window on Windows 10 on a 1920x1080p monitor, if all of those are available to you. – MrPersonHumanGuy (talk) 20:03, 13 March 2026 (UTC)

@MrPersonHumanGuy: The page jumps around for me very quickly and ends in the right place but it can vary by browser and circumstances. It's a common issue when there is collapsible content earlier in the page. The browser first jumps to where the anchor (section heading) is positioned at the time but then collapses or uncollapses something earlier in the page so it should no longer be the same distance from the top. The browser may or may not adjust the position after this. PrimeHunter (talk) 20:32, 13 March 2026 (UTC)

Seconding PrimeHunter. I believe this is entirely because of the collapsed tables within the article-sections above those link-targets. I.e. The links initially scroll to the correct place, but then the tables collapse afterwards [IIUC, this is because of how JavaScript runs after the browser has completed the HTML rendering?] which means the content gets moved. I think we probably need some kind of clearer warnings/explanations within MOS:DONTHIDE about this? I wrote a related essay years ago at mw:User:Quiddity/Collapsing and hiding that might be useful if anyone wants to document it formally (or improve/adapt the essay). HTH. Quiddity (talk) 20:34, 13 March 2026 (UTC)

If you click in the address bar and press enter then your browser probably jumps to the right place. It jumps to the section again and this time the collapsing is done. PrimeHunter (talk) 21:34, 13 March 2026 (UTC)

Is there an easy way (such as a bot) to fix "spaghettified" discussions such as has occured at Talk:Canadian Indian residential school system? IOHANNVSVERVS (talk) 09:37, 14 March 2026 (UTC)

Probably possible, but such things are quite controversial; see Wikipedia:Bots/Requests for approval/IndentBot for an example. — Qwerfjkltalk 15:25, 14 March 2026 (UTC)

The default toolbar of the source editor has search and replace on a magnifying glass icon to the right. It can be used to replace a large number of colons with nothing. PrimeHunter (talk) 16:52, 14 March 2026 (UTC)

@Sapphaline, can I ask what method you used in your edit fixing the indentation? And thank you for doing so. IOHANNVSVERVS (talk) 22:25, 14 March 2026 (UTC)

Manual copy-paste and comparing between page's code and rendered output. sapphaline (talk) 09:23, 15 March 2026 (UTC)

I see. Too bad there's not an easier way. Thanks again. IOHANNVSVERVS (talk) 11:27, 15 March 2026 (UTC)

I am trying to run off statistics on pages views for Category:History of the Paralympic movement in Australia articles but the massviews tool but I am getting "An unknown error occurred when querying" Anybody know what is going on? Hawkeye7 (discuss) 23:19, 14 March 2026 (UTC)

@Hawkeye7: It's discussed at meta:Talk:Pageviews Analysis#Massviews not returning any results. PrimeHunter (talk) 23:57, 14 March 2026 (UTC)

Thanks for that! I will keep an eye on it. Hawkeye7 (discuss) 00:24, 15 March 2026 (UTC)

Recently a parameter was added to {{Sidebar person}} to allow the "a series" text to link to the main category for the person, much as it's linked in sidebars like {{Shinto}} or {{Liberalism sidebar}}. Unfortunately the link remains blue, ignoring the font colour which is applied elsewhere. I've tried various things in the template sandbox, but none worked. Could someone better at programming templates take a look and see if there's a way for the link to use |font_color= when |series_category=yes is set? – Scyrme (talk) 00:01, 15 March 2026 (UTC)

@Scyrme: Link colors can only be changed inside a piped link. Special:ExpandTemplates shows {{Shinto}} produces [[:Category:Shinto| <span style="color:White;">a series</span>]] — Preceding unsigned comment added by PrimeHunter (talk • contribs) 01:26, 15 March 2026 (UTC)

Redoing ping to @Scyrme: for @PrimeHunter:. Graham87 (talk) 05:54, 15 March 2026 (UTC)

Or by changing the color with WP:TemplateStyles. Izno (talk) 06:12, 15 March 2026 (UTC)

OK, that's possible but too much work. If you want to use a template then just use {{Colored link}} which uses the piped link method. PrimeHunter (talk) 13:07, 15 March 2026 (UTC)

Thanks for the answers, though it turned out my mistake was using {{colored link}} around a link including the brackets rather than replacing the brackets with the template. Seems to work now. – Scyrme (talk) 17:07, 15 March 2026 (UTC)

Space bar resetting the search term was recently fixed at phab:T418172. But now there is a new problem. Now the search suggestions are always one step behind the typed term. For example when searching for Trapdoor. Typing T, nothing shows up. At Trap it shows Transnistria while omitting the p letter.

Confirmed affected sites: en.m.wikipedia.org, en.m.wiktionary.org

Phone model: OnePlus 3, operating system: Android 9 / OxygenOS 9.0.6, browser: Firefox 148.0.1

Aloysius Jr (talk) 23:23, 15 March 2026 (UTC)

WikiBlame seems to be broken. I almost always get "Your search term was not found at all. Check the settings and try again." I tried different search terms, different pages, different wikis, searching for wikitext or full text. Always the same result. It's been like this for a couple of days now, maybe a week. (Half an hour ago, it seemed to be working for a few minutes, but now it's broken again.) I also opened a GitHub issue. — Chrisahn (talk) 23:39, 15 March 2026 (UTC)

An example article and search text that failed would be useful. Johnuniq (talk) 06:48, 16 March 2026 (UTC)

I just visited John Draper and clicked "Find addition/removal" in history, then entered software engineer in 'Search for' and pressed Enter. In under a minute it found the addition on 02 March 2025. That is, it works for me. Johnuniq (talk) 06:53, 16 March 2026 (UTC)

Thanks for your response! There's been an overlap, @Flominator fixed the issue about an hour before you tested it. Thanks! — Chrisahn (talk) 09:02, 16 March 2026 (UTC)

 Done Fixed, see GitHub issue. — Chrisahn (talk) 09:03, 16 March 2026 (UTC)

Thanks for reporting that and getting it fixed. Apparently the fix was to set the newly required user agent. Johnuniq (talk) 10:08, 16 March 2026 (UTC)

I'm surprised anybody is still using WikiBlame. I recommend installing the Who Wrote That? extension instead, it's so much better and saves a lot of time. Am I right, Johnuniq? Bishonen | tålk 20:23, 16 March 2026 (UTC).

WWT does not work outside of mainspace last I checked. Wikiblame, and User:Daniel Quinlan/Scripts/Blame, do not have this limitation. Izno (talk) 21:15, 16 March 2026 (UTC)

I've been using w:de:Benutzer:Schnark/js/wikiblame which appears to be similar to that Blame script. — Qwerfjkltalk 22:27, 16 March 2026 (UTC)

@Bishonen: My life is sufficiently exciting without trying new things! But maybe later I'll have a look. Johnuniq (talk) 00:08, 17 March 2026 (UTC)

@Izno:, you're right, but I suppose you and I live different lives; I can't remember ever wanting to know when something was added except in mainspace. A problem for others, though, may be that Who Wrote That? only works (or is only optimized for, whatever) Chrome and Firefox. @Johnuniq:, once you've tried WWT, you'll find digging through WikiBlame almost intolerably unexciting. Bishonen | tålk 10:44, 17 March 2026 (UTC).

Hey folks. For a line break in an article -- in the infobox, or in the body of the article -- is it better to use an HTML break tag (i.e. <br> or <br />) or a break template (i.e. {{break}}), and why? Or does it not make any difference? — Mudwater ^(Talk) 17:14, 16 March 2026 (UTC)

Depends. WP:NOBR is relevant if what you're making is a list. Otherwise, HTML br is fine generally. Izno (talk) 17:41, 16 March 2026 (UTC)

<br> is preferable. <br /> is unnecessary XHTML syntax, and {{break}} is intended only for cases where you can't use the tag directly. sapphaline (talk) 17:57, 16 March 2026 (UTC)

Note that this markup shouldn't be used to create unbulleted lists; use one of the list templates. sapphaline (talk) 18:01, 16 March 2026 (UTC)

@Sapphaline: <br> is fine with me, but why do you say that it's preferable to the template? — Mudwater ^(Talk) 18:14, 16 March 2026 (UTC)

or
<br /> is preferable. <br> generates syntax highlighting errors in the editor. . In many cases, it is better to use a list template, such as {{UBL}} or {{hlist}} — GhostInTheMachine ^{talk to me} 20:51, 16 March 2026 (UTC)

Which editor? Do you mean the old syntax highlighting gadget? Jack who built the house (talk) 20:53, 16 March 2026 (UTC)

The editor that I use seems to be called the "2010 wikitext editor". It does get quite upset by plain <br> tags — GhostInTheMachine ^{talk to me} 21:05, 16 March 2026 (UTC)

You are likely using Dot's syntax highlighter. It is an issue in this way. Izno (talk) 21:13, 16 March 2026 (UTC)

And if not Dot, then potentially WP:WIKED. Either way, my opinion is that neither of these are necessary today, the tools one might use with them are available in what MediaWiki supports now. You should consider trying those and ditching whatever you do have installed. Izno (talk) 21:19, 16 March 2026 (UTC)

No explicitly loaded external stuff, just the standard "2010 wikitext editor" plus the alternative Syntax highlighter via enabling the gadget in Preferences. i.e. "Dot's". Turning off the gadget reverts to the "standrd" highlighter, which does not care about <br> vs. <br />, but (after using the gadget version for a while) now looks rather horrible </digression> — GhostInTheMachine ^{talk to me} 09:14, 17 March 2026 (UTC)

@Mudwater: To return to the original question: as far as our readers are concerned it makes not one scrap of difference. The <br> tag was introduced in HTML 2.0 way back in 1995, and is valid in all subsequent versions of HTML, but not XHTML (unless followed directly by the closing </br> tag). The <br /> tag first appeared in XHTML 1 (2000) and is also valid in HTML 5 (2014) as an optional variant of <br>. The {{break}} template emits one or more <br /> tags, and browsers simply do not care (or know) whether these tags were typed directly or emitted by a template, function, macro or other typing aid. The MediaWiki software serves HTML 5, and normalises <br /> tags (however produced) to the <br> form.

The missing question - that others are attempting to answer - is this: where are you using these tags? Is it to emit a cosmetic newline, or to make a list? If the former, that's OK; but if the latter, MOS:NOBR applies everywhere - in infoboxes, prose and talk page discussions. --Redrose64 🌹 (talk) 22:29, 16 March 2026 (UTC)

Yes, Redrose64, and everyone else, I should have stated this clearly before now. I would not use breaks to make a list, I would use a template such as {{plainlist}}, or just use asterisks or pound signs to create bulleted or numbered lists, respectively, with regular Wikipedia markup. — Mudwater ^(Talk) 23:09, 16 March 2026 (UTC)

Here's a bit more background: I saw this edit, and started to wonder if there's a reason to prefer either the HTML or the break template. The readers can't see the difference, and I haven't heard any technical reasons either way, so perhaps it's just a matter of editorial preference. But if so, some editors might be able to explain why they have a preference. I'd be interested in hearing any. Otherwise I won't worry about it too much. — Mudwater ^(Talk) 23:15, 16 March 2026 (UTC)

This is a cosmetic newline between two parts of an address. I would say that <br /> is fine to use in this instance. --Redrose64 🌹 (talk) 23:34, 16 March 2026 (UTC)

If people find bare HTML upsetting, then using the {{break}} template (or the {{br}} alias) is fine too. I really do not see any need for an edit that switches between tags and templates (or the other way) — GhostInTheMachine ^{talk to me} 11:52, 17 March 2026 (UTC)

MediaWiki message delivery 19:33, 16 March 2026 (UTC)

https://github.com/greencardamom/Wikiurl

wikiurl is a high-performance, multi-engine command-line tool for extracting URLs from Wikimedia projects. It allows you to search on specific domains across various wikis and output the results in multiple formats (TSV, JSONL, raw SQL, or article title list). At maximum, you could download all URLS across all 800+ wikis.

Notable for being written in Nim, it compiles to Linux, Mac or Windows binaries, and uses GitHub to do the compilation step, so users have safety downloading the executable. Being Nim it compiles to highly optimized C code which is then compiled to binary by GCC. It provides 4 options how to retrieve the URLs: API, SQL, Dump Download and Dump Streaming - each engine has pros and cons depending on nature of request. -- GreenC 21:11, 16 March 2026 (UTC)

Very interesting, and well documented at github. Thanks! Johnuniq (talk) 00:41, 18 March 2026 (UTC)

Something odd is going on when searching for pages in the Wikipedia:Project namespace using VisualEditor. The word Wikipedia is showing up with a lowercase w and the search results are displaying results for the project page's name if it was in mainspace, as seen to the right. mdm.bla 21:56, 16 March 2026 (UTC)

It looks like the search field wants to interpreted the input as an interproject link to Wikipedia, despite being on Wikipedia already. For example, on Wikimedia Commons, the wikitext to produce a link to this Village pump page is [[wikipedia:Wikipedia:Village pump (technical)]] (note the repetition of the word "Wikipedia"). —⁠andrybak (talk) 22:16, 16 March 2026 (UTC)

Filed as phab:T420288. Thanks both for the details. Quiddity (WMF) (talk) 23:45, 16 March 2026 (UTC)

As a workaround you can use the namespace aliases WP or Project instead of Wikipedia. PrimeHunter (talk) 00:25, 17 March 2026 (UTC)

This has been fixed and deployed. ESanders (WMF) (talk) 14:40, 17 March 2026 (UTC)

Thank you very much! mdm.bla 14:55, 17 March 2026 (UTC)

I'm trying to run a Quarry search for pjge titles that mix Devanagari with other scripts, but I can't figure out why it doesn't match anything. In particular, it should have found the deletion log entry for भोजपुरी language. Replacing with a different regex seems to work, but prepending "\b" fails.

SET @pat1='\P{L}*\p{Devanagari}.*[^\p{Devanagari}\P{L}].*';
SET @pat2='\P{L}*[^\p{Devanagari}\P{L}].*\p{Devanagari}.*';

WITH ns(ns_n, ns_s) AS (VALUES (-2, 'Media:'), (-1, 'Special:'), (0, ''), (1, 'Talk:'), (2, 'User:'), (3, 'User talk:'), (4,
  'Wikipedia:'), (5, 'Wikipedia talk:'), (6, ':File:'), (7, 'File talk:'), (8, 'MediaWiki:'), (9, 'MediaWiki talk:'), (10, 'Template:'),
  (11, 'Template talk:'), (12, 'Help:'), (13, 'Help talk:'), (14, ':Category:'), (15, 'Category talk:'), (100, 'Portal:'), (101,
  'Portal talk:'), (118, 'Draft:'), (119, 'Draft talk:'), (126, 'MOS:'), (127, 'MOS talk:'), (710, 'TimedText:'), (711, 'TimedText talk:'),
  (828, 'Module:'), (829, 'Module talk:'))
SELECT CONCAT('[[',
              COALESCE(ns_s, CONCAT('{{ns:', page_namespace, '}}:')),
              REPLACE(page_title, '_', ' '),
              ']]') AS title,
       EXISTS (SELECT 1
               FROM page p2
               WHERE p2.page_namespace = sq.page_namespace
                 AND p2.page_title = sq.page_title) AS existing,
       COUNT(log_namespace) AS `times deleted`,
       GROUP_CONCAT(log_timestamp SEPARATOR ' // ') AS `deletion timestamps`,
       GROUP_CONCAT(comment_text SEPARATOR ' // ') AS `deletion comments`,
       (SELECT GROUP_CONCAT(comment_text SEPARATOR ' // ')
        FROM logging_logindex
        JOIN comment_logging ON comment_id = log_comment_id
        WHERE log_namespace = page_namespace
          AND log_title = page_title
          AND log_type = 'protect'
          AND log_action = 'protect'
          AND log_params LIKE '%create=%') AS `salt comments`
FROM (SELECT page_namespace, page_title
      FROM page
      WHERE (REPLACE(page_title, '_', ' ') RLIKE @pat1
             OR REPLACE(page_title, '_', ' ') RLIKE @pat2)
         AND page_namespace NOT IN (1,2,3,4,5,6,7)
      
      UNION DISTINCT

      SELECT ar_namespace, ar_title
      FROM archive
      WHERE (REPLACE(ar_title, '_', ' ') RLIKE @pat1
             OR REPLACE(ar_title, '_', ' ') RLIKE @pat2)
         AND ar_namespace NOT IN (1,2,3,4,5,6,7)) sq
LEFT JOIN logging_logindex
       ON log_namespace = page_namespace
      AND log_title = page_title
      AND log_action = 'delete'
      AND log_type = 'delete'
LEFT JOIN comment_logging ON comment_id = log_comment_id
LEFT JOIN ns ON ns_n = page_namespace
GROUP BY page_namespace, page_title
ORDER BY `existing` DESC, page_namespace ASC, page_title ASC;

–LaundryPizza03 (dc̄) 05:12, 17 March 2026 (UTC)

Your backslashes aren't escaped. —Cryptic 05:24, 17 March 2026 (UTC)

Fixing this caused a lengthy delay and a replication lag, and still returned no results. Do I need to escape any characters other than the backslash? –LaundryPizza03 (dc̄) 06:31, 17 March 2026 (UTC)

No. The reason you're not getting results is that you forked from one of the versions of this query where the pattern I was matching didn't have to worry about non-Latin characters - which is admittedly most of them - so you'll have to explicitly convert page_title and ar_title to utf8. quarry:query/84985 was the first I found that does that, though most of the rest of it is outdated. And of course it was slow; not only does it have to do full table scans of both page and archive, both your regexes are catastrophically slow - the ending .* will be optimized away, but the initial \P{L}* likely won't be, and removing both won't change what they match. —Cryptic 07:05, 17 March 2026 (UTC)

Also, if you just want mainspace matches, or mainspace and category and template or whatever, say so - page_namespace = 0 or page_namespace IN (0, 10, 14) will be (partially) indexed, page_namespace NOT IN (1,2,3,4,5,6,7) tends not to be; and while a single blacklist regex has to match a candidate by itself, which is why they're written in pairs like (Devanagari character eventually followed by non-Devanagari letter) or (non-Devanagari letter eventually followed by Devanagari character), these queries don't: you're way better off with matching both "Devanagari character" and "non-Devanagari letter". SELECT COUNT(*) FROM page WHERE page_namespace=0 AND CONVERT(page_title USING utf8) RLIKE '\\p{Devanagari}' AND CONVERT(page_title USING utf8) RLIKE '[^\\p{Devanagari}\\P{L}]'; completed in 20 seconds, and the version for archive in 39. —Cryptic 07:42, 17 March 2026 (UTC)

This returned lots of false positives with U+02BC ʼ MODIFIER LETTER APOSTROPHE, which is used in the Boro and Dogri languages, so I had to exclude that as well. The completed query for article and draft space can be found at quarry:query/103274. –LaundryPizza03 (dc̄) 08:07, 17 March 2026 (UTC)

The Mobile Apps team is exploring what should happen when an app user taps "Edit" on an article, and input from your community would be valuable. The context is summarized below, and full information can be found on the Future of Editing on the Mobile Apps page. The plan is to make sure app users edit in the mobile web editor from within the app, where we have better editing tools.

Problem definition

The Wikipedia mobile apps were originally built as reading tools. Reading features and native app capabilities are the primary motivation for users to download them, and remain the driving factor for high reader retention. In the last several years native editing experiences were added to the Wikipedia apps to meet user requests. A challenge has been the absence of VisualEditor in the apps, which is the result of technical constraints; it would take several years to build a functional native WSYWIG editor. The lack of VisualEditor has meant anyone who opens an article to edit is immediately confronted with raw wikitext, which resembles code and leads many newcomers to assume editing requires technical knowledge. Research confirms that despite investments in improvements to the native editor, the lack of VisualEditor creates a barrier to editing articles in the absence of structured tasks like Suggested Edits. Additionally, community spaces like the Teahouse and Help Desk are difficult to access from within the apps due to it being outside of the main namespace.

Context: the reader strategy

The Wikimedia Foundation is placing more emphasis on improving reading experiences alongside editing, with the goal of supporting readership, attracting new users and retaining them. We can’t rely on readers finding us through search engines the way we have been used to, and have to find new ways to attract readers who keep coming back to the wikis – some of whom might become editors in the future.

As part of this direction, the apps are being developed primarily as a strong reading experience for active readers, with more emphasis on features such as personalized discovery using local device data, daily reader engagement opportunities, and deeper connections to content.

At the same time, improvements to editing tools are increasingly being made on the web. This includes features such as Edit Check in the VisualEditor, Suggested Edits, and the Newcomer homepage, which aim to make editing more accessible and supportive for contributors.

This context matters for editor recruitment. The apps attract new readers every year, do a good job at retaining them, and there are plans to increase app visibility. Many editors make their first contributions by correcting small errors while casually reading — if those moments of impulse happen inside the app and a newcomer encounters wikitext without the option of VisualEditor, it may discourage them before they establish a foothold. The Reader and Contributor teams at the Wikimedia Foundation are working together on this, and introducing editing is particularly important on the apps, where a large share of users visit daily, and daily users are most likely to try editing – for example, 3% of readers became new editors with unreverted edits after they learned they could edit through the new app Activity Tab feature.

What's being considered

The team is exploring ways for users to continue editing in mobile web from within the app, where VisualEditor and other more fully-featured tools are available. There are open questions about how to do this effectively.

Questions the team would especially like input on

• What are the most critical editing workflows or community spaces that need to be accessible (even via redirect) from within the app?
• If the mobile web editor was accessible from the app, should the Mobile Apps eliminate the native source editor and suggested edits altogether?
• For editors who have tried editing on the app: at what point did the experience fall short, and would access to VisualEditor / mobile web have changed that?
• Are there aspects of the handoff from app to mobile web editor that would be most important to get right?
• What should that transition feel like? A prompt, a redirect, a wrapped in web experience? What should the tone of the redirect take if we are sending people out of the app to provide the least jarring experience?
• For editors who guide newcomers: how often does the app come up as a first editing environment, and what problems follow from that?

The full discussion page is at Discussion: Future of Editing on the Mobile Apps. Feedback on this post is also welcome.

--ARamadan-WMF (talk) 12:37, 17 March 2026 (UTC)