Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Tech News: 2024-21

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

• The Nuke feature, which enables administrators to mass delete pages, will now correctly delete pages which were moved to another title. [1]
• New changes have been made to the UploadWizard in Wikimedia Commons: the overall layout has been improved, by following new styling and spacing for the form and its fields; the headers and helper text for each of the fields was changed; the Caption field is now a required field, and there is an option for users to copy their caption into the media description. [2][3]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 May. It will be on non-Wikipedia wikis and some Wikipedias from 22 May. It will be on all wikis from 23 May (calendar). [4][5]
• 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.

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

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

Something weird happened. I received a notification for this edit by ClueBot III archiving the section "Tech News: 2024-21". The notification is for a section on a talk page, which I've never edited (and don't think I ever interacted with user Cocobb8 before). I had no need to subscribe to that section. I did, however, subscribe to the section with the same name #Tech News: 2024-21 on the Village pump, because I participated in related section #Heading markup changes just below.

If I go to User talk:Cocobb8/Archives/2024/June#Tech News: 2024-21, I see an "Unsubscribe" button. —⁠andrybak (talk) 11:19, 8 June 2024 (UTC)

Wait a second. I also see an "Unsubscribe" button at Wikipedia:Tech news#Tech News: 2024-21. It's this just a quirk of the subscription system?

But I don't see it at User talk:Xaosflux#Tech News: 2024-21 and User talk:DannyS712#Tech News: 2024-21, which were delivered at 23:02, a minute later. Which would suggest that some key is constructed from section name and the timestamp. —⁠andrybak (talk) 11:31, 8 June 2024 (UTC)

 Confirmed per Wikipedia talk:Talk pages project/Archive 4#Site-wide thread subscription?, quote: not based on a title match, but on the author and time of the initial message. —⁠andrybak (talk) 11:51, 8 June 2024 (UTC)

I guess this is one of the reasons for deliberately separating #Heading markup changes into separate ==level 2== section, even though it is related to the topic of #Tech News: 2024-21. See Special:Diff/1227646231, Special:Diff/1227682725, and Special:Diff/1227745219. —⁠andrybak (talk) 11:57, 8 June 2024 (UTC)

DiscussionTools tracks subscriptions using the first poster's name and timestamp. This lets the heading name be changed easily without messing up everyone's subscriptions. In this case keeping both subscriptions seems ideal. –Novem Linguae (talk) 13:07, 8 June 2024 (UTC)

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)

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:

• Awesome Aasim's User:Awesome Aasim/rcpatrol.js
• BrandonXLF's User:BrandonXLF/FFUHelper.js
• Cacycle's User:Cacycle/wikEd.js, User:Cacycle/wikEd dev.js, and User:Cacycle/wikEd.user.js
• DannyS712's User:DannyS712/DiscussionCloser.js, User:DannyS712/SectionRemover.js, and User:DannyS712/SectionMover.js
• Enterprisey's User:Enterprisey/reply-link.js, User:Enterprisey/copy-section-link.js, User:Enterprisey/archiver.js, User:Enterprisey/strike-archived.js, User:Enterprisey/section-watchlist.js, and User:Enterprisey/section-redir-note.js
• Equazcion's User:Equazcion/OneClickArchiver.js, User:Equazcion/TeahouseRespond.js, and User:Equazcion/NewSectionSummary.js
• Evad37's User:Evad37/OneClickArchiver.js and MediaWiki:Gadget-XFDcloser-core.js
• Mr. Stradivarius's User:Mr. Stradivarius/gadgets/SignpostTagger.js
• PhantomTech's User:PhantomTech/scripts/AFCRHS.js
• SD0001's User:SD0001/RFUD-helper.js
• Terasail's User:Terasail/COI Request Tool.js
• Technical 13's User:Technical 13/Scripts/OneClickArchiver.js
• The Earwig's User:The Earwig/permalink.js and User:The Earwig/afc-helper.js
• The Evil IP address's User:The Evil IP address/hdedit.js

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

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)

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)

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)

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

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)

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

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)

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)

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

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

And a couple other gadgets still remaining:

• MediaWiki:Gadget-PrintOptions.js
• MediaWiki:Gadget-ptoc.js
• MediaWiki:Gadget-teahouse/content.js

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

Σ'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)

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

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)

@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)

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)

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)

@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)

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

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)

✅ 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)

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)

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)

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)

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

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

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)

@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: [6] – please try now. Matma Rex talk 20:27, 6 June 2024 (UTC)

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

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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

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)

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)

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

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

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

@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)

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

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)

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

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)

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)

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)

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)

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)

Apologies, my mistake. — Qwerfjkltalk 19:30, 9 June 2024 (UTC)

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)

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

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)

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

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

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

The obsolete nowrap attribute

See this edit and User talk:Awesometd#nowrap. The nowrap attribute on a td element, already deprecated in HTML 4 (December 1997), was marked as obsolete in HTML 5 (October 2014). The user says that they are copying its use from other pages, so does anybody know where in Wikipedia such usage is recommended or even suggested? --Redrose64 🌹 (talk) 10:30, 28 May 2024 (UTC)

I doubt it's suggested anywhere. A few cases may have been added long ago and some users just copy what they saw in other articles. The user is right that it's used in 2024 F1 season. Unsurprisingly it's also in previous seasons. It's common to start such pages with a copy-paste from another season. PrimeHunter (talk) 11:16, 28 May 2024 (UTC)

At a first estimation there are about 10k uses of it; I'm sure someone can refine that. Izno (talk) 15:26, 28 May 2024 (UTC)

There's many more obsolete attributes still being used in tables, such as align or bgcolor. If we truly want to get rid of them, the solution would probably be to extend the Linter extension, so that they'll be listed at Special:LintErrors. That's probably a discussion to be had over at WT:LINT. --rchard2scout (talk) 07:56, 29 May 2024 (UTC)

One could easily ask as well where in Wikipedia such usage is deprecated or discouraged? I'm pretty sure the amount of editors that read the HTML5 instructions prior to editing articles is rather low. You can't just assume that everyone is always aware of what parameters have become obsolete.

I am a regular editor of the Formula 1 Wikiproject and I remember us starting to use that parameter because it is more practical and intuïtive than the nowrap template and takes up less memory. The fact that it never produced any technical issue, nor was there any message that it is obsolete. This is litterally the first time anyone give an indication there is a problem. Why isn't this advertised more to the relevant WikiProjects? Like another person pointed out here, if these things would be flagged as LintErrors they would not be used. But I do wonder why such a simple, well working parameter was made obsolete.

We are well-intentioned people, so I'm sure that if you invite a couple of editors from the relevant WikiProjects, explain the issue and tell us what the correct CSS code is, per the HTML5 documentatien's recommendation, we'll set out to deal with those obsolete parameters. As a side note, I think the Superbike article has even more issues, like the usage of external links.Tvx1 21:53, 3 June 2024 (UTC)

This one is actually pretty easy to switch, we have a CSS class nowrap that you can change whatever templates to use instead. Izno (talk) 23:31, 3 June 2024 (UTC)

And what is that CSS class nowrap? Tvx1 10:26, 4 June 2024 (UTC)

The CSS rule is

.nowrap,
.nowraplinks a {
  white-space: nowrap;
}

and it's already set up for you. You use it in a table as e.g.

{| class="wikitable sortable"
|+ Demo table
|-
|class="nowrap" | Row 1 Column 1 || Row 1 Column 2
|}

This applies the class to one specific cell. It can also be applied to a whole row at once; or to the entire table. Doing those isn't such a good idea, you may cause excessive sideways scrolling. --Redrose64 🌹 (talk) 13:55, 4 June 2024 (UTC)

What about style="white-space:nowrap"? Tvx1 23:17, 4 June 2024 (UTC)

Yes, it does the same thing, but (i) it's more to type; (ii) less easily remembered; (iii) more easily broken e.g. by omitting or mistyping that hyphen; (iv) more difficult to apply cascading styles to. In general, class= is preferred over style=.

As for "why such a simple, well working parameter was made obsolete", it's part of the overall plan for HTML, going right back to the mid-1990s, that HTML should concern itself only with semantics, and leave styling to style sheets. Accordingly attributes that have no semantic meaning and affect only the style - other than style= itself, were first deprecated and then made obsolete; similarly with elements like <font>...</font> that affect only the style and have no semantic meaning. --Redrose64 🌹 (talk) 05:46, 5 June 2024 (UTC)

New Gadget for viewing CT images

We at Wiki Project Med have built a gadget to view stacks of images such a as CT scans, which you can see here[7]. We are wanting to install it on EN WP.

Previously mentioned to User:MusikAnimal here who want to verify community consensus first.

We have an earlier version working on Commons[8]. Based on Template:PD-medical we have collected a few thousand complete CT and MRI scans of various conditions. Doc James (talk · contribs · email) 19:13, 29 May 2024 (UTC)

@Doc James about how many pages would this need to run on? We are currently experimenting with our very first implementation of Template Gadgets (see a couple sections up) right now, which I imagine would be the way we would want to implement this (and most certainly not by hooking a full page text analyzer in to common.js). — xaosflux ^Talk 18:49, 30 May 2024 (UTC)

A template gadget version has been copied to mediawiki.org as a demo. See mw:Template:ImageStackPopup Bawolff (talk) 19:00, 30 May 2024 (UTC)

So User:Xaosflux sounds like it only loads when a specific category is present already. Doc James (talk · contribs · email) 19:21, 30 May 2024 (UTC)

@Doc James yes, where said category would come along with a template that would wrap whatever is being used. It sounds like all instances of this would use some template so that part isn't hard. What order of magnitude of pages would you expect this would get used on? — xaosflux ^Talk 19:23, 30 May 2024 (UTC)

User:Xaosflux few thousand at most, Doc James (talk · contribs · email) 19:44, 30 May 2024 (UTC)

Thanks for the note. — xaosflux ^Talk 19:24, 30 May 2024 (UTC)

The mediawiki version is quite a bit better.

• For a default gadget, i'd have some concerns about the accessibility of the play button. It's not a button, and it's also not labeled.
• Similar for the pager and slider in the window. This is unlabeled. It should have accessibility labels to make it possible to understand what the slider does.
• The play button positioning and sizing might need a little bit more work, it seems kinda off (esp on iphone)
• Might want to hide the play button on media print
• Good to see that media credits are being linked.
• Seems to work on mobile, but could use some additional spacing at the top controls, they are really difficult to hit because everything is so close together now.
• Closing the dialog. All MW dialogs currently have close at the top (an old pattern i note due to mobile usage favoring thumb interaction at the bottom of a dialog). This does create an inconsistency, but i'm not particular concerned.
• The whole ImageStackPopup-viewer is inside a label element atm. I think that's an accident?

—TheDJ (talk • contribs) 20:27, 30 May 2024 (UTC)

User:TheDJ We have added labels. Let me know if what was done is sufficient? Doc James (talk · contribs · email) 13:06, 1 June 2024 (UTC)

Perhaps we can use gitlab instead of mediawikiwiki for development? It can probably serve as the version which wikis copy from. I created a blank project at gitlab:repos/gadgets/ImageStackPopup, and can extend SDZeroBot 13 to support tracking updates from gitlab. – SD0001 (talk) 09:14, 31 May 2024 (UTC)

There's been some accessibility improvements in the latest version. Button is also now hidden on print. The label thing and the close button at the bottom seem to be due to using OO.ui.alert. I'm not sure why OOUI does it that way for alert boxes. Bawolff (talk) 13:18, 31 May 2024 (UTC)

Synced local fork from upstream. — xaosflux ^Talk 13:57, 31 May 2024 (UTC)

@Doc James, As one of our professors often says, "One view is no view in Radiology." From a content perspective, I am confident that these imaging stacks will enhance the quality of our radiology related articles. Looking forward to seeing this implemented soon. _signed, 511KeV ^(talk) 19:03, 30 May 2024 (UTC)

Moral support for the idea, bug-report for the implementation: the stack is scrolled by a left–right slider, but when hovering over the image the stack scrolls when I move the mouse up-and-down and not side-to-side. DMacks (talk) 19:49, 30 May 2024 (UTC)

Given the bird's-eye view with the line indicating the location of the specific scan is an up-and-down position, having the slider be side-to-side is confusing. Everything needs to be in sync. DMacks (talk) 00:09, 31 May 2024 (UTC)

• I've forked ImageStackPopup over for anyone that wants to test it out in sandboxes etc, you can either manually opt-in to it in the "testing and development" gadget section, or you can load it to a page with the ?withgadget query parameter. From discussion above, this seems like it will need some extensive testing and tweaking. Nothing should currently be placed in to an article that is dependent on this right now, as readers will not be able to make use of it yet. — xaosflux ^Talk 23:55, 30 May 2024 (UTC)

  The Vivarium template gadget being currently tested is much simpler, and we will make sure our roll out of template gadgets is done carefully. Additional discussion around if these should be able to be opted out of should also occur (i.e. not making them default+hidden). For a default here, we'll likely also use a fork, we have a bot to monitor remote changes and flag for promotion that can be used. — xaosflux ^Talk 23:58, 30 May 2024 (UTC)

The test version on Commons loads 250 images. Given how heavy these images are, this seems like a bad use case for a gadget and should potentially be in some sort of video instead, which won't try to download that many images all at the same time. Izno (talk) 00:24, 31 May 2024 (UTC)

That does seem like a lot if its all hitting the browser right away. Something that heavy sounds like it would be better to paginate and be done in mediaviewer perhaps. — xaosflux ^Talk 00:28, 31 May 2024 (UTC)

To clarify, the images get downloaded only after the user hits the play button, so only users who want to see them do the download. Perhaps that could be improved with a progress loading bar or something or the ability to cancel. The goal is to allow users to directly compare all the images all at once, so i'm not sure pagnation would work here. I agree that as a long term solution, transfering as a video with p-frames/temporal compression would probably be much more bandwidth efficient. Bawolff (talk) 05:43, 31 May 2024 (UTC)

Also, just to be clear, this gadget does not exist on commons. There is a separate gadget on commons called ImageStack, which is the inspiration for this gadget, but its a totally different gadget. Bawolff (talk) 09:46, 31 May 2024 (UTC)

Perfect. Got it working here on EN WP User:Doc_James#CT_scan_viewer. Agree a bit of fine tuning is still required.

I like the idea of a progress loading bar. As User:DMacks suggests lets move the scroll bar to the right of the image. We will need a naming convention for these pages User:Doc James/Appendicitis CT Doc James (talk · contribs · email) 15:43, 31 May 2024 (UTC)

this link can be used to manually enable to gadget once for others that want to see this without doing the opt-in. — xaosflux ^Talk 18:13, 31 May 2024 (UTC)

Next steps

We have implemented a bunch of the suggestions made above, see this link. Any further comments or can we have this go live and start using these in main space? Doc James (talk · contribs · email) 18:38, 1 June 2024 (UTC)

Ping User:TheDJ and User:DMacks Doc James (talk · contribs · email) 18:39, 1 June 2024 (UTC)

Looking very nice, but I still think it needs a bit more work for mobile. I'd still say that my fingers are not 3mm x 3mm. Additionally the right positioning of the controls now gets into the scroll zone, which is possibly even worse. I can trigger the rubber banding of the scroll area, and if I zoom in, we overlap with the scrollbar of the viewport. If you switch to desktop skin on mobile, you have the same, but zoomed out 6 times so you really do need that zooming and scrollbar. —TheDJ (talk • contribs) 22:33, 1 June 2024 (UTC)

How about we use swipe right / left on mobile to move through images? Doc James (talk · contribs · email) 05:22, 2 June 2024 (UTC)

My concerns about consistency in direction of scrolling are resolved. For the record, I'm using a desktop machine. DMacks (talk) 05:32, 2 June 2024 (UTC)

User:TheDJ We have done a bunch of work on the mobile interface. Let me know if you have further concerns. Doc James (talk · contribs · email) 04:36, 6 June 2024 (UTC)

Looks ok to me. I'll support. —TheDJ (talk • contribs) 17:15, 8 June 2024 (UTC)

This search has timed out. You may wish to try different search parameters.

Tracked in Phabricator
Task T363622

I'm getting this error pretty frequently lately when opening my watchlist. Maybe a third of the time over the past several days. Anyone know what this is? — Rhododendrites ^talk \\ 01:32, 1 June 2024 (UTC)

Reset your filters, so the page has to do fewer calculations ? Your watchlist is probably really large, I assume. —TheDJ (talk • contribs) 10:22, 1 June 2024 (UTC)

@Rhododendrites: It could be several different things, or more likely, a combination of these.

• A large number of pages are listed at Special:EditWatchlist/raw
• A significant proportion of pages listed at Special:EditWatchlist/raw have been edited recently
• Some of the pages listed at Special:EditWatchlist/raw have recieved large numbers of edits recently

Things to try:

• Go through Special:EditWatchlist/raw and remove pages that you're no longer interested in
• If you are watching a high-traffic page (like WP:ANI), unwatch it
• At Watchlist options, try
  • reducing the period of time to display
  • applying some of the "Hide" options
  • selecting one namespace (possibly with its Associated namespace enabled) rather than all

HTH. --Redrose64 🌹 (talk) 10:41, 1 June 2024 (UTC)

Thanks. I do have a very large watchlist (17k pages), but this issue started happening all of a sudden a few days ago and the list has barely changed in recent weeks. I don't think I've ever once seen the error before then. It's also inconsistent. If I just refresh a few times, it'll display. — Rhododendrites ^talk \\ 13:44, 1 June 2024 (UTC)

But the software and servers change all the time. If you are up to those numbers, even half percent of change in performance on that side can easily push you over an edge. —TheDJ (talk • contribs) 14:07, 1 June 2024 (UTC)

@Rhododendrites You can try User:Ahecht/Scripts/watchlistcleaner to clean out unneeded or stale pages from your watchlist, but with 17k pages you may have to let it run overnight. I've only tested it on about half that many pages. --Ahecht (TALK
PAGE) 01:53, 3 June 2024 (UTC)

Thanks. Frankly, though, I don't want to change my watchlist. It's huge, yeah, and includes a ton of e.g. deleted pages, but I like being able to see when something is recreated or when someone edits a page from way-back-when that probably shouldn't be edited anymore. Edits to inactive pages sneak through too easily sometimes. I'm just kind of surprised that I've had a massive watchlist for years (I became an active editor playing with counter-vandalism tools and AWB, so built up a huge watchlist early) and it's never caused a problem. Of all the things that use memory on Wikipedia, it's volunteers' watchlists that need to be limited? — Rhododendrites ^talk \\ 14:29, 3 June 2024 (UTC)

Almost everything is limited. It’s just that most people don't know about that because they hardly ever run into those limits. —TheDJ (talk • contribs) 17:23, 3 June 2024 (UTC)

It's more common on other projects (where RC tables are larger as well though), but I don't think 17K pages should be close to where these problems would start to occur (at least when you only select to display 50 or 100 pages, maybe). 1234qwer1234qwer4 18:19, 7 June 2024 (UTC)

The likelihood of a timeout can vary depending on how much load the servers are under. More load, more likelihood of a timeout. Watchlists are actually the single most database intensive feature on Wikipedia, probably by a fairly wide margin. On smaller wikis, adjusting the time period to search can help a lot but on a wiki the size of Wikipedia not so much. (Essentially there are two methods of calculating the watchlist depending on if the number of changes in the time period being search is smaller or larger than the amount of entries in your watchlist. On Wikipedia you'd probably have to set that super low before it made a difference because so many edits are happening all the time). Most of the other filters (including total number of results to show) don't make much of a difference most of the time, although there might be edge cases where they matter. Bawolff (talk) 00:04, 4 June 2024 (UTC)

Thanks for this background. Did not know they were the most database intensive feature, but I guess that makes sense. So I take this to mean the only way to fix it is to remove pages from the list? — Rhododendrites ^talk \\ 00:07, 4 June 2024 (UTC)

Rhododendrites, you could remove some pages from your watchlist and put links to those pages somewhere in your userspace, then use Special:RecentChangesLinked on that page as a kind of pseudo-watchlist. That'd allow you to split your watchlist into smaller chunks for the servers to process, at the cost of part of your watchlist becoming public. Rummskartoffel 16:28, 6 June 2024 (UTC)

I get this off-and-on, started about a week ago. No particular time of day afaict. My watchlist has been in the 25-26k range for ages, so it's not down to any change on my part. DuncanHill (talk) 16:47, 6 June 2024 (UTC)

Detecting transclusion through a redirect

In Wikipedia:Templates for discussion/Log/2024 May 22#Template:Edit semi-protected a reason some editors, including myself, are opposed to merging is that the merged template will no longer be able to work properly if used on an unprotected page (which can happen in the case of an unprotected WP:ARBECR page, for example). SilverLocust put it like this: If these were all redirected to one template, then there would be a loss of functionality unless someone knows how to tell a module not merely which wrapper is invoking a module (since there would only be one merged wrapper), but rather which redirect is being used to transclude the wrapper that invokes the module (and I don't think that is possible). So, is that right? Or is there a way to detect which redirect is used and merge the templates without any loss of functionality? Nickps (talk) 14:07, 2 June 2024 (UTC)

@Nickps The module could use getContent() to get the text of the current page and then search it for one of the redirect templates. --Ahecht (TALK
PAGE) 02:30, 3 June 2024 (UTC)

I would oppose that as confusing and probably inefficient. Editors expect it to make no difference whether a redirect is used. If we really want a certain "redirect" to behave differently then don't make it a redirect but a wrapper which passes a certain parameter. PrimeHunter (talk) 02:47, 3 June 2024 (UTC)

Yes, and that's exactly what has been done (but is proposed to be undone by merging the templates). Certes (talk) 13:56, 3 June 2024 (UTC)

@Certes It's no less efficient than what every single citation template is currently doing (using getContent() to get the text of the current page and then searching the text for date format templates). --Ahecht (TALK
PAGE) 16:59, 6 June 2024 (UTC)

Thanking other users

The link for thanking other users for their edits H:THANK is currently not available on my browser based interface. Am I missing something here? ♦IanMacM♦ ^{(talk to me)} 19:51, 4 June 2024 (UTC)

• Well that's bizarre, it's back again. It was definitely missing earlier today.--♦IanMacM♦ ^{(talk to me)} 20:35, 4 June 2024 (UTC)

  @Ianmacm, if you're using different devices, different networks, proxies, VPNs, or any combination of these, then you might be affected by an IP range block. The "thank" links are hidden in such cases. —⁠andrybak (talk) 18:43, 5 June 2024 (UTC)

That's useful. Maybe something along these lines could be added to H:THANK, as I read through this page and could not figure out why the thank link did not show up.--♦IanMacM♦ ^{(talk to me)} 19:22, 5 June 2024 (UTC)

Cite error: Invalid ref tag; no text was provided for refs named

In Economy of South Asia there are four "Cite error: Invalid <ref> tag; no text was provided for refs named..." error messages. I found the definitions in Economy of India, and copied them to the Economy of South Asia article following the example in Help:Cite_errors/Cite_error_references_no_text#List-defined_references, but I've still got the error messages and also some new messages about ref names not being used. How do I fix it? Thanks, DuncanHill (talk) 10:28, 6 June 2024 (UTC)

Scrub it, I managed to guess the answer. I have to give the refs a different name in the definition to that used in the text. I expect someone thought that was clever, especially when combined with not mentioning it on the help page. DuncanHill (talk) 10:32, 6 June 2024 (UTC)

The problem is an undocumented feature in {{Excerpt}}. It adds the page name to ref names it's transcluding. Economy of India says <ref name="India_kapur"/> and defines it elsewhere with <ref name="India_kapur">...</ref>. That works fine in the article itself but {{Excerpt|Economy of India}} only transcludes the reuse and changes it to <ref name="Economy of India India_kapur"/>. If you manually copy the definition then you have to change name="India_kapur" to name="Economy of India India_kapur", as you found out. The purpose of the name change is to avoid a clash with an existing reference using the same name in the article calling {{Excerpt}}. VisualEditor often creates the same ref names so it can easily happen for completely unrelated references. It should certainly be documented in the template, and maybe mentioned as a possible cause in Help:Cite errors/Cite error references no text. PrimeHunter (talk) 11:58, 6 June 2024 (UTC)

Thanks. VisualEditor refnames are a menace, when people copy-paste lumps of articles they often produce clashes. Excerpt generates both undefined refname errors and harv/sfn no-target errors. I can see how adding the name can stop clashes, but it needs to be mentioned on the help page for the error messages. DuncanHill ::(talk) 12:05, 6 June 2024 (UTC)

It looks like {{Excerpt}} does try to handle the case where the ref is defined elsewhere in the page. But for some reason it's failing in that particular case. Anomie⚔ 12:09, 6 June 2024 (UTC)

Looks like the "some reason" is that those four refs are defined inside an infobox parameter. When the reference fix-up runs the infobox is still present, so it sees no need to fix anything. Then, later, the code strips out the infobox and along with it the definitions of those four refs. Anomie⚔ 12:30, 6 June 2024 (UTC)

Wikipedia:Help_desk#Where_did_all_the_bytes_go?

If you can, please join and explain why this edit [9] is marked in the edit-history [10] as "+10,000‎". Gråbergs Gråa Sång (talk) 13:21, 6 June 2024 (UTC)

Gråbergs Gråa Sång, the user appears to have added a very large number of invisible Unicode characters. Specifically it's the Combining Grapheme Joiner character hundreds of times.
Credit to the user script w:de:Benutzer:Schnark/js/diff which shows invisible characters as well as their names. — Qwerfjkltalk 14:04, 6 June 2024 (UTC)

Thanks! Gråbergs Gråa Sång (talk) 15:30, 6 June 2024 (UTC)

Courtesy link Combining grapheme joiner. DuncanHill (talk) 16:48, 6 June 2024 (UTC)

Need help finding incoming link on a page

Can someone help me ... find the link to Wikipedia:Graphics Lab that is apparently on the page Sir William Ramsay School? I've been trying to find it to see if the link is valid in its placement, but to no avail. Steel1943 (talk) 17:58, 6 June 2024 (UTC)

It came from | image_size = {{ifc| (low quality)}}, which I removed as it was misusing the parameter. * Pppery * _{it has begun...} 18:10, 6 June 2024 (UTC)

It's Thursday, 6 June and I have spots before my eyes

Tracked in Phabricator
Task T366845
Resolved

Resolved

See this diff, where one line was moved. The moved line ought to be preceded with curved arrows, on both the left- and right-hand sides. Instead, I see that these arrows are obscured by large black discs. If I hover my mouse over the disc, it resoves to the correct curved arrow, but returns to being a disc on moving the mouse away. This started happening in the last half hour. Firefox 126.0.1, all skins, logged in or out. I blame WP:ITSTHURSDAY. --Redrose64 🌹 (talk) 19:42, 6 June 2024 (UTC)

Can confirm. Same issue for Extended Support Release version of Firefox. Similar on Chrome and desktop site version on Mobile Firefox, except that the black disks are respectively dark blue and dark grey there. Desktop site on Mobile Chrome gives emoji-style white curved arrows in a blue box rather than plain box-less curved arrows with or without obscuring dot. AddWittyNameHere 20:09, 6 June 2024 (UTC)

I've filed phab:T366845 for this. Also happens with inline mode as well. Izno (talk) 20:24, 6 June 2024 (UTC)

You can also click them, they take you to where the software thinks the line was moved to or from (with no highlight whatsoever), not sure why they were turned into black discs though. – 2804:F14:809B:2701:19B4:583A:7C56:999F (talk) 20:53, 6 June 2024 (UTC)

Oh yes, you can click them... but you could click them before today. --Redrose64 🌹 (talk) 22:33, 6 June 2024 (UTC)

Wow. – 2804:F14:809B:2701:19B4:583A:7C56:999F (talk) 22:35, 6 June 2024 (UTC)

And I've been Ctrl+F-ing moved lines like a dummy this whole time‽ (╯°□°)╯︵ ┻━┻ And it's not really that hard to discover yourself  Self-trout. —⁠andrybak (talk) 08:44, 7 June 2024 (UTC)

Added information about the clickable arrows to Help:Diff. —⁠andrybak (talk) 08:52, 10 June 2024 (UTC)

I too am seeing this same exact issue on edit diff pages. Also Firefox 126.0.1 64-bit here, I think it happened on my Linux computer as well. Vector 2022 skin.

I didn't know you could click on the arrows, that's something new I learned today! — AP 499D25 (talk) 08:34, 7 June 2024 (UTC)

The following code does kill the black spots, but it is very dirty and I really don't want to leave it like that. Is there an edit preview event that I can hook to?
setInterval( function() {$('.mw-diff-movedpara-left, .mw-diff-movedpara-right').text(''); }, 666); — GhostInTheMachine ^{talk to me}

There is wikipage.diff —TheDJ (talk • contribs) 09:26, 7 June 2024 (UTC)

Thanks. The code now reads — mw.hook( 'wikipage.diff' ).add( function() { $('.mw-diff-movedpara-left, .mw-diff-movedpara-right').text(''); } );

That works fine and is clean enough for me to feel that it can stay there if I don't notice when T366845 gets fixed — GhostInTheMachine ^{talk to me} 10:08, 7 June 2024 (UTC)

That was a bug? I thought it was some new design change. — Qwerfjkltalk 16:12, 7 June 2024 (UTC)

Scores won't play MIDI inside rendered mainspace?

Some JavaScript script loads, and on e.g. Syncopation, clicking on the JS'd play buttons just load forever now. Disabling JS enables normal playback, and page previews don't have this issue. Aaron Liu (talk) 20:57, 6 June 2024 (UTC)

WikidataInfo

Hi!!! In it.wiki there's a gadget that show me a link to the wikidata item. Is possible to have it also in other wikis? Is there a way to activate tha same preferences on all wikimedia projects?
Thanks for help Esc0fans -and my 12 points go to... 08:08, 7 June 2024 (UTC)

There should be a "Wikidata item" option under the Tools menu. That takes you to the matching Wikidata page — GhostInTheMachine ^{talk to me} 09:21, 7 June 2024 (UTC)

Help needed with collapsible infobox section templates

On the Ryzen article (permalink), I added Template:Collapsed infobox section begin and Template:Collapsed infobox section end to some parts of the Template:Infobox CPU to make it so they are put into collapsed boxes. The cache one came out fine aside from odd indenting which looks like it can be fixed using an additional parameter for CISB, however the transistor count one is not working as intended. While the transistor count entries are indeed in the box, the core count and extension parameters are also somehow in the collapsed template even though the CISB template is placed below them. What could be causing this? Is there some issue with Template:Infobox CPU? I turned on the syntax highlighter and couldn't see anything that sticks out, but my knowledge of template programming is quite minimal.

I tried enabling parameter "hide_subheadings=yes" for the infobox, and also tried adding "div=yes" parameters to the CISB templates (after seeing an editor remove it for lint error), neither of which have rectified the issue. — AP 499D25 (talk) 08:11, 7 June 2024 (UTC)

@AP 499D25: The display order of infobox fields is not determined by the order in the call but by the coding of the infobox template. The call can use any order and the order is ignored. The {{{name}}} box at the right of Template:Infobox CPU shows that the field right before transistors is numinstructions. Ryzen doesn't use that field so we go back one more field to extensions. That's where {{Collapsed infobox section begin}} should be placed if you only want transistors collapsed. I have reorganized the call accordingly.[11] Is that the result you want? I didn't actually have to move down the extensions parameter. Since the call order is ignored, I could instead have moved up {{Collapsed infobox section begin}} to wherever extensions is placed in the call, but my call layout is easier to understand and less likely to be broken later. PrimeHunter (talk) 16:49, 7 June 2024 (UTC)

I see what you are talking about. I didn't know the collapsed section begin template could affect what's above it. Indeed, that's the outcome I was looking for. I am happy with the reordering option as it is straightforward to see how the code works. Thanks! — AP 499D25 (talk) 23:59, 7 June 2024 (UTC)

Discussion at User talk:Enterprisey/script-installer#Confusing history of importScript

 You are invited to join the discussion at User talk:Enterprisey/script-installer § Confusing history of importScript. —⁠andrybak (talk) 12:39, 7 June 2024 (UTC)

Template-generated redlinked categories

The latest run of Special:WantedCategories features a cluster of redlinked categories that are being somehow autogenerated by WikiProject templates — but I can't work out where they're coming from because the category declaration does not exist in either the template or its documentation, and none of the templates have been edited recently to suddenly generate new categories that didn't exist before this week, which means they're being passed through by a new coding change somewhere other than the templates themselves, such as in a module or a template framework I'm not familiar with.

But I can't justify creating most of them either, as they mostly seem to correspond to task forces rather than full wikiprojects, and thus would never have categories at the names that have been newly autogenerated for them — and in many cases they already have categories located at different names than the ones that have been newly autogenerated for them, which are sitting on the template alongside the redlink. By and large, they seem to correspond word-for-word to the name of the template itself, meaning that most likely some edit somewhere has caused an erroneous assumption that every WikiProject template should automatically generate an eponymous category matching its own name, which is obviously not the case.

So I'm at a loss. Could somebody look into the following categories, and figure out how to resolve them?

• Category:Pages using deprecated categorytree parameters
• Category:Article Rescue Squadron
• Category:Etymology Task Force
• Category:WikiProject Article Collaboration and Improvement Drive‏‎
• Category:WikiProject Big 12 Conference‏‎
• Category:WikiProject Challenges‏‎
• Category:WikiProject Counter-Vandalism Unit
• Category:WikiProject Irish music
• Category:WikiProject Mathematical and Computational Biology
• Category:WikiProject Private Equity‏‎

Thanks. Bearcat (talk) 17:56, 7 June 2024 (UTC)

Created the first one, which is an upstream software change not related to the others. The others were due to recent changes to Module:WikiProject banner/templatepage, which I've now reverted. * Pppery * _{it has begun...} 18:05, 7 June 2024 (UTC)

It's related to recent work by MSGJ (talk · contribs) and others. --Redrose64 🌹 (talk) 22:34, 7 June 2024 (UTC)

@Gonnym: should these categories be created? — Martin (MSGJ · talk) 05:34, 8 June 2024 (UTC)

• Category:Etymology Task Force created.
• Category:WikiProject Irish music, Category:WikiProject Private Equity, and Category:WikiProject Big 12 Conference should be created soon, they required speedy renaming.
• Category:WikiProject Mathematical and Computational Biology should not be created, the banner was sent to TfD and should be merged into parent template.
• Category:Article Rescue Squadron - The project lead, banner and category use "WikiProject Article Rescue Squadron", the project page is titled "Article Rescue Squadron". One style should be followed, it is either a WikiProject or not.
• Category:WikiProject Article Collaboration and Improvement Drive, and Category:WikiProject Challenges should not be created. Banner sent to TfD. If kept at TfD category will need creating.
• Category:WikiProject Counter-Vandalism Unit if needed for the code, should be created as a redirect. I created Category:Wikipedia:Counter-Vandalism Unit to match project, banner and sub-categories.

Gonnym (talk) 08:38, 10 June 2024 (UTC)

Maybe better without the colon? Category:Wikipedia Counter-Vandalism Unit — Martin (MSGJ · talk) 08:43, 10 June 2024 (UTC)

Yeah, I agree. Gonnym (talk) 08:47, 10 June 2024 (UTC)

Quarry - now fails with error

Greetings, Earlier today, I ran this query to find Orphan articles. It previously ran Ok. First error View 'enwiki_p.pagelinks' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them. I then logged off, waited a while, logged back in, then Second error Unknown column 'pl.pl_title' in 'on clause' .

This afternoon, same (second) error, so I ran this query instead. Same error Unknown column 'pl.pl_title' in 'on clause' .

I have no idea how to fix, so I am reporting here and hoping a Quarry expert will be able to correct. Regards, JoeNMLC (talk) 19:55, 7 June 2024 (UTC)

Wikipedia:Village pump (technical)/Archive 212#Tech News: 2024-20. The sql munging given there is a really bad idea that won't work at all in some queries, and there's conceivably queries where it would appear to work but change the meaning, but it looks like it'll work ok for your two. —Cryptic 20:26, 7 June 2024 (UTC)

THanks @Cryptic - tried to follow those instructions without any luck. For example, broken Quarry code:

77922 Orphaned - June, 2024

USE enwiki_p;
SELECT p.page_title
FROM page p
INNER JOIN categorylinks c ON p.page_id = c.cl_from AND c.cl_to = "Orphaned_articles_from_June_2024"
INNER JOIN pagelinks pl ON p.page_title = pl.pl_title AND p.page_namespace = pl.pl_namespace
INNER JOIN page p2 ON p2.page_id = pl.pl_from
AND pl.pl_from_namespace = 0 and p2.page_is_redirect=0
GROUP BY p.page_title
having COUNT(pl.pl_from)>1
ORDER BY COUNT(pl.pl_from) desc, p.page_title;

I may be good a cloning a quarry that works (changing month/year), but have zero knowledge of how to fix. Above is the broken one. If someone here can fix, that would be great. Thanks. JoeNMLC (talk) 20:55, 7 June 2024 (UTC)

Here you go. —Cryptic 21:15, 7 June 2024 (UTC)

 Done - Thanks @Cryptic for this solution, very useful. Cheers! JoeNMLC (talk) 01:19, 8 June 2024 (UTC)

Broken infoboxes

I'm seeing broken infoboxes on Henry Kissinger and Donald Trump (broken styling making them too big, some kind of parse error in the 'spouse' field, specific offices held replaced by a redlinked 'Ambassador to'). No obvious recent edits to either that would have broken them, and both are high profile articles that I'd expect to quickly get fixed. Both use {{infobox officeholder}}, but again I don't see obvious recent changes (last one in April). It's probably something in the infobox machinery but I don't even know where to start looking or who to notify. Polyphemus Goode (talk) 11:43, 8 June 2024 (UTC)

Came here with the same issue! It appears to be all uses of that template. Jlalbion (talk) 11:46, 8 June 2024 (UTC)

Looks like Special:Diff/1227899624 fixed it. Anomie⚔ 11:55, 8 June 2024 (UTC)

That edit to Template:If both fixed the marriage templates; the "Ambassador to" link is still there as the TFD template is still on Template:Both. Peter James (talk) 12:02, 8 June 2024 (UTC)

I've reverted that, and that appears to have worked. -- zzuuzz ^(talk) 12:08, 8 June 2024 (UTC)

I've added the notice back to Template:Both enclosed in <noinclude>...</noinclude> as Nickps suggested on the talk page.[12] Nick has added the notice to Template:Both using |type=disabled.[13] Did these edits restore the merge notices without breaking anything? Rjjⁱⁱⁱ (talk) 12:43, 8 June 2024 (UTC)

Wow, that was bad! Yeah, I really should have chosen disabled from the start. I took two templates that are sometimes supposed to return nothing and made them always return something. What could possibly go wrong? As for my suggestions, there is no way for WP:noinclude to break since its whole purpose is to transclude nothing but I'm not so sure about |type=disabled. I guess we'll see. Nickps (talk) 13:19, 8 June 2024 (UTC)

Yeah, but everything is obvious in hindsight; it's no big. The first step in knowing something is not knowing it, Rjjⁱⁱⁱ (talk) 20:31, 8 June 2024 (UTC)

The Tfm notice on {{If both}} keeps breaking things. Around 350 of the articles using {{Infobox YouTube personality}} are currently displaying a reference error like this on Blimey Cow: "Cite error: The named reference YouTubeStatsBlimey Cow was invoked but never defined". {{If both}} has 134047 transclusions. I suggest we just place the Tfm notice in <noinclude>...</noinclude> instead of hoping to find another method which doesn't cause errors. PrimeHunter (talk) 12:25, 10 June 2024 (UTC)

noinclude has been added [14] and the {{Infobox YouTube personality}} errors have gone away. PrimeHunter (talk) 13:55, 10 June 2024 (UTC)

Revdelled content visible in filter log

Hi, I just noticed that revdelled content can still be visible through the filter log, if you click "examine" on an edit and the revdelled content was close enough to the attempted change shown in the filter log. Can this be fixed? Air on White (talk) 02:12, 9 June 2024 (UTC)

It can be fixed, but not by editors on-wiki. You'd have to file a task in Phabricator. This seems similar to phab:T207085, likely they missed an edge case. Anomie⚔ 11:45, 9 June 2024 (UTC)

Problematic gadget "Strike out usernames that have been blocked"

This gadget is making my browser flip out on page histories. See this topic for details. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:24, 9 June 2024 (UTC)

Infoboxes and taxoboxes pushed below opening paragraph in mobile

Infoboxes and taxoboxes are now pushed below opening paragraph in mobile. Is this behaviour deliberate?

The reason I ask is I discovered this while trying to fix an issue with excess white space before taxoboxes. This occurred because of T18700 which introduced an empty paragraph with this HTML: <p class="mw-empty-elt"></p>. The workaround was to precede the taxobox with a <nowiki/> or later with . This workaround no longer works after recent changes, which also introduced the shifted infoboxes and taxoboxes in mobile.

In an attempt to fix this I wrapped the taxoboxes in a <div> element and this worked in my first tests in edit preview. However it doesn't work in all cases. When the taxoobox is the first element in the article the fix works, but it does when preceded by some of the hatnote, protection and formatting templates. When it works the taxobox is no longer pushed below the first paragraph in mobile and the empty paragraph element is no longer there. It's as if the empty paragraph captures the first paragraph of the lede.

You can see this behaviour in Neoaves by wrapping the {{automatic taxobox}} <div> tags. Similarly at Lionel Messi, wrapping {{Infobox football biography}} with <div> tags moves the infobox to the normal top-right location in mobile. In this case the empty paragraph HTML code is reintroduced. If you remove all the hatnote/protection/formatting templates the empty paragraph disappears. Putting all the top templates on the same line also removes the empty paragraph.

Has this behaviour been reported anywhere else?  —  Jts1882 | talk  09:08, 9 June 2024 (UTC)

Mobile has deliberatly pushed infoboxes down after the opening paragraph for years. In desktop it's at the top right with text to the left. Mobile screens are usually narrow witn no room for text to the left so there is text above the infobox instead. People usually view a page left to right and then down so the desktop and mobile order is similar in practice on a narrow screen. Don't try to circumvent the mobile layout. See also mw:Recommendations for mobile friendly articles on Wikimedia wikis#Don't put infoboxes or images at the top of the wikitext if possible. PrimeHunter (talk) 10:00, 9 June 2024 (UTC)

I guess that shows how often I use the mobile view.

However, some recent change has cause that empty paragraph to reappear, or rather to prevent the nowiki workaround.  —  Jts1882 | talk  10:20, 9 June 2024 (UTC)

mw-empty-elt is supposed to be non-visible.. When you say mobile, do you mean mobile browser, or mobile app ? —TheDJ (talk • contribs) 11:09, 10 June 2024 (UTC)

I'm just using the mobile view on a laptop. However the issue is with desktop view. The pushing down of the infoboxes on mobile moves them away from the problematic templates at the top of the page and fixes the issue.

The mw-empty-elt element is empty but adds vertical space. Not a lot but enough for people to report on the template talk pages. Having wasted a lot of time on this over the years it's annoying to have the problem resurface.  —  Jts1882 | talk  13:16, 10 June 2024 (UTC)

Template-transcluded redlinked categories, again

The latest run of Special:WantedCategories features two template-transcluded redlinks that I've been unable to figure out how to empty. They both result from that perennially irritating "isn't supposed to be happening but still regularly happens anyway" thing where somebody throws a template-generated category to the speedy renaming process, but the bots that handle speedy renames can't edit the templates that transclude the categories, so everything stays filed in the redlink — in both of these two cases, I was able to mostly empty out the categories, but each has one or two leftover pages that won't clear out for some other reason I can't identify because the leftover redlinks have eluded everything I've done to try to find their sources.

So could somebody look into these two categories? Thanks.

• Category:Flagicons with missing country data templates (moved to Category:Flag icons missing country data templates
• Category:Flagdeco with missing country data templates (moved to Category:Flag decoration missing country data templates

- Bearcat (talk) 13:07, 10 June 2024 (UTC)

Two sandbox versions needed updating.[15][16] PrimeHunter (talk) 13:23, 10 June 2024 (UTC)

Collapsing FAC page

Until recently, the Nominations section on Wikipedia:Featured article candidates was collpased, allowing reviewers to get an overview. This has stopped working, as discussed at Wikipedia talk:Featured article candidates#Nominations aren't collapsed anymore. I followed the instructions for solving the problems by installing script User:A455bcd9/nominations viewer.js at User:Dudley Miles/common.js, but this did not work. I then followed the advice of Mike Christie at User talk:Mike Christie#Collapsing FAC nominations to try disabling other scripts, but this also did not work. Any other suggestions? Dudley Miles (talk) 13:42, 10 June 2024 (UTC)

@Dudley Miles: It works for me in Vector 2022 but not Vector legacy. I haven't tried the script before and don't know which skins it's supposed to work in. What is your skin at Special:Preferences? Did it work previously in that skin? PrimeHunter (talk) 14:28, 10 June 2024 (UTC)

Thanks PrimeHunter. You are getting beyond my knowledge. What is a skin? I have page User:Dudley Miles/vector.js but I do not know Vector 22. Should I create a page User:Dudley Miles/vector2022.js? Dudley Miles (talk) 14:49, 10 June 2024 (UTC)

@Dudley Miles: The skin setting is at Special:Preferences#mw-prefsection-rendering. User:Dudley Miles/common.js runs in all skins so you shouldn't have to make User:Dudley Miles/vector-2022.js (it has a hyphen) which only runs in Vector 2022. PrimeHunter (talk) 14:55, 10 June 2024 (UTC)

Changing to Vector (2022) in Preferences solved the problem for me. Thanks for your help PrimeHunter. Dudley Miles (talk) 16:18, 10 June 2024 (UTC)

@Dudley Miles: The skin affects many other things. I prefer Vector legacy and have made User:PrimeHunter/Vector 2022 reload.js to easily see how a page looks in Vector 2022 without changing skin. It can be installed with this in Special:MyPage/common.js:

importScript('User:PrimeHunter/Vector 2022 reload.js'); // Linkback: [[User:PrimeHunter/Vector 2022 reload.js]]

PrimeHunter (talk) 16:42, 10 June 2024 (UTC)

I prefer Vector Legacy as - at least on my computer - Legacy 2022 deletes the index of article contents. Vector Legacy with a menu option to switch to 2022 when needed seems a better solution. Thanks again for your help PrimeHunter. Dudley Miles (talk) 08:16, 11 June 2024 (UTC)

Template issue

Just came across a possible problem with the Template:Convert, it appears to be giving incorrect calculations. I notitced it in this article, though it doesn't appear to be limited to that page, and the errors I noted were specifically occuring when converting miles to kilometers. It seems to occur once you get into 3 and 4 digit numbers, though some rounded numbers come up correct (eg: 1,000 miles (1,600 km) ✓) but once you start adding single numbers to the end, the errors start to become larger. Eg;

• 1,001 miles (1,611 km) (+9.6, should be 1601.6)
• 1,002 miles (1,613 km) (+9.8, should be 1603.2)
• 1,115 miles (1,794 km) (+10, should be 1,784 km)
• 3,550 miles (5,710 km) (+30, should be 5,680 km)
• 7,077 miles (11,389 km) (+65.8, should be 11,323.2 km)

The two errors I initially noticed on that page were;

• 2,906 miles (4,677 km) (+27.4, should be 4,649.6 km)
• 2,900 miles (4,700 km) (+60, should be 4,640 km), the second entry dropped by 6 miles, but increased by 23 km...(?)

Also, I realize the template is rounding off to the next whole number, (or should be), I've only added decimals to show the fully correct number. If someone could take a look at this and either confirm there is a problem, or even better, fix the problem, or if I l've just bungled this somehow, then please let me know. Thanks - wolf 15:30, 10 June 2024 (UTC)

@Thewolfchild: A mile is by definition exactly 1609.344 m. You appear to incorrectly think it's 1600m. 1,000 miles (1,600 km) only says 1,600 km because 1,000 is a round number which was probably an approximation so the exact conversion 1609.344 km or a small rounding to 1609 km would give a misleading sense of precision. PrimeHunter (talk) 15:51, 10 June 2024 (UTC)

Just so. The default rounding is to "precision comparable to that of the input value... or to two significant digits". So 1000 miles = 1609.344 km is rounded to 1600 (2SF) but 1001 miles = 1610.95... is rounded to 4SF and becomes 1611. rbrwr^± 16:11, 10 June 2024 (UTC)

(edit conflict)@PrimeHunter: Ah, I see. Yes, I was just going by the basic n × 1.6≈, I didn't realize the temlplate was setup (sort of) to the exact number, including three decimal places. Thanks for clarifying that bit, though it only helps solve some of problem. Why have it set to calculate to the such a high degree of precision, only to try and immediately avoid it? For example, I'm still not sure why 2900 mi comes out as 4700 km? Shouldn't it be 4667 km? Is the template assuming/or set up that, if the miles are an even hundred or thousand, the result on the km side must also round all the way to nearest hundred or thousand? And doing so to avoid a "misleading sense of precision"? Because that seems to be remarkably imprecise. Whereas 2906 mi = 4677 km, which is much more exact. (Bear with me, I haven't really edited in quite some time, so I'm trying to shake of some rust. Your assistance, as well as anyone else's here, is appreciated.) Cheers - wolf 16:49, 10 June 2024 (UTC)

@Thewolfchild: Template:Convert has documentation for how to request another precision than implied by the roundness of the input. 2900 mi is exactly 4667.0976 km. The input has two zeroes so the output is by default rounded to two zeroes and becomes 4700 km. It seems reasonable to me. "2900 mi" often in practice means "around 2850 mi to 2950 mi". That's 4587 km to 4747 km. If we apply the same rule to the template result 4700 km then it becomes "around 4650 km to 4750 km" which gives a fair overlap with the expectation from "2900 mi". This type of default rounding to the same precision as the input is a common practice and not something Wikipedia has invented. It will not be changed so a suggestion at Template talk:Convert would be a waste of time. PrimeHunter (talk) 17:06, 10 June 2024 (UTC)

Request some kind of change at yet another talk page? Nah. I found what appeared to be an oddity, if not a disparity, and so reported it here. But if you're good with it, then I think we're done here. - wolf 23:45, 10 June 2024 (UTC)

Tech News: 2024-24

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

• The software used to render SVG files has been updated to a new version, fixing many longstanding bugs in SVG rendering. [17]
• The HTML used to render all headings is being changed to improve accessibility. It was changed last week in some skins (Vector legacy and Minerva). 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 Vector-2022. The developers are still 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.
• The HTML markup used for citations by Parsoid changed last week. In places where Parsoid previously added the mw-reference-text class, Parsoid now also adds the reference-text class for better compatibility with the legacy parser. More details are available. [18]

Problems

• There was a bug with the Content Translation interface that caused the tools menus to appear in the wrong location. This has now been fixed. [19]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 June. It will be on non-Wikipedia wikis and some Wikipedias from 12 June. It will be on all wikis from 13 June (calendar). [20][21]
• The new version of MediaWiki includes another change to the HTML markup used for citations: Parsoid will now generate a <span class="mw-cite-backlink"> wrapper for both named and unnamed references for better compatibility with the legacy parser. Interface administrators should verify that gadgets that interact with citations are compatible with the new markup. More details are available. [22]
• On multilingual wikis that use the <translate> system, there is a feature that shows potentially-outdated translations with a pink background until they are updated or confirmed. From this week, confirming translations will be logged, and there is a new user-right that can be required for confirming translations if the community requests it. [23]

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

MediaWiki message delivery 20:17, 10 June 2024 (UTC)

A small request

Anyone able to whip up some JavaScript that will change the "Upload file" link on the lefthand toolbar to go to Special:Upload, NOT Wikipedia:File upload wizard, as it currently does. Cheers, Mach61 23:13, 10 June 2024 (UTC)

The box in Wikipedia:File upload wizard has a link to Special:Upload on "Plain form for local uploads". Can you just use that? PrimeHunter (talk) 04:12, 11 June 2024 (UTC)

@PrimeHunter It’s marginally more convenient if the link takes me directly to where I want to go Mach61 05:08, 11 June 2024 (UTC)

Try adding this to your common.js:

$(function() {
    $("#n-upload > a").attr('href', '/wiki/Special:Upload');
});

Tested with vector2022 --Chris 09:26, 11 June 2024 (UTC)

@Chris G It worked! Thx Mach61 09:34, 11 June 2024 (UTC)

@Mach61: There is also User:Equazcion/SkipFileWizard, with the extra option described there. --Redrose64 🌹 (talk) 12:39, 11 June 2024 (UTC)

Gadget for unsupported titles

Would people be open to deploying a gadget similar to wikt:MediaWiki:Gadget-UnsupportedTitles.js on the English Wikipedia? The code there is somewhat specific to Wiktionary, but the idea is that pages like https://en.wiktionary.org/wiki/:%7C get JavaScript redirected to pages describing the characters in question, and it also uses JavaScript to fix the H1. I personally care less about the second issue than the first one, and would like to enhance it further so things like Building#19 get redirected to Building No. 19 rather than a nonexistent anchor in building. That part could be done using a template gadget that only loads on pages transcluding {{technical reasons}}. Not sure if the first part is feasible that way yet. * Pppery * _{it has begun...} 04:10, 11 June 2024 (UTC)

I pretty strongly believe that page titles should display the page title as accessible by the URL, regardless of whether that's the best title. Izno (talk) 06:27, 11 June 2024 (UTC)

That's not what's proposed. Pppery clearly say they "personally care less about" ... "us[ing] JavaScript to fix the H1". – SD0001 (talk) 07:20, 11 June 2024 (UTC)

If it's what e.g. isaacl came to, then I do probably still oppose implementation - fighting with MediaWiki over just how to navigate to a page sounds like a pure lose lose situation. Izno (talk) 15:54, 11 June 2024 (UTC)

It's a "pure lose lose" situation that readers get to read about Building #19 when they search for Building #19? Don't use overuse hyperbole – it spoils its impact when actually needed. – SD0001 (talk) 17:03, 11 June 2024 (UTC)

No, I'm not being hyperbolic. Please don't be a dick. I sincerely don't think there's a win to "let's fuck around with anchors". Izno (talk) 23:24, 11 June 2024 (UTC)

Not sure if the first part is feasible that way yet. It won't be feasible with a template gadget, but it would have been if phab:T241524 had been implemented instead, as you could inject the parser tag into the noarticletext interface message. – SD0001 (talk) 07:25, 11 June 2024 (UTC)

Did you mean MediaWiki:Badtitletext? I don't see how you could end up at noarticletext instead - it's been standard practice for longer than I've been editing to create redirects like Gunnin' for That -> Gunnin' for That No. 1 Spot where the title would otherwise be red. * Pppery * _{it has begun...} 14:48, 11 June 2024 (UTC)

Yeah that one. – SD0001 (talk) 15:20, 11 June 2024 (UTC)

We probably can add logic to MediaWiki:Badtitletext to at least show a "did you mean" for that case, though. * Pppery * _{it has begun...} 15:22, 11 June 2024 (UTC)

I've done that for now. Still think a gadget would be nice there, though, but it's probably not practical. * Pppery * _{it has begun...} 17:31, 11 June 2024 (UTC)

Wait a minute, turns out I'm wrong. Putting the interface message in the category does have the desired effect, even though it doesn't (obviously) cause pages using the message to show up in the category. – SD0001 (talk) 20:41, 11 June 2024 (UTC)

I don't think we should do this as a default gadget. — xaosflux ^Talk 09:44, 11 June 2024 (UTC)

I agree that work along these lines would be better implemented as a core feature rather than a gadget. I also don't like trying to redefine how URLs with fragment IDs work. It makes the behaviour non-standard and so the advantage of readers leveraging their experiences with the rest of the web is diminished. isaacl (talk) 15:34, 11 June 2024 (UTC)

It's a common pattern for fragment ids to redefine page content. SPAs wouldn't be possible without that. – SD0001 (talk) 17:03, 11 June 2024 (UTC)

(SPA = single-page application). * Pppery * _{it has begun...} 17:31, 11 June 2024 (UTC)

And the goal of Wikipedia is to educate people about the topic they are looking for, not preach about unrelated topics like how web apps work. * Pppery * _{it has begun...} 17:31, 11 June 2024 (UTC)

Didn't say anything about preaching. Just saying that following common web patterns means people know what to expect. A web page-based app uses a fragment ID to access a subresource of the page, as intended. Redefining the syntax to redirect to a completely different page is a different model. Sure, it can be done, but it's something unexpected. isaacl (talk) 00:49, 12 June 2024 (UTC)

And my point is that fact is irrelevant in almost all contexts, and it's unnecessary preaching to convey that point instead of taking people where they clearly want to be taken. But whatever, it's clear that, for reasons that make no sense to me, this is being shot down and we're instead choosing to deliberately get in people's way. * Pppery * _{it has begun...} 01:03, 12 June 2024 (UTC)

The majority of readers reach Wikipedia via search engines. Making it easier for search engines to know the right index phrases for an article will help readers the most, as most of them pay little attention to the characters in the URL. (For those that do, personally I'd rather not defy their expectations by showing a page with a title that differs from what appears before the URL fragment ID.) isaacl (talk) 01:40, 12 June 2024 (UTC)

Appearance dropbox menu

I have just noticed a new icon and associated dropdown menu "Appearance" just to the right of my user page link.(pair of spectacles?) It gives radiobox options for small, standard and large text. I like the idea, but it does nor work as I would expect. The selections change text size for existing article text and preview windows but edit window text size is unchanged by the selection. I assume this is a new feature, which I welcome, but the text size in the edit window is the one I really need to make bigger. Cheers, · · · Peter Southwood ^(talk): 15:00, 11 June 2024 (UTC)

The new text-size selector is geared around "Accessibility for Reading", feedback is welcome at mw:Reading/Web/Accessibility for reading/Updates/2024-06 deployments's talk page. You may also try to file a feature request under phab:T313828 to request something like "use the Accessibility for Reading font size selection for editing as well". — xaosflux ^Talk 15:12, 11 June 2024 (UTC)

Thanks for the feedback @Pbsouthwood! Could I ask which editor you're using? Currently, we have the Visual Editor keeping the same size as the text, and the wikitext editor keeping the smaller size. If you're using the wikitext editor, I'd be curious if you could tell me a bit more about why the wikitext editor would work better at this size for you? We're currently collecting feedback on the feature that we hope to use for future changes and configurations. OVasileva (WMF) (talk) 15:25, 11 June 2024 (UTC)

Describing my experience: right now I'm using the page zoom feature to make the all text sizes a bit bigger, both when reading and editing. If I reset this to 100% and use the accessibility for reading feature, then I can read with a larger font but would be editing (and previewing) with a smaller one. I'd have to increase the page zoom level anyway, and turn it back down when reading pages. So I'd rather just set page zoom once, as it will apply for all pages. isaacl (talk) 15:42, 11 June 2024 (UTC)

I always use the wikitext editor. Partly habit, partly to maintain my skills and partly because I get frustrated when visual editor doesn't do what I want. No doubt it is great for some things, but so far I have not found out what. My eyes are deteriorating and get tired quickly, so editing on a larger font helps a lot. I generally zoom in the whole page to see what I have just typed and make corrections. It is easier on desktop where I have a mouse at hand. On laptop I have no mouse because of no suitable surface for it most of the time so zoom in and out with touchpad. Before the tablet failed I would zoom with two fingers there as well. It would be nice to have the edit screen follow the others. Might also be nice to have a fourth font size option, even larger. Some eyes are worse than others, and more accessibility is better. Cheers · · · Peter Southwood ^(talk): 16:06, 11 June 2024 (UTC)

To be clear, for proofreading the wikitext I need bigger text to spot the errors. I can read the smaller text but spotting the errors needs better resolution for reduced eyestrain. Cheers · · · Peter Southwood ^(talk): 16:51, 11 June 2024 (UTC)

I think the table of contents and all other text should also be enlarged in proportion. We also want to encourage editing. · · · Peter Southwood ^(talk): 06:34, 12 June 2024 (UTC)

I asked over at Mediawiki, but is there a reason why the Special space is excluded from the Appearance menu? —Tenryuu 🐲 ( 💬 • 📝 ) 23:45, 11 June 2024 (UTC)

Toolforge problems

There is a problem which is causing widespread failures in toolforge and cloud-vps. I would expect that many tools and bots will be affected, so if you see something broken, thats probably what's going on. I'm afraid I don't have any more details. RoySmith (talk) 15:28, 11 June 2024 (UTC)

Link above claims it is now resolved· · · Peter Southwood ^(talk): 16:29, 11 June 2024 (UTC)

FYI - @Peter Southwood, and @RoySmith the message of the outage is listed above the "solved" message and timestamped after the solved message. For example, Quarry tool is still failing. Regards, JoeNMLC (talk) 19:07, 11 June 2024 (UTC)

Quarry error - access denied

For query here, getting this error message:

Access denied for user 'quarry'@'172.16.2.72' (using password: NO)

So far, I have tried these steps & always same error.

1. Logged out, then back in.
2. Tried Fork, then Submit.
3. Logged out of Wikipedia. Logged in at quarry.wmcloud.org

Regards, JoeNMLC (talk) 00:33, 12 June 2024 (UTC)

Minor template issue

Hi all, I'm noticing an issue with {{Cite Cambridge History of China}}. If I do {{Cite Cambridge History of China|volume=1}} it links to the wrong volume (volume 6 instead of 1):

Twitchett, Dennis; Loewe, Michael, eds. (1986). The Cambridge History of China, Volume 1: The Ch'in and Han Empires, 221 BC–AD 220. Cambridge: Cambridge University Press. ISBN 978-0-521-24327-8..

It should be linking here: [24]

Any help would be appreciated—I'm not exactly sure how/where in the code the google links are generated. Aza24 (talk) 01:07, 12 June 2024 (UTC)

@Aza24: I think I managed to fix it here: Special:Diff/1228582015. DanCherek (talk) 01:17, 12 June 2024 (UTC)

Awesome, thank you. I was only looking at the doc subpage for some reason! Aza24 (talk) 01:18, 12 June 2024 (UTC)

Resolved

–Novem Linguae (talk) 06:52, 12 June 2024 (UTC)