Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for 5 days.

[edit]
Tracked in Phabricator
Task T409073

The section link in the summary of the edit creating this section, i.e. →Section links with [square brackets] in edit summaries, will be linked to #Section links with square brackets in edit summaries, which doesn't work, not to #Section links with [square brackets] in edit summaries, which does work. Has this always been the case? I feel like this is a regression; am I misremembering? Nardog (talk) 14:22, 2 November 2025 (UTC)[reply]

This turns out to be caused by a mitigation for a different security issue. Your bug report has already been noted there, perhaps we can find a better solution. Matma Rex talk 17:54, 3 November 2025 (UTC)[reply]
We have found a better solution and it should be deployed after the weekend. Matma Rex talk 16:52, 8 November 2025 (UTC)[reply]

Tech News: 2025-45

[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

  • Administrators will now find that Special:MergeHistory is now significantly more flexible about what it can merge. It can now merge sections taken from the middle of the history of the source (rather than only the start) and insert revisions anywhere in the history of the destination page (rather than only the start). [1]
  • For users with "Automatically subscribe to topics" enabled in their preferences, starting a new topic or adding a reply to an existing topic will now subscribe them to replies to that topic. Previously, this would only happen if the DiscussionTools "Add topic" or "Reply" widgets were used. When DiscussionTools was originally launched existing accounts were not opted in to automatic topic subscriptions, so this change should primarily affect newer accounts and users who have deliberately changed their preferences since that time. [2]
  • Scribunto modules can now be used to generate SVG images. This can be used to build charts, graphics and other visualizations dynamically through Lua, reducing the need to compose them externally and upload them as files. [3]
  • Wikimedia sites now provide all anonymous users with the option to enable a dark mode color scheme, featuring light-colored text on a dark background. This enhancement aims to deliver a more enjoyable reading experience, especially in dimly lit environments. [4]
  • Users with large watchlists have long faced timeouts when editing Special:EditWatchlist. The page now loads entries in smaller sections instead of all at once due to a paging update, allowing everyone to edit their watchlists smoothly. As part of the database update, sorting by expiry has been removed because it was over 100× slower than sorting by title. A community wish has been created to explore alternative ways to restore sort-by-expiry. If this feature is important to you, please support the wish! [5]
  • Recurrent item View all 31 community-submitted tasks that were resolved last week. For example, the fixing of the persisting highlighting when using VisualEditor find and replace during a query. [6]

Updates for technical contributors

  • Since 2019 the Wikimedia URL Shortener at https://w.wiki is available for all Wikimedia wikis to create short links to articles, permalinks, diffs, etc. It is available in the sidebar as "Get shortened URL". There are 30 wikis that also install an older "ShortUrl" extension. The old extension will soon be removed. This means /s/ URLs will not be advertised under article titles via HTML class="title-shortlink". The /s/ URLs will keep working. [7]
  • On Thursday, October 30, the MediaWiki Interfaces and SRE Service Operations teams began rerouting Action API traffic through a common API gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to the Service Ops team board.
  • MediaWiki Train deployments will pause for the final two weeks of 2025: 22 December and 29 December. Backport windows will also pause between Monday, 22 December 2025 and Thursday, 2 January 2026. A backport window is a scheduled time to add things like bug fixes and configuration changes. There are seven deployment trains remaining for 2025. [8]
  • Recurrent item Detailed code updates later this week: MediaWiki

In depth

  • In 2025, the Wikimedia Foundation reported that AI systems and search engines increasingly use Wikipedia content without driving users to the site, contributing to an 8% drop in human pageviews compared to 2024. After detecting bots disguised as humans, Wikimedia updated its traffic data to reflect this shift. Read more about current user trends on Wikipedia in a Diff blog post.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 19:30, 3 November 2025 (UTC)[reply]

So should we convert template:Pie chart, template:Bar box, template:Clade, template:Cladogram etc. to use SVGs instead of HTML? sapphaline (talk) 19:47, 3 November 2025 (UTC)[reply]
@Sapphaline Is there any advantage to doing so from an aesthetic, accessibility, or include size standpoint? --Ahecht (TALK
PAGE) 19:21, 4 November 2025 (UTC)[reply]
HTML is a very bad tool to try to communicate the relationships in a graph. SVG isn't much better emitted-wise but would be significantly cleaner for the programmer. I agree with Sapphaline that some of these are clear and obvious rewrite targets ({{climate chart}} is another one). Izno (talk) 19:33, 4 November 2025 (UTC)[reply]
aesthetic - no. accessibility - yes, considering that some of these pseudo-graph templates are still hacking <table>s (I'm talking about template:clade and template:cladogram). include size - I think <img alt="..." src="data:image/svg+xml;base64,..."> is less HTML output than something like 
<div class="smooth-pie" style="width:100px;height:100px;background:#888;color:#000;-webkit-print-color-adjust: exact; print-color-adjust: exact;" aria-hidden="true">
<div class="pie25" style="background:#1b7837;color:#000" title="villages: 45.0%"></div>
<div class="pie25" style="background:#1b7837;color:#000; transform: rotate(0.202turn)" title="villages: 45.0%"></div>
<div class="pie50" style="background:#d9f0d3;color:#000; transform: rotate(0.449turn)" title="cities: 55.0%"></div>
<div class="pie50" style="background:#d9f0d3;color:#000; transform: rotate(0.5turn)" title="cities: 55.0%"></div>
<div class="smooth-pie-border"></div></div>
or 
<div class="clade"><style data-mw-deduplicate="TemplateStyles:r1261294616">body.skin-vector-2022 .mw-parser-output div.clade,body.skin-minerva .mw-parser-output div.clade{overflow-x:auto;overflow-y:hidden}body.skin-minerva .mw-parser-output div.clade p{font-size:inherit}.mw-parser-output table.clade{border-spacing:0;margin:0;font-size:100%;line-height:100%;border-collapse:separate;width:auto;display:table}.mw-parser-output table.clade table.clade{width:100%;line-height:inherit}.mw-parser-output table.clade td.clade-label{min-width:0.2em;width:0.2em;padding:0.1em 0.25em;vertical-align:bottom;text-align:center;border-left:1px solid;border-bottom:1px solid;white-space:nowrap}.mw-parser-output table.clade td.clade-label::before,.mw-parser-output table.clade td.clade-slabel::before{content:"\2060 "}.mw-parser-output table.clade td.clade-fixed-width{overflow:hidden;text-overflow:ellipsis}.mw-parser-output table.clade td.clade-fixed-width:hover{overflow:visible}.mw-parser-output table.clade td.clade-label.first{border-left:none;border-right:none}.mw-parser-output table.clade td.clade-label.reverse{border-left:none;border-right:1px solid}.mw-parser-output table.clade td.clade-slabel{padding:0.1em 0.25em;vertical-align:top;text-align:center;border-left:1px solid;white-space:nowrap}.mw-parser-output table.clade td.clade-slabel:hover{overflow:visible}.mw-parser-output table.clade td.clade-slabel.last{border-left:none;border-right:none}.mw-parser-output table.clade td.clade-slabel.reverse{border-left:none;border-right:1px solid}.mw-parser-output table.clade td.clade-bar{vertical-align:middle;text-align:left;padding:0 0.5em;position:relative}.mw-parser-output table.clade td.clade-bar.reverse{text-align:right;position:relative}.mw-parser-output table.clade td.clade-leaf{border:0;padding:0;text-align:left}.mw-parser-output table.clade td.clade-leaf p{padding-right:5px;padding-left:2px}.mw-parser-output table.clade td.clade-leafR{border:0;padding:0;text-align:right}.mw-parser-output table.clade td.clade-leafR p{padding-left:5px;padding-right:2px}.mw-parser-output table.clade td.clade-leaf.reverse{text-align:right}.mw-parser-output table.clade td.clade-leaf.reverse p{padding-left:5px;padding-right:2px}.mw-parser-output table.clade:hover span.linkA{background-color:yellow}.mw-parser-output table.clade:hover span.linkB{background-color:green}</style>
<table class="clade">


<tbody><tr>
<td class="clade-label first">root
</td>
<td rowspan="2" class="clade-leaf">
<div><link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r1261294616">
<table class="clade">


<tbody><tr>
<td class="clade-label first">
</td>
<td rowspan="2" class="clade-leaf">
<p>Leaf1
</p>
</td></tr>
<tr>
<td class="clade-slabel">
</td></tr>
<tr>
<td class="clade-label">
</td>
<td rowspan="2" class="clade-leaf">
<p>Leaf2
</p>
</td></tr>
<tr>
<td class="clade-slabel last">
</td></tr></tbody></table></div>
</td></tr>
<tr>
<td class="clade-slabel last">
</td></tr></tbody></table></div>
. sapphaline (talk) 21:02, 4 November 2025 (UTC)[reply]
Another reason to prefer SVGs is that they are "real" images that can be copied, exported, downloaded and indexed by search engines. It also contributes almost nothing to PEIS. The <img> tag isn't actually part of post-expand output – it's replaced by a strip marker which adds just about 26-30 bytes to PEIS (regardless of SVG size). – SD0001 (talk) 09:21, 7 November 2025 (UTC)[reply]
From the accessibility point of view, the SVG images don't do anything by themselves. You should think of them like any other image, so they should come with alt text and/or a caption. Often it may be helpful to display the same data in another format elsewhere on the page, e.g. the Climate chart template could generate a SVG chart with a simple HTML/wikitext table below it, perhaps collapsed.
Redoing the existing templates as SVG images without also adding alt text or other alternative presentation would probably be an accessibility regression; although I couldn't make sense of something like the Clade template using a screen reader, I imagine a more experienced user could, and at the very least it's possible to copy and read the text from it (which is no longer possible when the text is inside an image). Redoing them with some alternative presentation would definitely be an improvement. Matma Rex talk 21:26, 4 November 2025 (UTC)[reply]
There are two reasons for why SVG text is not selectable, and neither is the fault of SVG itself. One reason is that some people use text that is actually just paths and thus not selectable. People should instead use the fonts at meta:SVG_fonts. The other reason is that SVG thumbnails are not shown as SVG´s, but PNG´s. As for proof that SVG can have selectable text see for example https://upload.wikimedia.org/wikipedia/commons/d/d0/IsisPapyrus.svg . There has been some progress on sending SVG´s to the browser in the subtasks of phab:T5593. Snævar (talk) 23:32, 4 November 2025 (UTC)[reply]
The Scribunto modules that we're talking about emit SVGs in <img> tags, so the text in them is not selectable anyway. Making them interactive (including text selection) would be covered by T407783, but doing this securely is difficult. Matma Rex talk 19:40, 5 November 2025 (UTC)[reply]
Difficult? I'm nerd-sniped: https://gerrit.wikimedia.org/r/1203874 (just kidding, I was working on it anyway). – SD0001 (talk) 18:27, 11 November 2025 (UTC)[reply]

Scripts and gadgets sometimes not loading

[edit]

Context: I'm using Firefox on Linux, and the Vector legacy skin.

Sometimes, for no apparent reason, my scripts and gadgets just don't load, or only partially load. For example, I have the personal toolbar clock gadget enabled, and often it'll clear the space that the clock is meant to be in but doesn't show the clock itself, so it's just a blank space next to "log out". Other times, a couple of my toolbox scripts will load, but not others. Now the RefToolbar gadget has started to sometimes stop working (which is a huge blow to me, it's by far one of my most-used gadgets), and while most of these problems are solved by hard refreshing the page, RefToolbar seems to be stubborn and only fixed itself randomly after many refreshes, purges, and opening and closing tabs. This also comes a few months after the disambiguation warning pop-up stopped appearing for me, which was (and still is) a big annoyance.

I am getting deeply frustrated that things keep breaking for no reason. If anyone knows the solution, please help. Suntooooth, it/he (talk | contribs) 20:19, 5 November 2025 (UTC)[reply]

@Suntooooth: Please share if there are any errors in the console when scripts fail to work/load. See WP:CONSOLEERROR. — DVRTed (Talk) 05:14, 9 November 2025 (UTC)[reply]
Here are some cases and the errors I got.
  • When on an edit page, where most things loaded but not RefToolbar: (In this case there were also three "this ResourceLoader module is deprecated" warnings, for jquery.ui, mediawiki.ui.button, and moment.) 
     Uncaught SyntaxError: missing ) after argument list
    n index.php:1
    jQuery 2
        mightThrow
        process
 index.php:23:132
  • When reading an article, where the vast majority of my toolbox scripts and those in the "More" dropdown didn't load: zero errors, just two deprecated module warnings (the first two of the ones I listed above).
  • When editing another article, where I again didn't notice anything missing except for RefToolbar: a lot of HTML HTTP 429 errors for different scripts, with one example here - 
     XHRGET
 https://en.wikipedia.org/w/api.php?titles=User:Novem Linguae/Scripts/BlockedUserHistory.js&origin=*&format=json&formatversion=2&uselang=content&maxage=86400&smaxage=86400&action=query&prop=revisions|info&rvprop=content&rvlimit=1&inprop=protection
 [HTTP/2 429  43ms]
    Also this error:
If there's a way to show these without it taking up lots of vertical space, please let me know, this feels like it's taking up far too much space as it is. Suntooooth, it/he (talk | contribs) 17:03, 9 November 2025 (UTC)[reply]
I've never heard of a HTML 429 error; I think you mean HTTP 429 error. --Redrose64 🌹 (talk) 17:13, 9 November 2025 (UTC)[reply]
Yep, thank you - tired today so my words are getting mixed up. Suntooooth, it/he (talk | contribs) 17:14, 9 November 2025 (UTC)[reply]
One more error that I forgot to add: I don't have the exact error in my clipboard anymore and since this problem is random it's hard to recreate, but when the clock gadget failed to load in the way that I described above, there was a cross-domain error (IIRC) relating to the link to that gadget's JS page. Suntooooth, it/he (talk | contribs) 17:17, 9 November 2025 (UTC)[reply]
I tried a bunch of things (copying your common.js, testing in Firefox on both Vector skins with different "Tracking Protection" settings, etc.), but I couldn't reproduce the issue of scripts failing to load or show up in the toolbar.
The 429 errors probably showed up because you refreshed the page too many times. The syntax error comes from Macaw*'s User:Macaw*/noRefListAlert.js#L-23 (line 23) where it's missing a ')': rawHTML.indexOf('{{reflist}}');. That doesn't resolve the issue you described, though. — DVRTed (Talk) 20:53, 9 November 2025 (UTC)[reply]
Thank you for testing. Because you couldn't recreate it, I was thinking it might be a browser issue, but I just tested on Degoogled Chromium and I'm having the same issues. Here's the error relating to the clock gadget, since it happened again:
Access to XMLHttpRequest at 'https://www.mediawiki.org/w/api.php?titles=MediaWiki:Gadget-UTCLiveClock.js&origin=*&format=json&formatversion=2&uselang=content&maxage=86400&smaxage=86400&action=query&prop=revisions%7Cinfo&rvprop=content&rvlimit=1&inprop=protection' from origin 'https://en.wikipedia.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I also got a lot of 429 errors, despite not refreshing at all - I'm using a proxy (as I'm IP block exempt) and I wonder if there's a crawler using the same node and causing me to get these 429s. Not sure if that explains my problems though, considering there weren't any console errors in the second example I posted above. Suntooooth, it/he (talk | contribs) 21:38, 9 November 2025 (UTC)[reply]
I’ve fixed that syntax error but as DVRTed said I dont think its related. Best wishes, Macaw*! 14:30, 10 November 2025 (UTC)[reply]

Page creation disabled in DRAFTspace for temp accounts?

[edit]
Tracked in Phabricator
Task T409366

Has Wikipedia disabled draft article creation for what were IP users, now temp users? I'm unable to use the article wizard to create a new draft, nor is directly accessing the DRAFTspace page and trying to create it that way possible, as the [CREATE] button is missing. And adding a ?action=edit results in the Permission Error page, the same error page that results in trying to make an ARTICLEspace page -- ~2025-31118-76 (talk) 22:00, 5 November 2025 (UTC)[reply]

I can see no reason why you should be blocked from editing draft space on our end. Izno (talk) 22:24, 5 November 2025 (UTC)[reply]
I can edit an existing page in draft space, I cannot create a new draft in draftspace. So this would pertain to the Page Creation permission bit, I would assume. -- ~2025-31118-76 (talk) 22:29, 5 November 2025 (UTC)[reply]
@Izno I'm seeing the same thing when I try to create an account a draft while logged out. I get a "You do not have permission to edit this page" message that tells me to log in or create an account and be autoconfirmed. --Ahecht (TALK
PAGE) 22:27, 5 November 2025 (UTC)[reply]
@Ahecht Do you mean "when I try to create a page" instead of "create an account"? If so, that is expected, as logged out (or temp) users do not have the permission to create pages outside of the 'Draft:' namespace here. If you really see that message while trying to create an account, that's weird, please share more details (ideally a screenshot). Matma Rex talk 22:36, 5 November 2025 (UTC)[reply]
@Matma Rex: I meant "create a draft". This was in the draft namespace. Searching through this API query, no drafts have been created by temporary accounts since they were enabled. --Ahecht (TALK
PAGE) 22:38, 5 November 2025 (UTC)[reply]
@~2025-31118-76 Thanks for reporting. I can reproduce this, it seems like a bug in the configuration. To be clear, I clicked through Wikipedia:Article wizard and ended up on this URL: [9]. While logged out (not using a temp account), I see a page with instructions and an edit field (F69919483). While using a temp account, I see "You do not have permission to edit this page…" (F69919486). Matma Rex talk 22:34, 5 November 2025 (UTC)[reply]
Filed as T409366. Matma Rex talk 22:39, 5 November 2025 (UTC)[reply]
Looks like this should be fixed within the next few hours if I am reading things correctly. Is there a draft article location that you would prefer someone create for you in the meantime or not? --Super Goku V (talk) 07:05, 6 November 2025 (UTC)[reply]
Resolved
a patch has been pushed in the recent backport window. temp accounts now should be able to create draft articles. – robertsky (talk) 08:19, 6 November 2025 (UTC)[reply]
P.S. kudos to @Novem Linguae for fixing the issue. – robertsky (talk) 08:20, 6 November 2025 (UTC)[reply]
Ah, that was even faster than I expected. (And thanks to Novem Linguae.) --Super Goku V (talk) 19:28, 7 November 2025 (UTC)[reply]
Matma Rex too. He found the root cause before I did and mentioned it in the ticket :) –Novem Linguae (talk) 21:47, 7 November 2025 (UTC)[reply]

Module:If any equal

[edit]

I have an idea: Let's add a customized-output function to the Module:If any equal. The current output looks like this:

  • {{#invoke:If any equal|main|a|b|c|d|value=c}} gives yes
  • {{#invoke:If any equal|main|a|b|c|d|value=r}} gives no

My idea is to add |yes= and |no= parameters. For example:

  • {{#invoke:If any equal|main|a|b|c|d|value=c|yes=good|no=bad}} could give good
  • {{#invoke:If any equal|main|a|b|c|d|value=r|yes=good|no=bad}} could give bad

So, what do you think about that? Could it be done? Maiō T. (talk) 17:32, 6 November 2025 (UTC)[reply]

That sounds like an easy and useful enhancement, assuming you have some use-cases in mind. It would be analogous to a long-standing feature of {{yesno}}. DMacks (talk) 17:38, 6 November 2025 (UTC)[reply]
Or we could avoid adding complexity to a simple module when {{yesno}} already exists:
{{yesno|{{#invoke:If any equal|main|a|b|c|d|value=c}}|yes=output for yes|no=output for no}} → output for yes
{{yesno|{{#invoke:If any equal|main|a|b|c|d|value=r}}|yes=output for yes|no=output for no}} → output for no
Using {{yesno}}, which has a variety of fun features already, adds just ten total characters to a hypothetical modified module. – Jonesey95 (talk) 20:32, 6 November 2025 (UTC)[reply]
Although it doubles or triples the WP:PEIS. Adding the functionality to the module would add less than 80 characters. --Ahecht (TALK
PAGE) 21:27, 6 November 2025 (UTC)[reply]
Module:Yesno existing:
Izno (talk) 21:53, 6 November 2025 (UTC)[reply]

Maybe we could create a new little template that would call the Module:If any equal. I imagine it like this: The first two parameters would be for determining the value of yes and no, followed by the other parameters. For example:
{{New-template-name|good|bad|Jonesey95|Ahecht|DMacks|Izno}}. 😉 Maiō T. (talk) 13:08, 8 November 2025 (UTC)[reply]

@Maiō T. That's essentially what Jonesey95 proposed above, but there's no need for a new template since {{yesno}} exists. --Ahecht (TALK
PAGE) 19:52, 12 November 2025 (UTC)[reply]

Road maps seem broken

[edit]
Moved to Template talk:Infobox road § Road maps seem broken
 – --Redrose64 🌹 (talk) 09:33, 8 November 2025 (UTC)[reply]

Image browsing test on mobile: entering Phase 1

[edit]

Hi everyone,

I’m Eliza Blackorby from the WMF’s Reader Growth team. A few weeks ago, WMF posted here about declining pageviews to Wikipedia – that’s what our team is working to address. We want both new and existing readers to return to Wikipedia because they find it a compelling place to learn. Over and over, a top request from readers is that they wish for “more images/photos” on Wikipedia, as demonstrated in surveys of global internet users. As a result, we want to show readers more images and display images in a more enriching way. Our hypothesis is that by making it easier to explore images already in articles, readers may find Wikipedia more engaging and return more frequently, with some of them eventually becoming editors.

What idea are we testing?

A few weeks ago we shared how we were considering a test of a sliding gallery view of all an article’s images at the top of the article that readers can then click to jump to that part of an article, inspired by Community Wishlist requests for improved discovery of media. We’ve since built a prototype, called Image browsing, that takes your feedback into account. You can try it by adding the url parameter ?imageBrowsing=1 to the end of any URL on the mobile view for enwiki. For example: https://en.wikipedia.org/wiki/Hummingbird?useskin=minerva&useformat=mobile&imageBrowsing=1  

What stage is this project in?

Our initial discussions with you constituted phase 0 of our reader experiment phases. We now want to enter phase 1: launching a small test with an early version of these ideas. It’s not yet clear whether this feature will be an improvement for readers, so we want to test it to determine whether to proceed into Phase 2: building a feature.  

What is the timeline?

We will A/B test this version with 0.05% of mobile readers on English Wikipedia starting the week of November 17 and ending four weeks later on December 17.

What does the experiment include?

This test will include a gallery at the top of an article that shows all the article’s images. The feature will be available for any article that has three or more images. Tapping on any image will open a browsing experience with the image enlarged, its caption, and options to view it on Commons (if available). Readers will see images and paragraph-excerpts from the article itself in the gallery and will be able to switch back to where the image appears within the article. At the bottom of this experience, readers will be able to view images selected by editors for the same article in other Wikipedias.

Screenshots:

Below are three separate screenshots of the test's different aspects to demonstrate the experience when a user clicks through and scrolls.

Example screenshot of how the Benthos article would appear in the image browsing test.

What input are we looking for from you?

While this round of the experiment is focused on simply testing if readers are interested in image browsing, there are still issues that would need to be resolved before developing this into a feature, including those around bad images and cross-wiki images as it relates to conflicting policies or cultural sensitivities. We invite you to help us continue to identify concerns like this. In the collapsed box you'll find a summary of the feedback and risks we heard from you in September, along with how we're thinking through them.

Since this work is still experimental, we expect to refine and adjust this idea based on your feedback. We’d love for you to try the feature on a few articles using the url parameter above. Your input will help us decide how to improve it if we move forward after the test. Also, stay tuned for the test results. We’ll share them with you and discuss together whether it makes sense to continue with this idea into Phase 2, and if so, what additional changes we will need to make before proceeding. Please share your thoughts and questions here, and for more info, see our project page.

Thank you! EBlackorby-WMF (talk) 22:38, 6 November 2025 (UTC)[reply]

When I go to the hummingbird page and click on the article image that has the caption "Adult male bee hummingbird, Cuba", I am taken to a page that contains the image, along with credit and a link to the license information. It is my understanding that CC licenses require that information to be linked to and displayed when the image is clicked. When I click on the same image in the slide show, I do not see any licensing information. This may be a problem.
The other obvious issue, of course, is that the images are displayed without their captions until you click them individually. As User:DarthVader might have said, I find your lack of context disturbing. – Jonesey95 (talk) 01:21, 7 November 2025 (UTC)[reply]
Hi @Jonesey95, thanks so much for flagging. You raise some important points. We've taken them into conversation with colleagues in the Legal department, and agree that we would need to address them if we end up building a future feature out of this experiment. I'll follow up more here if/when that happens. EBlackorby-WMF (talk) 22:31, 7 November 2025 (UTC)[reply]
Is it really OK with the legal department to knowingly violate the terms of CC-BY-SA, even on an experimental basis? I'm not a lawyer, so I don't know if it really is a violation, but it doesn't seem like something that would normally be allowed here at en.WP. If someone tried to roll out a template that behaved in this way, I think it might get some license-related pushback. – Jonesey95 (talk) 00:15, 8 November 2025 (UTC)[reply]
@Jonesey95 I disagree that there is any semblance of a violation here. There is a prominently displayed link to commons off to the side, which imo counts as attribution. I also disagree that if a editor made a similar choice, they would get any license related pushback. The practice of using images as background and then overlaying attribtuion text is pretty common across userpages (a example of this would be Sigma's userpage) Sohom (talk) 13:30, 11 November 2025 (UTC)[reply]
The Creative Commons licences do not require a specific method for providing attribution. The licence states that it may be reasonable to meet the attribution requirement by providing a link to a page that has all the required information. Since clicking on a gallery image displays an expanded image with an overlaid link to the attribution information, personally I feel this is a reasonable approach to provide attribution. isaacl (talk) 06:02, 8 November 2025 (UTC)[reply]
I find the workflow to jump to the section where the image is located to be awkward. After swiping through the gallery at the top of the article, I select an image, and see an expanded image at the top of the page, but there's no link to the section. I have to scroll down through the list of images (with the little summaries) until I reach the image I originally selected, and then I can select "View in article". I think it would be better if the little summary and "View in article" link appeared directly below the expanded image, so the context and jump link would be immediately available. (I think it should still appear within the comprehensive list as well.) isaacl (talk) 06:11, 8 November 2025 (UTC)[reply]
I think the general idea here is good. If we can increase the visibility of media in a way that enhances the usefulness of Wikipedia to readers, then I'm all for it. The current implementation also seems to be decent, although some kinks may have to be worked out as pointed out above.
Even if directly pulling images from Commons is ruled out, what about simply providing a link to the Commons category? We already have {{Commonscat}}, so I don't see how this would be controversial. The link could look something like this:
 More from Wikimedia Commons
It could appear when you get to the end of the "Media from other projects" view. ~2025-32228-23 (talk) 00:08, 9 November 2025 (UTC)[reply]

I want to contribute with my IP Address

[edit]

I do not like the temporary account thing, I do not mind my IP being public. I don't want this forced temp account. I'm just used to what it used to be before. ~2025-31874-31 (talk) 13:23, 7 November 2025 (UTC)[reply]

@~2025-31874-31: It wasn't our decision, it was imposed upon us a few days ago, and we were given several months notice that it would happen. We can't change it back, even if we wanted to. More at mw:Trust and Safety Product/Temporary Accounts and its subpages (see the tabs from Overview to FAQ). --Redrose64 🌹 (talk) 14:12, 7 November 2025 (UTC)[reply]
Some notes: Your temporary account's IP information remains visible for users with sufficient permissions. If you don't change your IP address and don't clear your cookies, your temporary account also won't change. Izno (talk) 18:11, 7 November 2025 (UTC)[reply]
It’s not quite that simple. If you edit from different devices (eg an iPad and a laptop) the edits from each device will have a different temporary account because each device has its own set of cookies. Also, temporary accounts expire after 90 days so the next time you edit after then, you’ll get a new temporary account. Neiltonks (talk) 18:55, 7 November 2025 (UTC)[reply]
Yes, that's also true. Izno (talk) 18:57, 7 November 2025 (UTC)[reply]

Is this script safe

[edit]

I got a rednotice on my JS page about this script I was installing and said scripts on those pages can compromise accounts and it told me if I had doubts to ask here about it was safe so I wanted to ask is this safe User:Qwerfjkl/scripts/CFDlister(and if it is safe do I need to do anything about the red warning notice or just leave it.) GothicGolem29 (Talk) 17:35, 7 November 2025 (UTC)[reply]

@GothicGolem29: It's a standard warning which is always shown. The script looks safe. PrimeHunter (talk) 17:56, 7 November 2025 (UTC)[reply]
Ok so it is ok to leave on. Ok thanks appreciate it. GothicGolem29 (Talk) 17:57, 7 November 2025 (UTC)[reply]
@GothicGolem29: Assuming that you mean this text, displayed on a pink background, then: what PrimeHunter said. If not, what was the exact message? --Redrose64 🌹 (talk) 18:13, 7 November 2025 (UTC)[reply]
Yeah that is the warning I received on the page. GothicGolem29 (Talk) 18:21, 7 November 2025 (UTC)[reply]

Width converter

[edit]

Is there any module that converts % width to px width? sapphaline (talk) 19:22, 7 November 2025 (UTC)[reply]

Why...? %s are going to be resolution dependent in a way that px definitely are not. Izno (talk) 19:26, 7 November 2025 (UTC)[reply]
% width doesn't (yet) work with module:svg, so you can't convert graphs like Template:Bar percent to SVGs. sapphaline (talk) 19:32, 7 November 2025 (UTC)[reply]
Short answer: no. Why not? Because to make that calculation - say, converting 50% into n pixels, you first need to know the width of the space that you're fitting it into. But that depends upon many factors - for instance, what is the width of somebody else's screen? Nobody knows for sure, except the person actually viewing that screen. I could go on, but I won't. I've made this point so many times that I really should make it into a userspace essay. --Redrose64 🌹 (talk) 19:39, 7 November 2025 (UTC)[reply]
[edit]

Hello. Since temporary accounts are now forced on users, a default skin is also applied that's problematic to me: the "Tools" bar at right should be at the left and cannot be folded without scripts enabled, for instance. TAs apparently don't have skin preferences. I could use special browser-side tools to alter the skin, but considering that useskin as part of a URL corrects those issues, I thought that if there was a cookie equivalent I could configure, it would be ideal. Searching the VPT archives I found nothing related. Does this feature exist, if not, would it be a good suggestion candidate? Thanks. ~2025-31363-35 (talk) 20:30, 7 November 2025 (UTC)[reply]

IPs also don't have skin preferences, so this has not changed with TAs. There is no supported technical way to change the skin. I know of at least one browser extension lying around that will forcibly add useskin to your URL which you may seek for yourself.
Supporting hiding the sidebars in some remembered form for unregistered users is phab:T366999. Izno (talk) 20:36, 7 November 2025 (UTC)[reply]
Thanks, there was no such issue with IP editing before November 4, though. There was a working "..." menu at the top-right that could be clicked to get access to "contributions", etc. I suspect that the default skin was changed, possibly to accomodate a new TA-specific feature... (edit): Oh I did use custom local CSS to hide the right bar which apparently had buttons to resize text, but then the now absent working menu provided what was needed (I have disabled my Stylus entry for now to have access to those options, so the "Tools" bar is now "in the way"). ~2025-31363-35 (talk) 20:53, 7 November 2025 (UTC)[reply]
Do you have the same problems if you use a different browser where you don't have any custom CSS set up? – Jonesey95 (talk) 14:39, 8 November 2025 (UTC)[reply]
With a virgin profile, without having edited yet, so not under a TA profile, what I see is what I used to, the bar at right is an "appearance" one (the one my custom CSS was meant to hide, I found it useless to me and to limit the text width, considering that I use multiple vertical windows in a 16:9 screen rather than a fullscreen one, the article text was now cramped between two bars). The table of contents is in a "contents" bar at left. The "..." menu is gone because legacy IP editing now being disabled, there's no "my contributions", etc. So then I did a test edit in the sandbox to create a TA profile. The appearence changes a little, there's now a menu at top for the notifications and contributions, a bar with the name of the TA, as expected (the same as above). There also is now both "appearance" and "tools" in the bar at right, which are suboptimal there as above. But the virgin profile also has scripts enabled and so I can optionally manually hide each away, then the right bar disappears. While that's nice, it won't be my common use case. This means that I'll still need to use custom CSS (or a DOM altering local script) to move the right bar away. For now I've also noticed that if I zoom the text a bit the bar floats away falling somewhere at the left, that's some sort of compromise as well. Thanks again, ~2025-31363-35 (talk) 22:56, 9 November 2025 (UTC)[reply]

Site slow, care to share?

[edit]

Having trouble looking at articles, histories, and edits are not saving. Multiple browsers. Also wmcloud and maybe toolforge have been slow for days. Anybody in the know care to share what's going on? Abductive (reasoning) 20:58, 7 November 2025 (UTC)[reply]

@Abductive Might be on your end ? Have you tried browsing from different devices and/or different internet providers ? —TheDJ (talk • contribs) 10:57, 8 November 2025 (UTC)[reply]
FWIW, my bot had a bunch of minor problems (suggesting lag) this morning at about 03:00 UTC. —scs (talk) 13:19, 8 November 2025 (UTC)[reply]
See FAQ, last item. Nardog (talk) 15:51, 8 November 2025 (UTC)[reply]

Template:NUMBEROF broken

[edit]

It seems that, at the moment, most of the values outputted by the template is "-1". See the article Wikipedia's infobox. The {{format price}} template as used on the infobox cannot parse the output of numberof because it is negative. The data sources as listed at the template's documentation seem to be intact. Anyone know what is going on here? Justjourney (talk | contribs) 03:22, 8 November 2025 (UTC)[reply]

I'm investigating. Strange. Johnuniq (talk) 03:38, 8 November 2025 (UTC)[reply]
No idea what happened because some debugging seemed to show the data was at enwiki while the problem persisted. For the record, {{NUMBEROF|articles|fr}} was giving -1 here (that's the error return if frwiki is not found in the data). Anyway, the problem has gone away. The data comes from Commons (c:Data:Wikipedia_statistics/data.tab) so some kind of caching problem. Johnuniq (talk) 04:11, 8 November 2025 (UTC)[reply]
Again for the record, the problem was that the data was corrupted at the Commons link above due to some kind of problem with the bot that updates the data. The corruption was then fixed. Johnuniq (talk) 04:16, 8 November 2025 (UTC)[reply]
Thanks, John. I suspect the corruption originated with the MW API (can't replicate). Possibly API:SiteMatrix returned missing sites. I just added a sanity check on the JSON size, which will skip and log if this happens again. -- GreenC 05:12, 8 November 2025 (UTC)[reply]
In case you didn't notice, the statistics data had entries with, for example, "fr" in the first column. The fix restored "fr.wikipedia". Johnuniq (talk) 05:46, 8 November 2025 (UTC)[reply]
This is one of the more strange bugs I've come across. There are fingerprints in multiple places and logs that show what happened, but they make no sense, impossibilities. Everything has an explanation, this one is a mystery. I don't think it's the bot code but something on the MW side, like GIGO or backend with editing. I've added additional logging in case it happens again. -- GreenC 16:24, 8 November 2025 (UTC)[reply]

Discussion of default rendering of shapes/lines in Template:Infobox mapframe

[edit]

We're discussing how to handle the rendering of shapes/lines in Template:Infobox mapframe, given that OSM data is unreliable. You're welcome to join in the discussion. — hike395 (talk) 09:49, 8 November 2025 (UTC)[reply]

Temporary Accounts vs the API?

[edit]

If I edit via the API, how does that interact with temporary accounts? There's (probably) no cookie management going on, so does a new TA get created on every API call? RoySmith (talk) 13:44, 9 November 2025 (UTC)[reply]

Not on every API call. But if the API process isn't handling cookies (and isn't logged in with OAuth or the like), then yes, they'd get a new TA created on every edit or other action that triggers creation of a temp account. And probably quickly hit the daily temp-account creation rate limit. Anomie⚔ 15:27, 9 November 2025 (UTC)[reply]
I know that most client-side HTTP libraries have the ability to handle cookies, but many real-world application don't set that up. For example, the popular requests package for python only handles cookies if you go to the trouble to create a session and people often don't bother. And even if you did, if your client is multi-threaded (or multi-process), each thread will have its own session and thus its own cookie jar.
So, what happens when you hit the rate limit? Do API calls just start failing? RoySmith (talk) 15:55, 9 November 2025 (UTC)[reply]
Do API calls just start failing? I'd think so, but I haven't tested it. 🤷 But really, any API-using thing that's making logged actions shouldn't be doing it while logged out anyway, and could probably be blocked per WP:Bot policy even if it is properly managing sessions. Anomie⚔ 16:06, 9 November 2025 (UTC)[reply]
That may be true. But, as I understand it, TA's are created for read requests as well. Surely those shouldn't fail. RoySmith (talk) 16:09, 9 November 2025 (UTC)[reply]
Hmmm, that doesn't appear to be true. Experimenting a bit, it does indeed look like the TA only gets created when I make an edit. RoySmith (talk) 18:20, 9 November 2025 (UTC)[reply]
@RoySmith I haven't tested it, but I believe that temp account are only created on their home wiki on first edit, but are created on subsequent wikis on read requests. --Ahecht (TALK
PAGE) 15:04, 10 November 2025 (UTC)[reply]
Yes, but that's not a true account creation, just an autocreate, same as with named accounts. And you'd need to have cookies to do that anyway. There are some actions that can cause MediaWiki to reserve a temporary account name (like previewing an edit) but not fully create the temporary account, but I'm not sure any of those apply to the API. Unless you use the acquiretempusername API, of course. AntiCompositeNumber (they/them) (talk) 00:41, 11 November 2025 (UTC)[reply]

Iframes from OWID (Part 2)

[edit]

Hey All. We have rolled out one method of interactive visualization for OWID based on an all Commons svg approach. You can see the integration of these graphs here.

With this technique we are able to bring over limited functionality of the OWID "grapher visualizations", we however are unable to support their newer and more complex explorer visualizations which one can see here MDWiki:WikiProjectMed:OWID_popup#Explorer.

Wikimedia Foundation and Our World in Data technical staff are interested in meeting with interested Wikipedians to pitch possible usage to this community. We do not have a date set as first I am wanting to collect interest for such a discussion / plus concerns folks have. The WMF supports its use and has a signed MOU and are happy from a security perspective and license perspective.

The final decision of course is up to us. Doc James (talk · contribs · email) 19:33, 10 November 2025 (UTC)[reply]

Tech News: 2025-46

[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

Screenshot of the visual improvements made on talk pages
Example of a talk page with the new design, in French.
  • Starting November 12, users will see a change in the appearance of talk pages on some Wikipedias. Almost all wikis have received this design change; English Wikipedia will get these changes later. You can read more on Diff. Users can opt out of these changes in their user preferences in "Show discussion activity". [10]
  • MediaWiki can now display a page indicator automatically while a page is protected. This feature is disabled by default. It can be enabled by community request. [11]
  • Using the "Show preview" or "Show changes" buttons in the wikitext editor will now carry over certain URL parameters like 'useskin', 'uselang' and 'section'. This update also fixes an issue where, if the browser crashed while previewing an edit to a single section, saving this edit could overwrite the entire page with just that section’s content. [12][13][14]
  • Wikivoyage wikis can use colored map markers in the article text. The text of these markers will now be shown in contrasting black or white color, instead of always being white. Local workarounds for the problem can be removed. [15]
  • The Activity tab in the Wikipedia Android app is now available for all users. The new tab offers personalized insights into reading, editing, and donation activity, while simplifying navigation and making app use more engaging. [16]
  • The Reader Growth team is launching an experiment called "Image browsing" to test how to make it easier for readers to browse and discover images on Wikipedia articles. This experiment, a mobile-only A/B test, will go live on English Wikipedia in the week of November 17 and will run for four weeks, affecting 0.05% of users on English wiki. The test launched on November 3 on Arabic, Chinese, French, Indonesian, and Vietnamese wikis, affecting up to 10% of users on those wikis. [17]
  • Recurrent item View all 27 community-submitted tasks that were resolved last week. For example the inability to lock accounts on mobile sites has been fixed. [18]

Updates for technical contributors

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 20:35, 10 November 2025 (UTC)[reply]

MediaWiki can now display a page indicator automatically while a page is protected. This feature is disabled by default. It can be enabled by community request.
Would this feature be useful? — Malcolmxl5 (talk) 01:14, 11 November 2025 (UTC)[reply]
@Malcolmxl5 Enwiki already has a pretty extensive version of this of its own. It might be possible to convert that, but we first need to analyze how much functional overlap there is (or not). It’s not a very high priority, it is especially useful for wikis that don’t want to make and maintain their own version of a protection indicator. —TheDJ (talk • contribs) 07:25, 11 November 2025 (UTC)[reply]
@Malcolmxl5 and TheDJ: User FaviFake has started a related discussion at Wikipedia:Village pump (proposals) § Should we adopt the new "protection padlock" feature?. ~2025-32085-07 (talk) 00:15, 12 November 2025 (UTC)[reply]

Help with admin highlighter script, please?

[edit]

Hello techies. I'm using User:Amalthea/userhighlighter.js, in a way that leaves the background color of admins' names transparent and instead adds a little crown symbol after them. Please see my User:Bishonen/common.css, right at the top. I love that silly effect, but the script seems to have just stopped working, and Amalthea has left the project. On the script's page, near the top, I find the advice "Consider using User:Theopolisme/Scripts/adminhighlighter.js instead, a better version of this script". Maybe I should do just that, but I have no idea how to modify it to get my desired effect, i. e. the effect that Amalthea's script used to give. (Theopolisme has also left the project.) Should I uninstall Amalthea's script, install Theopolisme's, and attempt to give it the same specifications as Amalthea's script now has for me? I'm a little scared of fiddling with it and making a mess, incompetent as I am. Any help, please? And might there be a third script, more up-to-date and actively maintained, that does what I want? Bishonen | tålk 03:52, 11 November 2025 (UTC).[reply]

Installing Theo's script and using this in your common.css:
body #globalWrapper .userhighlighter_sysop.userhighlighter_sysop {background-color:transparent !important;}
.userhighlighter_sysop.userhighlighter_sysop:after{content:"♔" !important;}
...worked for me. Writ Keeper ⚇♔ 04:39, 11 November 2025 (UTC)[reply]
Thanks, Writ! I see that the little crown is back now. Should I still do it, do you think? (On the principle that Theopolisme's script is supposed to be better?) Or leave well enough alone? Bishonen | tålk 07:40, 11 November 2025 (UTC).[reply]
Eh. Switching over isn't a bad idea, but honestly, I'm of the "if it ain't (currently) broken, don't fix it" opinion. Might be useful to keep this CSS in 'zilla's back pocket, in case of future need. Writ Keeper ⚇♔ 13:47, 11 November 2025 (UTC)[reply]
I agree with you completely. Thanks, Writ. Bishonen | tålk 17:02, 11 November 2025 (UTC).[reply]

"Cannot access the database"

[edit]
Tracked in Phabricator
Task T409800

A few hours ago, trying to view a page, I received a message: Sorry! This site is experiencing technical difficulties, in large letters.

It then displayed, in medium-size letters, "Try waiting a few minutes and refreshing", and,

(Cannot access the database: Cannot access the database: Database servers in cluster31 are overloaded. In order to protect application servers, the circuit breaking to databases of this section have been activated. Please try again a few seconds.)

I waited a few minutes, as advised, and then was able to view the pages normally.

My question is whether this is any cause for special concern, or whether the system is responding as designed to a maximum load. If this is a normal response to a peak load, I will ignore it.

Robert McClenon (talk) 06:16, 11 November 2025 (UTC)[reply]

@Robert McClenon This is a normal response when the database cannot handle the traffic. It shouldn't generally happen, but sometimes it does. Maybe @Ladsgroup can find what triggered it. —TheDJ (talk • contribs) 07:19, 11 November 2025 (UTC)[reply]
@Robert McClenon This morning we had a massive network outage leading to loss of a whole row which overloaded practically everything and triggered our circuit breakers (they intentionally kill a certain subset of requests to try to keep the services up in general). It did recover in ten minutes. We are still investigating the root cause of that network incident and I will try to update here later. Thanks to theDJ for the ping. Ladsgroupoverleg 11:48, 11 November 2025 (UTC)[reply]

Does Wikipedia support inline prefers-color-scheme?

[edit]
Moved from Wikipedia:Village pump (miscellaneous)

I've moved this here as suggested by WhatamIdoing:

Exactly what the question says. Does wikitext support this for CSS? My userpage uses a lot of custom CSS and has a bunch of contrast issues depending on which colour mode a user is on which I need to fix by creating overprecise CSS.

thetechie@enwiki (she/they | talk) 05:04, 12 November 2025 (UTC)[reply]

Wikitext has little support for CSS that requires media queries (though I note the existence of CSS light-dark() which might work?). What can be done regardless is for you to make a Template:TemplateStyles sandbox (see WP:TemplateStyles) and then move it to a subpage of your user page and then you have access to all the media queries you might like. Izno (talk) 05:28, 12 November 2025 (UTC)[reply]
You can make dark mode-specific styles using html.skin-theme-clientpref-night, e.g. 
html.skin-theme-clientpref-night <var>.my-userpage</var> {
  background:#000;
  color:#fff;
  font-family:monospace,monospace
}
sapphaline (talk) 11:44, 12 November 2025 (UTC)[reply]
Btw, could you specify a custom color for links on your userpage? They're literally unreadable with Monobook. sapphaline (talk) 11:49, 12 November 2025 (UTC)[reply]
Not just MonoBook - the problem happens with all skins, unless dark mode is forced. --Redrose64 🌹 (talk) 06:51, 13 November 2025 (UTC)[reply]
An additional media query is needed to support the "follow OS" option (see mw:Recommendations for night mode compatibility on Wikimedia wikis § Target night mode using standard media query as well as HTML classes). Assuming the changes are tweaks to the appearance rather than a completely different layout, the simplest approach is to use CSS custom properties and redefine them for the corresponding mode. Here's a brief example extracted from User:Isaacl/style/discussion-threads.css:
#mw-content-text
{
	--discussion-threads-style-border-colour1: rgb(85%, 85%, 100%);               /* left border colour */
}

/* dark mode */

@media screen {
	:where(html.skin-theme-clientpref-night) #mw-content-text
	{
		--discussion-threads-style-border-colour1: rgb(5%, 5%, 30%);
    }
}  /* user-selected dark colour scheme */

@media screen and (prefers-color-scheme: dark) {
	:where(html.skin-theme-clientpref-os) #mw-content-text
	{
		--discussion-threads-style-border-colour1: rgb(5%, 5%, 30%);
    }
}  /* OS-selected dark colour scheme */

#mw-content-text /* ... other selectors ... */
{
	border-left: 5px solid var(--discussion-threads-style-border-colour1);
}
isaacl (talk) 17:44, 12 November 2025 (UTC)[reply]
(TemplateStyles cannot set CSS variables.) Izno (talk) 18:00, 12 November 2025 (UTC)[reply]
Thanks; I forgot about phab:T320322. Unfortunately that means rules have to be duplicated three times to set different CSS property values for different viewing modes. isaacl (talk) 18:31, 12 November 2025 (UTC)[reply]

Override default keyboard shortcuts

[edit]
Moved from Wikipedia:Village pump (proposals) § Override default keyboard shortcuts
 – jlwoodwa (talk) 20:06, 12 November 2025 (UTC)[reply]

I have a user script (User:Zackmann08/indent.js) that indents infobox code. Works great! I have it setup so that when I use the access keys + I it runs. The issue is that this also flag the edit as minor... Is there something I can do to override this? I.E. so that my code runs but the edit does NOT get flagged as minor? Zackmann (Talk to me/What I been doing) 19:36, 12 November 2025 (UTC)[reply]

Zackmann08, I'm not massively confident, but I think event.stopPropagation(); should do it (add after event.preventDefault();). — Qwerfjkltalk 21:39, 12 November 2025 (UTC)[reply]
User:Qwerfjkl sadly that didn't work. Appreciate the suggestion though! --Zackmann (Talk to me/What I been doing) 21:50, 12 November 2025 (UTC)[reply]
Zackmann08, maybe just remove the accesskey attribute at the start of the script? Something like
$("#wpMinoredit").removeAttr("accesskey");
— Qwerfjkltalk 22:11, 12 November 2025 (UTC)[reply]
User:Qwerfjkl ding ding ding! We have a winner!!! Thank you! Zackmann (Talk to me/What I been doing) 22:29, 12 November 2025 (UTC)[reply]

Testing reading lists on desktop

[edit]

Hi everyone,

This is Eliza from the Reader Experience team at the Wikimedia Foundation. The team’s focus is on making Wikipedia a more engaging and valuable place for our existing readers, encouraging them to come back to explore and learn more. We see this work as a part of addressing the decline in pageviews on Wikipedia we’ve talked about in the past. You may have recently seen my post about the Reader Growth team’s image browsing experiment. This is a separate idea focused on a different part of the reading experience.

As part of our explorations into ways to encourage readers to be more active in their experience and return to Wikipedia more frequently, next week the team will be launching a test of an early-stage version of what could become a “reading list” feature on the desktop and mobile web browser experience. This feature, which is already on the Wikipedia mobile apps, would allow readers to save articles they want to come back to later. Articles would be organized in a list that will be accessible in the top-right navigation for logged-in readers.

Why are we working on this?

We think that when readers are more active in their reading experience, they could become closer to making their first edit. We first want to explore the simplest approach to curation – allowing readers to save an article for reading later. Reading lists and saved tabs are a couple of the most popular features on the Wikipedia Android and iOS apps. Readers who use them frequently ask to sync their saved articles to their desktop reading experience.

The test is designed to help us understand if readers are interested in saving articles to read later, and whether they use these articles after they’ve saved them. The feature will be available to a small portion of randomly selected readers who have accounts with zero edits and nothing saved to their watchlists on English, Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias, accounting for about 15% of all logged-in users on these wikis.

What stage is this project in?

We are currently in Phase 1: launching a small test with an early version of these ideas. It’s not yet clear whether this feature will be an improvement for readers, so we want to test it to determine whether to proceed into Phase 2, building a feature. After the A/B test, we’ll come back here to discuss the results with you and decide together whether to proceed.

Because reading lists are an established feature on the Apps, we used learnings from the Apps team as well as informal conversations at in-person events and on Discord to serve as our research and background for Phase 0.

What is the timeline?

We will test the prototype starting the week of November 17. The test will run for 4 weeks and we will stop collecting data on December 17; however, the feature will still be accessible to the users who received it, so that they don’t lose their saved articles.

What are we testing?

The main capabilities that will be in the feature are:

  • Informing readers that the feature is available and indicating where to click to save an article and where to click to view the list of saved articles
  • Allowing readers to save articles to a private list for reading later
  • Allowing readers to access their list and remove articles that are no longer relevant to them

We will measure how often people are using the new feature and whether this has any positive effect on the number of pages readers open per session. If this test shows positive results on these two metrics, we will then discuss adding additional functionality, such as the ability to sync lists with the apps, creating multiple custom lists, and more.

Mocks:

Here is an example of what a user in the experiment would see when they save an article:

This is an example of what a user in the reading lists desktop experiment would see when they go to save the "Dog" article.

Here is also an example of what the saved page feature looks like on the app, where it is already live and used by readers:

Reading-list-share-14

What input are we looking for from you?

  • Would you as an editor find reading lists personally useful, either for your reading or editing work? If so, how?
  • If the experiment is successful, we will need to ensure designs avoid confusion between reading lists and watch lists. For this test, we’re only including logged-in users who don’t use the watchstar. However, if we decide to proceed with this idea in the future, we want editors as well as readers to be able to use both reading lists and watchlists.
    • Icons: The icons for reading lists and watchlists are similar. What is your opinion on the current icon for watchlist? Do you think it could be improved and if yes, how?
    • Placement: In the experiment, users don’t see the buttons for reading lists and watchlist next to each other, but instead the watchlist button is in the tools menu. Do you have any thoughts about that placement?
  • Have you used reading list/saved pages/playlist type features before, whether on the Wikimedia app or on other websites? If so, what types of functionality do you think could be useful for readers?

For other details, see our project page. Please share your thoughts here. Thank you! EBlackorby-WMF (talk) 21:16, 12 November 2025 (UTC)[reply]

Newly added hatnote doesn't appear in mobile website

[edit]

I just added a hatnote to Lexiphanes, and found that no hatnote appears on the page when viewed in mobile form through a mobile browser (I tried it on iOS through both the Safari and Firefox apps; Firefox showed it only with the "desktop site" option enabled), though it shows up normally on a regular computer (in my case Firefox 144.0 on Windows 10). I have no idea what is causing this problem. - LaetusStudiis (talk) 23:17, 12 November 2025 (UTC) This was the result of my own mistake in placing the note, as User:PrimeHunter said. - LaetusStudiis (talk) 03:00, 13 November 2025 (UTC)[reply]

@LaetusStudiis: The hatnote is displayed below the Taxobox in the mobile version if the window is narrow, both in a mobile and desktop browser. See mw:Reading/Web/Projects/Lead Paragraph Move. The mobile version apparently makes a bad guess at what to move in this example. PrimeHunter (talk) 00:02, 13 November 2025 (UTC)[reply]
@LaetusStudiis: I looked again and it actually happened because you placed the hatnote after the taxobox in the code. The mobile version didn't do anything wrong. I have moved the hatnote to the top where it belongs per MOS:ORDER. PrimeHunter (talk) 00:37, 13 November 2025 (UTC)[reply]

Road coordinates

[edit]

The coordinates at A3055 road were wrong, so I corrected them here, as far as it is possible to locate a road by single coordinates. When I click through from the new numeric coordinates at the top right of the article to the Google map, the location is OK. However, the pin in the "infobox" does not seem to have changed correspondingly. So where is the "infobox" getting its coordinates? I can't see where else in the article they are coming from. ITookSomePhotos (talk) 23:27, 12 November 2025 (UTC)[reply]

@ITookSomePhotos: The coordinates are pulled from Wikidata. Look for "Wikidata item" on the article. The location depends on your skin. It may be in the left pane under "In other projcets" or on a dropdown "Tools" menu at the top right. The link goes to A3055 road (Q4649116). PrimeHunter (talk) 00:41, 13 November 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1321895220"