Wikipedia:Village pump (technical)

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.

view · edit

Frequently asked questions (see also: Wikipedia:FAQ/Technical)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223

incategory searching

Tracked in Phabricator
Task T399730

Similar to this discussion from two months ago, an incategory search of Category:Living people (a check I have to perform several times daily, due to the constant addition of draftspace and userspace pages to it) is once again failing to clear and drop pages that were already removed from it hours ago.

The explanation last time was that "the indexing pipeline got stuck today...and no updates were being processed" — so that may have happened again, and I wanted to let people know so that it can be looked into and fixed. Bearcat (talk) 13:50, 16 July 2025 (UTC)[reply]

@Bearcat: It shows the time of the searched revision. Add sort=last_edit_desc to see results in descending order of that time, and you only have to examine pages with a newer time than the last time you fixed all pages. At least in theory. In practice, the previous time you made the search it may have missed pages which were added to the category recently in an edit which had not been indexed by that search. The category could also have been added by a template edit without editing the page. But I think it's good enough when it's not important whether a page stays a little longer in the category. PrimeHunter (talk) 14:41, 16 July 2025 (UTC)[reply]

There's nothing to "sort" — since the search isn't updating at all, it isn't picking up any new additions since my last cleanup run on the current contents either. But draft or user pages getting added to that category happens at a rate of at least 40 to 50 pages per day, and with over a million articles it's just not possible to manually browse the category for draft or user pages at all — so it's a search that needs to be performed several times a day and can't just wait a week, and we can't just let it slide as "not a problem" if the search is failing to update at all. Bearcat (talk) 15:03, 16 July 2025 (UTC)[reply]

Might a watchable subpage of Wikipedia:Database reports with output similar to quarry:query/95644 work better? (Admittedly, sometimes the database mirrors that both that and Quarry pull from sometimes get out of date too - try searching the VPT archives for "replication lag" - but it seems to happen less often.) —Cryptic 18:37, 16 July 2025 (UTC)[reply]

Replag won't be a factor if using the API though. It's possible to setup API-based reports like at User:SDZeroBot/Category:Living people outside mainspace. (I combined Ahecht's queries for userspace and draftspace, as the cmnamespace parameter is multi-valued.) – SD0001 (talk) 13:14, 22 July 2025 (UTC)[reply]

Yes, the api version is clearly superior. What I don't get is how it's so much faster - basically instant, when the query version consistently takes about ten seconds even when cached, and up to a minute otherwise. There's no possible index, so it still has to look through all 1.1 million members of the category. (Also, if we're going to link an api query, it should probably have all non-0/14 namespaces, not just 2 and 118 - the ones from talk: and so on are just as problematic.) —Cryptic 15:19, 22 July 2025 (UTC)[reply]

Theory: it's only looking at the first 500 results, and then filtering by namespace. Which is why clicking on the Talk link in the box on CAT:LP shows no results, despite there being four matching pages (Talk:David Dancrade, for example, which I deliberately haven't fixed). Also why my unsaved, aborted attempt to add a "non-article" link to {{APIQuery categorymembers/table}} shows nothing for Category:Living people but seems to work for Category:Automatic category TOC generates Large category TOC. Still some minimal value when using the recent links, I suppose, but anything not immediately caught would be lost forever. —Cryptic 16:27, 22 July 2025 (UTC)[reply]

That certainly is a thing that the API does in some cases. If you check the auto-generated documentation it even notes "using [cmnamespace] may result in fewer than cmlimit results returned before continuing; in extreme cases, zero results may be returned." If you follow the continuation, you'll eventually find any actual results. Anomie ⚔ 23:16, 22 July 2025 (UTC)[reply]

@Bearcat You can use Userspace pages from most recent and Draftspace pages from most recent to get the lists directly from the API without having to worry about search indexing. I added a collapsed box to Category:Living people that allows retrieving these lists for any namespace. --Ahecht (TALK
PAGE) 18:48, 16 July 2025 (UTC)[reply]

This specific instance of bad search data seems to have fixed itself before anyone could look into it. * Pppery * _{it has begun...} 21:47, 21 July 2025 (UTC)[reply]

Reply working erratically

Sometimes clicking on it works, sometimes it doesn’t. Doug Weller talk 19:25, 21 July 2025 (UTC)[reply]

Is it consistent how it fails? That is, does it always fail on certain comments or certain pages, or does it randomly go either way? DLynch (WMF) (talk) 21:00, 21 July 2025 (UTC)[reply]

Inconsistently. Sohom (talk) 21:12, 21 July 2025 (UTC)[reply]

Always works for me. Johnjbarton (talk) 23:24, 21 July 2025 (UTC)[reply]

Yeah, I've never seen it happen either. Makes me suspect it's a userscript or non-default gadget that's (unpredictably) adjusting the markup in the page that DiscussionTools uses to hook things up. DLynch (WMF) (talk) 01:22, 22 July 2025 (UTC)[reply]

I have zero scripts loaded at the moment and I still see it happening on a regular basis. Sohom (talk) 01:27, 22 July 2025 (UTC)[reply]

Okay, so I did some debugging and there are scenarios where mw.dt.init function just doesn't get called with #mw-content-text Sohom (talk) 02:07, 22 July 2025 (UTC)[reply]

That's interesting -- mw.dt.init is on a wikipage.content hook. Could you check whether that hook has fired at all when this happens to you? (And, I suppose, whether mw.dt.init actually exists? I'd think the DT modules failing to load is more likely than wikipage.content not firing, given how many things expect it to work.) DLynch (WMF) (talk) 02:32, 22 July 2025 (UTC)[reply]

This happens to me too. I have found it correlates with the "New section" button also not working. CMD (talk) 13:15, 24 July 2025 (UTC)[reply]

Makes sense -- it's the same initializer that sets them both up, and they use most of the same code. When you see this happen, do you find any errors in your browser's console?

(It would be much simpler if I could ever experience this myself. It happening to me once would be all I need to get a huge amount of debugging done. 😛) DLynch (WMF) (talk) 19:27, 24 July 2025 (UTC)[reply]

Interesting. I have the "new section" problem also. Doug Weller talk 07:08, 25 July 2025 (UTC)[reply]

I have been having this issue as well for past 3 weeks-ish and it is to the point I cannot participate in discussions without logging out then back in to make a comment. I am also experiencing this with adding new topics. My browser is Firefox. S0091 (talk) 20:08, 26 July 2025 (UTC)[reply]

I use Chrome. Doug Weller talk 20:15, 26 July 2025 (UTC)[reply]

Oh wow! It is letting me comment. Usually it only gives me one, especially on the same page. I thought it was something with me and I have tried removing scripts, fussing with browser settings, etc. so it is a relief others are experiencing the same but whatever this issue is, it desperately needs to be fixed. Pinging @DLynch (WMF). S0091 (talk) 20:22, 26 July 2025 (UTC)[reply]

Sadly, trying different browsers out hasn't helped me reproduce the issue. E.g. In Firefox right now I just reloaded this page ~20 times and didn't once experience broken reply buttons. DLynch (WMF) (talk) 19:28, 27 July 2025 (UTC)[reply]

@DLynch (WMF) you have to try to use the reply tool on multiple pages. So right now I can reply but I just experienced issues replying at WP:AFCHD so logged out and back in. S0091 (talk) 19:36, 27 July 2025 (UTC)[reply]

Ok, so at the time I posted the note above, I could reply at WP:AFCHD but I just refreshed the page and now I can't but it is letting me reply here. S0091 (talk) 19:42, 27 July 2025 (UTC)[reply]

I just refreshed this page and it is letting me reply both here and at AFCHD but normally refreshing does not work. I have to log out/in. S0091 (talk) 19:44, 27 July 2025 (UTC)[reply]

I just refreshed AFCHD again. It will not let me reply nor at User talk:TVresource. S0091 (talk) 19:45, 27 July 2025 (UTC)[reply]

Refreshed AFCHD again, it lets me reply. I also refreshed User talk:TVresource but it does not let me reply. 19:48, 27 July 2025 (UTC) S0091 (talk) 19:48, 27 July 2025 (UTC)[reply]

Just now, I started a new topic at WT:AFC about the reply tool and someone responded but I cannot respond. S0091 (talk) 21:01, 27 July 2025 (UTC)[reply]

@S0091: Are you unable to use the traditional method (click the "edit" link, position the cursor, type something followed by four tildes, click "Publish changes")? --Redrose64 🌹 (talk) 21:19, 27 July 2025 (UTC)[reply]

I'm having this issue as well, where sometimes it works and sometimes it doesn't. When I'm having the error, clicking reply does nothing. Clicking "Add topic" on a talk page loads the page with "&section=new&veaction=editsource" appended to the url but doesn't do anything else. The subscribe button also doesn't do anything when this is happening. Thebiguglyalien (talk) 🛸 20:44, 27 July 2025 (UTC)[reply]

I've had an issue over the last few weeks where sometimes clicking on reply just scrolls the page to the top. I did find if I open dev tools (F12), which has caching disabled, it then works. On FireFox, maybe 10-15% of the time. I've been meaning to look into it but it's always happened when I'm too busy to dig as I did think it was probably a user-script. If enough people report similar maybe a review of scripts will find the culprit. KylieTastic (talk) 21:44, 27 July 2025 (UTC)[reply]

I am also having this issue, for the last three weeks or so. It seems fairly random when it occurs. Often restarting the browser doesn't fix it, and I just have to wait and keep refreshing it. qcne (talk) 08:13, 28 July 2025 (UTC)[reply]

I use Microsoft Edge. qcne (talk) 08:14, 28 July 2025 (UTC)[reply]

Same problem here, been going on for a couple of months now.

I queried this at mw:Talk:Talk_pages_project#Problems_in_Vivaldi_browser, but it was suggested this might be because of my browser (Vivaldi) not being supported. Looks like there might be more to it, then.

As already noted above, whatever the problem is, it also affects other 'Talk pages project' functionality, esp. 'add topic', occasionally also 'subscribe'. --DoubleGrazing (talk) 12:27, 28 July 2025 (UTC)[reply]

Template:Nihongo romanizations looking off

Something's changed in how romanizations are shown with {{Nihongo}}. I'm not entirely sure what it is, but I think the Latin-alphabet romanized text might have been changed to use the font meant for Japanese text. It looks odd, and it doesn't work well with long vowels when bolded, e.g. komusō, an example from {{Nihongo}}'s own documentation.

I'm not able to find where the change was made, but I'm likely not able to edit it back anyway. Where was the change, and is there any way it could be put back to how it was before? Thanks. Ookap (talk) 03:05, 22 July 2025 (UTC)[reply]

Not knowing what it looked like in the past, I can't tell what difference there may be. Have you asked at Template talk:Nihongo? But if several other people do not see a change, the problem may be at your end - a browser upgrade, for instance. --Redrose64 🌹 (talk) 07:42, 22 July 2025 (UTC)[reply]

komusō looks fine to me, as does all of the other text at that template page. I suspect a change on the OP's end. The OP should try the usual tricks: look at it with a different browser, look at it while logged out, look from a different computer (e.g. go to a library). – Jonesey95 (talk) 12:27, 22 July 2025 (UTC)[reply]

It was a browser thing. Apologies. Ookap (talk) 17:25, 22 July 2025 (UTC)[reply]

Edit disappearing from watchlist

An occasional problem on this page is that of an edit not showing on the watchlist when all settings suggest that it should.

This edit popped up on my watchlist today, as a result of which I made this edit; and having saved it, the first edit vanished from Special:Watchlist. I've checked, and I am still watching the page. Yes, I do have "Expand watchlist to show all changes, not just the most recent" enabled. --Redrose64 🌹 (talk) 16:05, 22 July 2025 (UTC)[reply]

Do you have changes by you selected in the filters? ScottishFinnishRadish (talk) 16:14, 22 July 2025 (UTC)[reply]

That shouldn't make a difference, because (as I mentioned), I have "Expand watchlist to show all changes, not just the most recent" enabled. Other pages where I have made a subsequent edit still get listed as expected, such as, for example, to pluck something out of the air at random, Wikipedia:Village pump (technical). Anyway, where is this "changes by you" setting that you mention? It's not at Preferences → Watchlist, nor in Special:Watchlist itself, even with ?safemode=1 appended to the URL. --Redrose64 🌹 (talk) 21:14, 22 July 2025 (UTC)[reply]

In the previous cases I've seen (tracked as T364245), the edit in question didn't show up in the watchlist in the first place. If edits are now also disappearing after showing up initially, that sounds like a different issue. I can reproduce this, though: if I add the page to my own watchlist, only one edit is shown today (Redrose64's), and the other edit (Anohthterwikipedian's) is not shown. Perplexing. Matma Rex talk 21:38, 22 July 2025 (UTC)[reply]

The other edit is a page move, and it shows up if I also watchlist Template:Bhoj Metro blue Line Route (the redirect page). I can't remember what's the intended behavior of page moves on the watchlist if you're only watching the target page. However, if you were previously watching the source page, then that entry should have been copied (i.e. you should now have both the old and the new title on your watchlist). @Redrose64 Can you check whether that's the case for you? Matma Rex talk 21:45, 22 July 2025 (UTC)[reply]

Now that is a strange thing: the redirect isn't watched, only its target. They should both be watched, because a page move normally updates the watchlist to list both old and new names. --Redrose64 🌹 (talk) 07:44, 23 July 2025 (UTC)[reply]

I tried this locally on a test wiki and moving a page copied the watchlist entries for other users from the old title to the new one, as expected. At this point I suspect you must have accidentally unwatched the redirect. But if this happens again to you or anyone else, that would warrant further investigation. Matma Rex talk 09:42, 23 July 2025 (UTC)[reply]

T256069-like issue

Hello, am I the only one who is still experiencing T256069-like issues on mobile web? Not that images would disappear on scrolling to the bottom of a table, but they shrink significantly, which is confusing (because that is very disorienting, especially when browsing a series of large tables). Also, on some pages, the shrunk images are too small (at least on my smartphone) to be useful, e.g. List of paintings by Wassily Kandinsky. Janhrach (talk) 12:11, 23 July 2025 (UTC)[reply]

If you have images in a table, you need to give the images or the cells containing images a minimum size, or otherwise they will shrink to 0x0 —TheDJ (talk • contribs) 15:19, 23 July 2025 (UTC)[reply]

Thank you. But the sudden image shrinkage is still a bug, isn't it? Janhrach (talk) 15:24, 23 July 2025 (UTC)[reply]

It's not a bug, just a bad interaction with the CSS that wants to make images fit on mobile, since they may have a width that is larger than the width of a mobile device. They're set to have a maximum width of 100% along with one other change and that just doesn't interact well with how tables work. Izno (talk) 19:25, 23 July 2025 (UTC)[reply]

Honestly we should probably just nix the relevant CSS from applying in tables. Tables already have width issues and need separate fixing anyway, so this shrinkage just doesn't help in that case at all. Izno (talk) 19:23, 23 July 2025 (UTC)[reply]

Why do I now see all redirects are green?

Can someone explain what technical changes have been made so that redirects are now green, and why has this been done? I don't see how it's advantageous to have this setting, because for me it would seem to imply that there is something improper about having redirects and that they ought to be made into direct links, which after all defeats the original objective of putting redirects in place. Ohc ^{revolution of our times} 14:48, 23 July 2025 (UTC)[reply]

Have you installed something like User:Anomie/linkclassifier? CMD (talk) 14:56, 23 July 2025 (UTC)[reply]

Yes, looks like you're importing Schwede66's common.js into your vector.js, and that page in turn includes Anomie's linkclassifier script. Writ Keeper ⚇♔ 15:00, 23 July 2025 (UTC)[reply]

I use that tool, it's very useful, but in the mode where it's only enabled if I select it from the Tools menu. Wouldn't want it on all the time :) — Amakuru (talk) 20:03, 23 July 2025 (UTC)[reply]

mystery solved, thanks to all for your responses! — Preceding unsigned comment added by Ohconfucius (talk • contribs) 13:53, 27 July 2025 (UTC)[reply]

Cannot reply on talk pages

I was trying to reply to a user on my talk page using the "Reply" button, but clicking it did nothing (both with and without my adblocker on). However, "edit source" still works. I'm on Librewolf (Firefox fork) 140, X11, Arch Linux. thetechie@enwiki (she/they | talk) 01:24, 24 July 2025 (UTC)[reply]

Never mind, it appears to have fixed itself. Strange. thetechie@enwiki (she/they | talk) 01:31, 24 July 2025 (UTC)[reply]

Probably same as Wikipedia:Village_pump_(technical)#c-Doug_Weller-20250721192500-Reply_working_erratically above. Page reload usually helps. Ponor (talk) 02:32, 24 July 2025 (UTC)[reply]

Wikipedia statistics page small issue

Hi, I don’t really know if this is the place I should report this to but on WP:Statistics, there are some blue linked pages which do not exist anymore. There is only one instance where I saw this but it is possible that there could be more. The one that I noticed was “frameworks” on paragraph 3. Thanks MiniMikeRM (talk) 02:50, 24 July 2025 (UTC)[reply]

"frameworks" was a section link to the page itself but the section heading was removed.[1] I have updated the link.[2] PrimeHunter (talk) 03:12, 24 July 2025 (UTC)[reply]

Normally, if a link is the wrong colour, a WP:PURGE fixes it. --Redrose64 🌹 (talk) 19:51, 24 July 2025 (UTC)[reply]

Request for 2–4 redirect categories

I just created the redirect TNAP, which redirects from the name of a protein to the gene that codes for it. This kind of redirect is exceedingly common, since we usually have an article on just the protein or the gene, not both. It seems we don't have Rcats for this though. I would like to create some Rcat templates to track these cases: {{R to gene}} should say something like "This is a redirect to an article on a gene from the name of a protein it encodes", while {{R to protein}} should say "This is a redirect to an article on a protein from the name of the gene that encodes it". (Creating the corresponding "from" templates as well would be overkill.) Could anyone please make these for me or tell me how I could make them myself? And how would they get added to Capricon? Toadspike [Talk] 14:46, 24 July 2025 (UTC)[reply]

If you act now, you can rescue {{Rcat doc}} from deletion, by using it.
Just copying other rcats and tweaking the parameters should do it.
As for Capricorn, asking Wugapodes to edit User:Wugapodes/Capricorn/RedirectTemplates.json should do it. — Qwerfjkl talk 15:36, 24 July 2025 (UTC)[reply]

Heh, thanks. I have no idea how that template is supposed to work, so I'll take your advice and copy another Rcat. Toadspike [Talk] 19:38, 24 July 2025 (UTC)[reply]

I think "R from" names are usually preferred when practical like {{R from gene symbol}} which says something about the page it's on. {{R to gene}} could be many things, e.g. {{R from gene symbol}}. PrimeHunter (talk) 15:56, 24 July 2025 (UTC)[reply]

Very many Rcat names are exceedingly vague, with the specific "rules" in the actual text of the template. The same is true for "R from gene symbol", which is actually only for a specific kind of gene symbol from a specific organization, not for all gene symbols. So, I figured that short names are generally preferred over clear and specific names. If you prefer R from protein and R from gene, though, I can do that. Toadspike [Talk] 19:37, 24 July 2025 (UTC)[reply]

@Toadspike: Have you asked at Wikipedia talk:WikiProject Redirect? --Redrose64 🌹 (talk) 22:17, 24 July 2025 (UTC)[reply]

No...I didn't know it existed. Will take a look there before barreling ahead. Toadspike [Talk] 08:59, 25 July 2025 (UTC)[reply]

Temporary Accounts project update + Join us at Wikimania

Hello, I wanted to give you an update on the state of the Temporary Accounts project, the impact we see, and on the next steps.

In the second half of June, we rolled out temporary accounts on MediaWiki.org and 18 large and medium-sized Wikipedias including French, German, Chinese, Japanese, and more. On these wikis, we will invite community members to a survey where we will ask what they think about the new features and our communication. We will also conduct impact research, where we will check how temporary accounts make it easier or more difficult for users with extended rights to do their work.

On wikis where we deployed last year, we also conducted a similar survey (see the results here) and a quantitative analysis. In the latter, we found that temporary accounts did not pose any significant changes. The only notable change was a shift from IP-based blocking to temporary account-based blocking on our first set of pilot wikis.

You may monitor this dashboard to track changes from temporary accounts on projects where we are already deployed. The full list of these wikis is in the FAQ.

The final deployment on all remaining wikis is planned for September. We are considering options to limit the scope of that phase by rolling out to some wikis sooner. This is for the smallest communities and does not include English Wikipedia.

On a different note, our team has been recently merged with Security to form Product Safety and Integrity. To follow the progress on our projects, subscribe to our newsletter. Last but not least, we will have a Wikimania session about Temporary Accounts. You may also be interested in our other session: Updates from the Product Safety and Integrity team.

Thanks! NKohli (WMF) and SGrabarczuk (WMF) (talk) 00:04, 25 July 2025 (UTC)[reply]

Reply link not putting comments at the bottom

On Wikipedia:Articles for deletion/Andy Byron, if one attempts to !vote by replying to the nomination statement using the default DiscussionTools reply link (not those fancy gadgets like Factotum), the vote will not be put at the bottom, but rather before the first collapsible on the page. You can see a bunch of new comments piled up right before the collapsible due to this, with the first few comments after the collapsible being days before. I tried a test where I indented the {{collapse top}} template with :; that did not work. Does anyone have an idea as to how to fix it? OutsideNormality (talk) 02:45, 25 July 2025 (UTC)[reply]

I think this is a universal issue. I ended up just editing the page and adding my vote. Not sure if theres an actual fix Metallurgist (talk) 03:34, 25 July 2025 (UTC)[reply]

It makes sense with how it works. The threads parsed from that page are based on the rendered HTML, not the wikitext, for determining indentation. And particularly not on the pre-template-insertion wikitext.

On the AFD page the collapse_top is on a new line outside of the comment it's wrapping, so it's a top-level element, and the parser interprets that as the end of the previous thread and the start of a new one.

On your sandbox it's closer to working because you're maintaining the indentation-level at the start. Unfortunately, when the template is substituted into the wikitext before rendering it into HTML, it brings along its own linebreaks that result in the list being closed out and a new top-level element starting.

The ultimate solution would be us finally getting some progress on T230683 which would add wikitext syntax for multiline list items.

A medium-term fix for something like this could perhaps involve us looking into filtering out the mw-archivedtalk elements that templates like collapse_top are using entirely from the indentation calculations. I'm not sure how well that would work, though.

As a hacky solution for now, you could move the collapsed comments to another section. It's really not ideal, because it fails to preserve their original context, but it would stop this. DLynch (WMF) (talk) 03:39, 25 July 2025 (UTC)[reply]

Discussion at WT:XFDcloser § Circular redirects in hatnotes

You are invited to join the discussion at WT:XFDcloser § Circular redirects in hatnotes. Left guide (talk) 03:26, 25 July 2025 (UTC)[reply]

Gadget setting

I am not sure if this is the correct place, but is it possible to change the default color of the gadget "Display links to disambiguation pages in orange" to yellow or something? The orange is difficult to distinguish from a red link. Thanks. Metallurgist (talk) 03:33, 25 July 2025 (UTC)[reply]

@Metallurgist: The code is in MediaWiki:Gadget-DisambiguationLinks.css. You can disable the gadget and make your own version with another color in your CSS. Screens and vision vary but the current orange color is very easy to distinguish from a red link like this for me and probably most others. Yellow text is difficult to read on a white background so I oppose changing the default in the gadget. PrimeHunter (talk) 09:30, 25 July 2025 (UTC)[reply]

Actually I just realized this is because I use dark mode. In white background, they are more distinguishable, so this is an issue with dark mode, altho I am sure there must be a more distinct color that would work well on both. I also just color blind tested it with this and it does seem to be an issue with dark mode and they still look distinct enough on light mode. So I guess this is a dark mode issue. Thanks for at least getting me in that direction haha! Metallurgist (talk) 19:53, 25 July 2025 (UTC)[reply]

I have added a color flip to the gadget. Izno (talk) 22:19, 25 July 2025 (UTC)[reply]

Captioning issue

Users have reported an issue with the caption of a picture overlapping with the picture itself when viewing on mobile. See discussion at Talk:September_11_attacks#Semi-protected_edit_request_on_23_July_2025. Anyone know how to fix? meamemg (talk) 16:54, 25 July 2025 (UTC)[reply]

Watchlist 'Saved filters' drop down box moving right to left then back again.

As the title really, a couple of weeks ago my saved filters box moved from the right side of the page to the left. I wasn't sure what had happened just knew that something had changed. Today the box moved from the left back to its original position on the right, I'm fairly sure that I have made no preference settings changes to cause it. Does anyone know why this is happening? It would be great to find it in the same place every day. Nimbus (Cumulus nimbus floats by) 17:43, 25 July 2025 (UTC)[reply]

It looks like that was a layout-bug for a couple of weeks: phab:T398374. It has now been fixed. Quiddity (WMF) (talk) 20:19, 25 July 2025 (UTC)[reply]

Thanks, this can be archived assuming it doesn't move again! Nimbus (Cumulus nimbus floats by) 08:59, 26 July 2025 (UTC)[reply]

Changes not being saved

Are edits to certain articles "throttled"? I made four edits to a BLP article and now I can't make any more. Is there a cooldown to editing or is it a technical issue? TurboSuperA+_(talk) 06:00, 26 July 2025 (UTC)[reply]

I can change the prose, fix refs, etc. but for some reason I can't do the pipe trick on the links in the article (Clara Mateo) for some reason. In an edit where I change both the prose and add the pipe trick, the prose changes are saved but the links are all reverted to their previous form. I can't even change [[France women's national football team|France women's national football team]] to [[France women's national football team|]]. Is this expected behaviour? TurboSuperA+_(talk) 06:11, 26 July 2025 (UTC)[reply]

But I can change it to [[France women's national football team]]. Looks like the pipe trick doesn't work because Paris FC is an existing article and the system doesn't want to create a pipe link if the resulting link will be a WP:EASTEREGG. I think I figured out what I've been doing wrong. TurboSuperA+_(talk) 06:13, 26 July 2025 (UTC)[reply]

@TurboSuperA+: It doesn't matter whether the article exists. It sounds like you have just misunderstood what the pipe trick does. [[Foo|]] makes a piped link for any value of Foo, and it saves it as [[Foo|Something]] where "Something" may be a shortened version of "Foo". For example, [[Foo (disambiguation)|]] saves as [[Foo (disambiguation)|Foo]] which renders as Foo. If there is nothing to "pipe away" like a disambiguation in parentheses then it just saves as [[Foo|Foo]]. In your example it already said that so there was no change. If an edit makes no change to the saved text then it becomes a null edit which is not registered in the page history. PrimeHunter (talk) 10:09, 26 July 2025 (UTC)[reply]

Oh ok, thanks for the answer.

If an edit makes no change to the saved text then it becomes a null edit which is not registered in the page history.

Even when I changed other things, the piped link didn't change. So I changed prose and the links, the prose changes got saved while the link ones didn't. When I was doing the link changes only, then the edits were being nullified (and that was confusing me), so thank you for clearing it up. TurboSuperA+_(talk) 10:13, 26 July 2025 (UTC)[reply]

I have created phab:T400539: "Pipe trick should remove pipe if there is no change". PrimeHunter (talk) 11:08, 26 July 2025 (UTC)[reply]

Horizontal scrolling

I would appreciate help with Template:Family tree. I have a problem when I add too many people in the same generation. The names become squeezed into multiple lines, and so the tree as a whole becomes taller. See User:Surtsicna/Genealogy for an example. How can I make the tree scrollable left to right instead? Surtsicna (talk) 15:45, 26 July 2025 (UTC)[reply]

uw-brd template functionality

Can anyone who's versed in template editing take a look at the malfunctioning {{uw-brd}} and this related discussion on its talk page? — Fourthords | =Λ= | 17:28, 27 July 2025 (UTC)[reply]

Category:Harv and Sfn no-target errors question

AFGE v. Trump appears in the above Category. I think I figured out why...the sfn cites all link to nothing. Because a Template:Sfn whitelist was invoked and that template is basically stepping into the error notification process and stopping the notifications from happening. At least I think that's what it is... - Shearonink (talk) 03:44, 28 July 2025 (UTC)[reply]

The problem was that the last citation id was missing from the whitelist. The short citations link just fine. – Jonesey95 (talk) 04:14, 28 July 2025 (UTC)[reply]