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)

Thanks for the feedback. I think it would be best if articles saved would be used until the input for recommendations have been configured more explicitly by the user. As for using categories, see phab:T181157 which is about exactly that. It would be great if articles and categories would be used for the recommendations. I don't know if there is a way for topics other than categories except for WikiProjects (their tags on articles' talk pages). As for what I think an ideal experience would be and how often I'd like them to update, see wish W506. Basically in a feed that updates when, and only then, I open the feed page and scroll/swipe down. Prototyperspective (talk) 13:29, 18 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)

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)

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)

This is still happening. I think it's related to the previous fixes because when I write Trap and then press spacebar it acknowledges the letter p. Aloysius Jr (talk) 22:42, 19 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 mw:Talk:Wikimedia Apps/Team/Future of Editing on the Mobile Apps. Feedback on this post is also welcome.

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

See e.g. https://en.wikipedia.org/w/index.php?title=Wikipedia%3ASandbox&date-range-to=2026-03-17&tagfilter=&action=history&useskin=cologneblue or https://en.wikipedia.org/w/index.php?title=Wikipedia%3ASandbox&date-range-to=2026-03-17&tagfilter=&action=history&useskin=modern (if you have "Temporary account IP viewer" right).

Is there any way I can debug this? sapphaline (talk) 10:53, 18 March 2026 (UTC)

These are community supported skins (aka, not supported), so some functionality is expected to be missing —TheDJ (talk • contribs) 11:02, 18 March 2026 (UTC)

I want to fix this only for my account. sapphaline (talk) 11:03, 18 March 2026 (UTC)

User:PrimeHunter/Vector 2022 reload.js may be of interest. PrimeHunter (talk) 13:40, 18 March 2026 (UTC)

Note that required modules do load (as can be seen from browser's debugger), but they seem to error out, though I can't confirm this because there's nothing in the console. sapphaline (talk) 11:03, 18 March 2026 (UTC)

Both Cologne Blue and Modern are legacy skins (they were removed from Preferences → Appearance in mid 2021), and are no longer maintained. New features are not necessarily going to work with them. --Redrose64 🌹 (talk) 18:59, 18 March 2026 (UTC)

The reason it's not loading is that it is not finding the #bodyContent ID it requires to run. * Pppery * _{it has begun...} 19:06, 18 March 2026 (UTC)

The following incredibly dumb and brittle line of JS appears to work in both Cologne Blue and modern:

mw.loader.moduleRegistry["ext.checkUser.tempAccounts"].packageExports["ipReveal.js"].addIpRevealButtons($("#content"))

. Probably someone who knows more than me about how ResourceLoader works could find a less stupid way of writing that. * Pppery * _{it has begun...} 19:13, 18 March 2026 (UTC)

This needs to be executed after "ipReveal.js" was loaded, though. sapphaline (talk) 19:36, 18 March 2026 (UTC)

A way to do this without timeouts is by changing "mw-content-text" ID to "bodyContent":

if (mw.config.get("skin") == "modern" || mw.config.get("skin") == "cologneblue") {
	var mw_content_text = document.getElementById("mw-content-text");
	mw_content_text.setAttribute("id", "bodyContent");
}

sapphaline (talk) 19:54, 18 March 2026 (UTC)

We often have to ask people which editor they are using, which can be confusing for them and long-winded for us to explain.

I have made Wikipedia:Which editor? to which we can refer such people. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:03, 18 March 2026 (UTC)

@Pigsonthewing You might want to merge this into Wikipedia:Glossary/User interface. See also mw:Editor and Help:Edit toolbar. --Ahecht (TALK
PAGE) 14:31, 18 March 2026 (UTC)

Thank you; I don't. None of those pages are suitable for the purpose, especially when addressing novice editors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:54, 18 March 2026 (UTC)

There's mw:Editor already. Nardog (talk) 14:49, 18 March 2026 (UTC)

^ Izno (talk) 15:55, 18 March 2026 (UTC)

Is it must me or is there a more general problem with the way that "the system" is applying signatures?

If I edit an existing section at a talk page, then use the signature icon on the top of the editing box:

B I 🔗 etc

not only do I get my sig attached to the end of my post, but another sig is attached to the section title. What gives? 𝕁𝕄𝔽 (talk) 12:53, 18 March 2026 (UTC)

Not happening for me. That is mostly an "insert text here" button - are you in the "section header" input box when using it? Also it looks like you are trying to do an infinite loop on the second line of User:JMF/common.js. — xaosflux ^Talk 13:54, 18 March 2026 (UTC)

If it happens when you edit an existing section then I guess you see the heading on the first line and not in a box. Does it happen systematically like in with the signature at the end of the heading? Does it happen in safemode? PrimeHunter (talk) 14:04, 18 March 2026 (UTC)

No, not in the section header box. Just editing routinely [as in this case, using the explicit 'edit' function rather than ' reply'. I get a sig at the end of what I have written (as expected) and another gets tagged on to end of the section title. As it has just now, I will leave it for a moment as evidence and then correct it before responding to rest of your questions. --𝕁𝕄𝔽 (talk) 17:17, 18 March 2026 (UTC)

Doesn't happen in safemode! (https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=edit&section=22&safemode=1). I don't know for how long it has been going on.

Anyway, as it does not appear to be a general problem, best close the discussion in this forum and I would appreciate any suggestions at user talk:JMF#Wildcat signatures. Thank you. --𝕁𝕄𝔽 (talk) 17:29, 18 March 2026 (UTC)

If it doesn't happen in safemode, turn off all your userscripts and try again. See mw:Help:Locating broken scripts. — xaosflux ^Talk 10:28, 19 March 2026 (UTC)

It was a wikEd bug which has been reported and fixed at User talk:Cacycle/wikEd#Double insert on default toolbar icons. PrimeHunter (talk) 12:42, 19 March 2026 (UTC)

Hi all. I propose defuncting this template, {{PKRConvert}}, and instead relying on footnotes for relying on currency exchange using a live external link for that exact timeline.

The reason is inflation and currency unstability. The template may not reflect the recent changes, and it is nearly impossible to update it daily or on monthly basis.

Please see this footnote as a reference, and a recent concern raised over here. I am available to take any queries and suggstions. Thank you! M. Billoo 13:00, 18 March 2026 (UTC)

@M.Billoo2000 This should probably be discussed at Template talk:PKRConvert or WP:TfD. Is Pakistan significantly different from the 50 other countries supported by Template:Inflation? --Ahecht (TALK
PAGE) 14:23, 18 March 2026 (UTC)

I do not understand how this template works, Template:Inflation/PK/dataset, and that it is not edited in about four years. The inflation history can be seen here and any other similar website. I intentionally came on the village pump instead of TfD or Template talk, only because I want to specifically address this one currency, PKR only, to a wider PoV, and not any other currency. Also, that the template has been stale for years, so I felt useless in leaving a message there. I have seen multiple editors trying to use PKRConvert in Pakistan-related pages, which eventually generates a false value due to not reflecting that particular timeline. And that is why I have linked two of my PoVs above, and I can present more. Thank you. M. Billoo 14:40, 18 March 2026 (UTC)

I've been trying for ten minutes to fix the coordinates at Kirtland Community College. The campus was moved in 2016, but the dot still shows the old location, and even updating the coordinates is still showing the old location. What am I doing wrong? The current coordinates are 44.60180007265286, -84.70585794585037 Ten Pound Hammer • ^{(What did I screw up now?)} 14:53, 18 March 2026 (UTC)

Five decimal points gives a precision of around 1 metre. 14 is sub-atomic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:59, 18 March 2026 (UTC)

@Pigsonthewing: I tried shortening it to four decimal points and it still shows the old location. What am I doing wrong? Ten Pound Hammer • ^{(What did I screw up now?)} 15:08, 18 March 2026 (UTC)

Click "Wikidata item" under "Tools" and update the coordinates at Wikidata. PrimeHunter (talk) 15:15, 18 March 2026 (UTC)

I don't see either of those options anywhere. Ten Pound Hammer • ^{(What did I screw up now?)} 15:19, 18 March 2026 (UTC)

"Tools" is in the interface. In the default skin Vector 2022 it's a drop-down menu at the top right. In other skins it's a menu in the left pane but "Wikidata item" is a little further down under "In other projects". PrimeHunter (talk) 15:25, 18 March 2026 (UTC)

I have no clue what you're talking about. I'm using the default skin and I don't see anything called "Tools" anywhere on the page. Can you show me a screenshot? Ten Pound Hammer • ^{(What did I screw up now?)} 15:29, 18 March 2026 (UTC)

File:Commons "Tools" menu as of July 2024.png. "Tools" may also be in a sidebar to the right with a "hide" link next to it which would place it like the screenshot. In many browsers you can search a viewed page for a string with Ctrl+f. PrimeHunter (talk) 16:18, 18 March 2026 (UTC)

That area on the page is completely blank. I don't even see a "hide" anywhere. What page specifically do I need to be on to see it and therefore change it? Because it sure as shit isn't Kirtland's article, where the upper right is completely blank. Ten Pound Hammer • ^{(What did I screw up now?)} 16:23, 18 March 2026 (UTC)

Just go to https://www.wikidata.org/wiki/Q6416228. Scroll down to "coordinate location". Schazjmd (talk) 16:33, 18 March 2026 (UTC)

How did you get to that from the article, though? Ten Pound Hammer • ^{(What did I screw up now?)} 16:35, 18 March 2026 (UTC)

I'm using Vector Legacy. The associated Wikidata link is in the left-side menu at the very bottom. I don't know where it is shown in the default skin, sorry. Schazjmd (talk) 16:47, 18 March 2026 (UTC)

I take that back: I just opened the article in an incognito window so I could see it in the default skin. Along the top of the center pane is "Read - Edit - View history - Tools". The Tools dropdown menu shows "Wikidata item" at the bottom of the list. Schazjmd (talk) 16:50, 18 March 2026 (UTC)

The Tools menu is on every wiki page. Do you really have Vector 2022 at Special:Preferences#mw-prefsection-rendering? Do you see "Tools" near the top right here or if you log out? Try to bypass your cache with Ctrl+F5 if you have a Windows browser, or what do you use? If none of this works then your browser may have a serious problem, or are you using some app instead of a browser. "What links here" is also in the Tools menu. Do you know that feature? PrimeHunter (talk) 16:51, 18 March 2026 (UTC)

Ah, it's on the side for me and not the bottom. I see "what links here". Ten Pound Hammer • ^{(What did I screw up now?)} 17:03, 18 March 2026 (UTC)

Hammer's been around for far longer than I have, so like me probably still uses a pre-Vector skin (Cologne Blue, Modern or MonoBook): for each of these, it's in the left sidebar, below the "In other projects" subheading, titled "Wikidata item". If that is absent on an article, it means that there is no page at Wikidata. --Redrose64 🌹 (talk) 21:30, 18 March 2026 (UTC)

Obligatory xkcd Qwerfjkltalk 19:12, 18 March 2026 (UTC)

See your 2170 and raise you 2168. --Redrose64 🌹 (talk) 21:39, 18 March 2026 (UTC)

Hey, I noticed for a while that some imported webfonts on my CSS page from db.onlinewebfonts.com can't load anymore as they used to. Is Wikimedia blocking it or does the website block Wikimedia now? --Esperfulmo (talk) 21:30, 18 March 2026 (UTC)

We recently blocked loading of external resources from domains that aren't specifically whitelisted in response to a security incident. See phab:T419265. * Pppery * _{it has begun...} 21:34, 18 March 2026 (UTC)

https://www.base64encode.org/ + https://stackoverflow.com/questions/26867893/converting-and-rendering-web-fonts-to-base64-keep-original-look sapphaline (talk) 21:46, 18 March 2026 (UTC)

Thanks both for taking the time and attention to answer me. How can we ask to allow the aforementioned website to be able to load some basic fonts for me and anyone? This website has too many essential fonts. Using my phone I can't see them and I can't install fonts on it. --Esperfulmo (talk) 01:40, 19 March 2026 (UTC)

Converting to base64 isn't a solution for fonts which have too many characters and for dozens of fonts to load. It's impractical unless we want to just load a font which has a character or two. --Esperfulmo (talk) 01:43, 19 March 2026 (UTC)

You may want to remove the Content-Security-Policy HTTP header/modify it so that it includes your domain, then. There are multiple browser extensions to do so, e.g. "simple-modify-headers" (Firefox, Chrome). sapphaline (talk) 08:45, 19 March 2026 (UTC)

Would heavily advise NOT doing that, unless you know what any of those words mean. —TheDJ (talk • contribs) 10:53, 19 March 2026 (UTC)

Well, obviously this needs to be restricted to en.wikipedia.org. sapphaline (talk) 11:21, 19 March 2026 (UTC)

I tried to use alternative extensions since those are for the desktop version and I need to load the fonts on my phone, not my desktop which has enough fonts and it's easy to download on. I was not very sure how to implement the suggested solution with alternative extensions, so I failed to load any of my imported fonts. I want to load them on arz.wikipedia.org where they are imported from my common CSS on en.wikipedia.org. I believe a simpler exception could be made for db.onlinewebfonts.com for the case of loading fonts, am I right? I read the phabricator, but could understand the relation to my issue. They were talking about java script. I am not trying to load java script. --Esperfulmo (talk) 13:53, 19 March 2026 (UTC)

https://cdnjs.toolforge.org/ is a whitelisted domain, owned by WMF, that has some fonts. The "Fonts-linux" package in particular might help. If not, file a task at phabricator with all of the domains you are using and tag it with ContentSecurityPolicy. Snævar (talk) 17:04, 19 March 2026 (UTC)

https://fontcdn.toolforge.org/ provides proxy access to the fonts available from the Google font server. Note having a proxy doesn't completely eliminate privacy concerns and thus I was told (but can't locate the discussion right now) that the toolforge font server's purpose isn't to be used on Wikipedia. However it is an available resource if you are willing in essence to download the fonts from the Google font server. isaacl (talk) 17:57, 19 March 2026 (UTC)

Thank you all. I filed an issue. I hope it gets solved. --Esperfulmo (talk) 22:17, 19 March 2026 (UTC)

Does anyone know if there is a way to add a button to the WikiEditor toolbar using the built in functionality of that extension? I know I can hack it by inserting HTML after a certain element, but looking at mw:Extension:WikiEditor/Toolbar customization it looks like there should be a way to do it better IF the PHP settings are enabled. The question is... are they? Basically I would like to add a button that runs a certain javascript function... Any help appreciated as always! Zackmann (^{Talk to me}/_{What I been doing}) 04:11, 19 March 2026 (UTC)

They are. The examples on that page work on WMF wikis. Nardog (talk) 04:19, 19 March 2026 (UTC)

Was having a hard time getting it to work, I think I figured it out though. Zackmann (^{Talk to me}/_{What I been doing}) 04:22, 19 March 2026 (UTC)

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Wikipedia technical issues and templates When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Hi, I’m Johannes from Wikimedia Deutschland’s Technical Wishes team. We are considering to work on Community Wishlist/W17: Improve VE references' automatic names and reuse. This has been a long-term issue for wikitext editors (see e.g. WP:VisualEditor/Named references) which has been among the top-voted wishes in several Community Wishlist Surveys, e.g. 2017, 2019, 2022 or 2023.

We would like your input on the solutions proposed on our project page. We are considering several options, which can be combined if desired by the community.

• Changing the default pattern for automatically generated reference names (currently ":n", e.g. ":0", ":1"...) to use the reference type instead (e.g. "book_reference-1").
• Providing a simple mechanism for communities to configure a different default name.
• Generating automatic reference names based on the domain name (if it’s a web citation).
• Generating automatic reference names based on template parameters (e.g. "title" or "last"+"first") – defined by the community.

I would like to include an HTML comment with debugging information in the string I return from a Lua module
e.g.
return "<!-- DEBUG comment --><br/>TEST<br/>"
However, it seems that the parser is stripping out HTML comments as I do not see the HTML comment in the page source but I do see TEST in the rendered page. Is there a way to prevent the HTML comments from being stripped out? RedWolf (talk) 19:10, 19 March 2026 (UTC)

If you are expecting the debug comment to 'show' in an html rendering, it won't because by their very nature, html comments are not rendered visibly. I hacked a simple test to illustrate. If I write:

{{#invoke:Sandbox/trappist the monk/html comment|main}}

that returns:

TEST

if I write:

{{code|lang=html|{{#invoke:Sandbox/trappist the monk/html comment|main}}}}

that returns:

<!-- DEBUG comment --><br/>TEST<br/>

I can also write:

{{#invoke:string|find|{{#invoke:Sandbox/trappist the monk/html comment|main}}|DEBUG comment||true}}

that returns: 6 – the 'D' in 'DEBUG' is the sixth character in <!-- DEBUG comment -->

So the html comment is being returned; but you can't see it in an html rendering.

Have you considered mw.log() or mw.logObject()?

—Trappist the monk (talk) 21:41, 19 March 2026 (UTC)

You can use Special:ExpandTemplates to see html comments. Bawolff (talk) 22:16, 19 March 2026 (UTC)

• If I run ExpandTemplates with {{#invoke:Sandbox/trappist the monk/html comment|main}}, why can't I see <!-- DEBUG comment --> under PREVIEW when I view the Page Source (not the rendered output)? It's not in the RAW HTML output either. I know the HTML comment won't be in the rendered output but why doesn't it show up when I use FF's "Page Source" menu item? RedWolf (talk) 22:59, 19 March 2026 (UTC)

  Html comments are removed before outputting the html. Special:expandtemplates has a checkbox to disable this but you cannot disable on a normal page. Bawolff (talk) 00:23, 20 March 2026 (UTC)

I clicked a little too fast and clicked on the blue mark as read button for notifications for some multi-notification item for Commons like the one on the right when on this Wikipedia.

I haven't noticed any loss of notifications so I don't know

• if the marking failed fully or
• if there is some safeguard to prevent multi-items being marked as read when on another project or when it's too many items or
• whether it did successfully mark some notifications as read that I didn't mean to mark as read.

Is there any way to check if I did lose some notifications and see which? I only know of one way:

1. comparing the numbers of a screenshot of Special:Notifications to the current numbers. However, the last screenshot I made of the left panel of that page is too old.

For example, what would be great is a way of seeing 'read' notifications sorted by datetime of them being marked as read, not by the datetime the notification was created. Maybe there is a tool for that or it's possible in principle but one would need to code something for it.

If you think the problem of accidental clicking on mark as read should be solved, see this wish – one can vote on it:

W472: Confirmation dialog to prevent accidental clicks on Mark All As Read for notifications.

Help with retrieving the notifications if some did get marked as read would be very appreciated. Prototyperspective (talk) 23:41, 19 March 2026 (UTC)

If a usage of Template:Navbox timeline does not fit within the available area, Firefox will not allow users to scroll to see the remainder of the timeline, whereas Chrome will. There are various examples on the testcases page. I am not sure if the issue is specific to this template, or if multiple templates are affected. ~2026-17443-39 (talk) 01:11, 20 March 2026 (UTC)

@~2026-17443-39: It works for me in Firefox 148.0.2 (64-bit) on Windows 11. The scroll bars are just more narrow and might be overlooked. Are you sure it doesn't work for you? Try hovering your mouse over the bottom of the box. Is there no scroll bar or doesn't it work to click it? Please name a specific example. PrimeHunter (talk) 02:19, 20 March 2026 (UTC)