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.

Should "Pages transcluded onto the current version of this page" show up when editing a section?

[edit]

Special:Edit/Earth shows a big list of transclusion under the editor, starting with Planet Earth and ending with Module:Yesno, but edit with section=0 doesn't show the list at all. Was this always the case for editing a section of a page, or did something break recently? I don't look at this list often enough to remember if it was there or not when editing a section.

Both whole-article edit and section-edit show the other two lists: "Wikidata entities used in this page" and "This page is a member of 27 hidden categories" though. —⁠andrybak (talk) 16:26, 1 August 2025 (UTC)[reply]

I see a list called "Templates used in this preview (help):" starting and ending as you describe above in both cases. Johnjbarton (talk) 16:40, 1 August 2025 (UTC)[reply]
Ahh, the templates are shown only in preview, thank you. When exactly the preview gets shown depends on user's settings in Preferences → Editing → Preview. —⁠andrybak (talk) 16:49, 1 August 2025 (UTC)[reply]
I think it has always been preview-only for sections, and then it says "Templates used in this preview". MediaWiki doesn't know which templates are transcluded by the section until you preview it. PrimeHunter (talk) 18:42, 1 August 2025 (UTC)[reply]
Now that I read the replies, I think I always knew it. Maybe I wasn't pressing "Show preview" or something. Accesskeys can be wonky sometimes... Or just had a brain fart. —⁠andrybak (talk) 19:58, 3 August 2025 (UTC)[reply]
(edit conflict)
Searching for templates in the wikitext editor now (annoyingly) opens the collapsed lists below the main edit window. Searching for other text will also open those lists if the text being sought can be found in them. Is that what you're seeing? I asked if there were some way to disable that and got no response; see Wikipedia:Village pump (technical)/Archive 222 § Tech News: 2025-27.
—Trappist the monk (talk) 16:51, 1 August 2025 (UTC)[reply]
Hmm. In the HTML source code on the edit pages, I see HTML attribute hidden=hidden in Firefox, but hidden=until-found in Chromium (at least when logged out).
It might be that MediaWiki thinks that Firefox doesn't support it. There are tickets in Mozilla's bugtracker about hidden=until-found, but I can't figure out if Firefox actually supposed to support it or not, because I don't know how to search well on Bugzilla among the tickets about the "Find Toolbar". —⁠andrybak (talk) 17:33, 1 August 2025 (UTC)[reply]
Firefox added support for hidden=until-found very recently, in version 139 [1]. You might not have it yet. Matma Rex talk 18:20, 1 August 2025 (UTC)[reply]
@Trappist the monk: An extremely crude workaround to not display the "Templates used in this preview" list (which is super annoying now that it expands of its own volition, making it difficult to go directly to the editing box after previewing - because the edit box is no longer at the bottom, it's often several pages up from the bottom) is to add the following line to your common.css:
.templatesUsed {display: none;}
This kludge is okay for me because I never want to see that list. Someone who works with css regularly can no doubt suggest a more elegant solution. --Worldbruce (talk) 23:40, 6 August 2025 (UTC)[reply]
Yep, that is a kludge. But, it does prevent searches of the templates list and for that I am grateful; thank you. A variant can also prevent searches of the wikidata entities list, hidden categories list, and parser profile data: 
.wikibase-entity-usage,
.templatesUsed,
.hiddencats,
.limitreport {
	display: none
}
I've elected to hide wikidata, templates, and categories. If I need them, I can open the page in an incognito browser window. It would be nice if these lists would just stay collapsed until actually uncollapsed with a mouse click.
—Trappist the monk (talk) 20:08, 7 August 2025 (UTC)[reply]
It looks like the lists are supposed to remember whether they were last opened or closed, and try to stay that way. However, this may interact with the feature (recently enabled for Firefox, maybe around a bit longer for Chrome-based browsers) that opens a collapsed section if an in-browser search would find a match inside it to unexpectedly change the saved state to "open". Anomie⚔ 20:23, 7 August 2025 (UTC)[reply]
So is this a Firefox feature, or a MediaWiki feature? --Redrose64 🌹 (talk) 07:46, 8 August 2025 (UTC)[reply]
It's mostly a browser feature, but MediaWiki was changed to use the attributes to make use of the feature. You can read more about the browser feature at MDN, and T327893 for the request to enable it. Anomie⚔ 13:26, 8 August 2025 (UTC)[reply]

Logging in with Firefox

[edit]

I've noticed that logging in has changed. When I log in on Wikipedia or Wikisource on my computer with Firefox, I'm only logged in to Wikipedia or Wikisource. Before when I logged in, as recently as April, I was logged in to all wiki projects when I logged in with Firefox on my computer (Wikipedia, Wikisource, Wikidata, Wikimedia Commons, etc). But when I log in with Microsoft Edge, I'm logged in on all wiki projects at the same time. Do you understand what I mean and what has happened and why and how to solve it? Has this been brought up already on this or another language edition? I've already asked about it on Swedish Wikipedia, but maybe I'll get more helpful results here, I was directed to this section specifically. I don't know where else to ask to get a solution. Grey ghost (talk) 15:20, 2 August 2025 (UTC)[reply]

@Grey ghost: If "Delete cookies and site data when Firefox is closed" is enabled in Firefox then disable it. See [2] for how to do it. PrimeHunter (talk) 15:31, 2 August 2025 (UTC)[reply]
I'm the kind of guy who uses more than one device, sometimes I borrow a library computer or someone else's computer I asked for. Then this is still annoying. And I don't think I'm the only Wikipedia user who does this. Many users edit the site in Internet cafés. Can't the technical team do something so that it's like how it was earlier this year? Can I contact them somehow somewhere? Or are they already working on a solution? Grey ghost (talk) 16:00, 2 August 2025 (UTC)[reply]
@Grey ghost: Something did change this year, probably to improve security, but it usually works for me in Firefox. If I'm logged out when I change site then I usually only have to reload the page or click login without filling any login form. Libraries and Internet cafes may have the type of security setting I mentioned so the next user cannot use a login from the previous user. Did you examine the mentioned setting? PrimeHunter (talk) 16:11, 2 August 2025 (UTC)[reply]
I looked at the settings but having to do all that seems convoluted. Also, I very often use an incognito setting and I don't know how that affects the situation, checking to see how it does affect it makes things more convoluted. If this is something other Firefox Wikipedia users have to go through, then I think something behind the scenes should change. Is there a way to contact one or more members of the technical team or are they unreachable? Grey ghost (talk) 21:36, 2 August 2025 (UTC)[reply]
If you have Enhanced Tracking Protection enabled, disable it on Wikimedia websites as it may block or partition third-party cookies, such as the ones used by SUL. OutsideNormality (talk) 16:18, 2 August 2025 (UTC)[reply]
Sounds like a side effect of the SUL3 work (which is not great; its goal was exactly to prevent this kind of problem). Are you willing to do some debugging? Either by installing the WikimediaDebug extension, and enabling verbose mode, or (if you know how) logging your network traffic via the developer toolbar)? Then try to log out and log back in again.
("Delete cookies and site data when Firefox is closed" will log you out when you close Firefox, but shouldn't be relevant for whether login works across domains. Disabling Enhanced Tracking Protection probably helps, but we'd like the login to work even when it is enabled.) Tgr (WMF) (talk) 15:30, 4 August 2025 (UTC)[reply]
I tried verbose mode on the extension, but it didn't help. Grey ghost (talk) 17:15, 7 August 2025 (UTC)[reply]

Tech News: 2025-32

[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

  • Editors can now enable the User Info card. This feature adds an icon next to usernames on history pages and similar user-contribution log pages. When you tap or click on the icon, it displays data related to that user account such as the number of edits, reverted edits, blocks, and more. It's part of a broader project to make it easier for moderators to evaluate account trustworthiness. The feature can be enabled in your global preferences, and later this week it will be available in local preferences. [3]
  • Everybody is invited to share comments on Collaborative Contributions, a project recently launched by the Connection team. The project aims to create a new way to display the impact of collaborative editing activities (such as edit-a-thons, backlog drives, and WikiProjects) on the wikis. Post your comments on the project talk page. [4]
  • Administrators can now define the default block duration for temporary accounts. To do that, they need to create a page named MediaWiki:Ipb-default-expiry-temporary-account and use a value defined in MediaWiki:Ipboptions. This allows administrators to easily block temporary accounts for 90 days, which is functionally equivalent to an indefinite block. The advantage of this solution is that it does not clutter Special:BlockList. More documentation is available. [5]
  • Recurrent item View all 27 community-submitted tasks that were resolved last week.

Updates for technical contributors

  • Gadgets can now include .vue files. This makes it easier to develop modern user interfaces using Vue.js, in particular using Codex, the official design system of Wikimedia. Codex icons can be loaded through the gadget definition. The documentation has examples. For user scripts that use Vue.js, an API module now exists to load Codex icons. [6][7]
  • Module developers can now use a Lua interface to simplify the preparation of Lua modules for translation on Meta-Wiki. This improvement makes it easier for translators to find and edit module strings without dealing with raw Lua code. It helps prevent mistakes that could break the module during translation. Module developers and translators are invited to watch the demo video, read more about translatable modules to understand how it works, refer to Meta-Wiki's Module:User Wikimedia project for example usage, and share their feedback on how well it addresses the challenges in their workflow. The interface still has some performance issues, so it should not be used in widely used modules yet. [8]
  • Developers of external tools that connect to Wikimedia pages must set a user-agent that complies with the user-agent policy. This policy will start to be more strongly enforced in August because of external crawlers that are overusing Wikimedia's resources. Tools that are hosted on Wikimedia's Toolforge or Cloud VPS will not be affected by this for now, but should still set a user-agent. More technical details are available, and related questions are welcome in that task.
  • Parsoid Read Views is going to be rolling out to some smaller Wikipedias over the next few weeks, following the successful transition of Wikivoyages and Wiktionaries to Parsoid Read Views. For more information, see the Parsoid/Parser Unification project page. [9]
  • Recurrent item Detailed code updates later this week: MediaWiki

Meetings and events

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

MediaWiki message delivery 03:36, 5 August 2025 (UTC)[reply]

FYI, if you enable the User Info card but want the icon to be more subtle, I've found that .ext-checkuser-userinfocard-button.cdx-button .ext-checkuser-userinfocard-button__icon.cdx-button__icon {opacity: 0.2;} in your custom.css or global.css workds pretty well. --Ahecht (TALK
PAGE) 16:41, 5 August 2025 (UTC)[reply]
This is the first I've heard of "Parsoid Read Views". Are there other Parsoid Views? And other Read Views? I assume it just refers to Parsoid's HTML output, but it's confusing. Nardog (talk) 23:05, 6 August 2025 (UTC)[reply]
@Nardog Core Parser Read/Edit Views - Parsoid Read/Edit Views, I suppose. The first paragraph of mw:Parsoid/Parser Unification. Ponor (talk) 10:43, 7 August 2025 (UTC)[reply]
What are the Edit Views? I thought the whole point of Parsoid was that the same HTML could be used for editing in VisualEditor and reading. Nardog (talk) 11:47, 7 August 2025 (UTC)[reply]
By default most wikis still use the old parser to render html for the html that is used for article pages. This is a notification that more wikis will start using the parsoid parser to render html for the article pages (read views). —TheDJ (talk • contribs) 14:06, 7 August 2025 (UTC)[reply]
I figured. What I'm trying to figure out is why this confusing (to me at least) terminology was chosen in Tech News of all places. I guess it's because Parsoid is already used in VisualEditor? Nardog (talk) 03:17, 8 August 2025 (UTC)[reply]
because giving simple explanations of highly complex things is hard. —TheDJ (talk • contribs) 08:21, 8 August 2025 (UTC)[reply]
"Parsoid Read Views" are basically the only name the effort to use Parsoid for read views is known by. There wasn't other terminology to use. Izno (talk) 00:11, 11 August 2025 (UTC)[reply]
The new Parsoid viewer has significant bugs (linked from T391624) that make edit links on some page sections fail, including editing sections of template documentation pages. I encourage others to try the new viewer (Preferences - Editing - Use the new Parsoid wikitext parser) to see if they encounter any such show-stopping bugs. It would be good to get these major bugs fixed before the new viewer appears here on en.WP. – Jonesey95 (talk) 16:14, 11 August 2025 (UTC)[reply]

Activating an interactive OWID experience (Part 3)

[edit]

Am wanting to reapply to activate the OWID gadget following addressing the issues in the prior discussions:

  • 5 months ago concerns were raised regarding bandwidth usage and these were decreased down to 400 KB from 36 MB, a number of bugs raised have also been fixed
  • 2 months ago issues were raised regarding scrolling which have been addressed

The gadget is currently running on Basque Wikipedia. As we have developed multilingual / translation workflows.

Steps to install include

[edit]

Doc James (talk · contribs · email) 16:17, 6 August 2025 (UTC)[reply]

Support. Thank you for implementing my deduplication proposal. I confirm that I see "56 requests 541 kB transferred 2.1 MB resources," and no new requests when changing years, which is good. I was originally aiming for a 100% SVG 0% JS version, but this gadget would potentially handle web accessibility miles better than my idea; the only bug here is that I can't press tab to select countries. Overall, nice work! VectorWorld (talk) 00:10, 7 August 2025 (UTC)[reply]
Thanks VectorWorld. Can you clarify what you hope the gadget would do when tab is pressed? Not sure what you mean by "select countries"? Doc James (talk · contribs · email) 03:37, 7 August 2025 (UTC)[reply]
Us normal users with mice, after opening mdwiki:Template:Owidslider#Example_3, are able to click a country and see a line chart. How can users without mice (like blind people using screen readers) open that chart?
Currently, when I press tab, it cycles through "Select region", "Death rate from indoor air pollution, 2020", "Media credits", then the year slider. Instead, it should be "Select region", "Death rate from indoor air pollution, 2020", Country 1, Country 2, Country 3, ..., Country N, "Media credits", then the year slider.
After selecting a country such as Australia by repeatedly pressing tab, there should be alt text (alt="..." actually <title>Between 0 and 25 deaths</title> or the actual number) that a screen reader will read out loud to blind people who can't see the colors or anything at all. After pressing enter, the alt text of the opened line chart should say something like "0.3 in 1990 and 0.01 in 2021" or more granular.
On the other hand, I should not hear "No data, 0, 25, 50, 75, 100, 125, 150, 175, 200" before "Media credits" when using the Google TalkBack screen reader. The proposed alt text would play the same role for blind users, so the numbers on the scale should be muted with aria-hidden="true".
Tab is actually just cycling through "focusable" elements (so try wrapping each <path d="..."/> like <a xlink:href="#"><title>Alt text here</title><path d="..."/></a> and moving the onclick onto the <a>). TalkBack uses swiping right instead of a tab key. VectorWorld (talk) 05:18, 7 August 2025 (UTC)[reply]
Thanks for that feedback. We can add it to our development efforts Doc James (talk · contribs · email) 06:53, 7 August 2025 (UTC)[reply]
@Doc James Say I want to import the following graph https://ourworldindata.org/grapher/birth-rate-vs-death-rate. What workflow would you recommend? What settings should I keep or change in the importer? When it comes to translation, it seems that every imported svg needs to be translated, even though almost all the text in them is the same - it's hard to believe that people will do that. How will everything work in 2-3 years when new data comes in, will a new set of images be created, will old images be overwritten and new ones added (what if there are design changes)? I like the idea, but I would like us to not have to do the import, i.e. WMF (and ourworldindata.org) should find a way to enable option 2 for the benefit of both. Ponor (talk) 11:23, 7 August 2025 (UTC)[reply]
Only the first image in the world set needs to be translated and then the tool will apply it to the rest of them. It is not working 100% (only 50%) but we are working on it. Doc James (talk · contribs · email) 12:22, 7 August 2025 (UTC)[reply]
The tool is for heatmaps not line graphs so would go here https://ourworldindata.org/data and look for the world maps for uploads.
If we go with https://ourworldindata.org/grapher/human-development-index we start getting https://commons.wikimedia.org/wiki/File:Human-development-index,World,1990.svg Doc James (talk · contribs · email) 12:36, 7 August 2025 (UTC)[reply]

@Xaosflux, Sohom Datta, and Dylsss: those previously involved Doc James (talk · contribs · email) 13:37, 9 August 2025 (UTC)[reply]

The interface work has been done. The template/module can be looked in to by others. The category/gadget definition may need better descriptions. — xaosflux Talk 16:28, 9 August 2025 (UTC)[reply]
The gadgets page is giving the error "owidslider: Description MediaWiki:Gadget-owidslider for use in Special:Preferences does not exist" at the top. Might need to double check the gadget definition. –Novem Linguae (talk) 16:37, 9 August 2025 (UTC)[reply]
Where are you seeing that? I'm not seeing it at Special:Gadgets. The description needs MediaWiki:Gadget-owidslider created by any admin. It should point to the description page for this gadget onwiki. — xaosflux Talk 16:44, 9 August 2025 (UTC)[reply]
(Which someone should write at Wikipedia:xxxxxxxxxxxxxxxx) — xaosflux Talk 17:02, 9 August 2025 (UTC)[reply]
Where are you seeing that? MediaWiki:Gadgets-definition, at the top. –Novem Linguae (talk) 00:13, 10 August 2025 (UTC)[reply]
Oh ok, that's not an error per se, it's just a custom template that notices it. The definition description isn't actually needed for a gadget to work. It should be done though - directions above along with all the other things that have to be done still. — xaosflux Talk 00:18, 10 August 2025 (UTC)[reply]
It might not be an error per se, but it does show as a problem at more than one page. So far, I have found:
There may be others. To fix these issues, I have noted that MDWIKI:MediaWiki:Gadget-owidslider exists, and contains the plain text "Shows a popup dialog with a slider for OWID images". Since this is licensed CC BY-SA 4.0, I have copied it verbatim to MediaWiki:Gadget-owidslider, with appropriate attribution in the edit summary. As regards the Wikipedia:xxxxxxxxxxxxxxxx mentioned above, judging by Category:Pages using gadget owidslider that would be WP:owidslider gadget. Perhaps Bawolff (talk · contribs) could assist in writing that. --Redrose64 🌹 (talk) 10:51, 10 August 2025 (UTC)[reply]
(Copying over my response to the post at WP:IANB which appears to have been placed in the wrong place all along) Oppose, I still have reservations about this, it does not feel production ready, the page jumps around when click on the play button (and when I return to the article). The play button itself looks out of alignment/misshapen and the text surfaced by the info button cannot be interacted with (copied etc). My understanding is that by deploying this on enwiki, you will start using this in reader facing areas (and the gadget will need to be maintained by interface admins). If this had been "hey we will experiment with this thing onwiki but not in article", and it had buy-in from a interface administrator (somebody who can say "hey, I'll keep updating and fixing this"), you would have my cautious support. But, at the moment, you don't have my support since I don't believe the gadget in a "finished" state and you don't have folks who would be interested in maintaining it long-term on the English Wikipedia. -- Sohom (talk) 03:52, 10 August 2025 (UTC)[reply]
Also, question, @Doc James what are the security considerations that were considered when you implemented the gadget, were any considerations given to mXSS (mutation cross-site scripting) vectors (given that MediaWiki's sanitizers are server-side sanitizers that do not consider the way your gadget loads SVG files to be a valid way of loading svgs). The more I look at this, the less sure that deploying it on enwiki in reader facing areas is a good idea especially considering we might be putting our readers at risk (besides giving them a janky experience). Sohom (talk) 04:55, 10 August 2025 (UTC)[reply]
Until the question above is addressed/has a satisfactory response, I've removed the default directive from the gadget as a precaution (i.e. only users who explicitly enable it will load the JS code). -- Sohom (talk) 05:07, 10 August 2025 (UTC)[reply]
Will ask User:Bawolff to provide the security details you requested. With respect to play button appearance it is perfect on my machine but yes notice that it is too flat on some browsers. Will look into it.
Will work on making the text under I selectable. Agree it is not perfect yet.Doc James (talk · contribs · email) 05:37, 10 August 2025 (UTC)[reply]
One security consideration that needs to be addressed is that innerHTML should not be used, such as at https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-owidslider.js&oldid=1305026826#L-1583 . It should be const node = document.createElement("span"); node.textContent = config.name; countryPopup.appendChild(node); like the other places.
But as for the "finished" state, nothing on a wiki is supposed to be or will ever be complete, so this is fine as long as it is being improved. VectorWorld (talk) 07:00, 10 August 2025 (UTC)[reply]
I agree that nothing is ever complete, but in the context of gadgets that are being deployed in a reader facing manner I personally would expect the JavaScript code to be relatively more mature and bug free compared to the status quo. Sohom (talk) 07:06, 10 August 2025 (UTC)[reply]
I've gone and manually yanked out that innerHTML, my concerns regarding mutation cross-site scripting still remains. Sohom (talk) 13:02, 11 August 2025 (UTC)[reply]

Artificial intelligence of things

[edit]

Artificial intelligence of things should be rewritten because it is a mess. Polygnotus (talk) 05:03, 7 August 2025 (UTC) [reply]

Extended content
It is appropriately tagged. This page is a forum for discussing technical issues and problems, not content problems. If you want someone to improve that article, it would help to list specific problems and suggestions on the article's talk page, as suggested by the cleanup template. – Jonesey95 (talk) 05:26, 7 August 2025 (UTC)[reply]
@Jonesey95 Yeah I tagged it. I know the purpose of the village pump, to pump water and spread gossip. I have to go feed the chickens (not a metaphor) so I figured I leave a note here. Polygnotus (talk) 05:30, 7 August 2025 (UTC)[reply]
No, this is the technical village pump. Please read the text in the banner at the top of the page. – Jonesey95 (talk) 05:31, 7 August 2025 (UTC)[reply]
Yes, this is the technical village pump. We wouldn't want the chickens to go hungry. Polygnotus (talk) 05:33, 7 August 2025 (UTC)[reply]
 Done Polygnotus (talk) 11:05, 12 August 2025 (UTC)[reply]

New "Cannot find section" error at Template:Tire

[edit]
Tracked in Phabricator
Task T391624

The first time this happened to me today, I wrote it off as a page change that happened while I was reading. The second time, I can't explain it. Here's how to replicate it:

  1. Go to Template:Tire
  2. Next to the section header "Usage", click the "edit" link.
  3. I see an error page with the heading "Cannot find section".

The URL it is looking for is: https://en.wikipedia.org/w/index.php?title=Template:Documentation&action=edit&section=T-1

This URL is wrong. Notice that it is trying to edit {{Documentation}}, not {{Tire/doc}}. When I am logged out, the above steps work correctly, showing me an edit window for the Usage section at this URL: https://en.wikipedia.org/w/index.php?title=Template:Tire/doc&action=edit&section=T-1

When I view the page in safe mode, I get the same error.

I use the original source editor, if it makes a difference, and Vector 2022. FWIW, my "edit" link is on the right, due to some preference, I think. I have tons of css and js customizations, but see the above note about safe mode. Can anyone replicate this problem? – Jonesey95 (talk) 21:21, 7 August 2025 (UTC)[reply]

I cannot replicate this, with either of my accounts. The URL it points to for me is correct (screenshot of mouseover). HTH. (My setup: latest Firefox, Mint Linux, Vector-2022, tons of scripts and gadgets). Quiddity (WMF) (talk) 23:36, 7 August 2025 (UTC)[reply]
I can reproduce this when using Parsoid for page views: https://en.wikipedia.org/w/index.php?title=Template:Tire&useparsoid=1 Matma Rex talk 02:18, 8 August 2025 (UTC)[reply]
I submitted a bug report to https://www.mediawiki.org/wiki/Parsoid/Feedback#enwiki:Template:Tire using the "Report visual bug" button in the sidebar. Matma Rex talk 02:20, 8 August 2025 (UTC)[reply]
That's it. I just switched over to Parsoid views today, since the Tech News (above) said that it was coming. Hooray, I found a bug! – Jonesey95 (talk) 05:03, 8 August 2025 (UTC)[reply]
Thanks for the reports. Just for visibility, phabricator:T391624 tracks the broad set of issues we are working through around section edit links and Parsoid. SSastry (WMF) (talk) 16:08, 8 August 2025 (UTC)[reply]

Fixing archives numbering

[edit]

Hi, there is an issue with the numbering on my talk page archives; they're not appearing in the correct sequence in one line from 110 onward. Does anyone know how to fix this? If so, could you please fix it for me? Thank you. Cassiopeia talk 23:23, 7 August 2025 (UTC)[reply]

DreamRimmer Thank you very much for fixing it for me. Stay safe and best. Cassiopeia talk 01:57, 8 August 2025 (UTC)[reply]
This is likely because archive numbers from 1 to 99 are short enough to fit inline, but once they reach triple digits (100 to 132) the links become longer and do not display properly in the small box size. – DreamRimmer ■ 02:07, 8 August 2025 (UTC)[reply]
DreamRimmer Thank you for taking the time to fix it for me. Appreciate that! Cassiopeia talk 02:16, 8 August 2025 (UTC)[reply]
I have posted to Template talk:Archives#Line wrap for 3-digit numbers. PrimeHunter (talk) 11:02, 8 August 2025 (UTC)[reply]

Random article - keyboard shortcut

[edit]

The link for random article has a tooltip showing the keyboard shortcut as Alt-Shift-X. This seems to be correct in Firefox and various FF based browsers I've tried, but if I use Edge it appears that Shift-X is the keyboard shortcut instead. Is this just a feature (or oddity) of Edge or does it apply to all Chromium based browsers - I don't have any others installed to test. Nthep (talk) 08:20, 8 August 2025 (UTC)[reply]

@Nthep: See Help:Keyboard shortcuts#Using access keys. I don't know whether MediaWiki tries to read the browser and adjust the displayed shortcut. Most people use browsers where Alt+⇧ Shift works. PrimeHunter (talk) 10:34, 8 August 2025 (UTC)[reply]
Actually, I tried Chrome which has a majority browser share on desktop and it only worked with Alt but still said Alt+⇧ Shift. Maybe it's best to mention both keys. It's easier to guess you might omit one of them than you have to add an unmentioned key. PrimeHunter (talk) 10:44, 8 August 2025 (UTC)[reply]
Looks like Chromium-based browsers have changed their behavior sometime since we set up the tool that generates our labels. They used to, on Windows, always work if you did Alt+⇧ Shift, and only-sometimes work if you did just Alt because of conflicts with other shortcuts (e.g. Alt+d focuses the location bar). Thus we just generated everything as Alt+⇧ Shift and called it a day.
It looks like now the most-comprehensive thing to do would be to encode knowledge of all the built-in shortcuts that are based on Alt and selectively display the modifiers based on that list.
Alternatively, and what I'm going to submit a patch to do on T401503 😛, is changing it to just show Alt, and hope that Chromium will someday actually implement the accessKeyLabel property that everyone else provides that would just let it tell us what the label is supposed to be. DLynch (WMF) (talk) 00:02, 9 August 2025 (UTC)[reply]
Update: actually, the way it worked before is still true. However, Chrome has rolled out a lot more browser shortcuts based off of Alt since we originally made those accesskeys. In particular, every accesskey in the main menu now seems to be overlapping with a browser shortcut related to new tab-group features... which don't actually do anything if you have tab groups disabled, thus the appearance that they're just being completely skipped.
On the bright side, since my last comment, the chromium issue for accessKeyLabel got assigned someone to maybe work on, so the entire question may shortly be moot. DLynch (WMF) (talk) 21:56, 11 August 2025 (UTC)[reply]

SpecialPages

[edit]

Why am I seeing a single list of special pages that takes a ton of scrolling and needs a search function of it's own? Did I foolishly set some option or gadget? Or is this an "upgrade"? In either case can I reverse it? All the best: Rich Farmbrough 16:01, 9 August 2025 (UTC).[reply]

Extended content
Always provide a link when reporting a problem. Are you talking about the list at Help:Special page or something else? – Jonesey95 (talk) 18:01, 9 August 2025 (UTC)[reply]
Everyone else seems to understand what I mean. I've added a link to the header. All the best: Rich Farmbrough 09:23, 10 August 2025 (UTC).[reply]
I did not until I read zzuzz's post. Thanks for confirming the page to which you were referring. isaacl (talk) 17:38, 10 August 2025 (UTC)[reply]
Neither did I. But hey, Jonesey, please go easy on him; he is still not in the top five yet; you can't expect him to know everything. Mathglot (talk) 02:52, 11 August 2025 (UTC)[reply]
@Mathglot: This is completely irrelevant to the original query ... but I know you were joking around, and from your edit count stats it appears that you weren't that active here when the original poster was more prominent in the community, but he actually used to hold the #1 ranking. The history of the subsequent events is a very long, sad, and complicated story. As a perennial lurker in this situation, I don't think it's my place to try to offer any more explanation than that and perhaps I've already said too much. Sorry Rich for calling you out like this. Graham87 (talk) 07:04, 11 August 2025 (UTC)[reply]
I don't see the point in bringing their failed RfA here. What a bizarre comment. — DVRTed (Talk) 07:28, 11 August 2025 (UTC)[reply]
I realise there's probably little I can do to dig myself out of this, but by way of explanation, I linked his 2015 RFA as a pointer to the 2012 arbitration case about him that severely curtailed his editing. On a much brighter note, there's this 2020 piece in the Signpost, published when he was ranked 4th in terms of number of edits here. I think it may well have been better if I'd sent an informational email to Mathglott and one to Rich saying "I just let Mathglott know that <XYZ>", rather than airing out dirty laundry in public like this. This will be my last comment here unless anyone has specific questions that they wish to have answered on this thread (I don't really mind whether it's hidden or shown); my talk page/email are always open too. Graham87 (talk) 10:32, 11 August 2025 (UTC)[reply]
It's no problem at all, it's all part of Wikipedia history, and though it was suboptimal, some of it is quite funny, like when two prominent editors "accused" me of being calm, reasonable and polite on AN/I. (And indeed the "not in the top five yet" comment above.) All the best: Rich Farmbrough 10:39, 11 August 2025 (UTC).[reply]
phab:T219543 is the cause. Snævar (talk) 18:02, 9 August 2025 (UTC)[reply]
That would be Special:SpecialPages. I can't say I see it as an improvement either. -- zzuuzz (talk) 18:09, 9 August 2025 (UTC)[reply]
-1 from me, too. It's a little less offensively space-wasting with the vertical padding removed (body.page-Special_SpecialPages .cdx-table__table td { padding-top: 0px; padding-bottom: 0px; }), but only a little. —Cryptic 18:59, 9 August 2025 (UTC)[reply]
Hmm, WMF not getting consensus again I guess. Thanks folks. All the best: Rich Farmbrough 23:29, 10 August 2025 (UTC).[reply]
While I'm personally not a fan of the change, routine technical changes do not need consensus. Sohom (talk) 13:32, 11 August 2025 (UTC)[reply]
This is a major user interface change, especially for power gnomes. For context also, there are bugs/feature requests that have been outstanding for a dozen years or more. When WMF did the font refresh, they asked for volunteer input and, as far as I can tell, ignored it. It's certainly true that WMF can do what the hell they want, as indeed can volunteers, but working together is both an an efficient use of resource and a promoter of harmony. All the best: Rich Farmbrough 13:41, 11 August 2025 (UTC).[reply]
The font refresh you are talking about is a change from 2014 (over a decade ago at this point). Do you believe any of the folks (or even the same C-level staff) working on that project worked on this? (From the looks of it, for this particular change it was a single engineer + designer who pushed this change during their volunteer time, and there is rightfully pushback against their changes from some members of WMF staff and technical volunteers on the phab task) For context also, there are bugs/feature requests that have been outstanding for a dozen years or more. - Right, I am aware. I don't get the point you are trying to make by bringing that up, this is a bit like saying "We haven't gotten any of our vital articles to good article status, we shouldn't invest in making any new shiny articles". Sohom (talk) 14:22, 11 August 2025 (UTC)[reply]
Some of those bugs were fixed by volunteers and the staffers didn't have time to do code reviews. It's not a question of specific things, it's a question of culture - not just tech stuff incidentally.
We have seen repeatedly vast sums spent on projects that produce nothing or almost nothing, while simple things go unfixed. Another example was when a mass of triaged tickets were changed to "won't do".
And the WMF wants to do better, it just repeatedly fails. One notable exception is the Wish List.
I get how hard this is, when you are trying to run something that looks very like a business (but isn't a business) - the bit in brackets gets forgotten. We really should be able to deal with it though, maybe there's something we can do from the volunteer side to sharpen the focus.
All the best: Rich Farmbrough 14:38, 11 August 2025 (UTC).[reply]
I think Sohom is trying, with the whole PTAC thing. It is unlikely to fix all problems right now and retroactively, but it is intended as a step in the right direction. Polygnotus (talk) 18:47, 11 August 2025 (UTC)[reply]
This was a relatively minor change. I get it when people are frustrated over a lack of consultation on big changes, but this was a relatively small change. There are like 500 changes to mediawiki a day. If you want to give feedback on all of them, you can by all means register an account at https://gerrit.wikimedia.org and watch MediaWiki's equivalent of RecentChanges. Otherwise someone needs to come up with some criteria for what type of changes they'd like to be consulted on. Bawolff (talk) 18:55, 11 August 2025 (UTC)[reply]
@Bawolff I'm happy to be consulted on all changes, but then I would also like a salary or two. Polygnotus (talk) 19:04, 11 August 2025 (UTC)[reply]
Im all for criticizing WMF when they deserve it, but i think it should be for things that they could at least theoretically do better on. Community does not generally want to be consulted on changes of this magnitude, because there are too many. But they also want to be consulted on the "bad" ones. That is not physically possible because WMF cannot read minds. Bawolff (talk) 22:29, 12 August 2025 (UTC)[reply]
Agreed. But if they pay me a decent salary or two I can tell em which changes the community objects to, and even when they should and shouldn't ignore that. Polygnotus (talk) 22:46, 12 August 2025 (UTC)[reply]
Users regard changes in line with how many pages it affects, or in some cases, if the page in question is widely used in administrative workflows. The problem is actually that it very much differs by wmf designer wether they listen to feedback or not, not where or if the feedback gets posted. Users are also at blame here, listening to feedback does not mean doing every little bit of it. I would like to end with a quote.
"As one designer, you know, I couldn´t possibly hope to ever encompass the massive diversity of experiences that those readers have in my work alone, right? Uh and so I truly feel like contributors feedback is a gift." (Justin Scherer, ux designer, Reader growth team, Wikimania, session "Making Wikipedia More Readable: What Comes Next", link to verify ). Snævar (talk) 20:56, 11 August 2025 (UTC)[reply]

This has been (mostly) reverted back to the original display now, per phab:T219543. See: the page on the beta cluster. The original appearance is back, but the filtering search is retained. It'll make its way out to all the wikis by the Thursday deployment.DLynch (WMF) (talk) 22:13, 11 August 2025 (UTC)[reply]
That's excellent news. All the best: Rich Farmbrough 22:15, 11 August 2025 (UTC).[reply]
Woo! Sohom (talk) 22:17, 11 August 2025 (UTC)[reply]

Adding animations and interactive visuals to make Wikipedia easier to understand

[edit]

Hey everyone, I just wanted to throw out an idea about making Wikipedia a bit more engaging for readers. I love how much info Wikipedia has, but sometimes the pages can feel a bit dry or overwhelming, especially when there's complicated data or timelines. What if Wikipedia added some subtle animations or interactive visuals — like charts you can explore, timelines that move, or little infographics? [at least on mobile devices] I’ve seen something similar with the The Hundred cricket tournament — their animations and scorecards look really cool and help explain things better. I heard those might be from Jump Design (Mark Fairless leading animation)? Not totally sure though. I’m not talking flashy or distracting stuff, just simple, clean visuals that help people get the info faster and maybe even enjoy reading more. Has this been thought about before? Or are there any plans to add more of this kind of thing? Would love to hear what people think! Vinizex94🌍 12:20, 10 August 2025 (UTC)[reply]

This could be helpful, although one drawback of animations is that they're not really editable like the rest of the article, which makes it harder for other editors to participate. However, we do have some more editor-friendly (while still also reader-friendly!) tools, like the interactive Chart extension for infographics! Chaotic Enby (talk · contribs) 12:42, 10 August 2025 (UTC)[reply]
WikiProjectMed:VideoWiki has worked on editable ones. There are also other issues, such as how you know that content in a video is properly sourced. There's a bit of previous discussion here. FactOrOpinion (talk) 02:32, 11 August 2025 (UTC)[reply]
Its often surprisingly hard to come up with good ideas for animation and interactivity. I think the best thing people could do on this front is come up with fleshed out ideas (perhaps drawing by hand if appropriate) which people can discuss and decide if they want. Then once people are agreed on what is wanted, technical people can make it happen. Bawolff (talk) 00:01, 11 August 2025 (UTC)[reply]
This is a wonderful idea, but animations are difficult to verify. Many animations in science articles perpetuate incorrect concepts. Johnjbarton (talk) 02:25, 11 August 2025 (UTC)[reply]
I see what you mean about the challenges here — especially when it comes to keeping things editable and accurate. One thing that might be worth looking into is the Chart extension for Mediawiki. It lets you create interactive visualisations directly in wikitext, so they’re easier for other editors to maintain and update than traditional animations.
Maybe the best approach is to start with a few concrete examples of what could work — even if that’s just simple sketches or mockups — so people can discuss and refine them before anything gets built. That way we can focus on ideas that really help readers without risking accuracy, and ensure that whatever’s added can be verified and improved over time by the community. Vinizex94🌍 02:32, 11 August 2025 (UTC)[reply]
A good solid, comprehensive HowTo page for editors would go a long way to make these feature more commonly deployed. Johnjbarton (talk) 02:51, 11 August 2025 (UTC)[reply]
Wikipedia:Graphics Lab/Resources/Charts explains how to add an chart using extension:chart. Snævar (talk) 20:32, 12 August 2025 (UTC)[reply]

Should it really not be possible to edit your own watchlist while blocked?

[edit]
Tracked in Phabricator
Task T401577

I do a lot of browsing Wikipedia from behind a VPN and something that I've noticed in the past few days is that it seems to now be impossible to add or remove a page from my watchlist while under the effects of a block (in my case, the "No open proxies" IP block). Opening the watchlist link in its own tab displays "You do not have permission to edit your watchlist, for the following reasons:" and then the block notices. Considering that nobody else can even tell what's in your watchlist, this seems like an odd permission to deny for blocked users. Any ideas what's going on here? twotwos (talk) 14:12, 10 August 2025 (UTC)[reply]

This seems odd. I was not able to duplicate this on testwiki. Are you using tor specifically, or something that has a manual range block? — xaosflux Talk 22:05, 10 August 2025 (UTC)[reply]
If you would believe it, watching and unwatching pages from the UI now seems to work normally. Typical of technical problems to go away as soon as someone else looks at them. But, going to one of the watchlist edit pages, like https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=watch, still brings up the block screen. It's a global manual range block but not tor, like this - I did just go through my VPN region options to see if I could test one that was locally blocked on Wikipedia but not globally blocked, but couldn't find any. twotwos (talk) 03:00, 11 August 2025 (UTC)[reply]
Bug phab:T401577 opened on this. It should be consistent one way or the other. — xaosflux Talk 10:13, 11 August 2025 (UTC)[reply]
Thinking about this it's not clear what IP blocks are supposed to be doing. If you are a trusted user with good security there is no need for you to be affected by IP blocks. Therefore we can assume IP blocking of accounts is either for untrusted user accounts or accounts with poor security (not exclusive or). The first could be reasonably addressed by excluding extended confirmed accounts. The second - for example attempts to hail Mary weak passwords (where we do want to protect users who's accounts have been ahved from having their watchlists tampered with), should be applied by very different mechanisms than those we use for anonymous editors from high schools, libraries and pubs. All the best: Rich Farmbrough 10:29, 11 August 2025 (UTC).[reply]
That seems to be going off tangent of this bug, which is presenting in the presence of any block that affects editing, but only via the action parameter. Administrators applying network blocks may choose to have them affect or not affect users - this situation should not be affecting logged in users that are otherwise able to edit a page. If it is, please let us know. — xaosflux Talk 12:59, 11 August 2025 (UTC)[reply]
Yes it certainly is a tangent. On the other hand I've already learned that there is a new option for IP blocks that I wasn't aware of (thank you). I am also pleased if I've got people thinking about more efficient and editor-friendly ways that blocks could - and maybe should - work. All the best: Rich Farmbrough 13:46, 11 August 2025 (UTC).[reply]
Making sure we are on the same page :) "Block watchlist access" is not an option that is expected - that seems like a bug. A longstanding option feature of IP blocking is (Apply block to logged-in users from this IP address) Customary practice on IP blocks is not use this option unless there is a need for it. When not set the block will usually show as (anon only) in lists such as the blocklist. — xaosflux Talk 14:10, 11 August 2025 (UTC)[reply]
Yes definitely the same page. All the best: Rich Farmbrough 14:39, 11 August 2025 (UTC).[reply]

Global contribution tool seems to be broken

[edit]

The global contributions tool, linked in the bottom of the contributions page, seems to be broken. Trying to access https://guc.toolforge.org/ results in a 404 error. 86.23.87.130 (talk) 16:06, 10 August 2025 (UTC)[reply]

86.23.87.130, This URL is managed by the guc tool, maintained by Krinkle, Lucas Werkmeister, Luxo, Majavah. I would start by asking them. — Qwerfjkltalk 19:04, 10 August 2025 (UTC)[reply]
It works again. Polygnotus (talk) 08:13, 11 August 2025 (UTC)[reply]
Huzzah! All the best: Rich Farmbrough 10:30, 11 August 2025 (UTC).[reply]

How to archive article with some kind of pop-up?

[edit]

If you want to load archived version of this article or pdf version at Wayback Machine pop-up error appear and if you skip it you are being redirected to main page. Eurohunter (talk) 21:23, 10 August 2025 (UTC)[reply]

User:Eurohunter, this page is about raising technical issues about Wikipedia. We have no say in how the Wayback Machine (Internet Archive) organizes their platform. I suggest you check with them. Mathglot (talk) 02:08, 11 August 2025 (UTC)[reply]
@Eurohunter H:ARCHIVESOURCE provides a few options. Polygnotus (talk) 08:13, 11 August 2025 (UTC)[reply]

Replacements for old tools?

[edit]

In some WikiProjects, I see the following tools listed that are dead links:

  • Reflinks - Edits bare references - adds title/dates etc. to bare references
  • Checklinks - Edit and repair external links
  • Dab solver - Quickly resolve ambiguous links.
  • Peer reviewer - Provides hints and suggestion to improving articles.

While I know Wikipedia:reFill is seen as a replacement for Reflinks, and Wikipedia:Tools/Navigation popups helps with resolving ambiguous links, has anything replaced the other two? I particularly recall Peer reviewer being a really useful tool. At the very least, I'd like to clean up these tools recommendations lists in WikiProjects with updates or deletions whenever I come across them. Stefen 𝕋owers among the rest! Gab • Gruntwerk 09:56, 11 August 2025 (UTC)[reply]

There's reFill 2 which is pretty good. All the best: Rich Farmbrough 13:48, 11 August 2025 (UTC).[reply]
User:Dispenser/Dab solver was a very useful tool which broke due to database changes within Wikipedia. There are several copies of the source code but no licence to update and deploy them. Its replacement was a popular item on the annual community request lists but never received any resources. Certes (talk) 17:10, 11 August 2025 (UTC)[reply]

Delete vote listed as redirect

[edit]

I just glanced at my AFD stats here and notice that it's counted me as a redirect vote for Wikipedia:Articles_for_deletion/Coldplay_jumbotron_controversy. I never supported redirect there, in fact I was the one who nominated it for deletion, so my vote should be listed as delete. It's purely cosmetic, but is there a way to fix that? Valenciano (talk) 17:27, 11 August 2025 (UTC)[reply]

@Valenciano: I haven't looked at the code but you have a post saying "delete and redirect" in bold as part of a quote. I guess that caused it. You could try unbolding it or breaking up "redirect" with something undisplayed like nowiki or {{void}} inside. PrimeHunter (talk) 18:03, 11 August 2025 (UTC)[reply]
I'll try that. Thanks a lot! Valenciano (talk) 18:04, 11 August 2025 (UTC)[reply]

Tech News: 2025-33

[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

  • The WikiEditor toolbar now includes its keyboard shortcuts in the tooltips for its buttons. This will help to improve the discoverability of this feature. [10]
  • The Product and Technology Advisory Council published a set of proposed experiments the Wikimedia Foundation can try to improve communication with community. Feedback on the proposals are welcomed until August 22 on this talk page.
  • The search bar on the Minerva skin (mobile) has been updated to use the same type-ahead search component that is used on the Vector 2022 skin. There are no changes in search functionality but there are minor visual changes. Specifically, the close-search button has been changed from an "X" to a back arrow. This helps to distinguish it from the other "X" button that is used to clear any text. [11]
  • Editors on some wikis will see a new toggle for "Group results by page" on watchlist, related changes, and recent changes pages. This is an A/B experiment that is planned to start on August 11, and will run for 3–6 weeks on the Bengali, Chinese, Czech, French, Greek, Portuguese, and Urdu Wikipedias. The experiment will examine how making this feature more discoverable might affect editors' ability to find the edits they are looking for. [12]
  • Recurrent item View all 31 community-submitted tasks that were resolved last week.

Updates for technical contributors

  • The multiwiki datasets of Unicode data have been moved to Category:Unicode Module Datasets on Wikimedia Commons, to follow the idea of "One common data source, multiple local wikis". Most wikis have been updated to use the Commons version. You can ask questions at the talkpage. [13]
  • Lua code can add warnings when something is wrong, by using the mw.addWarning() function. It is now possible to add more than one warning, instead of new warnings replacing old ones. If you maintain a Lua module that used warnings, you should check it still works as expected. [14]
  • Recurrent item Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 23:25, 11 August 2025 (UTC)[reply]

Just once I would like this to tell me about a major breaking change like Phab:T400119 Hawkeye7 (discuss) 00:52, 12 August 2025 (UTC)[reply]
@Hawkeye7 Good news, last week's edition mentioned it:

Developers of external tools that connect to Wikimedia pages must set a user-agent that complies with the user-agent policy. This policy will start to be more strongly enforced in August because of external crawlers that are overusing Wikimedia's resources. Tools that are hosted on Wikimedia's Toolforge or Cloud VPS will not be affected by this for now, but should still set a user-agent. More technical details are available, and related questions are welcome in that task.

Matma Rex talk 00:59, 12 August 2025 (UTC)[reply]
Since the policy will be progressively enforced over a couple of weeks, would it be possible to have an update of where we are at in each tech news? It could be more practical in case people suddenly start getting API issues without having seen the news weeks ago. Chaotic Enby (talk · contribs) 12:20, 12 August 2025 (UTC)[reply]
The issue where the only last invocation of mw.addWarning() on the page worked was, if I recall correctly, a regression, and SomeRandomDeveloper, who graciously submitted the patch fixing it, identified gerrit:731175, which was merged almost four years ago, to be the likely culprit. Did we not have mw.addWarning() working as expected for that long? (cc Trappist the monk) Nardog (talk) 14:27, 12 August 2025 (UTC)[reply]

Bridge over a dry ravine

[edit]

On a schema diagram, I am using the code uexhKRZWae to produce a bridge symbol for an under-construction rail line using it. The code shows water flowing under the bridge, which I do not want as the bridge passes over a dry ravine. I want to represent the bridge, as it is a substantial construction to carry a new tram line over a deep ravine. Is there a code for a bridge without the water? I looked at lists of schema codes without success. Thanks for any advice. TheTrolleyPole (talk) 01:30, 12 August 2025 (UTC)[reply]

You should ask this question on the relevant template's talk page or the relevant WikiProject's talk page. I would guess most people familiar with whichever flavor of schema you're referencing don't hang out here.
NB a dry ravine today is a flash flood warning tomorrow, so whether it's an actual river now is potentially irrelevant. Izno (talk) 02:46, 12 August 2025 (UTC)[reply]
@TheTrolleyPole: The full list is available at Template:Bsicon, and it's crazy how many different icons are available. You're probably looking for hSTRae, but there's a whole section full of bridge/viaduct icons. Jay8g [V•T•E] 03:23, 12 August 2025 (UTC)[reply]
File links are   (uexhKRZWae) and   (hSTRae). This would have been better posted at WT:RDT, but should really be asked at c:Talk:BSicon/New icons and icon requests. BTW: Template:Bsicon, here on English Wikipedia, is a long way short of the full set. All icons should be in c:Category:BSicon or its many subcategories. --Redrose64 🌹 (talk) 21:37, 12 August 2025 (UTC)[reply]

Coptic identity: Maintenance template has extra orange stripe

[edit]

On the Coptic identity article, the multiple issues notice contains an extra orange stripe partially intersecting with the bullet points. I tried safemode=1 and opening it in incognito (without any extensions and on Vector 2022 instead of 2010) and the issue persisted. It seems to be a CSS issue. Would someone be able to investigate? I'm on Firefox 141.0.2 (64-bit) though it also happened on Chrome version 139.0.7258.67 (Official Build) (64-bit). Thanks, OutsideNormality (talk) 01:34, 12 August 2025 (UTC)[reply]

Fixed. This was caused by Template talk:Ambox#Fix stripe and bg color in dark mode. * Pppery * it has begun... 01:38, 12 August 2025 (UTC)[reply]

'de-expand' page data beneath editor

[edit]

Whenever I edit an article, there's a cluster of data 'reports' beneath the editor, such as "Wikidata entities on this page", "This page is a member of X categories", etc.. That all would be fine, if each of the entries was not by default expanded, sometimes pushing the preview down an entire screen's length. I've looked through the various preferences and extensions I have in place and nothing stands out as a possible cause. I use monobook on PC, largely on Firefox. I also have the following scripts in my monobook.js, however, after disabling them there was no change, so I've re-enabled them - User:AzaToth/twinkle.js. User:Lupin/recent2.js, User:Omegatron/monobook.js, User:Dr_pda/prosesize.js. Thoughts, suggestions? cheers. anastrophe, an editor he is. 22:25, 12 August 2025 (UTC)[reply]

@Anastrophe: I can collapse those items and this setting is remembered so they start out collapsed next time. Do you have any Firefox settings against cookies? The preview is above the items for me in, also in MonoBook, so the preview isn't pushed down even if they are expanded. Is the preview really below the items for you? PrimeHunter (talk) 22:45, 12 August 2025 (UTC)[reply]
That's an interesting angle. I just checked my FF settings, and I did have a 'custom' setting configured for privacy; returned to standard privacy, but no joy. However, I also have uBlock origin installed. I disabled it for WP, collapsed the entries, then went into the editor on a large article - joy! As for your preview query, I by default have preview selected to be beneath the editor, and the cluster of data reports is between the editor and the preview. But now that it's collapsed, it's entirely livable. Many thanks! cheers. anastrophe, an editor he is. 23:28, 12 August 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1305585218"