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 five 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, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Heading markup changes

The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.

MediaWiki message delivery 23:01, 20 May 2024 (UTC)[reply]

Based on a quick search, it looks like the heading change will affect almost 300 scripts, many of which have inactive maintainers. Some arbitrary highlights from the top of the list include:

Plus many, many more. --Ahecht (TALK
PAGE) 19:22, 21 May 2024 (UTC)[reply]

A quick way to test these scripts right now, is to enable the Parsoid beta option (which already uses the new html structure) and to disable DiscussionTools, which uses a partial form of the new heading structure. —TheDJ (talk • contribs) 08:39, 22 May 2024 (UTC)[reply]

Indeed, you can already see it in Parsoid mode (but note that there are other differences – e.g. Parsoid output has <section> tags around each section, which may require a separate set of updates in some scripts).

Disabling DiscussionTools doesn't actually change anything though. The HTML structure is the same whether it's enabled or disabled, only the styles are different. Also, note that it uses a "hybrid" heading structure currently when using the default parser, as you say, but it uses the new structure when using Parsoid.

So in short, you can just use Parsoid mode to test these scripts today here on English Wikipedia, but beware that there may be extra issues. But if they work with Parsoid, they will work with the new headings too. Matma Rex talk 11:25, 22 May 2024 (UTC)[reply]

The technical 13 script was blanked, so we don't have to worry about that one.

Will the fact that they're rolling this out for only some wikimedia-deployed skins at this time make the patch more complicated? If I'm reading it right, the scripts may temporarily have to support both heading styles. –Novem Linguae (talk) 09:16, 22 May 2024 (UTC)[reply]

Yes, it does, and they have to. Matma Rex talk 11:20, 22 May 2024 (UTC)[reply]

At a glance, it seems that User:Mr. Stradivarius/gadgets/SignpostTagger.js already supports the new style, as it uses $( '#bodyContent h2:first' ).text() as a backup if $( '#bodyContent h2:first span.mw-headline' ) doesn't exist (line 291). — Mr. Stradivarius ^{♪ talk ♪} 13:09, 22 May 2024 (UTC)[reply]

Fixed RFUD-helper. Thanks for the ping. – SD0001 (talk) 18:33, 22 May 2024 (UTC)[reply]

This is going to break both my edit request scripts, I will try to fix them at the weekend. Terasail ^[✉️] 18:41, 22 May 2024 (UTC)[reply]

I've fixed my fork of the OneClickArchiver script (though now it only works with the new format; I don't care enough to get it working with both). Elli (talk | contribs) 02:09, 8 June 2024 (UTC)[reply]

And copy-section-link too (same caveat). Elli (talk | contribs) 02:16, 8 June 2024 (UTC)[reply]

Another one: User:Σ/Testing_facility/Archiver.js. Izno (talk) 00:45, 7 June 2024 (UTC)[reply]

And a couple other gadgets still remaining:

Izno (talk) 00:51, 7 June 2024 (UTC)[reply]

Gadget-teahouse is no longer used now that DiscussionTools has been rolled out. Pinging @Prtksxna and @TheDJ for the other two. --Ahecht (TALK
PAGE) 15:54, 12 June 2024 (UTC)[reply]

Σ's Archiver script has been superseded by forks. See subsection just below: #Tech News – User:Enterprisey/archiver.js. —⁠andrybak (talk) 01:19, 7 June 2024 (UTC)[reply]

I had no idea that one had gotten forked. Izno (talk) 01:24, 7 June 2024 (UTC)[reply]

Gadget-autonum (Auto-number headings)

I'm assuming ~ and feel free to correct me if i'm wrong ~ that something about this deployment is why headings no longer have numbers (for me)? Will it be possible to go back to that at some point? I find long pages almost impossible to navigate around without numbered headings, so will have to learn a new way of working if it won't be possible. Thanks, Happy days, ~ Lindsay^Hello 16:24, 27 May 2024 (UTC)[reply]

@LindsayH: No, that was removed a while ago. You may try the "Auto-number headings" gadget here. Nardog (talk) 19:31, 27 May 2024 (UTC)[reply]

If you're speaking about the table of contents, Vector 22 does not provide numbering. Vector, Monobook, and Modern do.

If you are speaking about each actual heading, then indeed the preference is gone and indeed there is a gadget for it now. You have correctly identified that gadget as needing to be updated for this change. It looks like the necessary change to the snippet (documentation) has already been made, so someone needs to port that here. Izno (talk) 19:59, 27 May 2024 (UTC)[reply]

Thank you, Izno, helpful. I'd assumed it was a script/gadget, as so many appeared to be affected above. I shall patiently wait in hope

Happy days, ~ Lindsay^Hello 11:51, 28 May 2024 (UTC)[reply]

@LindsayH. I think I fixed this gadget for monobook/timeless/modern with this update. But there is still a double number bug on some talk pages on vector/vector-2022. Will work on that next. –Novem Linguae (talk) 16:50, 1 June 2024 (UTC)[reply]

You star! Thanks for the notification (and, of course, for fixing it). Happy days, ~ Lindsay^Hello 06:14, 2 June 2024 (UTC)[reply]

Tech News – User:Enterprisey/archiver.js

I've been testing my fork of Enterprisey's script – User:Andrybak/Archiver. Example edits: 1226884323, 1227442551, 1227443165, 1227444165. So far, the script doesn't seem to be affected. —⁠andrybak (talk) 19:21, 5 June 2024 (UTC)[reply]

✅ Another successful test with random things (including cases, which were mentioned in bug reports): Special:Diff/1227451320. —⁠andrybak (talk) 21:33, 5 June 2024 (UTC)[reply]

Did you try all the old skins such as Timeless and Monobook? Vector isn't affected at all yet, and editing likely uses the API, but I can imagine the location of the header links this script places being possibly broken in old scripts. I fixed this kind of thing in 2 gadgets so far. –Novem Linguae (talk) 22:15, 5 June 2024 (UTC)[reply]

I know that Σ's User:Σ/Testing facility/Archiver supported at least Timeless: User talk:Σ/Archive/2021/January#Archy McArchface button caption in Timeless, so I expect Enterprisey's version to have remained compatible with other skins.

Good shout.

Checking... —⁠andrybak (talk) 22:28, 5 June 2024 (UTC)[reply]

Facepalm argh, I didn't read past the first sentence. My bad. Thank you, Novem Linguae, for pointing it out. —⁠andrybak (talk) 22:44, 5 June 2024 (UTC)[reply]

Novem Linguae, support for MonoBook and Timeless has been added: Special:Diff/1227543602. —⁠andrybak (talk) 11:22, 6 June 2024 (UTC)[reply]

Tests on real discussions: MonoBook, Timeless, Vector 2010, Vector 2022. —⁠andrybak (talk) 11:47, 6 June 2024 (UTC)[reply]

New h2 headings use serif font even when the "Vector classic typography" gadget is enabled

Vector classic typography is a gadget that forces all text to use sans-serif fonts, but even with the gadget enabled h2 headings on articles use a serif font. Incorrect behavior seen on both Firefox and Edge. TomatoFriesLAN (talk) 18:51, 6 June 2024 (UTC)[reply]

@TomatoFriesLAN Thanks for reporting, this is caused by the heading changes announced two weeks ago, which were deployed to legacy Vector as well this week. This edit should fix it: [1] – please try now. Matma Rex talk 20:27, 6 June 2024 (UTC)[reply]

Works, good job. TomatoFriesLAN (talk) 03:53, 7 June 2024 (UTC)[reply]

XFDcloser

I usually spend part of the day closing AFD discussions but none of the XFDcloser options are showing up. Not even the ability to relist. I've uninstalled every installation, unchecked the XFDcloser gadget, returned everything to normal but nothing works. Do I have to reboot my computer or something? Log out and log back in? This rarely happens so I'm not sure what happened today. I've posted a message on the XFDCloser talk page but it doesn't get much activity there. Liz ^{Read! Talk!} 23:26, 6 June 2024 (UTC)[reply]

It's not an XFDC issue, it's a THURSDAY issue. Primefac (talk) 00:35, 7 June 2024 (UTC)[reply]

Izno, I see you've moved this section, and it does appear to be mentioned in the original post of this threading, but why would it only appear now? I seem to recall closing discussions earlier this week (and I suspect Liz has as well). Primefac (talk) 01:17, 7 June 2024 (UTC)[reply]

I mean, it could not be this, and you're welcome to move it back, it just has the smell. Izno (talk) 01:24, 7 June 2024 (UTC)[reply]

I patched xfdcloser a couple days ago, so a new bug today is probably something else. Will take a look. –Novem Linguae (talk) 02:52, 7 June 2024 (UTC)[reply]

Well, I thought this thread was deleted until I found it reposted up here.

It's odd because XFDCloser was working fine this morning and then this afternoon, it just didn't load at all. But I see other editors closing discussions so I hope it isn't just me. I've had ongoing problems with XFDCloser not loading on CFD pages but it hasn't been a problem on AFD daily logs until today. Thanks for checking Novem Linguae, there are usually over 100 AFD discussions daily so if this is happening for other closers, they could pile up pretty quickly. If it matters, I use a laptop with Windows. Liz ^{Read! Talk!} 03:17, 7 June 2024 (UTC)[reply]

It's still working in Vector 2022, so changing your preferences temporarily is a workaround. Hopefully the issue will be fixed soon. Extraordinary Writ (talk) 03:39, 7 June 2024 (UTC)[reply]

I figured out the cause. I should have a fix deployed soon.

For the record, it looks like WMF deployed mw:Heading HTML changes to old skins (monobook, timeless, modern, cologneblue) last week, vector (2010) this week, and probably minerva and vector-2022 in the coming weeks. All breakages we see today will probably be vector (2010) only.

This staggered deployment has pros and cons. It means that if someone like me does fix a bunch of gadgets today, I'll just have to go fix them all again next week when they break on vector-2022.

It would be nice if there were an API for inserting header links. phab:T337286. APIs like mw.util.addPortlet(), mw.util.addPortletLink(), etc are great for multi-skin support and for keeping HTML changes from breaking gadgets and user scripts. –Novem Linguae (talk) 05:43, 7 June 2024 (UTC)[reply]

Yeah, I don't understand all of this jargon but I am FOREVER grateful that their are editors who do. Thanks for looking into this. Liz ^{Read! Talk!} 06:33, 7 June 2024 (UTC)[reply]

Fix deployed for XFDcloser. Should be fixed within the next 15 minutes (gadget code is cached for up to 15 minutes). –Novem Linguae (talk) 06:35, 7 June 2024 (UTC)[reply]

I see I did use Vector Legacy 2010. I don't like for page formatting and white space of the updated Vector 2022. Liz ^{Read! Talk!} 06:37, 7 June 2024 (UTC)[reply]

I also use Vector 2010. Best skin :) –Novem Linguae (talk) 06:38, 7 June 2024 (UTC)[reply]

I am looking forward to Vector 2034 — GhostInTheMachine ^{talk to me} 06:51, 7 June 2024 (UTC)[reply]

Yeah, and I don't like the left-side menu. But thanks Novem Linguae, it looks like things are now back to normal. I can go back to my old skin! Many thanks. Liz ^{Read! Talk!} 07:24, 7 June 2024 (UTC)[reply]

Novem Linguae, XFDCloser disappeared again! I think you said this might happen. It came back when I changed to Vector 2022 but, ugh! I guess I'll use that skin when working in AFDLand and then change back when doing regular editing. Liz ^{Read! Talk!} 22:15, 8 June 2024 (UTC)[reply]

I'm trying out Timeless. It's not as bad as Vector 2022. Liz ^{Read! Talk!} 22:32, 8 June 2024 (UTC)[reply]

But it doesn't work with Twinkle. Liz ^{Read! Talk!} 01:53, 9 June 2024 (UTC)[reply]

Well, XFDcloser returned to operational status. Thanks to whomever fixed that. Liz ^{Read! Talk!} 03:13, 9 June 2024 (UTC)[reply]

Very strange. I haven't done any work on XFDcloser since the last deploy on Thursday, and I don't see any relevant backport patches at wikitech:Server Admin Log that might have changed MediaWiki behavior this weekend. This is all quite mysterious. –Novem Linguae (talk) 08:56, 9 June 2024 (UTC)[reply]

Novem Linguae, it's just happened again, over the span of the past hour! This is getting annoying to have to keep changing skins. Liz ^{Read! Talk!} 23:31, 12 June 2024 (UTC)[reply]

@Liz. I deployed a fix related to the beta version of XFDcloser. Can you try Vector again and let me know if things are fixed? –Novem Linguae (talk) 00:48, 13 June 2024 (UTC)[reply]

User script that puts a ¶ symbol next to headings

What's the user script or gadget that puts a ¶ symbol next to headings, and when you click on it, it opens a modal with links to that section that you can copy/paste? It broke for me today and I want to fix it, but can't remember what it's called. Thanks. –Novem Linguae (talk) 03:35, 7 June 2024 (UTC)[reply]

Is it User:Enterprisey/copy-section-link? Sounds like what you described, but I don't see where you have it imported. – 2804:F14:809B:2701:19B4:583A:7C56:999F (talk) 04:22, 7 June 2024 (UTC)[reply]

Ah, it's in my global.js. No wonder I couldn't find it. Thank you very much for this link. –Novem Linguae (talk) 06:37, 7 June 2024 (UTC)[reply]

I wrote a script that provides links to user comments as well as headings, which I updated to support both the new and legacy methods of marking up headings. Its interface is a bit different though from the copy-section-link script. isaacl (talk) 06:23, 7 June 2024 (UTC)[reply]

I can't find where the script is putting the link(s) on Vector 2010. Any hints? –Novem Linguae (talk) 07:04, 7 June 2024 (UTC)[reply]

The function showCommentLinks() (starting on line 73) adds the links. The section of code starting at line 84 finds headings in the HTML document structure previously generated by MediaWiki (which I believe is the same across skins). The section of code starting at line 93 finds headings in the currently generated HTML document structure. isaacl (talk) 15:27, 7 June 2024 (UTC)[reply]

I was hoping you'd just tell me where the links are. lol. Anyway, I put a breakpoint on line 75 and the breakpoint is not getting hit when I refresh this page. I'm missing something. –Novem Linguae (talk) 20:33, 7 June 2024 (UTC)[reply]

I'm sorry, I didn't realize you were asking about the interface. As described in the documentation, you have to select the "Toggle link2clipboard" item in the tools menu (the location of the menu depends on your skin; for Vector 2010 it's in the left sidebar). </> is prepended to the start of each comment. For headings, <h/> is also prepended. Most of the time I don't want to see the links, so I chose to require an extra step to display them. Another difference from the other script is that for the major non-Safari browsers, the link text is automatically copied to the clipboard (always without surrounding square brackets; the other script can be configured not to do that if desired). isaacl (talk) 20:51, 7 June 2024 (UTC)[reply]

Nice, that worked. Thanks a lot. Feature idea: Add a way to copy it as an external link. I do this a lot when writing GitHub or Phabricator tickets, for example. –Novem Linguae (talk) 20:59, 7 June 2024 (UTC)[reply]

As my personal frequent use case is to link to comments or sections in wikitext, I wanted a way that would provide easy access to the link without underscores ;-) (And I chose to avoid square brackets as it's easier to add them when needed than delete them, and I like to use {{section link}} when feasible.) I'll take it under consideration, though; thanks for the feedback! isaacl (talk) 21:08, 7 June 2024 (UTC)[reply]

@Novem Linguae: I made a copy of Enterprisey's script with this fixed, if you'd like to switch to it: User:The Earwig/copy-section-link.js. — The Earwig (talk) 03:37, 20 June 2024 (UTC)[reply]

And I've just been informed that Enterprisey has replicated the fix to his version. — The Earwig (talk) 03:45, 20 June 2024 (UTC)[reply]

It seems that User:Enterprisey/copy-section-link.js and User:The Earwig/copy-section-link.js broke again after WP:THURSDAY. They put "undefined" after the hash (Wikipedia:Village pump (technical)#undefined instead of Wikipedia:Village pump (technical)#Heading markup changes), and don't work on headings other than ==second level== (<h2>). —⁠andrybak (talk) 10:20, 22 June 2024 (UTC)[reply]

To fix the issue I described above, I re-used similar code for finding the section headings from User:Andrybak/Archiver.js (as described just above in #Tech News – User:Enterprisey/archiver.js). Enterprisey and The Earwig, please see Special:Diff/1230446524/1230449212. —⁠andrybak (talk) 19:31, 22 June 2024 (UTC)[reply]

More changes were necessary:

new CSS selectors needed because of the layout changes. <h3>, <h4>, <h5>, and <h6> no longer get CSS class .mw-heading. Hmm 🤔, is that intentional or a bug?
target.append instead of target.after to handle pages with non-conventional ways of adding headings, like Wikipedia:Community portal and Main Page
Main Page is still a bit awkward because of the comma treatment (diff1, diff2). Though it seems better than in original version, which caused some glitches (pilcrow wrapping to a new line or something like that), requiring workarounds.
font-size: initial to counteract font-size: small of class .mw-editsection, which we now have to deal with because of #2.

—⁠andrybak (talk) 21:42, 25 June 2024 (UTC)[reply]

Section header typeface

I just noticed that section headers in articles are now using a serif typeface on both Vector and Vector legacy. Sorry I couldn't find information about this elsewhere but when and why was this change made? I do not like that it uses Oldstyle figures and would like to change it in my settings or .css page to be the same sans serif font used in other headers. Thanks! Reywas92^Talk 17:23, 7 June 2024 (UTC)[reply]

@Reywas92 Vector headers have actually been using serif fonts by default for a long time, but you have user CSS which was overriding that. It no longer works due to some changes to heading HTML. You can either change that part of your user CSS to:

h1, h2, .mw-heading1, .mw-heading2 {
    font-family: inherit !important;
}

Or alternatively just use the gadget "Vector classic typography" which has already been fixed. the wub "?!" 19:25, 7 June 2024 (UTC)[reply]

Thank you! Forgot they did that a decade ago, these numerals are awful. Reywas92^Talk 20:23, 7 June 2024 (UTC)[reply]

One click archiving not working?

I have been using User:Evad37/OneClickArchiver for some time, but I noticed the other day that the archiving links are no longer appearing for me. Anyone know why that might be? Just Step Sideways ^{from this world ..... today} 18:06, 9 June 2024 (UTC)[reply]

Just Step Sideways, see § Heading markup changes. I believe User:Andrybak/Archiver is a working ~~fork~~. — Qwerfjkl talk 18:08, 9 June 2024 (UTC)[reply]

Thanks for the pointer! I guess I'm off to install that. Just Step Sideways ^{from this world ..... today} 18:13, 9 June 2024 (UTC)[reply]

Well, that works, but it certainly isn't "one-click". Oh well. Just Step Sideways ^{from this world ..... today} 18:17, 9 June 2024 (UTC)[reply]

Just Step Sideways and Qwerfjkl, there are two kinds of scripts, which make semi-automatic archiving easier. Page Wikipedia:One click archiving lists User:Evad37/OneClickArchiver as the most recent script for "One click archiving". My User:Andrybak/Archiver is the latest for "Multi-section archiving". —⁠andrybak (talk) 18:28, 9 June 2024 (UTC)[reply]

I didn't mean to disparaige your script,it works just fine, while currently, the Evad one does not. Just Step Sideways ^{from this world ..... today} 18:44, 9 June 2024 (UTC)[reply]

No disparagement taken. From Qwerfjkl's reply it might seem like User:andrybak/Archiver is a fork of User:Evad37/OneClickArchiver, but it's not. I just wanted to ensure there's no confusion about that. —⁠andrybak (talk) 18:49, 9 June 2024 (UTC)[reply]

Apologies, my mistake. — Qwerfjkl talk 19:30, 9 June 2024 (UTC)[reply]

It looks like Elli and FlightTime have recently worked on their copies of OCA. Are yours functioning in the new structure? Izno (talk) 21:00, 9 June 2024 (UTC)[reply]

Yep, mine works :) Elli (talk | contribs) 21:05, 9 June 2024 (UTC)[reply]

Elli, please consider adding your script to Wikipedia:One click archiving and Wikipedia:User scripts/List#Discussions 3. —⁠andrybak (talk) 21:57, 9 June 2024 (UTC)[reply]

I've now done so. Elli (talk | contribs) 22:07, 9 June 2024 (UTC)[reply]

@Just Step Sideways ^ Izno (talk) 22:06, 9 June 2024 (UTC)[reply]

Nice, just installed it works great. Thanks all. Just Step Sideways ^{from this world ..... today} 17:19, 10 June 2024 (UTC)[reply]

Neat! I came to VPT just to browse, and not even 10 sections in, I learned of a script that deals with the new header markup. Rusty4321 ^{talk contribs} 01:34, 14 June 2024 (UTC)[reply]

OneClickArchiver disappeared...Answers found here

Very handy gadget for manual-archiving - User:Evad37/OneClickArchiver.js - but it isn't showing up today on any talk pages for me. Don't know why, the script is still sitting on my common.js page. Has it been disabled/usurped by a better gadget? Why isn't it showing up?... Help please & thanks, Shearonink (talk) 14:48, 15 June 2024 (UTC)[reply]

Ok so after posting the above query I have now read through some of the other threads about archiver scripts... Is there a present script or fork that works on individual sections/posts/threads like Evad37's used to do? Shearonink (talk) 14:54, 15 June 2024 (UTC)[reply]

Forgot to add...I am editing with Vector 2010 original/legacy if that make a difference. Shearonink (talk) 14:57, 15 June 2024 (UTC)[reply]

For anyone who is as much of a non-adept at code & tech stuff around here and has Evad37's one-click oneclick one click archive script installed, and wants the same functionality, do the following:

go to the Wikipedia:One click archiving page.
navigate to Wikipedia:One click archiving#One click archiving (1CA) section.
See User:Elli/OneClickArchiver listed there? It is an updated 2024 script that is maintained and fixes some issues with Evad37's script (having to do with the 'Heading markup changes' mentioned at the top of this page.
Follow the instructions at the User:Elli/OneClickArchiver page.
Yay! You made it. - Shearonink (talk) 15:49, 15 June 2024 (UTC)[reply]

Broken template in Vector 2010

It would appear that these recent changes have broken Evad37's WP:Highlight duplicate links script in Vector 2010, which now no longer distinguishes between repeated links in the lead section and repeated links in the article body. ‑‑Neveselbert (talk · contribs · email) 18:20, 14 June 2024 (UTC)[reply]

Script works for me. What kind of skin are you using ? —TheDJ (talk • contribs) 18:41, 14 June 2024 (UTC)[reply]

Oh lol, it was in the title :) Anyway. works with vector 2010 for me. —TheDJ (talk • contribs) 18:42, 14 June 2024 (UTC)[reply]

This seems unrelated. Should be moved out to its own section. Nothing has changed in Vector 2010 skin. 🐸 Jdlrobson (talk) 20:01, 14 June 2024 (UTC)[reply]

@TheDJ and Jdlrobson: On Elizabeth II, using Vector 2010, the script highlights links in the lead section which shouldn't be highlighted, as they're not repeated in the lead section, and highlights links (in red) that are the first instances of those links in the article body. This does not occur in Vector 2022. ‑‑Neveselbert (talk · contribs · email) 22:49, 14 June 2024 (UTC)[reply]

This is indeed caused by mw:Heading HTML changes. I think this needs to be fixed in User:Evad37/duplinks-alt.js. It should be sufficient to replace this line:

if (this.nodeName.toLowerCase() == 'h2') {

with this:

if ( $(this).is('h2, .mw-heading2') ) {

(cc @Evad37) Matma Rex talk 08:46, 15 June 2024 (UTC)[reply]

I made an edit request: User talk:Evad37/duplinks-alt.js#Update for mw:Heading HTML changes Matma Rex talk 17:03, 18 June 2024 (UTC)[reply]

help desired

Real life has kept me away for the better part of a fortnight; I really shouldn't be taking the time to write this...

I have a script User:Trappist the monk/HarvErrors.js that is a tweaked copy of User:Ucucha/HarvErrors.js. Some of those tweaks were my own to turn down the glare of the red error messages that Ucucha's script produced. At some point someone asked me for further tweaks. What I know about javascript can be put in a thimble so I had to rely on the expertise of other more javascript fluent editors.

My script may have become broken because of the mw:Heading HTML changes. I suspect that the broken code is at lines 46–48. The code is supposed to make three separate lists of references found in each of an article's §External links, §Further reading, and §Publications sections. The purpose of that is to suppress the error messaging that would occur if any reference in those sections duplicates or can be linked from a short-form reference ({{sfn}} and the like).

With my script installed for example, this version of Rudolf Roessler (permalink) shows Harv error: linked from CITEREF... for every reference in (§Bibliography (permalink)). Those were 'fixed' by renaming §Publications to §Works (diff).

Is there anyone out there who would be willing to show me how to fix the issue? Because I'm not really here for the time being, a post on my talk page will find me via an email notification from MediaWiki.

Thank you.

—Trappist the monk (talk) 17:05, 19 June 2024 (UTC)[reply]

@Trappist the monk I'm not sure if I understand exactly what the script should do, however, I think it may be enough to add .mw-heading2 to the selectors in those 3 lines, like this:

		var further_reading = $content.find('#Further_reading').parent().nextUntil('h2, .mw-heading2').find('.citation').get();	// get all cites inside a Further reading section
		var external_links = $content.find('#External_links').parent().nextUntil('h2, .mw-heading2').find('.citation').get();		// get all cites inside a External links section
		var publications = $content.find('#Publications').parent().nextUntil('h2, .mw-heading2').find('.citation').get();			// get all cites inside a Publications section

Matma Rex talk 17:25, 19 June 2024 (UTC)[reply]

@Matma Rex: Ding! Ding! Ding! That works though I don't understand why it works. Thank you.

—Trappist the monk (talk) 13:56, 21 June 2024 (UTC)[reply]

The HTML nesting of headings changed recently. The fix done above is to check for both the old and the new selector (h2, .mw-heading2), until all skins are switched over in a couple weeks, at which point just the new selector can be used. –Novem Linguae (talk) 21:02, 21 June 2024 (UTC)[reply]

Blue rectangle when clicking images

Tracked in Phabricator
Task T368137

The glitch in Firefox on the page Wikipedia:Community portal

The glitch is more easily visible after middle-clicking any image, i.e. any <img> tag, but it also appears on the left mouse button down. All images are affected, e.g. it's also visible when clicking on the image on any file page, like File:Example.jpg. I think this started appearing yesterday.

Reproduced both logged in and logged out. Only Vector 2022 is affected. Monobook and Legacy Vector (2010) are not affected.

The issue is more prominent in Firefox, where the blue rectangle intersects the image.

In Chromium, the blue rectangle follows the border of the image, however, the blue border in Chromium seems to be less visible for <img> tags of smaller size. E.g. lynx image in Template:In the news (currently on the Main Page) only shows the border at the bottom of the image. —⁠andrybak (talk) 09:51, 22 June 2024 (UTC)[reply]

Any clickable object has a hotspot, the area within which a click will fire the associated event (for example, for a link in running text the hotspot is the word or phrase enclosed by the link, and the event is the browser taking you to the link target). In Firefox, if you click a link in text, come back to the same page, and then press the Tab ↹ key, the next link in sequence will gain a blue border - this indicates the extent of the hotspot. I first noticed this some jobs ago, waaaay back in 1998, when my browser at work was Netscape 4, so it's not really a new feature. Clickable images also have a hotspot, which normally corresponds to the image outline, but when you tab into a clickable image in Firefox 127, for some reason it draws the blue border smaller than the true extent of the hotspot. I think that you're seeing this border. In the days before style sheets, this border appeared by default, even when you weren't tabbing between links, but could be suppressed by using the border=0 attribute on the <img /> tag. --Redrose64 🌹 (talk) 12:59, 22 June 2024 (UTC)[reply]

It appears that the "focus ring" is appearing around the bounds of the <a> tag, which has the width of the image but the height of the line. At a quick check I'm not seeing any MediaWiki-specific styles for the :focus-visible pseudo-class, and a test HTML page with no styles has the same behavior, so this is coming from the browser's default behavior. Anomie ⚔ 21:07, 22 June 2024 (UTC)[reply]

This is probably worth a bug report. Izno (talk) 16:09, 22 June 2024 (UTC)[reply]

Created phab:T368205. —⁠andrybak (talk) 20:06, 22 June 2024 (UTC)[reply]

I'm experiencing a this same issue, and another not mentioned by OP. When I visit a page with a non-existent talk page, the talk page link is blue. When I click to confirm that the talk page does not exist and go back to the previous page, the link becomes red. This started three or four days ago for me. Could this be related? ✗plicit 00:23, 23 June 2024 (UTC)[reply]

Can reproduce – most noticeable for file pages on Commons, which rarely have talk pages. This seems like a separate bug to me. —⁠andrybak (talk) 06:59, 23 June 2024 (UTC)[reply]

See phab:T367982 for that issue. Sjoerd de Bruin (talk) 09:08, 23 June 2024 (UTC)[reply]

And also see section #Blue link to non-existent user page below. —⁠andrybak (talk) 19:33, 24 June 2024 (UTC)[reply]

Blue link to non-existent user page

Tracked in Phabricator
Task T367982

Recently (past week or two?) when I go to a new(ish) user's talk page, the link to their user page is shown in blue, but when I go to take a look, there's nothing there. When I return to the talk page, the same link is now red. Is this a bug or a 'feature'? (I've not noticed it anywhere else other than the user namespace, either because it's unique to that, or it's just not that often one comes across a talk page with no corresponding main page.) Happened loads of times, so not limited to any one user's pages, but just as an example: User talk:Daksh kochar. -- DoubleGrazing (talk) 06:50, 24 June 2024 (UTC)[reply]

I've seen it happen in mainspace too, mostly because I do a lot of G8 tagging. A reliable way to test this is to go to any talk page archive, since the corresponding main page won't exist. Try Talk:Giraffe/Archive 1 for example. Also quite notable is that once you've clicked on to the main page, the link will stay red forever, even if the talk page is reloaded or closed outright and reopened. Liu1126 (talk) 07:24, 24 June 2024 (UTC)[reply]

This sounds a lot like phab:T367982. —⁠andrybak (talk) 07:45, 24 June 2024 (UTC)[reply]

Thanks, most likely is the same bug. Liu1126 (talk) 07:58, 24 June 2024 (UTC)[reply]

Thanks @Andrybak, it does indeed sound the same (actually, the reverse, but I reckon reverse is the same!), thanks for flagging that up. -- DoubleGrazing (talk) 08:10, 24 June 2024 (UTC)[reply]

I've also seen this happen in mainspace, with nonexistent talk pages seeming blue until I click on them and they don't exist, and only then becoming red. Bearcat (talk) 10:45, 24 June 2024 (UTC)[reply]

There is a CSS rule saying:

a.new {
	color: var(--color-link-red,#d73333);
}

That works in red wikilinks but the tab links in Vector 2022 swap the order of a and new. Fix for your CSS:

.new a {
	color: var(--color-link-red,#d73333);
}

PrimeHunter (talk) 11:16, 24 June 2024 (UTC)[reply]

Thanks, works splendidly. Liu1126 (talk) 11:23, 24 June 2024 (UTC)[reply]

Thanks @PrimeHunter, that works! :) DoubleGrazing (talk) 11:24, 24 June 2024 (UTC)[reply]

Record of thanks given

Is there any way that I can demonstrate to another editor that a third editor has thanked me for a particular edit? I am trying to make clear that I have a level of support for an issue that I raised on a talk page. ThoughtIdRetired _TIR 19:29, 23 June 2024 (UTC)[reply]

This is less a technical question, and more a question of whether or not the use of the "thanks for the edit" function can be used to imply a specific reason for thanking you. I presume others are like me - thanks does not always, or even most of the time, mean "I agree with this and support it". It can mean something as simple as "I appreciate your participation in this discussion", or even "while I disagree with you, you haven't flamed me or become toxic, so here's thanks". -bɜ:ʳkənhɪmez (User/say hi!) 19:49, 23 June 2024 (UTC)[reply]

Special:Log/thanks can show that user A thanked user B at time C. It doesn't reveal which edit was thanked. This is deliberately non-public. PrimeHunter (talk) 20:00, 23 June 2024 (UTC)[reply]

And I have had editors thank me for reverting their unconstructive edits. Context matters. Donald Albury 20:36, 23 June 2024 (UTC)[reply]

How this works seems strange when, on thanking another editor, you are asked to confirm that you wish to publicly thank them. Whatever the intended design, it seems only to benefit those who might wish to misrepresent being thanked. If the record simply showed the edit that was thanked, then it would take very little effort to see the context in which that edit was made. Should this move over to the policy section? ThoughtIdRetired _TIR 21:01, 23 June 2024 (UTC)[reply]

This is covered at Help:Notifications/Thanks#How do I see the thanks I've received and Help:Notifications/Thanks#How do I see the thanks I've given out. In short: anybody can find out if John has thanked Jane, and when that was done; but nobody except Jane can see what the thanks was actually for. There is plenty of previous discussion in the archives of its talk page. --Redrose64 🌹 (talk) 21:46, 23 June 2024 (UTC)[reply]

I have never seen someone use thanks as evidence of support, and I wouldn't encourage it. Some users may want to keep it private that they follow edits to a page or liked a particular edit. Thanks are meant to show an editor that you appreciated their edit. If the edit was public then thanks would be used for other purposes and maybe less for the intended purpose. There is probably a Phabricator request somewhere but all Phabricator searches are currently down for me. PrimeHunter (talk) 21:48, 23 June 2024 (UTC)[reply]

That seems strange to me – other editors can see that editor A is thanking editor B, but not what for. So editor C might infer that two others were ganging up on them, when actually the "thank" was for an edit in an article unknown to editor C. The solution for those who really want to keep what they are doing private (unlike just about everything on Wikipedia – you can even work out when an editor probably goes to bed at night!) – the solution is don't thank anyone. OK, not the biggest problem on Wikipedia, but it is one of the few poor bits of system analysis that I have seen here. ThoughtIdRetired _TIR 22:05, 23 June 2024 (UTC)[reply]

Phabricator search is still down for me but I found a 2013 request with Google: phab:T51087. There is no sign Wikimedia wikis will make the thanked edit public but there was discussion about a MediaWiki option for other wikis so the task hasn't been closed as declined. PrimeHunter (talk) 20:40, 24 June 2024 (UTC)[reply]

Honestly for WP/related projects I don’t see why individual thanks need to be published at all. Just publish “user has received X thanks” if anything, and keep the actual thanks logged in the back end visible to admins/CUOS/whatever is deemed to be useful. -bɜ:ʳkənhɪmez (User/say hi!) 20:46, 24 June 2024 (UTC)[reply]

more efficient watching

Each day I download my watchlist page, filter it for the "mw-changeslist-watchedunseen" tag, open the histories for the unseen pages; I have scripts for these steps. But then, on each of these history pages, I have to click by hand to get the diffs from the last "seen" version to the current version. Is there a more automatic way to get those diffs? (The links I want are in the mail notices, if I choose to receive them, but again that's a couple of clicks for each.) —Tamfang (talk) 21:18, 23 June 2024 (UTC)[reply]

Link to existing script? Figuring out what language it's in and what it's doing will help with figuring out if you can just add code to it or need to explore a different option. What do you mean by "mail notice"? I assume you just want the diff of last time you viewed it compared to the newest revision, right? –Novem Linguae (talk) 04:04, 24 June 2024 (UTC)[reply]

The scripts are on my own computer, in Vim and Python. I could in principle write a script to combine these and then curl the history pages and then examine these for the last unseen version; but I'd rather use an existing script native to WP, if possible!

I used to get a notice by mail whenever a watched page was changed, if I had seen it since the previous change. (I turned that off; now I cannot find it in Preferences.) That notice included the link I want, but again only one at a time. —Tamfang (talk) 03:42, 25 June 2024 (UTC)[reply]

The grouping mode has "n since last visit" links. Nardog (talk) 01:43, 25 June 2024 (UTC)[reply]

What is this grouping mode of which you speak? n what? —Tamfang (talk) 03:43, 25 June 2024 (UTC)[reply]

Click "n changes, n days" and check "Group results by page", or check "Group changes by page in recent changes and watchlist" in Preferences. But it seems the links only appear when there are seen and unseen edits made within the same day, so it might not totally satisfy your needs. Nardog (talk) 03:53, 25 June 2024 (UTC)[reply]

Seems to do nothing but show tags. Can't see how it helps me, thanks anyway. —Tamfang (talk) 21:09, 26 June 2024 (UTC)[reply]

Here's an idea: a toggle in Preferences to allow Watchlist to link diffs from last seen in place of last diff. —Tamfang (talk) 05:12, 28 June 2024 (UTC)[reply]

Short description error

Despite the {{short description}} being set, the article at Ayub Khan shows an entirely different local description of (see): "Template of famous historical Pakistani figure/president/field marshal."

Please see if this can be fixed. Thanks. Gotitbro (talk) 20:43, 24 June 2024 (UTC)[reply]

@Gotitbro: It was in a used template as hinted by the text. Fixed by [2]. PrimeHunter (talk) 20:49, 24 June 2024 (UTC)[reply]

Some users unable to email blocked users?

Tracked in Phabricator
Task T341908

Is there a prohibition for newer users from being able to email another user? I'm trying to assist a newer wiki user (autoconfirmed, but not yet extended confirmed) who can email some users but not someone who is blocked. I can email blocked users, though. There is nothing in WP:Emailing users describing restrictions. So I'm wondering if the newer user is [undocumented] unable to email a temporarily blocked user. Any insights? ▶ I am Grorp ◀ 21:34, 24 June 2024 (UTC)[reply]

(If this is a known feature, not a bug, can someone please add it to the documentation?) ▶ I am Grorp ◀ 21:34, 24 June 2024 (UTC)[reply]

Are you able to confirm that the blocked user's account can be emailed? (I'm thinking unauthenticated email or just no email)

The API documentation lists some possible errors (for the API, no idea what the UI says) and links to various generic ones (mw:API:Emailuser#Possible errors), but I didn't notice any that seemed like what you described.

Also, are you able to ask what message they got when they tried? – 2804:F1...13:F724 (talk) 22:05, 24 June 2024 (UTC)[reply]

Yes, it was the first thing I checked. I also see "Email this user" on the left margin under "Tools" for those users, and was able to successfully send a test email to one of them. The error message they had gotten was something like "You cannot email users on this Wikipedia (or en.wikipedia)", which made no sense, especially when they just turned around and successfully emailed someone else (who was not a blocked user). Users with their emails turned off, or without an email in the wiki system, don't display the "email this user" option under "Tools". However, I am an extended confirmed user (they are not), which is the only thing I could think of as an explanation for the fact they could email me (I'm not blocked), and one other not-blocked user, but could not email those other two users (one is indef blocked, the other is temp blocked). 500 edits would be a steep quota for a new user just to send an email (they have less than 100 so far) especially if there's no error message telling them that's what they need. ▶ I am Grorp ◀ 23:46, 24 June 2024 (UTC)[reply]

Grorp, the other users might have "Allow emails from brand-new users" off in settings? I can't tell if brand-new means autoconfirmed or extended confirmed. — Qwerfjkl talk 15:23, 25 June 2024 (UTC)[reply]

WP:Emailing users says "You can also prevent users without the autoconfirmed permissions level from emailing you by un-ticking the 'Allow emails from brand-new users' option", so that's not it because this user is autoconfirmed. I'm beginning to think 'blocked' and 'not yet extended confirmed' might be the reality of the situation. It would just be nice if someone could confirm and then fix the documentation. I think I'll post the issue to the talk page of WP:Emailing users and hope someone familiar with the behind-the-scenes-code will be able to confirm. ▶ I am Grorp ◀ 16:52, 25 June 2024 (UTC)[reply]

The only similar message I can find is MediaWiki:usermaildisabledtext which says "You cannot send email to other users on this wiki". Based on a very quick look at the source ([3][4]) that message should only appear on a wiki where email is disabled entirely. Can you double-check that your emailer is using a WMF site, and not some third-party wiki? Suffusion of Yellow (talk) 00:01, 26 June 2024 (UTC)[reply]

They were on en.wikipedia.org, and yes that is the error message they told me. But then they turned right around and emailed me thru wiki. So yes, they can send emails, just not to someone who was blocked. ▶ I am Grorp ◀ 00:11, 26 June 2024 (UTC)[reply]

Their description may be inaccurate. That happens a lot with new users. PrimeHunter3 isn't even autoconfirmed but gets an email form at Special:EmailUser/Quiubennt, and that user is blocked. PrimeHunter (talk) 00:56, 26 June 2024 (UTC)[reply]

+2 that. I expect this is a bad report. They can open a WP:BUG and include screenshots if it is unexpected behavior. — xaosflux ^Talk 01:10, 26 June 2024 (UTC)[reply]

PrimeHunter: The form shows just fine, but they get the error when they click to send the email. ▶ I am Grorp ◀ 01:13, 26 June 2024 (UTC)[reply]

This could be many reasons, like hitting a throttle, an underlying IP block of some sort, etc. Troubleshooting by having you provide somewhat vague information isn't very useful. At this point, advise the third party to engage the larger community directly. — xaosflux ^Talk 10:40, 26 June 2024 (UTC)[reply]

"The form shows" wasn't mentioned before and I didn't want to mail a random blocked user. I have blocked my alternative accont PrimeHunter2 for a week and can reproduce the issue. PrimeHunter3 can mail my main account PrimeHunter normally but cannot mail the blocked PrimeHunter2, and it has "Allow emails from brand-new users" enabled. PrimeHunter3 gets an "Email this user" interface link on User:PrimeHunter2 and a mail form on Special:EmailUser/PrimeHunter2, but clicking "Send" gives a page which still shows the mail form and in red "You cannot send email to other users on this wiki". PrimeHunter can mail the account. Others may try for testing but I may not read the mails. PrimeHunter (talk) 11:02, 26 June 2024 (UTC)[reply]

@PrimeHunter this seems to be "unexpected" behavior, would you open a bug on it with the details? — xaosflux ^Talk 14:42, 26 June 2024 (UTC)[reply]

@Xaosflux: Matma Rex later said below that it's caused by T341908 and he will make a note there. I don't have permission to view T341908 and will not open a bug without knowing what is happening. PrimeHunter (talk) 02:35, 27 June 2024 (UTC)[reply]

FYI, I don't think it is the same user story, but phab:T361481 appears to be at least closely related. — xaosflux ^Talk 15:54, 26 June 2024 (UTC)[reply]

Primehunter: Thank you for reproducing this error. It didn't occur to me to create some alt-accounts (properly declared to avoid socking claims) in order to test this. I think I will for future instances. ▶ I am Grorp ◀ 17:20, 26 June 2024 (UTC)[reply]

@Grorp: Do you mind asking permission of this user to share their username here? It might be helpful. Suffusion of Yellow (talk) 21:32, 26 June 2024 (UTC)[reply]

I asked. They said they would prefer not to be mentioned. I think with two other users having reproduced the problem, their username is not really needed. ▶ I am Grorp ◀ 23:16, 26 June 2024 (UTC)[reply]

xaosflux: In that report the user wasn't yet autoconfirmed (they only had one edit), and it's not the same user as I'm working with. ▶ I am Grorp ◀ 17:20, 26 June 2024 (UTC)[reply]

Oh certainly, but it could be related to a root cause. Someone should create this bug in phab with all the documentations, screenshots, etc. This doesn't appear to be an "English Wikipedia" problem, but something in software. (i.e. we can't fix it here). — xaosflux ^Talk 19:51, 26 June 2024 (UTC)[reply]

I can reproduce this too. I was able to email PrimeHunter2 from my main account, but not from Suffusion of Yellow alt 7. I was also able to email Suffusion of Yellow alt 8 from Suffusion of Yellow alt 7. Using WP:QQX shows that the error message is, in fact, MediaWiki:usermaildisabledtext. Suffusion of Yellow (talk) 19:21, 26 June 2024 (UTC)[reply]

This is caused by private WMF config added to mitigate email abuse (T341908). I will make a note on that task that it's affecting legitimate users. Matma Rex talk 00:23, 27 June 2024 (UTC)[reply]

I have a feeling that if the message were more accurate ("You cannot send email to this user" rather than "You cannot send email to other users on this wiki") then we'd document the restriction and move on. Anomie ⚔ 02:02, 27 June 2024 (UTC)[reply]

Perhaps, but why would an autoconfirmed user not be allowed to email a blocked user when an extendedconfirmed user can? Why the difference? If you display a generic message like "You cannot send email to this user", it is inadequate for the sender to understand why he cannot, or how to solve his problem. Either provide a better message ("You cannot send email to blocked users until you reach extended confirmed status") or simply allow them the ability to send such emails. ▶ I am Grorp ◀ 02:08, 27 June 2024 (UTC)[reply]

It's a confusing message but the restriction is apparently specific to Wikimedia wikis and not coded in the general MediaWiki software so maybe they didn't have a good way to make a new message. I don't have permission to view T341908 so I don't know exactly what the restriction actually is. I wonder whether it also caused Wikipedia:Help desk/Archives/2024 January 22#Email where we never found an answer. We could make a localized version of MediaWiki:Usermaildisabledtext but what would it say when we don't know why the message is served to a user? PrimeHunter (talk) 02:54, 27 June 2024 (UTC)[reply]

Presumably the same reason we protect pages to autoconfirmed and if that's not enough to extended confirmed, i.e. it's more time consuming to reach extended confirmed without scrutiny so abuse with extended confirmed accounts happens less often.

I honestly wouldn't have thought anyone would have the need to email blocked users before this - and seeing as this phab has been a thing for almost a year now without major complaints it's probably actually a rare occurrence. – 2804:F1...2D:8B49 (talk) 03:59, 27 June 2024 (UTC)[reply]

OK - so there is a temporary measure that may be causing this upstream in phab:T341908, the devs/security teams are reviewing some options. We are not able to share the details of the situation. No additional user troubleshooting is needed at this time. — xaosflux ^Talk 08:29, 27 June 2024 (UTC)[reply]

Tech News: 2024-26

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

Recent changes

Editors will notice that there have been some changes to the background color of text in the diff view, and the color of the byte-change numbers, last week. These changes are intended to make text more readable in both light mode and dark mode, and are part of a larger effort to increase accessibility. You can share your comments or questions on the project talkpage. [5]
The text colors that are used for visited-links, hovered-links, and active-links, were also slightly changed last week to improve their accessibility in both light mode and dark mode. [6]

Problems

You can copy permanent links to talk page comments by clicking on a comment's timestamp. This feature did not always work when the topic title was very long and the link was used as a wikitext link. This has been fixed. Thanks to Lofhi for submitting the bug. [7]

Changes later this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 June. It will be on non-Wikipedia wikis and some Wikipedias from 26 June. It will be on all wikis from 27 June (calendar). [8][9]
Starting 26 June, all talk pages messages' timestamps will become a link at English Wikipedia, making this feature available for you to use at all wikis. This link is a permanent link to the comment. It allows users to find the comment they were linked to, even if this comment has since been moved elsewhere. You can read more about this feature on Diff or on Mediawiki.org. [10]

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

MediaWiki message delivery 22:30, 24 June 2024 (UTC)[reply]

How do we disable the linking of timestamps? It isn't explained at the links provided. — Fourthords | =Λ= | 03:45, 29 June 2024 (UTC)[reply]

You may add

.ext-discussiontools-init-timestamplink {
	pointer-events: none;
}

to your CSS. Nardog (talk) 03:56, 29 June 2024 (UTC)[reply]

You'd also want to add color: #000; inside that block to change the grey text back to black. (By the way, at least on Monobook, the color of the link is below WCAG standards. I don't know how best to bring this up, but it felt worth mentioning somewhere.) - Purplewowies (talk) 04:18, 29 June 2024 (UTC)[reply]

That code seems to be very particularly coded. How best should it be added "inside that block"? — Fourthords | =Λ= | 04:25, 29 June 2024 (UTC)[reply]

I thought about describing what I meant and then didn't for some reason. I mean on a new line (or even the same line) inside the curly brackets, like so:

.ext-discussiontools-init-timestamplink {
	pointer-events: none;
	color: #000;
}

I should have been clearer! Sorry! (And I also think it might be better if it were a preference or gadget--it would be less confusing for people less comfortable with CSS.) - Purplewowies (talk) 05:14, 29 June 2024 (UTC)[reply]

text-decoration:none too, if you use the underline-links preference. (Like so.) —Cryptic 05:27, 29 June 2024 (UTC)[reply]

On Vector the text color is technically not quite black (plus this will not work with dark mode, or if the text itself has color, like the occasional green talk page quotes). I would recommend color: inherit; instead. That said, try out the feature first, you might end up liking it :) Matma Rex talk 00:42, 30 June 2024 (UTC)[reply]

I'd think this should obviously be a preferences toggle. Is there any reason it isn't? (By the way, your wikitext here breaks compliance with MOS:ACCESS, though I don't know how to fix it. Just a heads-up!) — Fourthords | =Λ= | 04:25, 29 June 2024 (UTC)[reply]

Which part of MOS:ACCESS? Nardog (talk) 05:11, 29 June 2024 (UTC)[reply]

@Nardog: Where is the pointer-events property defined? It's not in CSS Basic User Interface Module Level 4. --Redrose64 🌹 (talk) 09:31, 29 June 2024 (UTC)[reply]

It's in the editor's draft. —Cryptic 15:57, 29 June 2024 (UTC)[reply]

Ah, an editor's draft. These are even more fluid than a Working Draft, and it even says Editor's Drafts are works in progress inside a W3C Group and are not required to have the consensus of the Group participants. These drafts have not received formal review and are not endorsed W3C.
These drafts MUST NOT be cited as W3C standards and may or may not become W3C standards.
Software MAY implement these drafts at their own risk. Implementation is neither discouraged nor encouraged but can contribute to proposals for further action on a specification. In other words: don't rely on it. --Redrose64 🌹 (talk) 17:28, 29 June 2024 (UTC)[reply]

It may not have been formally promoted to a standard, but it has been stable and supported by browsers for over ten years. https://caniuse.com/pointer-events You can rely on it. Matma Rex talk 00:39, 30 June 2024 (UTC)[reply]

Invalid certificate?

This started a few days ago I think. My browser (Opera on iPhone, latest version as far as I know) is telling me (I think) that the signed certificates for Wikipedia pages are invalid? The 'https' in the URL is red with a line through it and a red warning sign. When this started I got redirected to a different page, telling me that the URL wasn't safe or something, and I had to click 'proceed anyway' a few times. I'm in the UK, in case that makes a difference. Thecolonpagesaretoocomplicated (talk) 18:23, 25 June 2024 (UTC)[reply]

@Thecolonpagesaretoocomplicated first, make sure the date on time on your device are current. Second, you would need to examine the certificate chain - perhaps your connection is being manipulated. — xaosflux ^Talk 20:20, 25 June 2024 (UTC)[reply]

Space aliens ate my map icons.

Tracked in Phabricator
Task T368546

In Big Duck, I've got a mapframe in the infobox. There's a building icon on the map, but sometimes it shows up as a home icon. I've been noticing this for at least a few days and a few cycles of going back and forth, but now I've finally captured screen shots in both states. It's quasi-stable, but I can't pin down exactly what's going on. Right now, Special:Permalink/1231017752 has the home and Special:Permalink/1231002261 has the building. Viewing the pages in an incognito window makes no difference. Viewing them in a different browser (Firefox vs Chrome) makes no difference. Special:Purge doesn't change anything. Force reloading the browser window doesn't change anything. Clearing my browser cache doesn't change anything. I'm into serious WTF territory here, but it smells like some kind of cache botch at a lower level than what Special:Purge touches. Anybody have any ideas? RoySmith (talk) 00:42, 26 June 2024 (UTC)[reply]

I always get the building icon

. If I change mapframe-marker = building to mapframe-marker = home in Big Duck then I get a different home icon

which is listed at mw:Help:Extension:Kartographer/Icons. The icon in your screenshot is not listed there. If I remove mapframe-marker then I get a pin with no icon. PrimeHunter (talk) 11:42, 26 June 2024 (UTC)[reply]

More weirdness... Special:Permalink/1231017752 shows the home icon. If I click on the map, I get to the full-size version at https://en.wikipedia.org/w/index.php?oldid=1231017752#/map/0, which shows the building icon. RoySmith (talk) 13:54, 26 June 2024 (UTC)[reply]

styles.css

Good morning! I need a little assistance. Currently I created the page User:ToadetteEdit/styles.css for use in my userpage; however the content model is CSS and not sanitized CSS which is somewhat required to use TemplateStyles. Can someone change the content model to "sanitized-css"? Thank you! Toadette^Edit! 09:24, 26 June 2024 (UTC)[reply]

@ToadetteEdit: You can use {{Edit interface-protected}} on the talk page, or see Template:TemplateStyles sandbox for what you could do by yourself. PrimeHunter (talk) 10:01, 26 June 2024 (UTC)[reply]

Understood. Toadette^Edit! 10:12, 26 June 2024 (UTC)[reply]

@ToadetteEdit:

Done — xaosflux ^Talk 10:35, 26 June 2024 (UTC)[reply]

What links here not listing a redirect

If I do "What links here" for 2025 Formula One World Championship, the resulting list includes the redirect 2025 Emilia Romagna Grand Prix. However, if I select "Hide links", 2025 Emilia Romagna Grand Prix is not listed. Does anyone know why? Is it because of the RfD template? DH85868993 (talk) 10:04, 26 June 2024 (UTC)[reply]

Yes, the RfD template causes the page to stop being a redirect right now, which is why it's listed as a regular link instead of a redirect. If you compare it to for example F1 2025 in the same list, it says "(redirect page)" after the link, showing that that link is an actual redirect. --rchard2scout (talk) 10:09, 26 June 2024 (UTC)[reply]

Thanks for the clarification. DH85868993 (talk)

Module:RfD has code to display "This title is currently a redirect to ...", but use of the module deactivates the redirect code so it's currently not an actual redirect. That's admittedly confusing and maybe the module should change the wording. PrimeHunter (talk) 15:42, 26 June 2024 (UTC)[reply]

For a page to be a redirect, the #REDIRECT must appear at the start of the first non-blank line. Even a HTML comment  on that blank line will break it. --Redrose64 🌹 (talk) 15:47, 26 June 2024 (UTC)[reply]

Not getting the curly apostrophe message at page creation

Hello, ran into an issue at Wikipedia:Administrators' noticeboard#Help creating a redirect where when viewing Muñoa’s Pampas cat and Draft:Muñoa’s Pampas cat I do not see MediaWiki:Titleblacklist-custom-curly-quote. This occurs both logged in and logged out, so I thought it worth raising here. Best, CMD (talk) 11:27, 26 June 2024 (UTC)[reply]

Some observations. Draft:Muñoa’s Pampas cat produces the link https://en.wikipedia.org/w/index.php?title=Draft:Mu%C3%B1oa%E2%80%99s_Pampas_cat&action=edit&redlink=1. I can create it in my admin account but if I log out then it redirects to https://en.wikipedia.org/wiki/Draft:Mu%C3%B1oa%E2%80%99s_Pampas_cat with no action=edit&redlink=1. I thought that's only supposed to happen if the page exists but I may be wrong. Draft:Bingus cat exists so it produces the link https://en.wikipedia.org/wiki/Draft:Bingus_cat as expected. If it had been a red link then it would have produced https://en.wikipedia.org/w/index.php?title=Draft:Bingus_cat&action=edit&redlink=1 which as expected redirects to https://en.wikipedia.org/wiki/Draft:Bingus_cat. Draft:Muñoa's Pampas cat has an allowed straight quote instead of a curly quote and produces https://en.wikipedia.org/w/index.php?title=Draft:Mu%C3%B1oa%27s_Pampas_cat&action=edit&redlink=1 which doesn't redirect. So it appears the system is: redlink=1 on an edit link to a blacklisted title you cannot create will cause a redirect to a non-edit page. I don't know whether this is intentional or a bug. It also happens for more normal entries at MediaWiki:Titleblacklist like Draft:Epic fail which isn't coded to display a custom MediaWiki message. PrimeHunter (talk) 12:24, 26 June 2024 (UTC)[reply]

I forgot to mention that Draft:Muñoa’s Pampas cat has a "Create" tab which links to https://en.wikipedia.org/w/index.php?title=Draft:Mu%C3%B1oa%E2%80%99s_Pampas_cat&action=edit with action=edit but no redlink=1, and this displays MediaWiki:Titleblacklist-custom-curly-quote without redirecting. PrimeHunter (talk) 12:42, 26 June 2024 (UTC)[reply]

Dark mode for logged-out users coming soon!

Hi everyone, for the past year, the Web team at the Wikimedia Foundation has been working on dark mode. This work is part of the Accessibility for Reading initiative that introduces changes to the Vector 2022 and Minerva skins. It improves readability, and allows everyone, both logged-out and logged-in users, to customize reading-focused settings.

Since early this year, dark mode has been available as a beta feature on both the mobile and the desktop website. We have been collaborating with template editors and other technical contributors to prepare wikis for this feature. This work included fixing templates and ensuring that many pages can appear with dark mode without any accessibility issues. We would like to express immense gratitude to everyone involved in this. Because so much has been done, over the next three weeks, we will be releasing the feature to all Wikipedias!

Deployment configuration and timeline

Tier 1 and 2 Wikipedias: wikis where the number of issues in dark mode when compared to light mode is not significant. These wikis will receive dark mode for both logged-in and logged-out users. Some small issues might still exist within templates, though. We will be adding ways to report these issues so that we can continue fixing templates together with editors.
Tier 3 Wikipedias: wikis where the number of issues in dark mode when compared to light mode is significant. These wikis will only receive dark mode for logged-in users. We would like to make dark mode available to all users. However, some wikis still require work from communities to adapt templates. Similar to the group above, these wikis will also receive a link for reporting issues that will help identify remaining issues.
Week of July 1: mobile website (Minerva skin) on the Tier 1 Wikipedias (including English Wikipedia)
Week of July 15: desktop website (Vector 2022 skin) on all Wikipedias; mobile website: logged-in and logged-out on the Tier 2 Wikipedias, logged-in only on the Tier 3 Wikipedias

How to turn on dark mode

The feature will appear in the Appearance menu alongside the options for text and width. Depending on compatibility and technical architecture, some pages might not be available in dark mode. For these pages, a notice will appear in the menu providing more information.

How to make dark mode even better!

If you would like to help to make more pages dark-mode friendly, go to our previous message and see the section "What we would like you to do (template editors, interface admins, technical editors)".

Thank you everyone. We're looking forward to your questions, opinions, and comments! SGrabarczuk (WMF) (talk) 12:28, 26 June 2024 (UTC)[reply]

From IP editors everywhere, thank you very much! Looking forward to our new dark mode overlord. 57.140.16.8 (talk) 14:47, 26 June 2024 (UTC)[reply]

Just a note that there will still be LOTS of pages and templates etc that will still have some sort of problem in dark mode. We simply have a lot of content that never assumed something like dark mode would exist (and even though multiple gadgets for dark mode have existed over the years, many of these problems were never solved in those years either). While those who can make these fixes will likely be happy to help, I expect a bit of a torrent of requests on this page in the first days, so some patience might be required to fix all issues that people will find —TheDJ (talk • contribs) 14:22, 27 June 2024 (UTC)[reply]

For anyone wanting to help out, give mediawikiwiki: Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis a good read. It gives an overview of various problems and possible solutions. —TheDJ (talk • contribs) 08:41, 29 June 2024 (UTC)[reply]

Not sure

As a user of dark mode for the past year and a half or so, I've learnt that the quick fix for invisibility / illegibility in templates is to add class="mw-no-invert" inside the offending tag like <span class="mw-no-invert">. Apologies if this is widely known and feels condescending. Folly Mox (talk) 10:59, 28 June 2024 (UTC) edited 14:49, 29 June 2024 (UTC)[reply]

As I understand it, this version of dark mode (as opposed to the dark mode gadget) doesn't invert existing colours. It defines a different palette of colours for the skin. Thus problems with legibility due to choices in colour would have to be fixed by changing the colours. isaacl (talk) 05:45, 29 June 2024 (UTC)[reply]

Welp, I suppose that voids my existing knowledge. Cheers to new solutions to new problems? Folly Mox (talk) 14:49, 29 June 2024 (UTC)[reply]

Wonky archiving on Talk:Said_Nursî

On Talk:Said Nursî something has gone wrong with the archiving bot: only two archives exist for the page, Archive 1 and Archive 7. No archives between them exist, which means the list of archives at the top of the page does not show the most recent archive. Meluiel (talk) 18:32, 26 June 2024 (UTC)[reply]

Looks like when the auto-archiving template was added in revision 605280857, presumably copied and edited from some other talk page, that the current archive counter was set to 7 - the person who added then manually archived all the talk page comments into archive 1 in the next edit.

To make things worse in the very next edit someone restored it all by reverting and didn't remove the restored threads from archive 1, and in the edit after that the bot archived half of the talk page again into archive 7 - so basically the first archive is just full of duplicates.

I feel like the correct course of action would be to delete the first archive and move archive 7 in its place without creating a redirect, and also change the template so it starts counting from 1 again. I or anyone could fix the template, but I'm not going to risk doing that until the rest of the problem is fixed. – 2804:F1...2D:8B49 (talk) 19:10, 26 June 2024 (UTC)[reply]

Doing... --Redrose64 🌹 (talk) 20:36, 26 June 2024 (UTC)[reply]

@Meluiel:

Done but I suspect that some threads were removed from the main talk page and somehow didn't make it to the archives. --Redrose64 🌹 (talk) 20:59, 26 June 2024 (UTC)[reply]

I fixed what I was able to spot, what a mess. – 2804:F1...2D:8B49 (talk) 22:06, 26 June 2024 (UTC)[reply]

Thank you very much, both of you! Meluiel (talk) 22:22, 26 June 2024 (UTC)[reply]

Salt loophole?

An LTA seems to have discovered a loophole to WP:SALTING as in the following example:

Devi Movement was deleted and indef salted by me in Aug 2023, requiring EC access for recreation.
Yet, the LTA's sock Vinuraj Solanki (talk · contribs) was able to effectively recreate the article in Jun 2024 by moving the completely unrelated redirect Annexationist Movement to the Devi Movement title and then over-writing its contents. The sock was not extended confirmed at that, or any, point.
This LTA has used this strategy numerous times; see this for a small fraction of affected articles.

Am I missing something or this indeed a way to overcome salting? And is there a way to counter it?

PS: As this question raises obvious WP:BEANS concerns, any admin is welcome to revdel it and point me to a better venue to raise the issue. Abecedare (talk) 23:02, 26 June 2024 (UTC)[reply]

They moved it to the unnecessarily-disambiguated and not salted Devi Movement (Gujarat). SafariScribe, who is extended confirmed, moved it over the salting, likely without realizing they were doing so. This is phab:T85393. At one point I was tricked into performing this exact trick on behalf of a different LTA (User talk:Pppery/Archive 18#Wikipedia:Articles for deletion/Billy Cranston) * Pppery * _{it has begun...} 23:10, 26 June 2024 (UTC)[reply]

Aha, I had missed that two-step. So it's social engineering rather than a purely technical loophole. I'll start salting this LTA's recreations at admin level to make it less likely to be overlooked. Other than that, I don't believe there is anything to be done here for the moment and so we can consider this resolved. Thanks. Abecedare (talk) 23:21, 26 June 2024 (UTC)[reply]

I didn't know it was salted . @Pppery, is there any way of getting a pop up message regarding a page that is salted before moving (just like blacklist reminder does)? Safari Scribe^{Edits! Talk!} 23:33, 26 June 2024 (UTC)[reply]

Not aware of any. * Pppery * _{it has begun...} 23:33, 26 June 2024 (UTC)[reply]

This is a fairly frequent issue, not just with creation-protected pages but blacklisted titles. Since the lack of a warning isn't going to get fixed anytime soon, maybe it should get stuck into Mediawiki:Movepagetext. It would do a lot more good than the warning about not suppressing the redirect breaking links to the page; I doubt any admin or pagemover has read that without thinking "Duh?", but the only time silently overriding salting and blacklisting doesn't take you by surprise is when you never notice you've done it. —Cryptic 08:53, 27 June 2024 (UTC)[reply]

I would actually file a MediaWiki bug about this, it would make sense to display a warning about this that requires an override before the move goes through (in a similar manner to the one you get if you e.g. try to block yourself). Matma Rex talk 00:44, 30 June 2024 (UTC)[reply]

We did that ten years ago, but fixing security vulnerabilities in the administrator toolset is considered a feature request, so there has not and I'm betting there never will be any developer action on it. —Cryptic 02:01, 30 June 2024 (UTC)[reply]

Article navigator inconsistent

Hola mis amigos. I don't know if it is coded in User:Dr. Blofeld/monobook.js or another one but I have an A-Z article browser at the top of pages with arrows. The problem is it is inconsistent, I'll click a few pages and the alpha order navigation stops. Can somebody tell me how to fix it? ♦ Dr. Blofeld 17:43, 27 June 2024 (UTC)[reply]

@Dr. Blofeld it looks like that may be coming from your import of User:PleaseStand/prevnext.js, you can ask the maintainer about it here: User talk:PleaseStand. — xaosflux ^Talk 18:32, 27 June 2024 (UTC)[reply]

What tense should be used in articles about obsolete computers?

Moved to Wikipedia talk:Manual of Style

— Preceding unsigned comment added by RoySmith (talk • contribs) 16:36, 28 June 2024 (UTC)[reply]

Finding broken section anchors

In this edit at a WT:MOS discussion about section anchors, User:Gawaon asked:

is there some way to find all broken section anchors pointing to some article?

and I thought that this question might get better responses here.

To start with, Gawaon, could you please define what you mean by a broken section anchor, starting with anchor? The term anchor is overloaded and can mean either the starting point or the ending point of a link. Most typically at Wikipedia it means the endpoint, but given you said "pointing to some article" you must mean the starting point, better known as a section link; is that what we are talking about?

Secondly, what do you mean by broken—are we talking about syntax errors or other noncompliant link formats or characters, or do you mean a section link where the section identifier (URI fragment) does not match the name of any section at the destination page; or something else? In the former case, it shouldn't be too difficult to come up with a regex that would match malformed anchors, and maybe after creating one you could then use AWB or possibly an advanced search to find them (if alternation is not required, which it probably is). If you mean the latter case (no matching section name), you might need a user script of some sort.

I assume you have seen something before that prompted your question, and it would be good to have some concrete examples that could be looked at. Thanks, Mathglot (talk) 02:42, 28 June 2024 (UTC)[reply]

Excuse the sloppy wording. What I meant is the latter case, that is, "finding links from other articles to a section (or other anchor) in this page that doesn't exist anymore". Take the article Human cannibalism, which is very old, has lots of incoming links (more than 2000 from the article namespace), and has seen a lot of content reorganization over time, including lots of historical stuff moved into continent-specific articles. So I'm sure that many incoming links point to sections that don't exist anymore, because they were renamed or moved elsewhere. I would like to go through these broken section links and fix them, but that would mean finding them first. So what I'm looking for is like "What links here", but with an additional "Show only broken section links" option. Gawaon (talk) 09:49, 28 June 2024 (UTC)[reply]

This does not exist as a feature of MediaWiki. MediaWiki doesn't even track the fragments in the pagelinks table. See T18561 for the request for the feature. Anomie ⚔ 11:10, 28 June 2024 (UTC)[reply]

Section links are relatively rare so you can try searching for them and check them manually. This only finds 13 section links in articles to Human cannibalism: linksto:"Human cannibalism" insource:/Human[ _]cannibalism\#/i. Some links are made with {{Section link}} or its redirects. This tries to search for them but only gets one irrelevant hit: hastemplate:"Section link" insource:"Human cannibalism" insource:/\|Human cannibalism\|/. Our search function doesn't search the content of redirect pages so redirects to sections are not found but see Wikipedia:Database reports/Broken section anchors. PrimeHunter (talk) 11:45, 28 June 2024 (UTC)[reply]

That's a great idea, I'll use it! Something like that had already crossed my mind when Mathglot added the tip about searching for individual section links, but I had stupidly assumed sections links would be much more frequent than they actually are. Gawaon (talk) 12:02, 28 June 2024 (UTC)[reply]

Bot required

A bot is required for another language Wikipedia section to correct spelling in articles. Who can I contact? With respect. Smpad (talk) 08:49, 28 June 2024 (UTC)[reply]

WP:AWB could do this. Check if the other language Wikipedia supports AWB. You make a list of articles, perhaps containing the spelling mistake, and then have a table telling what corrections to make. If the logon has the bot flag, then it can go non stop without manual check. For Armenian look at https://hy.wikipedia.org/wiki/%D5%8E%D5%AB%D6%84%D5%AB%D5%BA%D5%A5%D5%A4%D5%AB%D5%A1:%D4%B1%D5%BE%D5%BF%D5%B8%D5%8E%D5%AB%D6%84%D5%AB%D4%B2%D6%80%D5%A1%D5%B8%D6%82%D5%A6%D5%A5%D6%80 or the corresponding language that will be linked. Graeme Bartlett (talk) 09:15, 28 June 2024 (UTC)[reply]

Colleague Graeme Bartlett, in Talysh Wikipedia there are also many articles that do not have interwikis or categories. I would like one bot both for correcting spelling and for finding articles without interwikis and categories. Is this possible? With respect. Smpad (talk) 09:24, 28 June 2024 (UTC)[reply]

Smpad, in my experience, it is best to have a solution that does one thing well, and then search for other solutions for other problems, rather than trying to find a jack of all trades, that does nothing very well. Mathglot (talk) 09:31, 28 June 2024 (UTC)[reply]

I suspect AWB is not set up for Talysh Wikipedia, but there would be a way to adapt it. Also here we have Special:UncategorizedPages, is there an equivalent? Graeme Bartlett (talk) 12:23, 28 June 2024 (UTC)[reply]

Yes see tly:Xususi:UncategorizedPages; There are only 223 pages, and this could be handled manually by someone who knows the language and category structure. I use the WP:HotCat gadget to add categories. And also see tly:Xususi:WithoutInterwiki with 2449 pages, a big job. Graeme Bartlett (talk) 13:01, 28 June 2024 (UTC)[reply]

Change in URL for the George Washington Papers held at UVA

FYI to anyone editing any George Washington connected articles. This resource is probably one of the ultimate reference sources for Washington facts about dates etc. It has his papers plus various articles about the man.

The old URL was http://gwpapers.virginia.edu (etc).
URL has been changed, the NEW URL is https://washingtonpapers.org/ (etc).

I already posted about this at the GW main article because I ran into an URL warning when I tried to access a reference using the old URL. Don't know if a script for correcting the outdated URL is necessary or even possible, I just wanted people to know. Shearonink (talk) 14:04, 28 June 2024 (UTC)[reply]

@Shearonink: Is it only the URL scheme and host that have changed - is the rest of the URL, after the third slash (i.e. the path, optional query string and optional fragment), exactly the same in all instances? If so, send it to WP:AWBREQ. --Redrose64 🌹 (talk) 17:20, 28 June 2024 (UTC)[reply]

I'm not sure Redrose64...my browser gave me a warning so I backed slowly away... Shearonink (talk) 17:58, 28 June 2024 (UTC)[reply]

Or WP:URLREQ. — Qwerfjkl talk 18:43, 28 June 2024 (UTC)[reply]

(edit conflict)

Apparently not (only one url sampled). I tried:

http://gwpapers.virginia.edu/articles/twohig_3.html – my browser says that the connection is not private

https://washingtonpapers.org/articles/twohig_3.html – page not found

According to a February 2024 archive.org snapshot, the article page title is: "George Washington Forgeries and Facsimile". Putting that title into the search box at washingtonpapers.org finds https://washingtonpapers.org/resources/articles/george-washington-forgeries-and-facsimile/. Too bad. But, on the other hand, perhaps all article titles follow that pattern so converting to lowercase and using hyphens in place of spaces might work?

At this writing Special:LinkSearch finds 172 instances of http://gwpapers.virginia.edu/; 13 in user pages; 3 in user talk; 64 in talk pages; 7 in Wikipedia; and 1 in wikipedia talk (88). So, 172-88=84 instances across 75 articles. That doesn't seem to me to be sufficient to code a bot or even an awb task (unless the lowercase hyphenated title works for all – don't hold your breath).

—Trappist the monk (talk) 18:46, 28 June 2024 (UTC)[reply]

Trappist the monk - The "not private" warning is what concerned me. I've run into occasional instances here on WP where a previously great resource website was abandoned and then was usurped by a bad actor/scamming website, so yeah...didn't go any further than the warning.

That special link search is very helpful, thanks. I think I'll just go through all the instance of the errant URL in WP articles and manually correct them. Might make up a notice about the change to leave for any editors that have it on their talk etc. Yay Wiki-Gnoming ahead! - Shearonink (talk) 13:54, 29 June 2024 (UTC)[reply]

Is there a quick way to find broken templates?

I was wondering, does there exist any way to quickly find pages with broken templates? This often happens with bracket imbalances, for example this edit, which was missing a closing bracket for the wikilink. This results in the template not being transcluded, with the raw template code being displayed on the page instead of the template. However, I don't know of any ways to find such instances without (a) using Google to search for the template name showing up on a mainspace article, or (b) using Wikipedia's search of the template name and comparing it with the list of articles transcluding a template. I was hoping there would be an easier way. Thanks, S.A. Julio (talk) 21:16, 28 June 2024 (UTC)[reply]

Bracket imbalances are at https://checkwiki.toolforge.org/cgi-bin/checkwiki.cgi?project=enwiki&view=only&id=47 and https://checkwiki.toolforge.org/cgi-bin/checkwiki.cgi?project=enwiki&view=only&id=43 . Please mark all completed fixes as done in the tool. Missing square brackets ([) cause issues in links, while, curly brakets ({) cause issues with template transclusions. Snævar (talk) 23:08, 28 June 2024 (UTC)[reply]

In addition to the above, Wikipedia:Database reports/Transclusions of non-existent templates lists calls to templates that don't exist, which can be fixed per WP:REDNOT. – Jonesey95 (talk) 15:26, 29 June 2024 (UTC)[reply]

PDF on Commons shows dimensions of 0x0 on Wikipedia; File: template doesn't work

I uploaded this PDF to Commons to add to the Moyle v. United States page, but the file won't display when added to the page, like so:

File:Moyle v United States 603 2024 leaked draft.pdf|thumb|Moyle v United States 603 2024 leaked draft

Looking at the file's page on Wikipedia, it lists the dimensions as 0 x 0 (with no pages), while on Commons it says 1,275 × 1,650 (and 22 pages).

Any help would be appreciated! Brad (talk) 21:41, 28 June 2024 (UTC)[reply]

Seems to work now? Gawaon (talk) 22:01, 28 June 2024 (UTC)[reply]

Weird, so it does! Thanks and sorry! Brad (talk) 23:11, 28 June 2024 (UTC)[reply]

Time on talk pages is light gray

Harder to read than black.— Vchimpanzee • talk • contributions • 22:59, 28 June 2024 (UTC)[reply]

And it is still black on some older pages.— Vchimpanzee • talk • contributions • 23:14, 28 June 2024 (UTC)[reply]

As noted above, this is to signify that it's clickable. It's the same light gray shade used for section links in edit summaries. By the way, if you purge one of these older pages, the timestamps will turn into links. Nickps (talk) 23:17, 28 June 2024 (UTC)[reply]

I'm not sure what, if anything, should be done about this. Perhaps an optional setting that turns the links blue? Nickps (talk) 23:18, 28 June 2024 (UTC)[reply]

Thanks. I looked, but apparently not enough.— Vchimpanzee • talk • contributions • 23:19, 28 June 2024 (UTC)[reply]

@Vchimpanzee:

.ext-discussiontools-init-timestamplink,
.ext-discussiontools-init-timestamplink:visited,
.ext-discussiontools-init-timestamplink:active {
  color: #72777d;
}

Put that in Special:MyPage/common.css, and change the #72777d to any valid colour specification. --Redrose64 🌹 (talk) 23:30, 28 June 2024 (UTC)[reply]

I'm not seeing a change. I chose blue.— Vchimpanzee • talk • contributions • 15:31, 29 June 2024 (UTC)[reply]

Weird, I tested it and it works fine for me. Perhaps WP:BYC might help? Nickps (talk) 16:00, 29 June 2024 (UTC)[reply]

I mentioned this in a section higher up on the page, but it may be worth noting that the color contrast of the timestamp with the background, at least on a skin like Monobook, is lower than the WCAG contrast accessibility standards for text of its size. This discussion did make me realize the color is the same as sections in edit summaries, but I wonder if I never had a problem with those because I tend to skim over them, as opposed to me reading the timestamps... (Then again, I don't usually have issues with low contrast. ~~Maybe this is the year where I start turning old...~~) - Purplewowies (talk) 04:23, 29 June 2024 (UTC)[reply]

In Vector 2022, I'm getting #FFFFFF for my background and #757A80 for this gray text. That shows as 4.32:1 contrast ratio in the WCAG test, which is a Fail for normal-sized text. Unless I have some special CSS settings installed, which is quite likely, this seems like an accessibility failure that might be worth a site-wide workaround. [Edited to add: I see that the actual color specification is #72777D, which passes the contrast test at 4.51:1, but almost all of the pixels in the text are rendered for me in lighter shades of gray by the operating system's text smoothing function, or whatever makes it look nice in 2024. So the contrast appears to be failing in the real world rather than on paper.] – Jonesey95 (talk) 15:48, 29 June 2024 (UTC)[reply]

I think the second link should be #72777D. In any case, if we decide to change the color, I think we should also change the edit summaries' section links, since they are supposed to be the same color. Other than that, I have no objections. Nickps (talk) 16:15, 29 June 2024 (UTC)[reply]

Link fixed, thanks. – Jonesey95 (talk) 16:47, 29 June 2024 (UTC)[reply]

If I recall correctly, the color was chosen to de-emphasize the links/timestamps in relation to the text of the comment, while still highlighting them as a separate interface component. The color is a standard one from the Wikimedia Codex color palette. There is some discussion about the color at the end of T275729, with some ambivalent comments. Matma Rex talk 01:08, 30 June 2024 (UTC)[reply]

Really? To de-emphasise? I found the grey made the timestamp stand out much more, being a different colour from the text, which is why i hastened to implement the solution given above. Different strokes for different folks, eh? Happy days, ~ Lindsay^Hello 06:07, 30 June 2024 (UTC)[reply]

Archive bot on Talk:2024 Atlantic hurricane season

I was trying to fix the archive bot. I eventually got it archiving again with this version, however, now it is archiving to Archive 2 without filling up Archive 1. Prior to that edit, I am pretty sure the code was the same as the 2023 season (besides the year change) and it was working fine there last I checked. ✶Qux yz ✶ 13:12, 29 June 2024 (UTC)[reply]

This should hopefully fix it. I've also deleted the archive 2 page. --Chris 13:50, 29 June 2024 (UTC)[reply]

Thank you! ✶Qux yz ✶ 19:44, 29 June 2024 (UTC)[reply]

Please create page for "Login Help"

Please make the new "Login Help" page not require you to be already logged in to use it, as the current page does.

It would be nice if it did not require cookies. 108.194.49.226 (talk) 18:29, 29 June 2024 (UTC)[reply]

There is already Help:Login. Can you please clarify what you are asking for? RudolfRed (talk) 22:14, 29 June 2024 (UTC)[reply]

Should the Script Installer gadget add userscript pages to the watchlist?

If you're using the Script Installer gadget, i.e. you have this checkbox enabled:

Preferences → Gadgets → Advanced →

Install scripts without having to manually edit JavaScript files (documentation)

please join the discussion at User talk:Enterprisey/script-installer § Should script-installer add userscript pages to the watchlist? —⁠andrybak (talk) 20:31, 29 June 2024 (UTC)[reply]

Size of Media Viewer arrows

Im trying to make the Wikipedia Media Viewer arrows bigger do you the code for it Flasherme7 (talk) 03:07, 30 June 2024 (UTC)[reply]

Wait a week and they will be bigger, a change to them was just merged last week. —TheDJ (talk • contribs) 09:14, 30 June 2024 (UTC)[reply]