Wikipedia

Wikipedia:Village pump (technical)/Archive 213

< Wikipedia:Village pump (technical)
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

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)

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[6]. 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[7]. 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)

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 Towers among the rest! Gab • Gruntwerk 04:24, 9 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)

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?

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)

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)

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 <templatestyles>. 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.

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

Two sandbox versions needed updating.[8][9] PrimeHunter (talk) 13:23, 10 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.[10] Nick has added the notice to Template:Both using |type=disabled.[11] Did these edits restore the merge notices without breaking anything? Rjjiii (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, Rjjiii (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 [12] and the {{Infobox YouTube personality}} errors have gone away. PrimeHunter (talk) 13:55, 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. [13]
  •   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. [14]

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. [15]

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). [16][17]
  •   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. [18]
  • 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. [19]

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)

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)

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)

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)

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: [20]

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)

Not loggin

Hi! Before when I was trying to put a reply in Phillip Jeong there's was a thing that said I wasn't logged in. I was loggin. Ned1a Wanna talk? 15:07, 12 June 2024 (UTC)

There are lots of reasons that could happen, refreshing the page will normally resolve it or prompt you to log in again. — xaosflux Talk 15:07, 13 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

  Resolved
 – Fixed in external tool. — xaosflux Talk 15:08, 13 June 2024 (UTC)
Tracked in Phabricator
Task T365374
Resolved

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)

Update - Today at Quarry, the list of "Recent Queries" show them all as Failed for the last 24 hours or so. Once more, asking for help fixing this issue. Thanks. JoeNMLC (talk) 13:26, 12 June 2024 (UTC)
The English Wikipedia volunteers can't do anything about Quarry, however you can report bugs about quarry here. — xaosflux Talk 14:34, 12 June 2024 (UTC)
Note, the "access denied" bug appears to already be open as phab:T365374. — xaosflux Talk 14:35, 12 June 2024 (UTC)
Thanks @Xaosflux for the quick response. Good to know that issue is being addressed. Going forward I saved above info. in my (offline) notepad Query file. Thanks again. Regards, JoeNMLC (talk) 14:48, 12 June 2024 (UTC)
FYI: the "access denied" bug is now resolved. — xaosflux Talk 15:07, 13 June 2024 (UTC)

Disable edit summary warnings on redirect AES

Tracked in Phabricator
Task T367412

So, I've enabled the warning on a blank edit summary and, while it has helped me a lot, it's also really annoying in one specific case. When I want to make a redirect, the H:AES is more than enough since it perfectly describes what the edit is. If people want to know the motivation behind the redirect's creation, they can look at the WP:RCATS I've provided. So, in that case, I'm forced to click Publish twice so the edit goes through, even though I know that it is going to have an edit summary and one that I'm perfectly happy with. I wish there were a way to disable the warning when an automatic summary is generated in the case of redirect creation(obviously excepting the default undo summary which should still generate a warning). To be clear, I'm not asking to change how the setting works for everyone. I'm asking for a way to toggle it between the current behavior and the one I described above. Nickps (talk) 11:33, 13 June 2024 (UTC) After reading m:Help:Edit_summary#Automatic_summaries, I changed my request to only apply to redirect creation Nickps (talk) 11:38, 13 June 2024 (UTC)

"Prompt me when entering a blank edit summary (or the default undo summary)" is a software feature, not a community gadget, to request changes to its behavior you may file a feature request at phabricator. — xaosflux Talk 13:55, 13 June 2024 (UTC)
I wanted to see if there was interest first. Will do. Nickps (talk) 13:56, 13 June 2024 (UTC)
Done. Nickps (talk) 14:11, 13 June 2024 (UTC)
I'm not sure that AES is always the only thing needed when creating a redirect, yes it is useful but it only tells "what" was done, not "why" it was done, which is part of the usefulness of edit summaries. — xaosflux Talk 14:15, 13 June 2024 (UTC)
For example, we often tag or categorize our redirects with more information, like "redirect from misspelling", etc -- and not everyone would know about that, but if they say so in their edit summary, others can figure out their intent. — xaosflux Talk 14:17, 13 June 2024 (UTC)
I don't disagree with that, but, since most redirects are created for obvious reasons, I still think it should be left to the editor's discretion whether to rely on AES or not (that's why I'm asking for a second toggle instead of a change in the default behavior). I don't leave a custom summary on most redirects I make, and I don't think there's anything wrong with that. In the very rare case I think the redirect is needs an explanation, I will write a custom summary. In any case, the warning mostly gets in the way when I make redirects. Nickps (talk) 15:12, 13 June 2024 (UTC)

EARWIG seems to be down atm

[21] I thought I should mention it. Gråbergs Gråa Sång (talk) 09:56, 13 June 2024 (UTC)

Bugs with that external tool can be reported here or possibly with the developer here: User talk:The Earwig — xaosflux Talk 13:53, 13 June 2024 (UTC)
Well, it's up again. Gråbergs Gråa Sång (talk) 15:33, 13 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)
Just wanted to note that Olga has answered there. In short, this is about scannability and information density on pages that don't include long-from text. I'm not sure but perhaps we should move the discussion about font size on special pages on MediaWikiwiki? People from other wikis could chime in. SGrabarczuk (WMF) (talk) 22:53, 12 June 2024 (UTC)
Perhaps it should also be about legibility in general, and accessibility for visually impaired users, unless there is a technical issue making it too difficult, or you have plausible reason to believe it would be unwanted by enough users to make it a problem. Cheers, · · · Peter Southwood (talk): 07:15, 13 June 2024 (UTC)
I understood the version in permalink/1228796863, or you have plausible reason to believe it would not be wanted by enough users to make it a problem., but or you have plausible reason to believe it would be unwanted by enough users to make it a problem. says something very different and I'm having trouble making sense of it in context. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:23, 13 June 2024 (UTC)
Sorry to confuse. What I wanted to convey is that it does not really matter if a fair number of people fail to find it desirable, but it could be problematic if there are enough people who actively do not want it, which is the revised meaning. Wikipedia does have a history of people objecting strongly to things they feel have been pushed onto them without due process. Cheers, · · · Peter Southwood (talk): · · · Peter Southwood (talk): 13:32, 13 June 2024 (UTC)
I'm starting to revert back to the old skin. The new skin's look feels awful, especially the infobox. I do not like the Infobox on the new Vector 2022 skin because it looks kinda like the mobile one, even the hatnotes. (EDIT: I reverted back to the Vector 2010 skin everytime I log in only.) ScarletViolet (talk • contribs) 13:39, 14 June 2024 (UTC)

Font size change in Vector 2010

Tracked in Phabricator
Task T367643

Since the style changes, I've noticed a significant decrease in font size across all text, not just infoboxes, while using the Vector 2010 skin on my iPad. Here's a screenshot for reference. ‑‑Neveselbert (talk · contribs · email) 22:54, 14 June 2024 (UTC)

In phab:T349793 the viewport changed from 1000px to 1100px which may explain a feeling of being zoomed out. 🐸 Jdlrobson (talk) 02:28, 15 June 2024 (UTC)
@Jdlrobson: How can I change it back to how it was? ‑‑Neveselbert (talk · contribs · email) 03:02, 15 June 2024 (UTC)

Can a caption in a group of images span an entire row?

 
There is a large amount of empty space next to this caption. Is it possible to make this caption span the entire row of images, so that no space is left empty next to the caption?
 
 
 
This footer spans an entire row of images, unlike the caption above.

See the discussion here: is it possible to display a caption using {{Multiple image}} that spans a row of images? Jarble (talk) 16:42, 14 June 2024 (UTC)

Everything is possible, but shoving all possible functionality into a single template is generally a bad idea and creates a maintenance nightmare. —TheDJ (talk • contribs) 17:09, 14 June 2024 (UTC)
@TheDJ: If this template doesn't have this capability, which template should I use instead to display images in this format? Jarble (talk) 21:05, 14 June 2024 (UTC)
I don't think we have a template for this and don't see a big need for it. You could use {{multiple image}} more than once and use the footer parameter when wanted. The images will be split into separate boxes with a gap but is that so bad? At least it would be very clear what the captions apply to. PrimeHunter (talk) 14:11, 15 June 2024 (UTC)

How to create a redirect or even new article if one letter is capitalized?

I had a hard time creating MaryLand because it kept redirecting to Maryland. I found there was a way around the problem if I added an extra letter and then deleted it in the URL when creating the article.— Vchimpanzee • talk • contributions • 22:59, 14 June 2024 (UTC)

If you search for a title like MarYlAnD that doesn't exist except with different capitalization, it'll take you to one of those existing variations. You can get to the nonexisting title by typing the correct title into the url or by clicking on a redlink like MarYlAnD. SilverLocust 💬 23:29, 14 June 2024 (UTC)
You could just add ?redirect=no to an URL to avoid redirects or just use the NoRedirect script. Vestrian24Bio (TALK) 02:37, 15 June 2024 (UTC)
This wasn't actually a redirect, so that wouldn't have made any difference. SilverLocust 💬 02:58, 15 June 2024 (UTC)
@Vchimpanzee: You can click "Search for pages containing" in the dropdown below the search box. Then you will not go directly to a matching page name. If the searched term is not an exact page name including the same capitalization then you get an option to create the page. PrimeHunter (talk) 14:19, 15 June 2024 (UTC)
SilverLocust mentioned what I did, but I don't get a dropdown below the search box. Maybe it's because I use Monobook. Anyway, Vestrian24Bio had the best solution.— Vchimpanzee • talk • contributions • 15:42, 15 June 2024 (UTC)
@Vchimpanzee: Please always say from the start if you don't use the default skin when you ask for interface help. MonoBook has a "Search" button below the search box with the same functionality as the Vector dropdown "Search for pages containing". PrimeHunter (talk) 19:08, 15 June 2024 (UTC)

Dragging a url from the &action=edit text area into the search box

Why does drag-and-dropping an url from the page editor's textarea (and seemingly only from there) into the search box strip most of the url?
Steps:

  1. Go to https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit
  2. Put the link https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit somewhere in the editor's text area
  3. Select that text and drag and drop it into the search box at the top of the page
  4. Observe how the text that showed up was index.php

This doesn't happen only with urls, any text that starts with text: gets altered.
What I expected was for the link to not be altered, which is what happens if you drag and drop while holding ctrl (a copy drag and drop).
I'm on Google Chrome (v 125.0.6422.142, Official Build, 64-bit), desktop. – 2804:F1...C5:7348 (talk) 04:37, 15 June 2024 (UTC)

Appears specific to Chromium. Nardog (talk) 10:08, 15 June 2024 (UTC)

What causes banners made with Module:WikiProject banner to collapse when placed inside {{WPBS}}. I imported that module among others to another wiki and everything works, except the banners don't collapse automatically. I've looked in Module:WikiProject banner/styles.css, Module:Banner shell/styles.css, Module:Message box/tmbox.css, and even the Vector.css and it eludes me. Could someone point me in the right direction? –Fredddie™ 04:56, 15 June 2024 (UTC)

@Fredddie: Module:WikiProject banner adds the class innercollapse which has code in MediaWiki:Common.js and MediaWiki:Common.css. PrimeHunter (talk) 10:17, 15 June 2024 (UTC)
Huh that did the trick. It must have been the Common.js because I already had Common.css. Thanks for the quick reply. –Fredddie™ 16:47, 15 June 2024 (UTC)
  Resolved
–Novem Linguae (talk) 02:51, 16 June 2024 (UTC)

In My Preferences: Vector (2022) removes my search box, Vector legacy (2010) restores it. Any ideas? Thanks. Martinevans123 (talk) 21:09, 13 June 2024 (UTC)

Vector 2022 is responsive. I can reproduce that at screen width below 1120 pixels, the search box disappears, but a flat button with magnifying glass icon   (or   in dark mode) appears. Clicking on it shows the search box. To focus on the search box, you can also use accesskey F.
Does this correspond to what you encountered? What width screen are you using? —⁠andrybak (talk) 21:57, 13 June 2024 (UTC)
Many thanks for the advice. Now resolved. Martinevans123 (talk) 08:21, 14 June 2024 (UTC)
  Resolved
–Novem Linguae (talk) 03:04, 16 June 2024 (UTC)

Is AFDStats down?

I've been sitting here about half an hour trying to pull up my AFD stats (https://afdstats.toolforge.org/afdstats.py?name=Maile66&max=&startdate=&altname=) and it just hangs in a never-ending loop. — Maile (talk) 11:57, 15 June 2024 (UTC)

My Toolforge bot has been working fine. This is probably a software-specific issue. Dragoniez (talk) 13:11, 15 June 2024 (UTC)
Meaning, I guess, the MediaWiki software, because the AFD stats were working perfectly when I edited yesterday, and nothing has changed on my computer. — Maile (talk) 13:48, 15 June 2024 (UTC)
It finally came up, but took two hours to finally complete. Hope this gets better soon. — Maile (talk) 15:29, 15 June 2024 (UTC)

FYI - Here we are eight hours later, and absolutely nothing has changed as far as the hours it takes to pull up the AFD Stats. Something is not good somewhere. — Maile (talk) 23:30, 15 June 2024 (UTC)

It looks like the tool is semi-abandoned, but User:Legoktm has semi-adopted it. I've contacted him off-wiki and he says he'll take a look when he gets back to a keyboard. RoySmith (talk) 01:28, 16 June 2024 (UTC)
And, yes, it sure looks like it fell down and can't get up. I'm getting python stack dumps. RoySmith (talk) 01:30, 16 June 2024 (UTC)
Thank you! Thank you! We don't know how much we rely on something until it falls down on its job. — Maile (talk) 02:19, 16 June 2024 (UTC)
The homepage is still up so the tool is not down completely. A query for my AFD stats completed after several minutes so is going much slower than it should. The only thing this tool does to interface with MediaWiki is via a couple mw:Action API queries, so I think it's unlikely that MediaWiki is the culprit. Maybe the webserver needs to be restarted, or maybe we need to step debug the python code and see if something there is slowing things down. –Novem Linguae (talk) 02:46, 16 June 2024 (UTC)
Thanks Roy for the ping. The database server queries are taking much slower than they should (I just killed one that had been running for 30 minutes!). s1 replag is currently ~4 hours, which might be the cause or another symptom of something else.
I applied one small performance fix and restarted it and now it seems to returning results, so one of those two did the trick. Legoktm (talk) 05:02, 16 June 2024 (UTC)
Also if someone has some time, the tool is running as a legacy CGI application running under lighttpd. Would be great if we could convert it to a proper WSGI application (e.g. flask) or ... port it to Rust. Legoktm (talk) 05:06, 16 June 2024 (UTC)

High quantity of poor edits to short descriptions

I suddenly see a swarm IPs and newbie editors happily adding short descriptors in my watchlist of 20K+ pages. Today, "assuming good faith" I reviewed a couple hundred edits and notified several editors to go careful with these. And suddenly I paid attention that it looks like some tool was rolled out which puts edit summary "Added short description, #suggestededit-add-desc 1.0" and of course this bot screws up numerous articles because it is brainless and newbies brainlessly follow stupid advices. Whatever the feature is, it must be disabled ASAP for editors without extended confirmed status, because it increases unnecessary workload on other wikipedians. It takes much more time to confirm validity of such an edit (because it comes from who knows who) compared to brainlessly clicking some button. And developers deserve a trout slap for a tool that suggests edits to people who have no idea what they are doing. - Altenmann >talk 03:12, 15 June 2024 (UTC)

Broadly agree, although I think any relative newbie could add a short description if they've checked the guidelines and looked at SDs on similar pages to the one they're editing. But there is probably no automated way to get people to do that. I'm not familiar with the tool in question, does it mention the general best practices for SDs? It could be limited to articles that are very easy to give a good SD, such as albums. Wizmut (talk) 04:27, 15 June 2024 (UTC)
If a noob makes an edit per 1 minute in widely disparate areas, I doubt best practices help them without domain knowledge. - Altenmann >talk 04:44, 15 June 2024 (UTC)
Sounds like Wikipedia:Suggestededit-add 1.0. -- Malcolmxl5 (talk) 07:08, 15 June 2024 (UTC)
I don't see the feature being the issue. It's an editor making edits as quickly as possible without giving any care to whether they are useful or not. Traumnovelle (talk) 07:41, 15 June 2024 (UTC)
What the editor is motivated/thinks is constructive to do is informed an awful lot by the user interface. Remsense诉 07:51, 15 June 2024 (UTC)
He could've made poor edits to other articles via the suggested edits thing regarding copy editing. Traumnovelle (talk) 07:55, 15 June 2024 (UTC)
And you know what? people were complaining about this several times on several issues (including mine), and the tool still runs.
Someone deserves a BIG trout.- Altenmann >talk 09:22, 15 June 2024 (UTC)
Again, there's a phabricator ticket about it. Devs have a lot of work to do. Remsense诉 09:27, 15 June 2024 (UTC)
Then it must be disabled until fixed. Don't you think editors have a lot of work to do other than struggling with screw-ups of devs? If I tell my customers "our devs have a lot to do", they will say "goodbye, we will renew our contract once your devs become less busy". - Altenmann >talk 09:33, 15 June 2024 (UTC)
Shrug. It's annoying to me, but I can't easily summon your level of frustration. Remsense诉 09:34, 15 June 2024 (UTC)
Do you have a link to the Phabricator ticket handy? That is the quickest way to read up on the issue and also to tell the devs. –Novem Linguae (talk) 03:02, 16 June 2024 (UTC)
The WMF doesn't want to help you, they want to feel good. Cremastra (talk) 20:50, 15 June 2024 (UTC)
Yes the feature is an issue. It is a suggested edit. A novice would normally think they should trust the suggestion supposedly coming from someone smarter (not). Therefore I came here to take the blame off the novice and put in on tool owners. - Altenmann >talk 09:33, 15 June 2024 (UTC)
Where in the suggestion does it tell you to add something like the article's title as the description? It directs the editor to the feature/function but doesn't tell them what to write. Traumnovelle (talk) 10:16, 15 June 2024 (UTC)
Whatever. Still, my point is that this feature should not be available to random IPs who often no clue to write and also have no clue that in this case they should not write (Dunning–Kruger effect :-) and my suggestion was to permit "Edit suggester" only to extended confirmed users. - Altenmann >talk 21:01, 15 June 2024 (UTC)
Have you seen IPs do this? The feature Malcolmxl5 mentioned, in commons, claims to be logged-in users only. – 2804:F1...54:15BE (talk) 21:06, 15 June 2024 (UTC)
Oops, you are right. I reviewed my contribs, with plenty of recerts of IPs, and only logged-in users have "uggestededit-add-desc " in edit summary. Still, I am standing with my suggestion to increase level to extended confirmed status. - Altenmann >talk 00:03, 16 June 2024 (UTC)
How bad are these edits? Can you provide a couple diffs of edits you fixed/reverted? How many edits did you check and what percent of those are problematic? Can this be fixed by warning a couple people or do we need to get a consensus for an edit filter to block these edits? (If the latter, we should probably start an AN/ANI thread.) –Novem Linguae (talk) 03:01, 16 June 2024 (UTC)
The edits of this one editor are very poor – I had to revert at least two-thirds of the recent ones – and that editor has been asked to stop. I don't know if there is a systemic problem with the tool or if this is just a single-editor CIR problem. If there is a way that an edit filter could prevent the "suggested edits" tool from changing a short description of "none" to something else, contrary to instructions, that would be great. T326898 has been waiting for action for over a year, and it is not fixed yet. It is always disappointing when the developers roll out shiny new toys and then don't stick around to fix them. – Jonesey95 (talk) 04:30, 16 June 2024 (UTC)
I went to test this, since there hasn't been any new "edit short description" newcomer task added recently. I noticed that in Suggested Edits "mode" (clicking through to a suggested edit from the newcomer Homepage), if I switched to VisualEditor, the short description of an article displays at the top of an article as a box with the grey text "Short description", rather than displaying the short description, which is only shown if you click through to alter it. See c:File:Screenshot suggested edit short description visual editor.png. Folly Mox (talk) 22:19, 16 June 2024 (UTC)

Date problem

I am citing an issue of a journal dated "July August 2024", but "date=July August 2024" gives an error message. How can I show this date? Dudley Miles (talk) 20:57, 16 June 2024 (UTC)

Dudley Miles, you may wish to try |date=July–August 2024 per Help:Citation Style 1 § Date format compliance with Wikipedia's Manual of Style, but the template might still get mad at you for using a date in the future. Using the parameter |publication-date= instead of |date= might fix the problem of the date being in the future; I'm not sure if that parameter is checked the same way. If nothing works better, |date=2024 will at least not produce an error. Folly Mox (talk) 22:03, 16 June 2024 (UTC)
Both are checked, but it appears there is no issue with how far in the future it is: "T". J. July–August 2024. Izno (talk) 22:17, 16 June 2024 (UTC)
date=July–August 2024 works OK provided it is an endash not a hyphen. Thanks to you both for your help. Dudley Miles (talk) 22:45, 16 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 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)
mediawiki.action.view.redirect.js – MediaWiki has for decades, to use your language, fucked around with anchors (to resolve sections links on redirected pages). You not thinking it's a win does not mean it's suddenly considered a bad practise. – SD0001 (talk) 15:37, 12 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)
I don't really like this idea. What good is having the page under an invalid title if you can't link to it (except as an external link)? All kinds of other interfaces also won't work or will display a different title as a result (e.g. what links here, watchlist, page view counts…). Matma Rex talk 20:56, 12 June 2024 (UTC)
I agree with Matma Rex. This kind of reminds me of phab:T315893 and phab:T338151, which I am also disinclined to support. We should keep all the various systems (what links here, watchlist, page view counts, wikilinks, how the title displays when loading the page) in sync with each other, and try to avoid adding more complexity than what we already have (the redirect system, CirrusSearch accepting case insensitivity, unnecessary space character in mobile talk page titles, etc.). By continuing to pile on complexity to the title system, I see a lot of potential for technical debt here. Debugging becomes difficult as the system gets so complex that few can wrap their head around the entire thing. –Novem Linguae (talk) 21:48, 12 June 2024 (UTC)
This system thinking is exactly what is needed across the wiki. But to the point, I agree it should apply here. All the best: Rich Farmbrough 23:26, 16 June 2024 (UTC).

Outdated GA review still hanging around on an article talk page

If someone around here who isn't as exhausted as I am today would please visit Talk:Tiny Town (miniature park), there is an old GA assessment I did - see the GA1 (show) line - that needs to be moved off the article talk into wherever. I can't remember how to make that happen and if you did that it would be awesome. Thanks, Shearonink (talk) 19:22, 15 June 2024 (UTC)

An ending </div> was missing so it combined with the following section. This was fixed by [22]. PrimeHunter (talk) 21:39, 15 June 2024 (UTC)
omg. it's the little things ain't it... thank yooooooou. Shearonink (talk) 00:48, 16 June 2024 (UTC)
O wise PrimeHunter...the next thing is this: Since the GA Review is outdated etc how does one make it go off the main article talk/go away? GA Reviews don't hang around forever right? Don't laugh, I should know this but it's been a long day.... I think I can just archive the GA Review at its actual talk page - Talk:Tiny Town (miniature park)/GA1 which will then archive the GA Review to Talk:Tiny Town (miniature park)/Archive 1 and all will be well. Lol I confess I'm always concerned I'll break something around here... Please confirm and thanks - Shearonink (talk) 01:01, 16 June 2024 (UTC)
If you want to make it auto archivable, you'd probably want to wrap it in a level 2 heading and a signature. Then since you don't have WP:AUTOARCHIVE set up, either set that up, or one click archive it. –Novem Linguae (talk) 02:31, 16 June 2024 (UTC)
@Shearonink and Novem Linguae: I have noticed that newly-created GANs and GARs are generally transcluded into a totally unrelated section, whichever one happened to be last on the talk page when Legobot popped by. Once the GAN/GAR is over, it's no longer an ongoing discussion; but it seems that Legobot has no post-GA clearup task, and it's left for a manual edit.
I have never come across anybody wrapping a GAN/GAR in the manner that you describe, whether to be bot-archived or not; and generally speaking, it's not necessary to retain it since either the {{GA}} box or the article history box should already link to it. When I find that a talk page still transcludes a closed GAN/GAR, I first make sure that it's linked from the article history box together with its outcome, and then I simply de-transclude it, like this. --Redrose64 🌹 (talk) 08:13, 16 June 2024 (UTC)
Thanks for this info. I maintain the user script that closes a lot of GANs and GARs. I just checked and the script's closing algorithm leaves these template transclusions in place. GAN example. GAR example.
Perhaps we should have a wider discussion about what to do with these on the WT:GAN and WT:GAR talk pages. The fact that they're not wrapped means they don't get auto archived and hang around forever. Perhaps there's a work instruction we can get consensus to update somewhere, and we could ask that it be updated to wrap these in headings and signatures so that they don't hang around forever. –Novem Linguae (talk) 08:32, 16 June 2024 (UTC)
There should be no need to archive it, as it's technically already archived - GANs and GARs are talk subpages, albeit ones that don't contain the word "Archive" in their names, for example Talk:Kurt Wolff (aviator)/GA1. As I mentioned, for anybody curious about reading the text of the GAN/GAR, these pages are linked from one of the boxes at the top of the talk page - either {{GA}} or {{article history}}. Please can we not suggest creating a process that is more complex than it needs to be: simple de-transclusion should be quite sufficient. --Redrose64 🌹 (talk) 10:22, 16 June 2024 (UTC)
A lot of things hang around forever. It's a capital mistake to think that "things" should be deleted (or moved) just because one currently has no use for them. All the best: Rich Farmbrough 23:30, 16 June 2024 (UTC).

Size for text renderings at Zero-width non-joiner

I need help resizing the Bengali and Telugu render images in the table to appear the correct size, matching the x-large font size (Example Text) when viewed on desktop using default settings. It may be preferable to replace them with unpadded SVGs. The Malay Jawi script renderings are in the correct format, but at a very large native size, and the sizes of those images in the ZWNJ article should be double-checked. –LaundryPizza03 (dc̄) 07:01, 15 June 2024 (UTC)

In one case I have reduced the image size, in the other it said 148p instead of 148px. All the best: Rich Farmbrough 23:48, 16 June 2024 (UTC).
Tracked in Phabricator
Task T367468
Resolved
  Resolved

(putting this here because it seems related, feel free to move if needed) I noticed on mobile web that section headings that include both linked and unlinked text place each type of text into a separate column. I first encountered it at Wikipedia talk:WikiProject Film but I'm seeing it elsewhere. Any idea what might have caused it? RunningTiger123 (talk) 21:20, 13 June 2024 (UTC)

I don't know what caused it, but as per MOS:NOSECTIONLINKS there shouldn't be links in section headings in any case - Arjayay (talk) — Preceding undated comment added 21:25, 13 June 2024 (UTC)
That MOS only applies to ns:0. — xaosflux Talk 13:18, 14 June 2024 (UTC)
Unrelated cause to the above, I think this is the heading change previously notified about and how DiscussionTools is or was dealing with stuff in headings? Matma Rex Izno (talk) 21:32, 13 June 2024 (UTC)
Stjn just filed phab:T367468 which identifies the issue (it's the flex), but IDK how the future is supposed to be. Izno (talk) 21:33, 13 June 2024 (UTC)
Yep, not related to the style changes discussed above, it's a bug in the styles I wrote for Minerva for the heading HTML changes rolling out to that skin this week, as noted in Tech News. It affects any formatting in a heading, not just links, and somehow I never thought to test that. Sorry about that, I'll get it fixed soon (Monday at the latest). Matma Rex talk 23:19, 13 June 2024 (UTC)
Yep, and it happens with italicized text as well ꧁Zanahary꧂ 23:45, 14 June 2024 (UTC)

Formatting

I'm here to report a bug. There is a weird format going on where if you go to September 1967 (as an example) and look at the Wednesday and Thursday sections, the dates are in two separate spaces. It is not how its supposed to be set up. This is also goes for pretty much every page that's made for the 1950s, 60s, 70s, etc... I use an android to get on to Wikipedia so it may or may not differ from other devices but I wanna know if this is some kind of bug that can easily be fixed? Arcadia (talk) 23:00, 14 June 2024 (UTC)

Section headings on numerous pages are currently glitched when I view the mobile version on my phone. I came here to report a similar issue with Matchbox Twenty; the section "Yourself or Someone Like You lawsuit" gets broken up with the album title on the left and "lawsuit" broken up into "law sui t" on three separate lines over to the right. Home Lander (talk) 00:00, 15 June 2024 (UTC)
It's the same problem as #Section headings with links above. It should get fixed on Monday. Matma Rex talk 08:49, 15 June 2024 (UTC)

Subheadings containing italics example text lorem ipsum

I was organising my user page and noticed that the part of the subheading in italics appeared strange in the mobile view. I visited articles to see if the issue was in the main space. I checked music articles like Madonna and Nirvana, as they would have italic subheadings when discussing their works and the issue is present. If this issue has already been noted, please direct me to it and close this discussion. On mobile view, it looks like it creates a table and puts the part in italics in a cell. Svampesky (talk) 15:16, 15 June 2024 (UTC)

This also happens with wikilinks in headings... Janhrach (talk) 15:19, 15 June 2024 (UTC)
Update: It's discussed above, see #Section headings with links. Janhrach (talk) 15:23, 15 June 2024 (UTC)

For example:

The section title appears like a 3-column table with the three columns as follows:

  1. the text before the link: "Notability of"
  2. the text of the link itself: "Nonmetallic compounds and elements"
  3. the text after the link: "article disputed"

Lines wrap in the three parts separately, which is REALLY weird. In portrait mode it appears on three lines:

  1. Notab … Nonmetallic … article
  2. ilty of … compounds and … dispute
  3. … elements … d

In landscape mode on two lines:

  1. Notability … Nonmetallic compounds and … article
  2. of … elements … disputed

This does not occur in the desktop version of the page, no matter how narrow the screen. To fix this, I changed the wiki link square brackets to double quotes:

And then the issue disappears in both mobile and desktop view:

But it really should be fixed so that this is not required. ——YBG (talk) 00:47, 17 June 2024 (UTC)

Never mind. I see this is already being discussed. I will subscribe to the appropriate section. YBG (talk) 00:49, 17 June 2024 (UTC)

Tech News: 2024-25

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

  • People who attempt to add an external link in the visual editor will now receive immediate feedback if they attempt to link to a domain that a project has decided to block. Please see Edit check for more details. [23]
  • The new Community Configuration extension is available on Test Wikipedia. This extension allows communities to customize specific features to meet their local needs. Currently only Growth features are configurable, but the extension will support other Community Configuration use cases in the future. [24][25]
  • The dark mode beta feature is now available on category and help pages, as well as more special pages. There may be contrast issues. Please report bugs on the project talk page. [26]

Problems

  •   Cloud Services tools were not available for 25 minutes last week. This was caused by a faulty hardware cable in the data center. [27]
  • Last week, styling updates were made to the Vector 2022 skin. This caused unforeseen issues with templates, hatnotes, and images. Changes to templates and hatnotes were reverted. Most issues with images were fixed. If you still see any, report them here. [28]

Changes later this week

  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 June. It will be on non-Wikipedia wikis and some Wikipedias from 19 June. It will be on all wikis from 20 June (calendar). [29][30]
  • Starting June 18, the Reference Edit Check will be deployed to a new set of Wikipedias. This feature is intended to help newcomers and to assist edit-patrollers by inviting people who are adding new content to a Wikipedia article to add a citation when they do not do so themselves. During a test at 11 wikis, the number of citations added more than doubled when Reference Check was shown to people. Reference Check is community configurable. [31]
  • Mailing lists will be unavailable for roughly two hours on Tuesday 10:00–12:00 UTC. This is to enable migration to a new server and upgrade its software. [32]

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

MediaWiki message delivery 23:46, 17 June 2024 (UTC)

Lots of problems with Quarry

Tracked in Phabricator
Task T367464

There have been problems with Quarry query for days now (and I opened a phab ticket but no action so far) and now the bots I rely on issue reports that are all out of whack, coming hours after they are regularly scheduled to be issued. I'm wondering if there is a bigger problem going on here with the database and since my phab ticket had has little response, I thought I'd inquire here in case anyone had any answers. It's frustrating and it's been going on days now. Liz Read! Talk! 06:03, 17 June 2024 (UTC)

According to the ticket, SD0001 wrote a patch to try to fix it and got it deployed. Sadly it didn't completely fix things though and more work is needed. Seems like a tricky bug. –Novem Linguae (talk) 01:06, 18 June 2024 (UTC)

(Un)subscribe JS error [Gadget?] (and many warnings)

(Skin Monobook) Example from this page: 

Wikipedia:Village_pump_(technical):984 This page is using the deprecated ResourceLoader module "mediawiki.ui.input".
[1.41] Please use Codex. See migration guidelines: https://www.mediawiki.org/wiki/Codex/Migrating_from_MediaWiki_UI
Wikipedia:Village_pump_(technical):984 This page is using the deprecated ResourceLoader module "mediawiki.ui.checkbox".
[1.41] Please use Codex. See migration guidelines: https://www.mediawiki.org/wiki/Codex/Migrating_from_MediaWiki_UI
Wikipedia:Village_pump_(technical):984 This page is using the deprecated ResourceLoader module "mediawiki.ui.button".
[1.41] Please use Codex. See migration guidelines: https://www.mediawiki.org/wiki/Codex/Migrating_from_MediaWiki_UI
(anonymous)	@	Wikipedia:Village_pump_(technical):984
Wikipedia:Village_pump_(technical):984 This page is using the deprecated ResourceLoader module "codex-search-styles".
[1.43] Use a CodexModule with codexComponents to set your specific components used: https://www.mediawiki.org/wiki/Codex#Using_a_limited_subset_of_components
(anonymous)	@	Wikipedia:Village_pump_(technical):984
startup.js:1307 This page is using the deprecated ResourceLoader module "jquery.ui".
Please use Codex instead.
2
log.js:79 Use of "addPortletLink" is deprecated. Use mw.util.addPortletLink instead
maybeLog	@	log.js:79
index.php?title=User…=text/javascript:67 Reflinks: Loading messages from cache @ 1718487515832
index.php?title=User…text/javascript:185 Promoting reFill 2
log.js:79 Use of "addPortletLink" is deprecated. Use mw.util.addPortletLink instead
maybeLog	@	log.js:79
startup.js:1307 This page is using the deprecated ResourceLoader module "mediawiki.ui".
[1.41] Please use Codex. See migration guidelines: https://www.mediawiki.org/wiki/Codex/Migrating_from_MediaWiki_UI
execute	@	startup.js:1307
ext.gadget.Navigatio…ps-script-0.js:2997 Uncaught 
TypeError: Cannot read properties of null (reading 'indexOf')
    at Title.namespaceId (ext.gadget.Navigatio…script-0.js:2997:22)
    at isInStrippableNamespace (ext.gadget.Navigatio…script-0.js:3220:18)
    at navlinkTag.getPrintFunction (ext.gadget.Navigatio…script-0.js:7580:48)
    at navlinkTag.html (ext.gadget.Navigatio…-script-0.js:7360:8)
    at navlinkStringToHTML (ext.gadget.Navigatio…script-0.js:7347:19)
    at pg.structures.menus.popupTopLinks (ext.gadget.Navigatio…script-0.js:1146:10)
    at pg.structures.shortmenus.popupTopLinks (ext.gadget.Navigatio…script-0.js:1160:30)
    at fillEmptySpans (ext.gadget.Navigatio…script-0.js:3876:12)
    at simplePopupContent (ext.gadget.Navigatio…s-script-0.js:365:3)
    at mouseOverWikiLink2 (ext.gadget.Navigatio…s-script-0.js:331:4)


Error does not seem to be 100% consistent, but I've had it on other pages too.

What is Codex? Were we asked about it?

All the best: Rich Farmbrough 10:59, 17 June 2024 (UTC).

Codex is "described" here. All the best: Rich Farmbrough 11:20, 17 June 2024 (UTC).
Most of that isn’t relevant, just warnings. The part that matters is:
ext.gadget.Navigatio…ps-script-0.js:2997 Uncaught TypeError: Cannot read properties of null (reading 'indexOf') at Title.namespaceId (ext.gadget.Navigatio…script-0.js:2997:22) at isInStrippableNamespace (ext.gadget.Navigatio…script-0.js:3220:18)
so it was an error when rendering a Navigation popups of a specific link that you were hovering. —TheDJ (talk • contribs) 21:32, 17 June 2024 (UTC)
Any console warnings that talk about "deprecation" mean that there are plans to delete support for that in the future, so folks are encouraged to update their code before that happens. But they don't result in any errors yet, just noisy warnings. So deprecation stuff can be ignored when debugging. –Novem Linguae (talk) 01:00, 18 June 2024 (UTC)
Many thanks for the replies.
  • I know what deprecation is.
  • I sometimes raise issues solely because they are a problem for me, though I would probably do so ref desk.
  • Generally I will raise issues here because they are issues for the wiki. These are such.
Breakdown of issues
  1. Warnings are important, including deprecations. They are a designed to enable us to prevent things from breaking rather than letting them break then (maybe) fixing them.
  2. We have a whole new JS component infrastructure. It may well be that most people are already aware of this, on the other hand it may not. If not this is a series socio-technical issue that needs addressing. Which is the case?
  3. We need to have a program to remove these deprecated items before they are no longer supported, or, a campaign to undeprecate them. This pf course applies to other wikis. Is such in place?
  4. There is an issue with a popular gadget. Someone willing and competent should look at this. If that someone is reading this great, if not who is it?
I've added a question to each issue (to try and move things forward), except the first, which is really a matter of maintenance philosophy, though I hope most people agree with it. Hope this makes the issues clearer.
All the best: Rich Farmbrough 08:55, 18 June 2024 (UTC).

Sorting problem

Why it's impossible to sort properly "Monthly net minimum wage (EUR)" in this list. Eurohunter (talk) 21:14, 17 June 2024 (UTC)

The documentation for sortable tables is at Help:Sortable tables —TheDJ (talk • contribs) 21:34, 17 June 2024 (UTC)
@Eurohunter: I have added data-sort-type="currency" to all wage columns [33]. They now ignore the currency symbol and sort the numbers in numerical order. If you want to sort by value then see Help:Sortable tables#Specifying a sort key for a cell. You could add data-sort-value="€..." | with an approximate € value to numbers not given in €. The data-sort-value is not shown to readers so the conversion doesn't have to be precise. PrimeHunter (talk) 22:10, 17 June 2024 (UTC)
@PrimeHunter: Thanks. Eurohunter (talk) 16:54, 18 June 2024 (UTC)

Thursday 13 June style changes

Update: The images problem was resolved on Tuesday 19th, the changed styling of infoboxes and hatnotes was reverted on Fri 14th

Infobox problems

Tracked in Phabricator
Task T367462

I am not seeing infobox borders anymore (at Walter Cronkite and Google for example). Is that a "me" issue, or is something broken? (I am on Debian/Firefox, so it might very well be a "me"/specific issue.)

On Android (both app and Firefox) everything seems normal. JackTheSecond (talk) 19:08, 13 June 2024 (UTC)

Same here. Also, my search box now disappeared! Martinevans123 (talk) 19:13, 13 June 2024 (UTC)
In My Preferences, Vector legacy (2010) restores my search box, Vector (2022) removes it. Perhaps coincidental/ unrelated. Martinevans123 (talk) 20:44, 13 June 2024 (UTC)
Consider starting a new section for that. I have no idea what could be causing it. Izno (talk) 20:51, 13 June 2024 (UTC)
  Done Have started a new thread. Thanks. Martinevans123 (talk) 21:10, 13 June 2024 (UTC)
The infoboxes look different for me as well, starting recently. But I'm not sure it's a technical problem, it could be a recently released change? Simeon (talk) 19:14, 13 June 2024 (UTC)
I have the same thing. On further investigation, it only affects me on Vector 2022 and not on any other skins. If it's a change to the skin, it's also broken some images in infoboxes and sidebars. The images seem to have either shrunk considerably at their default size, stopped loading or completely disappeared. Examples include: Next Senedd election, 2024 United States presidential election, Template:Donald Trump series, Template:Joe Biden series, Template:Keir Starmer sidebar, Template: Rishi Sunak sidebar, Template:Elon Musk series, etc. I remember a similar change to infoboxes was made a few months ago but dropped within a day or two. Can anyone at Wikimedia provide some clarification? ThatRandomGuy1 (talk) 19:16, 13 June 2024 (UTC)
Images are the same cause. I'll file a separate task for them since it's not obvious to me what the best resolution is for them. Izno (talk) 20:07, 13 June 2024 (UTC)
Tracked in Phabricator
Task T367463
Ok, this one was caused by phab:T113101 and I've filed phab:T367463 for resolution. Izno (talk) 20:23, 13 June 2024 (UTC)
On Monobook, I'm finding that certain infobox images are showing smaller than usual. Images in {{Infobox station}}, for example, are appearing at 272px for me rather than the 340px that I normally see that at. I assume this is related to this issue? Pi.1415926535 (talk) 03:03, 14 June 2024 (UTC)
Pi.1415926535, please see subsection #Infobox thumbnail-sized images are a few pixels too small. —⁠andrybak (talk) 09:40, 14 June 2024 (UTC)
@Andrybak: I'm not sure if the issue I'm seeing is that - I'm on Monobook rather than Vector, and I'm seeing them at ~80% size rather than just a few percent smaller. Regardless, hopefully it'll be sorted out by one of these Phabricator threads. Pi.1415926535 (talk) 20:16, 14 June 2024 (UTC)
For disappearing images in {{ombox}}, subsection #Ombox images sometimes not showing has been created below. —⁠andrybak (talk) 09:40, 14 June 2024 (UTC)
Same here on Firefox/Windows11. Don't remember seeing any discussion about this change anywhere before now. --JackFromWisconsin (talk | contribs) 19:23, 13 June 2024 (UTC)
It's affecting me on Windows 10 as well. ThatRandomGuy1 (talk) 19:26, 13 June 2024 (UTC)
This happened yesterday on commons with Wikidata Infobox when using Vector-22 so it seems to be a Wikimedia change. Cakelot1 ☞️ talk 19:33, 13 June 2024 (UTC)
Did looking around and the infoboxes now look like they do on the Minerva skin, and the hatnotes on the top of the article also look like Minerva now. Not sure if this is intentional or not. --JackFromWisconsin (talk | contribs) 19:40, 13 June 2024 (UTC)

I'm not surprised this happened, I will poke the relevant task. And yes, the relevant task also caused the hatnote differences below. Izno (talk) 19:45, 13 June 2024 (UTC)

So, these were caused by the work in phab:T361573 and elsewhere. I've filed phab:T367462 for a resolution. Izno (talk) 20:01, 13 June 2024 (UTC)

Please have a look at the infobox on 2024 European Parliament election in Ireland to see another issue this has caused. Why was it even changed in the first place? Was there a strong consensus for this change? The new format is causing many more problems than the old one ever did. Please ping me in your reply. Helper201 (talk) 05:26, 14 June 2024 (UTC)

I have reported this specific problem at T367462 just in case it is a separate problem from the other problems in this section. – Jonesey95 (talk) 06:05, 14 June 2024 (UTC)
Thanks. You can see another issue in this - Next Australian federal election - infobox as well. Helper201 (talk) 06:33, 14 June 2024 (UTC)
And another - 2017 United Kingdom general election. Helper201 (talk) 08:31, 14 June 2024 (UTC)
And more: 2024 European Parliament election, 2024 European Parliament election in Denmark, 2024 European Parliament election in Finland, 2024 European Parliament election in Germany, 2024 European Parliament election in Latvia, 2024 European Parliament election in Malta, 2024 European Parliament election in Poland, 2024 European Parliament election in Portugal, 2024 European Parliament election in Romania (see the middle overstretching in the middle as well as the extension outside of the infobox in this example), 2024 European Parliament election in Sweden. Helper201 (talk) 08:57, 14 June 2024 (UTC)
The latest post on "phabricator" says "We can either inverse the media queries for those hatnotes/infobox.less for now. (only apply at lower resolutions), or revert." I don't have an account on this platform but my vote in 100% revert this infobox change and return to how things were on Wednesday 12 June. Helper201 (talk) 09:25, 14 June 2024 (UTC)

I've been seeing issues with {{Infobox film}} which I assume are a result of this change. If no image is used in the infobox, then the width is set so low that even average-length names get split across two lines (see Normal Love for an example). hinnk (talk) 09:58, 14 June 2024 (UTC)

Multi-column tables in infoboxes aligned badly

split from the section above for tracking purposes

 
Bad infobox formatting on Chris Dangerfield

This seems to have broken a lot of infoboxes. The career history of every association football player is a misaligned mess; see the screenshot I've attached for an example. It seems like this change needs to be reverted until it's more polished. –IagoQnsi (talk) 20:12, 13 June 2024 (UTC)

Consider that your specific example is also how it displays on mobile and you should consider how best to remedy that regardless. This just made the issue visible for desktop as well. There probably needs to be some work done on the template to support small resolutions. Izno (talk) 20:25, 13 June 2024 (UTC)
The footballers infoboxes look nasty now it's true. CNC (talk) 21:48, 13 June 2024 (UTC)
A four-column table should be four columns. Not four items placed at seemingly-random horizontal alignments. I checked, and the HTML has the data as a table with several rows and four cells per row. Now, HTML tables go right back to HTML 3.2 (27 years ago), and it's always been the case that tables having multiple rows and multiple columns are presented in such a way that each cell is the same width as the other cells in the same column. How can this have been screwed up so badly? It looks as if all of the cells in a row have been merged into one, with proportionate spacing between the items. --Redrose64 🌹 (talk) 22:19, 13 June 2024 (UTC)
We have a chicken-egg problem. The issue here is that the infobox is currently a table element. Using the table for this element is bad, as it is difficult to consistently make tables friendly on a mobile device. For mobile devices, we currently resort to using display: flex.
Hopefully this GIF demonstrates the problem we are talking about here and how it impacts our mobile users (please click):
 
GIF demonstrating the challenges with using table based infoboxes at different font sizes and screen resolutions
Some wikis have successfully moved away from using a table for this reason. For example fr:Pic_de_Guadeloupe. English hasn't been able to move away from a table so easily, as many infoboxes like this example rely heavily on the status quo that it is a table.
The correct solution here would be to insert a table inside the relevant infobox section and not rely on the fact it will always be a table.
I've applied a change to Module:Infobox3cols to restore the old behaviour for now - but I hope we can agree this is not a long term solution. 🐸 Jdlrobson (talk) 01:28, 14 June 2024 (UTC)
Thanks. That fixed the column alignment. The infobox is still incredibly wide, much wider than it used to be and much wider than on Vector legacy, and there is also far too much vertical padding. I hope that fixes to the tickets tracked here will undo those changes. Also, it is not clear to me that French Wikipedia uses something other than tables for infoboxes. fr:Diego Maradona's infobox definitely uses a table for its infobox layout. fr:Pic_de_Guadeloupe, which does not use an infobox, also uses tables for layout of its taxobox, inside of div tags. – Jonesey95 (talk) 01:56, 14 June 2024 (UTC)
Sorry I should have clarified - French Wikipedia still has legacy infoboxes that they are trying to migrate away from. If you inspect the newer ones tend to come from newer infobox templates! 🐸 Jdlrobson (talk) 03:45, 14 June 2024 (UTC)
Links to examples of post-migration French infoboxes would be magnifique. – Jonesey95 (talk) 06:06, 14 June 2024 (UTC)
fr:Projet:Infobox/V3 is probably the best entry point! 🐸 Jdlrobson (talk) 16:06, 14 June 2024 (UTC)

Font size change

split from the section above for tracking purposes

Tracked in Phabricator
Task T367462

For me, at least, the font size in infoboxes has changed to 90% of the default size instead of 88%, which it has been forever. In Vector 2010, the font size in infoboxes is still 88%. I am looking at John Dalton, for example. I have the (formerly default) "small" font size selected as my prose body font preference in the new radio-button switcher on the right-side toolbar. – Jonesey95 (talk) 19:50, 13 June 2024 (UTC)

Is the small size also related to the massive line spacing as well? Is that visible for everyone else? microbiologyMarcus [petri dish·growths] 20:09, 13 June 2024 (UTC)
Line spacing inside infoboxes? Yes, that would be this change. Line spacing outside? Probably worth a different section Izno (talk) 20:52, 13 June 2024 (UTC)
Dear MediaWiki designers, dividers can be either gaps or lines – there is absolutely no need to use both approaches together, as this consumes valuable space and adds visual noise at the same time without producing any benefits. — Mikhail Ryazanov (talk) 06:23, 14 June 2024 (UTC)
And why .infobox td has that damn padding in hard-coded pixels instead of font units?! — Mikhail Ryazanov (talk) 07:24, 14 June 2024 (UTC)
A font size change this minor can have a significant impact, as in Louisville, Kentucky, two of the image descriptions in the montage went from two to three lines. I may have to change to a combined description as a cleanup, unless, of course, the font size is reverted back. Stefen Towers among the rest! Gab • Gruntwerk 06:56, 14 June 2024 (UTC)
I just changed a couple images to make the descriptions go back to two lines. Image widths make a difference in this case. And it so happens I was able to select images that focused more on the entities they represent. Stefen Towers among the rest! Gab • Gruntwerk 15:54, 14 June 2024 (UTC)
You should t be relying on fontsize to begin with. Ever. —TheDJ (talk • contribs) 17:11, 14 June 2024 (UTC)
I'm not "relying on fontsize". I never set any font size involved here. I just want to ensure things display well given the typical display settings and relative sizes of things. If anything, I have made the display less brittle due to underlying font size changes. And that's the point. Stefen Towers among the rest! Gab • Gruntwerk 19:50, 14 June 2024 (UTC)
I've noticed a significant decrease in font size across all text, not just infoboxes, while using the Vector 2010 skin on my iPad since the style changes. Here's a screenshot for reference. @Jonesey95: do you know if this is a separate issue? Thanks, ‑‑Neveselbert (talk · contribs · email) 17:53, 14 June 2024 (UTC)
Unrelated. This issue only applied to Vector 2022 skin. 🐸 Jdlrobson (talk) 19:55, 14 June 2024 (UTC)

Biographical infoboxes

Biographical infoboxes suddenly got much larger! Anybody know what is going on? Hawkeye7 (discuss) 21:55, 13 June 2024 (UTC)

Hawkeye7, please see section #Infobox problems above. —⁠andrybak (talk) 21:58, 13 June 2024 (UTC)

Hatnotes have Minerva-style background color?

Tracked in Phabricator
Task T367462

Look at the documentation for {{hatnote}} under Vector 2022. A WP:THURSDAY just happened; is there some change in MediaWiki that would've caused this? The CSS indicates that the change is intended to apply to any responsive skin. Aaron Liu (talk) 19:21, 13 June 2024 (UTC)

Is it possibly related this change to Module:Message box/fmbox.css? Oops, that was a month ago, but the class seems to be affected. With a bit more digging, that change seems unrelated. Probably something in the MediaWiki code itself, probably related to dark mode changes. – Jonesey95 (talk) 19:38, 13 June 2024 (UTC)
I've made some notes above. Regarding specifically hatnotes, you should also consider participating in Module talk:Hatnote#Mobile styling, which I started some time ago. Izno (talk) 20:01, 13 June 2024 (UTC)
Not keen on the new look at all, this is something that should have been agreed. Also, the font on the hatnotes looks smaller than it used to, it was a slight strain to read it on my laptop... this seems like a MOS:ACCESS issue if nothing else - small text is a huge no no.  — Amakuru (talk) 08:51, 14 June 2024 (UTC)

Infobox madness

Tracked in Phabricator
Task T367462

OK, does anyone know what is going on with infoboxes right now? The formatting is all askew as of the past 10 minutes or so. Stefen Towers among the rest! Gab • Gruntwerk 22:04, 13 June 2024 (UTC)

Came here to raise similar concerns. We have articles like SS United States with two infoboxes tucked inside one another having extraordinarily wiiiiide boxes, to the point that articles are hard to read. I've seen broken infoboxes thinner than the current ones.
Yesterday, I was set to the old 2010 display settings. Who's screwing with the new vector display? GGOTCC (talk) 22:21, 13 June 2024 (UTC)
Annnnd it's fixed! Check Thursday 13 June style changes above for more info. GGOTCC (talk) 22:23, 13 June 2024 (UTC)
The pages I'm looking at are not fixed. I work on pages for Star Wars characters and have done a lot of work to get infobox items to stay on one line. Now they're wrapping to a second line. Wafflewombat (talk) 22:26, 13 June 2024 (UTC)
Yes, the worst of it has apparently been corrected, but I'm still seeing things out of whack. Stefen Towers among the rest! Gab • Gruntwerk 22:27, 13 June 2024 (UTC)
Definitely not fixed yet in Vector 2022. The borders are still missing, and there are new, unnecessary borders between the rows, with excessive vertical spacing. The font size is also still at 90% instead of 88%, which is wrong. – Jonesey95 (talk) 23:37, 13 June 2024 (UTC)
Are the borders suppose to be missing? When I first saw it, I thought the change was to improve ascetics. GGOTCC (talk) 00:29, 14 June 2024 (UTC)
Yes, this appears to be an issue with the Vector (2022) skin. Infoboxes look fine on the old Vector. Stefen Towers among the rest! Gab • Gruntwerk 22:25, 13 June 2024 (UTC)
Others on this page are wondering the same thing. Some infoboxes now have far less space for content, which messes everything up. Wafflewombat (talk) 22:23, 13 June 2024 (UTC)
If I may summarize the key problem I'm seeing at this point, it's when you have a tabular presentation within the infobox, the first column is hogging up too much width. Stefen Towers among the rest! Gab • Gruntwerk 22:45, 13 June 2024 (UTC)
Perhaps, although the infoboxes seem thinner altogether, like there is simply less room for text overall. Or perhaps the text is just bigger than it was before? For me, changing the skin to 2010 doesn't fix the issue. Wafflewombat (talk) 22:47, 13 June 2024 (UTC)
From what I'm seeing, that is the appearance because first columns (usually data descriptions) are being given lots of extra width at the expense of second columns (the data). Stefen Towers among the rest! Gab • Gruntwerk 23:15, 13 June 2024 (UTC)
Just my 2¢ I'm working on Præsidenten fra Nordvest and the infobox looks so strange with the width being the size of the image. It looks inconsistent with other films like Batman (1989 film) (which I presume the width maxes out when there's a line break in one of the cells). The new infoboxes look the same as mobile-view, so it feels like a mobilificiation. Do style changes like this have a consensus discussion before changing? Svampesky (talk) 23:11, 13 June 2024 (UTC)

Infobox thumbnail-sized images are a few pixels too small

Tracked in Phabricator
Task T367462

FWIW, thumb-sized images now show slightly smaller than my chosen preference (300px) in infoboxes in Vector 2022. A normal thumbnail or frameless image shows as 300px, and the same image in Template:Infobox person (which defaults to the "frameless" image size option) shows as 295px.

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1228927316

When I force the view to Vector legacy, both images are the same, correct, size. Vector 2022's style sheets do not appear to be respecting users' (or at least my) preferred image thumbnail size. Maybe it's just me. I entered the above info into T367462, but it might be a separate bug. – Jonesey95 (talk) 00:00, 14 June 2024 (UTC)

See Izno's message above about T367463. —⁠andrybak (talk) 00:09, 14 June 2024 (UTC)
These images are not minuscule; they are just a little smaller than they should be, about 1.5% too small. – Jonesey95 (talk) 06:03, 14 June 2024 (UTC)
My mistake. I've struck link to the incorrect ticket. —⁠andrybak (talk) 10:04, 14 June 2024 (UTC)

Other images (which are not in infoboxes) have also shrunk. The images in the {{Public art row}} template in List of public art in the London Borough of Ealing § Acton are now minuscule, but the portrait-format images in List of public art in the London Borough of Ealing § Ealing are the size they ought to be. Ham II (talk) 06:56, 14 June 2024 (UTC)

Take a look at Wikipedia:Top 25 Report or any other page in Category:Wikipedia Top 25 Report; all of them them have images set to 100px inside a wikitable, but the displayed images are much smaller than what it should be... Vestrian24Bio (TALK) 14:29, 14 June 2024 (UTC)

How do I get these style changes on my local MW install?

I just noticed the new look of the infobox and am wondering how I can get this to my local MediaWiki install. I've already used Special:Export with Template:Infobox and Module:Infobox with Include templates on, but the changes have not applied. Anything I've forgotten to import? A diehard editor (talk | edits) 00:48, 14 June 2024 (UTC)

A diehard editor, because it is WP:THURSDAY, these changes are caused by the latest deployment of a new version of MediaWiki, which is 1.43.0-wmf.9 (see Special:Version). These changes are considered to be a bug. It was reported to the bug tracker at phab:T367462 and phab:T367463. —⁠andrybak (talk) 01:04, 14 June 2024 (UTC)
Oh, so it's not supposed to be like this on desktop, and I should not bring them over? I'm still on 1.42. A diehard editor (talk | edits) 01:07, 14 June 2024 (UTC)

Infoboxes

Tracked in Phabricator
Task T367462

Who and what changed the infoboxs to their new format in the last 24 or 48 hours? It’s causing issues I'd to let them know about. Where do I do this? Helper201 (talk) 05:21, 14 June 2024 (UTC)

This was a change to the MediaWiki code. Nobody at the English Wikipedia caused it. See above. – Jonesey95 (talk) 06:03, 14 June 2024 (UTC)
Jonesey95 can you please give me the link to the MediaWiki page where this decision came about or where on MediaWiki to present the issues this change has caused? Helper201 (talk) 06:17, 14 June 2024 (UTC)

Ombox images sometimes not showing

Tracked in Phabricator
Task T367463
 
Screenshot illustrating the problem.
 
Screenshot illustrating what it should look like.

Seems like there is a problem with {{ombox}} where sometimes images are not showing up, see e.g. {{sockpuppet}}. Mz7 (talk) 06:28, 14 June 2024 (UTC)

That's phab:T367463. Vector 2022 is now being affected by the same issues which affected Minerva (mobile) and Timeless skins for a long time (phab:T282588). —⁠andrybak (talk) 09:36, 14 June 2024 (UTC)
{{tmbox}} got a workaround applied in Special:Diff/1228936760. —⁠andrybak (talk) 09:40, 14 June 2024 (UTC)
I've submitted a request to apply the same workaround to {{ombox}}. —⁠andrybak (talk) 10:42, 14 June 2024 (UTC)
   Workaround has been applied. —⁠andrybak (talk) 19:35, 14 June 2024 (UTC)
@Andrybak: Thank you so much for your help on that! Mz7 (talk) 10:09, 15 June 2024 (UTC)

Infobox & Hatnotes

What just happened? Infoboxes and Hatnotes on Vector 2022 looks similar to that on Minerva... Is it any of my scripts or is it the new MediaWiki software causing these madness??? Vestrian24Bio (TALK) 07:37, 14 June 2024 (UTC)

 
How hatnote looks like in Minerva
 
How hatnote now looks like in Vector 2022
 
How hatnote should look like (Vector)
Added screenshots for reference. Vestrian24Bio (TALK) 08:46, 14 June 2024 (UTC)
@Vestrian24Bio, you started this subsection "Infobox & Hatnotes" of the big section #Thursday 13 June style changes. Please see other subsections for details about infoboxes and hatnotes. All issues highlighted in your screenshots are already being discussed there. —⁠andrybak (talk) 09:13, 14 June 2024 (UTC)
Got it. Thanks! Vestrian24Bio (TALK) 09:16, 14 June 2024 (UTC)

It's not the skin; it's the parser

Earlier this week, Wikimedia newsletter stated this week they are making changes to the HTML parser; even though it was supposed to only effect the citations, looks like its effecting other things as well.

I just tried breaking the parsing process and the images, hatnotes and even the infoboxes looked just like how they were yesterday and had none of these problems other than broken rendering. (Same for the Parsoid and Legacy as well) Vestrian24Bio (TALK) 14:47, 14 June 2024 (UTC)

Combination of tiny font and pale blue background is making section hatlinks almost illegible and major eyestrain on my laptop. The text size does not increase with selecting larger text from the appearance menu. This combination with excessively small text in edit boxes is untenable. I am now spending too much time zooming in and out when I could be actually improving content. · · · Peter Southwood (talk): 12:37, 14 June 2024 (UTC)

Is this part of Wikipedia:Village_pump_(technical)#Thursday_13_June_style_changes above or something different? Can you provide a link to an example, if you are on mobile or desktop, your skin, and your viewport size? — xaosflux Talk 13:17, 14 June 2024 (UTC)
It is part of #Thursday 13 June style changes. Vestrian24Bio (TALK) 14:22, 14 June 2024 (UTC)

Friday message from the Web team

Hey everyone, this is the Web team working on skins. We wanted to explain the situation, apologize, and share what will happen next. Thank you all for reporting and helping us fix things.

This week, we released styling changes to hatnotes, templates, and images. Some of these changes were not intended for rollout this week. Our focus was mostly on "Images should be responsive in Vector and restrained to a max-size" (T113101) and related tasks. We apologize for introducing bugs and making editors confused.

We read concerns shared on different wikis and on Discord, and went over our options. We decided to revert all changes to templates and hatnotes for the time being, and keep the changes to images. Next, we'll review the changes to templates and hatnotes, and bring them for discussion one by one prior to proceeding. If you notice any remaining issues with images, please report them in comments to this Phabricator ticket. We hope to have a fix for the remaining issue on Monday.

Thank you! SGrabarczuk (WMF) (talk) 17:24, 14 June 2024 (UTC)

@SGrabarczuk (WMF) thanks for addressing us here! These changes seem massively consequential. Was the mistake the rollout of these changes or were these changes not supposed to be as broken as they were, i.e. it wasn't properly tested but the changes where rolled out as planned? microbiologyMarcus [petri dish·growths] 18:52, 14 June 2024 (UTC)
Hey @MicrobiologyMarcus. The former - the mistake was the rollout of changes to hatnotes and infoboxes (and maybe other templates too). We only wanted to roll out the changes to images. SGrabarczuk (WMF) (talk) 19:09, 14 June 2024 (UTC)
@SGrabarczuk (WMF) Hi! I liked the design for infoboxes that was changed, will it be coming back? Interestingedits (talk) 20:03, 14 June 2024 (UTC)
@Interestingedits: It had better not be coming back, see #Multi-column tables in infoboxes aligned badly. --Redrose64 🌹 (talk) 21:46, 14 June 2024 (UTC)
Seconded. It caused way too much damage. Some articles had infobox images going off into the border whilst others had them shrinking or seemingly disappearing. Plenty other issues also emerged. They should fix those issues caused by the redesign first before considering whether to bring it back as an actual feature. ThatRandomGuy1 (talk) 21:58, 14 June 2024 (UTC)
Just FYI, it is the same infobox design as in the Minerva (mobile) skin. Just an idea if you wanted to switch over. JackFromWisconsin (talk | contribs) 07:46, 15 June 2024 (UTC)
Hey @Interestingedits - yes, we would like to bring the main ideas of the design back in the future! The issue was that it got batched together with some other changes before it was fully tested and ready for release. To bring it back we would need to do a bit more testing of the design and discussing on here and other wikis to make sure we can adapt everything in time before proceeding with the change. OVasileva (WMF) (talk) 08:12, 17 June 2024 (UTC)
Hi! Looking forward to it. Is there a way to keep track of the tests/discussions? Would love to be apart of it! Interestingedits (talk) 00:03, 18 June 2024 (UTC)
These changes/discussions are being tracked in phab:T367519 Jon (WMF) (talk) 21:13, 18 June 2024 (UTC)
Thanks for the update and your work. For me, there was a bright side to these events: It pushed me to fix display issues in two infoboxes that will make them appear less clunky on mobile. Stefen Towers among the rest! Gab • Gruntwerk 20:10, 14 June 2024 (UTC)

Tuesday 19th update

The problem with images was resolved on Tuesday 19th, the changed styling of infoboxes and hatnotes was reverted on Fri 14th. —TheDJ (talk • contribs) 07:58, 19 June 2024 (UTC)

"Talk:" page locked

98.248.161.240 (talk) 03:53, 19 June 2024 (UTC)

This edit was also requested at Wikipedia:Teahouse#"Talk:" page locked. This request was implemented by User:RudolfRed in this and this edit. LightNightLights (talk • contribs) 09:44, 19 June 2024 (UTC)

Accessibility of map pushpin in infobox

Hello,

On this page, Glover-Archbold Park, I noticed the red dot signifying coordinates on the map in the infobox is quite hard to see. The background has a lot of lines, etc., that make it hard to identify where on the map the red dot is at a glance. Are there more accessible ways to portray this within infobox? Namely, a red dot on a green line seems like a colorblindness nightmare. Cheers, --Engineerchange (talk) 01:17, 19 June 2024 (UTC)

@Engineerchange: Template:Location map#Parameters has mark to change File:Red pog.svg, but Glover-Archbold Park uses {{Infobox NRHP}} which doesn't pass on mark so this method doesn't currently work here. There is no pretty way to do it. An ugly way is wrapping the whole infobox call in {{replace}} to change the file name but it would make it hard to edit the infobox in VisualEditor, and it could fail later if the infobox changes a detail in its output. I don't recommend such a hack for a minor change like this. You could try a request at Template talk:Infobox NRHP to pass on mark. PrimeHunter (talk) 11:12, 19 June 2024 (UTC)

MediaWiki:Actionthrottledtext triggered for non-bot account

Hi. Using this account (which is not automated, albeit new), I tried to make a major edit to this page. Request got blocked by MediaWiki:Actionthrottledtext. I tried again roughly 14 hours later : same error message. The Help Desk told me to publish this technical difficulty here. You can found my original message here.
I did try to make the same edit with an older account : got hit by the MediaWiki:Actionthrottledtext too.
Thanks in advance. Alpiiiiiine (talk) 14:42, 17 June 2024 (UTC)

The help desk and Teahouse has recently got several posts from users reporting this message. None of them were autoconfirmed. We didn't get such reports before so something has probably changed. PrimeHunter (talk) 21:56, 17 June 2024 (UTC)
That older account, which is autoconfirmed, is also hit by the same restriction, even after waiting for a day. It's @Erwan789. I really don't understand why both accounts are receiving that message is one is years older and autoconfirmed, and the other one isn't. Alpiiiiiine (talk) 08:47, 18 June 2024 (UTC)
User:Erwan789 is not autoconfirmed. It requires both four days and ten edits at the English Wikipedia. Erwan789 only has seven edits here. Special:CentralAuth/Erwan789 shows edits at other wikis but that doesn't count. PrimeHunter (talk) 11:46, 18 June 2024 (UTC)
Oh OK I got it now, thanks for explaining, that really helped me. Erwan789 (talk) 22:49, 18 June 2024 (UTC)
@Alpiiiiiine: I know this happened because of this situation, but please read the policy on multiple accounts, you really aren't supposed to be using more than one account at once without it being for at least one of the valid reasons, and even then the accounts should usually be linked – 2804:F14:80D0:4F01:ECC5:CFE4:210D:21A8 (talk) 19:00, 18 June 2024 (UTC)
Do not worry : I will delete the newly (and useless) account, thanks for reminding me to do so. Erwan789 (talk) 22:50, 18 June 2024 (UTC)
@Alpiiiiiine:/@Erwan789: Did you get a CAPTCHA with your "major edit", and if so how many times did it take for you to get it right? In any case, can you try one more time, from the Alpiiiiiine account, please? Suffusion of Yellow (talk) 23:09, 18 June 2024 (UTC)
I did get CAPTCHA for them, and I got them right on the first trim except for one.
I tried again, this time i got not CAPTCHA, just the error message. Erwan789 (talk) 08:00, 19 June 2024 (UTC)
That post was the tenth edit by User:Erwan789, meaning the account is now autoconfirmed. Can you test whether it still fails for Alpiiiiiine but now works for Erwan789? PrimeHunter (talk) 11:27, 19 June 2024 (UTC)
The edit was blocked on Alpiiiiiine, but it (finally) went through for this account! Erwan789 (talk) 11:41, 19 June 2024 (UTC)
Thanks for the information. It may help somebody (not me) who tries to track down the cause. PrimeHunter (talk) 12:43, 19 June 2024 (UTC)

U.S. county infobox display issue

See Template talk:Infobox U.S. county#"Location within the state" map broken?. This is a map display problem seemingly discovered just today. Stefen Towers among the rest! Gab • Gruntwerk 23:29, 16 June 2024 (UTC)

FYI, This doesn't seem to be related to the CSS changes. File:Map of Texas highlighting Liberty County.svg is not displaying correctly for me. Are others seeing this? I am using Vector 2022, logged in or logged out, mobile and desktop view. It also does not display in Timeless or Vector legacy. – Jonesey95 (talk) 05:35, 17 June 2024 (UTC)
I possibly assumed too quickly this connected to the infobox formatting. The problem exists in the Commons version too. SVG processing error, or some problem at the Commons source? Stefen Towers among the rest! Gab • Gruntwerk 06:22, 17 June 2024 (UTC)
Rendering of US county SVG files has changed and fixed replacements must be uploaded at Commons. See Wikipedia:Teahouse#Infobox probelem and Wikipedia:Teahouse#Us couties on article map. PrimeHunter (talk) 09:35, 17 June 2024 (UTC)

SVG file not displaying correctly - Microsoft Edge

Tracked in Phabricator
Task T367645

Hi, it looks like SVG files and their PNG preview versions are not displaying correctly in Microsoft Edge browser Version 126.0.2592.56 (64-bit). For example, Cabell County, West Virginia shows the red outline of the county but no background map of the state in the infobox picture. It has the same appearance if "reloaded in Internet Explorer mode". Tsarivan613 (talk) 14:10, 17 June 2024 (UTC)

I just submitted a bug report to Phabricator site. Tsarivan613 (talk) 14:20, 17 June 2024 (UTC)
It's a problem with the SVG files that was revealed by last week's software update (see #Tech News: 2024-24) – it's already filed as T367645. Matma Rex talk 14:33, 17 June 2024 (UTC)
I've filed a BRFA over on Commons to sort these. Mdann52 (talk) 17:46, 19 June 2024 (UTC)

New York City locator maps in Slovenian?

 
Screenshot of the locator map for Radio City Music Hall on 2024-06-17

It appears that the locator maps for places in New York City are being displayed with labels in what appears to be Slovenian or another Slavic language. For example, see the screenshot I just took of the locator map in the Radio City Music Hall article: Lincoln Square is "Linkoln Skver", Columbus Circle is "Kolambus Serkl", Hell's Kitchen is "Hels Kičen", South Central Manhattan is "Južni Srednji Menhetn", etc. —Bkell (talk) 21:59, 17 June 2024 (UTC)

See Wikipedia:Village pump (technical)/Archive 212#Serbian place names displayed on Manhattan maps. It's being worked on. PrimeHunter (talk) 22:12, 17 June 2024 (UTC)
The priority of one ticket, T230013, was recently moved from "Backlog" to "Later". A second ticket, T195318, looks like it might actually have a patch available, but it needs to be moved forward. – Jonesey95 (talk) 22:22, 17 June 2024 (UTC)
In Wikipedia, language translates you! RoySmith (talk) 14:30, 18 June 2024 (UTC)
 
I have a similar issue but with the '2022 Russian invasion of Ukraine.svg' image used in Russian invasion of Ukraine. It's only visible one the original file option. -- LCU ActivelyDisinterested «@» °∆t° 19:23, 19 June 2024 (UTC)

Saving settings

Whenever I attempt to save my settings (both on mobile and laptop) it instantly resets as soon as I leave the settings page, regardless of whether I have clicked save. Has anyone else experienced this? The main issue for me is the email settings and I am considering just removing my email address so I am not constantly receiving emails, however it does mean that if I forgot my password I will be locked out of my account. Any help would be greatly appreciated. Longhorncowfish (talk) 00:25, 19 June 2024 (UTC)

@Longhorncowfish The options at Special:Preferences#mw-prefsection-echo include having one email per week with all your notifications, and check boxes to specify what these notifications should include. Are you saying you can't save changes to that set of preferences? Mike Turnbull (talk) 21:24, 19 June 2024 (UTC)

Line of text at top of user page or user talk page with statistics

In the past when I was on a user page or user talk page I would see a line of text near the top with the age of the account, number of edits and most recent edit date or something like that. It disappeared a while ago. I've tried some things but couldn't figure out to bring it back. What's the deal? SchreiberBike | ⌨  21:07, 19 June 2024 (UTC)

@SchreiberBike: Are you sure it wasn't just displayed when you hovered over a link and had Navigation popups enabled? PrimeHunter (talk) 21:57, 19 June 2024 (UTC)
Nope. I even tried turning on Navigation popups, but that didn't bring it back. I remember reading about the trick to see that line of text at VPT many years ago and I think I copied some code to one of my code pages, but it stopped some time in the last month or so. I then deleted all the code from the code pages so I could move forward with a clean slate. Thanks for the idea though. SchreiberBike | ⌨  22:07, 19 June 2024 (UTC)
@SchreiberBike: This would be User:PleaseStand/User info, which you attempted to disable two weeks ago (but probably broke instead, hence the subsequent edit). Please note that the <!--...--> tags only work on HTML pages, they are not valid Javascript for which the comment syntax is /* ... */. --Redrose64 🌹 (talk) 22:18, 19 June 2024 (UTC)
@Redrose64: That did the job. Thank you for your help. SchreiberBike | ⌨  22:35, 19 June 2024 (UTC)
I think this is the XTools gadget. Izno (talk) 22:14, 19 June 2024 (UTC)
@Izno: Nope, but that's interesting too. Thank you. SchreiberBike | ⌨  22:39, 19 June 2024 (UTC)

Morebits

Hi. I recently created the AlertAssistant user script. Would it be possible to make the two radio buttons appear on the same line and display the {{Contentious topics/log}} template? Also, would it be possible to not be warned by filter 602? Thanks. '''[[User:CanonNi]]''' (talk • contribs) 00:19, 19 June 2024 (UTC)

This is not directly supported by Morebits, but can be achieved by custom CSS modifications. – SD0001 (talk) 04:51, 20 June 2024 (UTC)

Watched pages at Wikidata

Is this possible to see which pages are already in watch list on Wikidata while on page at ENWP? Is there any icon to show it? Eurohunter (talk) 20:32, 19 June 2024 (UTC)

@Eurohunter: I don't know a way to see on a Wikipedia page whether the Wikidata item for the page is on your watchlist at Wikidata. It's not what you asked for but in case you don't know this, you may be interested in the option "Show Wikidata edits in your watchlist" at Special:Preferences#mw-prefsection-watchlist. PrimeHunter (talk) 21:44, 19 June 2024 (UTC)
@PrimeHunter: Yes, I have it but all the time I visit page at ENWP I don't know if I watch it already in WD. Eurohunter (talk) 15:47, 20 June 2024 (UTC)

I Wikignome IMDb errors using this insource search. Tonight, I corrected about a dozen articles based on the hits (see my contributions for details). Usually, if I repeat the search, the hits are gone as soon as I've made the relevant correction but this time they only disappeared slowly: the search is still giving six hits despite, in reality, the articles currently not having the issue searched for! Is this a known behaviour? Mike Turnbull (talk) 21:13, 19 June 2024 (UTC)

I sometimes see delays in search results, not specific to insource. The time stamp at the search result shows the searched revision but doesn't reveal if there is a newer revision. I assume any search will be based on the same revision until the search index is updated with a newer revision. Navigation popups shows how long ago a page was edited when you hover over a link. This time should always be up to date. PrimeHunter (talk) 21:53, 19 June 2024 (UTC)
Thanks, I thought I was cracking up! I do use navigation popups and can see the discrepancy in the times: there are still six hits as I write and the oldest is now ~ 2 hours out-of-date. Mike Turnbull (talk) 22:01, 19 June 2024 (UTC)
In case you don't know how a search index works: It's far too slow for the software to actually search every page when a user performs a search. For efficiency reasons, a search index is built, e.g. listing all pages with "imdbtitle" in the wikitext. This search index has to be updated every time a page is saved. I remember years ago when the search index of all pages was always only updated once a day, and some days skipped the update. PrimeHunter (talk) 22:13, 19 June 2024 (UTC)
Yes, over the years I've had experience with Db2 and Oracle for large scientific databases. I just hadn't noticed such latency here on Wikipedia before. Mike Turnbull (talk) 09:09, 20 June 2024 (UTC)
They recently introduced such a latency, it would take 10 mins to process. Sjoerd de Bruin (talk) 16:02, 20 June 2024 (UTC)

"updated since your last visit" stopped working on WP:RSN

The "updated since your last visit" feature (where that text is displayed next to revisions in the edit history) has stopped displaying for me on Wikipedia:Reliable sources/Noticeboard. It still works on other pages. I suspect the issue is the extraordinary size of Wikipedia:Reliable sources/Noticeboard, currently 1,051,395 bytes. Is this a known issue, that this feature fails on large pages? It is not overly pressing, as it seems some big discussions are going to be archived off that page soon, bringing the size back down. -sche (talk) 00:20, 21 June 2024 (UTC)

Ensure Preferences -> Gadgets -> Watchlist -> Subtle update marker is checked. Separately, ensure you're watching that page still. Izno (talk) 00:23, 21 June 2024 (UTC)
Thanks. I checked and I still have it enabled, and still have the page watchlisted. And now it's showing up for me on that page again. It had always continued showing up for me on e.g. WP:AN, even when it wasn't showing up on RSN. I guess it was a temporary glitch. (If it stops showing up again, I'll report back.) -sche (talk) 01:22, 21 June 2024 (UTC)

Mysterious alteration of anchor

  Resolved

I made two edits, to Template:Citation Style documentation/title and to Template:Citation Style documentation/quote. The second one works to allow a link like Template:Cite web#csdoc_trans-quote, but the first one doesn't work - the link Template:Cite web#csdoc_trans-title fails. Checking the HTML emitted by Template:Cite web, I find that the intended anchor id="csdoc_trans-title" is being silently altered to id="csdoc_trans_title" but id="csdoc_trans-quote" is left as intended. Does anybody know why the behaviour differs? --Redrose64 🌹 (talk) 21:37, 20 June 2024 (UTC)

csdoc_trans_title appears in Template:Citation Style documentation/web, could that have something to do with it? That's the extent I have looked at it, haven't perused around the code. – 2804:F14:80D0:4F01:D5D6:530:F7B:3C2A (talk) 21:45, 20 June 2024 (UTC)
The markup in Template:Citation Style documentation/web is transcluded from Template:Citation Style documentation/title, and the third entry in the search provided shows the correct markup. --Redrose64 🌹 (talk) 21:56, 20 June 2024 (UTC)
Maybe I'm just misunderstanding things, but neither /web nor /title appear to transclude each other, they're both manually written, even if it's the same content. /web is trancluded in Template:Cite web... personally I would just have tested if changing it in /web and purging the cache fixed Template:Cite web#csdoc_trans-title, but I don't know the reasons for the id being what it is and am afraid of messing things up. – 2804:F14:80D0:4F01:D5D6:530:F7B:3C2A (talk) 22:07, 20 June 2024 (UTC)
@Redrose64: Eh, I didn't see how changing it could break anything, so I did change it(diff) - Template:Cite web#csdoc_trans-title now works. – 2804:F14:80D0:4F01:D5D6:530:F7B:3C2A (talk) 22:29, 20 June 2024 (UTC)
This sounds like a MediaWiki parsing error, and if I had a suspicion of cause it would have to do with title being a valid HTML attribute. Izno (talk) 21:56, 20 June 2024 (UTC)
On that basis, Template:Citation Style documentation/title#csdoc_trans-title would also fail, but it works. --Redrose64 🌹 (talk) 22:03, 20 June 2024 (UTC)
Both of the links you gave, Template:Cite web#csdoc_trans-quote and Template:Cite web#csdoc_trans-title, work for me. Matma Rex talk 23:29, 20 June 2024 (UTC)
I fixed #csdoc_trans-title, as I mentioned above. – 2804:F14:80D0:4F01:D5D6:530:F7B:3C2A (talk) 23:56, 20 June 2024 (UTC)
Thanks. It totally missed me that Template:Citation Style documentation/web did things its own way. Late evening and sleepy, I guess. --Redrose64 🌹 (talk) 07:09, 21 June 2024 (UTC)

Category:Wikipedia requested photographs of

This page, which redirects and seems completely redundant to Category:Wikipedia requested photographs, has been created three times since November 2023 (twice so far this month). The first two creations were misplaced userspace drafts. As I type, it's slowly being populated with talk pages, with the corresponding redirect link being left behind on each talk page. I've just switched it from a "hard" to a soft redirect in line with WP:R#CATEGORY.

Does anyone know why this category is continuing to be populated? Also, considering its recreations, has there been some kind of template documentation change somewhere on en.wiki which keeps leading users to this page?

I'm not sure the category must be deleted, but seeing as the category title is longer than the one it redirects to, keeping it seems rather pointless to me.

I'm in half a mind to just G6-delete and re-salt on account of the technical issues from the category population, but I'm intrigued... SuperMarioMan (Talk) 20:51, 20 June 2024 (UTC)

I am pretty sure this is due to |image-needed= not being set up correctly or there being something not quite working in Module:WikiProject banner. @MSGJ? Izno (talk) 20:58, 20 June 2024 (UTC)
  • Soft-redirecting appears to have stopped the category population. When it was a hard redirect, the category seemed to be accumulating talk pages at a rate of ~10 a minute. SuperMarioMan (Talk) 21:10, 20 June 2024 (UTC)
Correction: the category is still populating, but more slowly. SuperMarioMan (Talk) 21:57, 20 June 2024 (UTC)
The code is in Module:WikiProject banner/auxiliary. I see it looks whether a category of the form Category:Wikipedia requested photographs of {{{topic}}} exists. If it does then it uses that category, otherwise it will use the default, which for biographies is Category:Wikipedia requested photographs of people. So creating Category:Wikipedia requested photographs of has actually caused this problem. But I obviously need to update the code so that a blank topic parameter will be considered. — Martin (MSGJ · talk) 22:34, 20 June 2024 (UTC)
I posted a similar query at the module's talk page. – Jonesey95 (talk) 23:09, 20 June 2024 (UTC)
I think that the main problem is that ‹The template Category link is being considered for merging.› Category:Wikipedia requested photographs of got created - this occurred yesterday, and was done by The Sharpest Lives (talk · contribs). The code in Module:WikiProject banner/auxiliary relies on the non-existence of that category page. We may need to delete it, and then WP:NULLEDIT every page in the category. --Redrose64 🌹 (talk) 07:16, 21 June 2024 (UTC)
I assume it got created because it already contained some pages, which I don't understand. But anyway I have updated the module code so this should no longer happen — Martin (MSGJ · talk) 07:31, 21 June 2024 (UTC)
Apologies – I created the redirect because I noticed it was on Special:WantedPages with thousands of links. I thought that making the category a redirect would "move" the pages into the correct category, but I'm sure now that that's not how all this works. Sorry for any trouble. – The Sharpest Lives (💬•✏️•ℹ️) 12:53, 21 June 2024 (UTC)
@The Sharpest Lives: If a page uses mw:Help:Extension:ParserFunctions##ifexist then it causes an entry in WhatLinksHere for the tested page, and probably also counts in Special:WantedPages. A template may make thousands of ifexist checks of the same page. It doesn't imply somebody wants the page to exist, or that anything actually links to the page. PrimeHunter (talk) 15:42, 21 June 2024 (UTC)
A null edit isn't needed, a purge with forcelinkupdate works. Eventually the job queue should get around to doing that due to the module edit, but I don't know how long that might take or if there's job queue breakage of some sort at the moment. Anomie⚔ 14:57, 21 June 2024 (UTC)

The time allocated for running scripts has expired

Hello, appear to get red messages of "The time allocated for running scripts has expired." As an example there is 3 messages at end of Bridlington and The Wolds (UK Parliament constituency). The page does not display the templates at the end of the article. I have tried a dummy edit on page to see if that will clear the problem. The page is OK when viewed in edit preview, wikitext editor. Keith D (talk) 12:26, 21 June 2024 (UTC)

A purge seemes to have fixed it. — xaosflux Talk 13:20, 21 June 2024 (UTC)
@Keith D: This has been affecting random pages at random times for some weeks, all you need to do is WP:PURGE. --Redrose64 🌹 (talk) 16:06, 21 June 2024 (UTC)

Bugs persisting after last week

Hello! Ever since the infobox bugs last week, I've been experiencing some issues. Just wanted to let you know.

  1. The search bar at the top of the page disappears if I zoom in on the page too far. I usually read and edit WP zoomed-in, and this doesn't usually happen.
  2. On Talk pages, the WikiProject headers have lost their icons.
  3. When I'm in the visual editor and I click the number for an inline citation, the full citation pops up in a box like usual, but sometimes I am unable to click links in the citation.

Thanks! Wafflewombat (talk) 16:19, 20 June 2024 (UTC)

@Wafflewombat: Regarding no. 1: the search bar does not disappear, it collapses into a magnifying glass icon - try clicking that. No. 2 doesn't happen for me. --Redrose64 🌹 (talk) 18:27, 20 June 2024 (UTC)
Do you know if the search bar is supposed to collapse, or if the collapsing is a glitch? Wafflewombat (talk) 21:16, 20 June 2024 (UTC)
@Wafflewombat Re: 1 - If you zoom-in far enough using your browser's settings, the page will eventually switch into the layout that it uses for everyone if their browser-window is less than 1120pixels wide (which doesn't use the sticky header)
Re: 2 - It might help if you could link to an example page, and describe what icons you used to see at that example, but no longer see. E.g. I don't see any missing icons at Talk:Cat. (It might also help if you clear your browser cache with a hard-refresh, cf. WP:REFRESH.)
Re: 3 - Matma Rex has covered below. Quiddity (WMF) (talk) 01:10, 21 June 2024 (UTC)
I figured out the icons issue, but I still find the search bar issue strange, because it's disappearing at a zoom level that I always use, and it didn't disappear at that zoom level before. Not a big deal, though. I can live with it, if it's not a problem for anyone else. Wafflewombat (talk) 01:22, 21 June 2024 (UTC)

When I'm in the visual editor and I click the number for an inline citation, the full citation pops up in a box like usual, but sometimes I am unable to click links in the citation.

This is now filed as T368119. Matma Rex talk 01:09, 21 June 2024 (UTC)
Just a heads-up, this clicking problem in the VE is now happening with other buttons in addition to the inline citations. Wafflewombat (talk) 06:22, 21 June 2024 (UTC)
@Wafflewombat Hi, please could you describe which specific other buttons you are experiencing problems with? (I tried opening an article in VE and clicking random things, but everything else worked as expected.) Thanks. Quiddity (WMF) (talk) 17:39, 21 June 2024 (UTC)
Thanks for the message. The other buttons are working properly now, but the links within citations I mentioned above are still not functioning. Wafflewombat (talk) 17:48, 21 June 2024 (UTC)

Getting a list/count of values of a parameter.

(not real example). Template Infobox:Guinea Pig has a parameter called "Tail color". I'd like to be able to see what values this parameter has over all articles that use the infobox. (I asked on the help desk and got no response)Naraht (talk) 21:46, 20 June 2024 (UTC)

Bambots TemplateParam supports it for templates that have TemplateData. Izno (talk) 00:14, 21 June 2024 (UTC)
Any template that has a TemplateData section filled out in its documentation should also have a {{TemplateData header}} template. That header template contains a link to a report, generated monthly, of parameter usage. If the template you are interested in does not have a TemplateData section yet, one will have to be added. After that, the bot runs sometime around the 10th of each month and generates a report. – Jonesey95 (talk) 01:42, 21 June 2024 (UTC)
thank you both very much. While only running monthly, the Bambots TemplateParam for Infobox Fraternity is proving very useful at Wikipedia:WikiProject Fraternities and Sororities.Naraht (talk) 03:18, 22 June 2024 (UTC)

Citing Wikipedia Library sources

Not sure where to ask this but a few times I've tried to cite a source found through the Wikipedia Library but all I get is this rather than the article I'm citing from. See Niccolò Paganini and Manuel de Falla for examples. Is this a technical issue with the cite tool? Or am I doing something wrong? — Iadmc♫talk  10:36, 22 June 2024 (UTC)

Well you should not be pasting in the url that you use for the Wikipedia library to the cite tool. The tool will be asked to logon and that will be why you get the wrong link. You can use the doi or other permanent link that the pages show. Or the url that would be used if not using Wikipedia library. I get close to 100% success with dois. Graeme Bartlett (talk) 12:16, 22 June 2024 (UTC)
Ah that could be it! Thanks I'll try that next time. — Iadmc♫talk  12:45, 22 June 2024 (UTC)

Heads-up: Diff colour

Hey everyone,

On the topic of accessibility: As you might know, the Wikimedia Foundation Web team is working on a night mode, which is currently available on mobile but continues to be developed. As part of the accessability work around this, the developers made some slight changes to the colour in the diff text, which will be visible on the wikis this week but didn't make it into Tech News until next week. You can read more in phab:T361717.

As part of the Tech News crew, I wanted to let you know since it didn't make it into this week's issue. /Johan (WMF) (talk) 15:07, 19 June 2024 (UTC)

Is having different colours between different modes such a hard thing to add? The colour look much worse now on the default/white mode and are too pale. Traumnovelle (talk) 10:17, 20 June 2024 (UTC)
I'm using the old Vector style, and I want to switch back to old diff colors. This is hurting my eyes...can someone help me with the css code needed? Jonatan Svensson Glad (talk) 11:56, 20 June 2024 (UTC)
I came here to ask the same, particularly the new yellow is painfully vivid due to light sensitivity. -- LCU ActivelyDisinterested «@» °∆t° 14:23, 20 June 2024 (UTC)

This should restore the old colors: 

.diff-deletedline {
  border-color: #ffe49c;
}
.diff-addedline {
  border-color: #a3d3ff;
}
.diff-deletedline .diffchange,
.mw-diff-inline-deleted del, .mw-diff-inline-changed del, .mw-diff-inline-moved del {
  background: #ffebad;
}
.diff-addedline .diffchange,
.mw-diff-inline-added ins, .mw-diff-inline-changed ins, .mw-diff-inline-moved ins {
  background: #a3d3ff;
}

-- hgzh 14:31, 20 June 2024 (UTC)

Thanks hgzh that works perfectly. -- LCU ActivelyDisinterested «@» °∆t° 15:36, 20 June 2024 (UTC)
Before too many people copy this over to their user CSS, I strongly advise instead that you use the CSS I recommended in T361717#9910664 instead as diff HTML (and thus associated selectors) is not covered by the mw:Stable_interface_policy/Frontend. Jon (WMF) (talk) 16:21, 20 June 2024 (UTC)
I used the selectors because they work in all skins, while the changes to css variables will have no effect in timeless and monobook skin (don't know how many people are using these over here, in dewiki I think we have quite a lot of people that still use monobook and are not very keen on a changing interface). If you are only on Vector/Minerva skins, the variable override is better. hgzh 17:41, 20 June 2024 (UTC)
Ack. I forgot the old skins are not getting CSS variables right now. I'll update my comment with clearer advice by the end of the day. Thanks for pointing this out. Jon (WMF) (talk) 21:11, 20 June 2024 (UTC)
@Johan (WMF), Tech News is distributed to 700+ communities. So it is extremely weird (and a bit disheartening) to see WMF people inform only the English-speaking community if something was not relayed there.
(Though I am of the opinion that this strange diff colour change should not have been made at all, or should’ve been made with more care to keep the colours closer to the original.) stjn 16:32, 20 June 2024 (UTC)
Stjn: I absolutely understand that perspective, and this is not a substitute for a Tech News update – there will be a Tech News update – but I'd like to point out didn't only update the English-speaking community. I also posted on a mailing list for people who have signed up to spread technical information to their home communities. Where this quick update ended up doesn't reflect Foundation priorities, but language limitations – it's also been posted on Swedish Wikipedia, for example. Johan (WMF) (talk) 17:05, 20 June 2024 (UTC)
Thanks for that hgzh! I think two of the colors are slightly off. I think this will restore the original colors:
/* restore old diff colors */
.diff-deletedline {
  border-color: #FFE49C;
}
.diff-addedline {
  border-color: #A3D3FF;
}
.diff-deletedline .diffchange,
.mw-diff-inline-deleted del, .mw-diff-inline-changed del, .mw-diff-inline-moved del {
  background: #FEEEC8;
}
.diff-addedline .diffchange,
.mw-diff-inline-added ins, .mw-diff-inline-changed ins, .mw-diff-inline-moved ins {
  background: #D8ECFF;
}
I did try the CSS that Jon (WMF) linked, but sadly it did not work. –Novem Linguae (talk) 16:59, 20 June 2024 (UTC)
What should be the previous colors can be found at Special:Permalink/1228175150 (old version of Help:Diff). The hex color codes in Novem Linguae's version look accurate to me. —⁠andrybak (talk) 22:38, 20 June 2024 (UTC)
The hex colour codes are correct and normally work fine; however, when one is comparing a diff with highlighted text such as [34] the colours are more bold and vivid than before.
Diffs where text is not highlighted such as [35] appear fine however. Traumnovelle (talk) 00:20, 21 June 2024 (UTC)
Just wanted to remark that the colours are interfering with the ability to highlight text (for example, for copying and pasting)—the highlight can't be seen against the purple colour. — SGconlaw (talk) 02:33, 21 June 2024 (UTC)
The colours used when marking text for copy and paste are a feature of your browser and/or operating system, we have no control over them. There aren't even any CSS pseudo-classes, CSS background properties or CSS color properties that might provide any means of selection or setting. --Redrose64 🌹 (talk) 07:07, 21 June 2024 (UTC)
Pseudo-element ::selection applies styles to the part of a document that has been highlighted by the user (such as clicking and dragging the mouse across text). —⁠andrybak (talk) 09:51, 21 June 2024 (UTC)
@Novem Linguae: thanks for that version. It worked with my monobook. I was fearing I'd have to stop editing here, it was that bad. My eyes hurt and watered. -- Valjean (talk) (PING me) 22:12, 21 June 2024 (UTC)
Thanks for this. The new colors are awful and non-intuitive. Some1 (talk) 22:30, 21 June 2024 (UTC)
Our interface admin switched our wiki back to the old colors, but on m.wikipedia I'm still seeing the new low-contrast backgrounds (purple and ochre). So there must be something else that needs to be fixed. Form over function - rarely a good thing! Ponor (talk) 14:36, 22 June 2024 (UTC)
Why isn't that a setting in preferences? I already have problems with my head hurting lately, and high contrast on my computer or phone screen doesn't help. LilianaUwU (talk / contributions) 03:07, 21 June 2024 (UTC)
Speaking of which, there already is a gadget called "Display diffs with the old yellow-and-green colors and design". Time for another one? lol Nardog (talk) 03:15, 21 June 2024 (UTC)
I mean... why not. LilianaUwU (talk / contributions) 03:19, 21 June 2024 (UTC)
Or you can paste the old diff color CSS code that NL made to your Meta global.css page. Codename Noreste 🤔 Talk 19:50, 21 June 2024 (UTC)
Novem Linguae's version worked for me. -- Valjean (talk) (PING me) 22:13, 21 June 2024 (UTC)

This should be some type of setting one can easily toggle. -- Valjean (talk) (PING me) 22:15, 21 June 2024 (UTC)

New color for added text in diffs?

Is it just me, or has --background-color-content-added changed to a lilac #afb6e9 from the previous blue? The color contrast's awful now. Aaron Liu (talk) 17:39, 21 June 2024 (UTC)

see #Heads-up: Diff colour above. Nthep (talk) 17:49, 21 June 2024 (UTC)

Recent change to colors in "Difference between revisions" window?

When I look at the "Difference between revisions", the colors have been changed. When did this happen? It is now more difficult for me to read the text. The previous version worked fine. -- Valjean (talk) (PING me) 21:47, 21 June 2024 (UTC)

Wikipedia:Village_pump_(technical)#Heads-up:_Diff_colour -- GreenC 21:51, 21 June 2024 (UTC)
Thank you! I'll check it out. I hope it isn't a permanent change, as it's really disturbing to my eyes. -- Valjean (talk) (PING me) 21:57, 21 June 2024 (UTC)

Category problems

Using the template "{{Month events in country category header}}" it does not always generate the three categories needed see Category:June 1943 events in Australia it has not generated Category:June 1943 events in Oceania; likewise for Category:June 1943 events in the United States it has not generated Category:June 1943 events in North America

Hugo999 (talk) 23:11, 22 June 2024 (UTC)

@Hugo999: Most templates aren't supposed to add non-existing categories. It uses mw:Help:Extension:ParserFunctions##ifexist to test whether the category exists and only adds it in that case. PrimeHunter (talk) 23:44, 22 June 2024 (UTC)

Connexion problems

I've had a few "Original error: upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: delayed connect error: 111" errors tonight, also one or two "unable to load your Twinkle preferences". DuncanHill (talk) 22:45, 22 June 2024 (UTC)

Probably related to the ongoing outage. —⁠andrybak (talk) 22:51, 22 June 2024 (UTC)
I had the same error message repeatedly, when trying to go from the Main Page (which loaded fine), to the login page. Seems to be getting back to normal now. --Tryptofish (talk) 23:16, 22 June 2024 (UTC)
A report, once ready, will appear on the landing page for incidents – wikitech:Incident status. It will be published as a subpage, most probably for the date 2024-06-22, but maybe for 2024-06-23, depending on how it is be counted. —⁠andrybak (talk) 13:51, 23 June 2024 (UTC)
 
 

Hello everyone, today I'd like to introduce a tool that I've just finished developing called Feverfew. This application is designed to check links within an article and determine whether they are working or broken.

The idea for Feverfew stems from Dispenser's Checklinks tool, which has been intermittently accessible via IP and is now unreachable since 2020. With Dispenser's absence, Checklinks has had reliability issues, prompting the development of Feverfew in hopes of reviving some of Checklinks' functionality.

You can access the tool at this website: https://feverfew.toolforge.org/, and learn how to use it by visiting: User:Plantaest/Feverfew.

While I acknowledge that InternetArchiveBot has done a commendable job archiving links, I believe a tool similar to Dispenser's Checklinks remains valuable for certain needs. Further perspectives on this can be explored in the "Feverfew and InternetArchiveBot" section.

I plan to add a feature for previewing web pages via iframe, though this may take some time.

This tool has been open-sourced on GitHub: feverfew repo. You can star it to show support if you have a GitHub account.

You can leave comments, give feedback, or report bugs about this tool on the following page: User talk:Plantaest/Feverfew; or directly here. Thank you very much :D

Plantaest (talk) 16:58, 22 June 2024 (UTC)

You might want to take a look at a similar tool I wrote a while ago at https://link-dispenser.toolforge.org :) Sohom (talk) 17:15, 22 June 2024 (UTC)
Is this an appropriate place to plug these tools? I assume they are free? — Iadmc♫talk  17:17, 22 June 2024 (UTC)
Sure, seems fine to plug Wikipedia-related tools here. –Novem Linguae (talk) 14:39, 23 June 2024 (UTC)
OK. Thanks — Iadmc♫talk  14:40, 23 June 2024 (UTC)
toolforge:link-dispenser is free and hosted completely on toolforge. I think feverfew is also free, but uses AWS infrastructure (which has it's own downsides and upsides imho). Sohom (talk) 17:20, 22 June 2024 (UTC)
@Sohom Datta: Good tool. I wasn't aware of it, probably because I don't frequent enwiki. Initially, I hosted the entire Feverfew on Toolforge, but realized that Toolforge IPs could potentially be blocked if there were too many requests from this tool to websites. Therefore, I moved a small portion of the code to an AWS Lambda Function to take advantage of their extensive IP pool. Overall, this tool is free, as the cost for AWS Lambda Function is negligible (I still have quite a long time left on their free tier). Plantaest (talk) 17:35, 22 June 2024 (UTC)
@Plantaest AFAIK, a lot more URLs are blocked from AWS/GCP/Hetzner like cloud providers than smaller ones like Toolforge https://gitlab.wikimedia.org/toolforge-repos/link-dispenser/-/blob/main/blocked.json?ref_type=heads is the entire list for my tool (along with archive.org). Btw, maybe you could add a check for spammy links? Sohom (talk) 17:48, 22 June 2024 (UTC)
@Sohom Datta: I think what you're saying is possible, but in reality, I don't see the blocking situation; the tool still accesses archive.org. The purpose of hiding Toolforge IP addresses is to avoid impacting tools developed by other developers, as Toolforge is a shared server. Regarding the issue of spam links, I have another project to handle (Citron), but it's only for Vietnamese Wikipedia because I think this issue requires significant infrastructure resources to address, which is not suitable for a large wiki like English Wikipedia. Plantaest (talk) 17:58, 22 June 2024 (UTC)
Internet Archive Reference Explorer is similar. Early public release. One development feature, not in this release, is the ability to switch the dead link checker method - currently the IABot method, or the Wayback Machine method - to be able to compare results. Neither method use machine learning like Feverfew, would be interesting to compare. The version posted here is using the IABot method. -- GreenC 00:39, 23 June 2024 (UTC)
@GreenC: A good tool with a bright UI. I noticed that the Internet Archive Reference Explorer allows for PDF file analysis, so it is a larger-scale project compared to Feverfew. I will share my machine learning model method when I have time, although this model is not entirely accurate, and I am not an expert in machine learning. However, I think this could be helpful for those interested in this topic in developing a better model in the future. Plantaest (talk) 01:49, 23 June 2024 (UTC)

Yesterday's run of Special:WantedCategories featured a full 185 weird ghost redlinks that had somehow been populated by {{WikiProject Military history}}, each with somewhere between one and 437 pages in them yet without actually appearing on any of those pages — and further, they were largely at abbreviated forms like CAT-class or RED-class or IMG-class, that aren't how real WikiProject class-rating categories would ever actually be named. But neither the template nor its class-mask subtemplate appear to have been edited recently, so I couldn't find any obvious root cause.

Accordingly, I just patiently gnomed my way through by visiting each category and smashing the "Null edit category members" link to clean them all out, which worked at the time. (Luckily, since many of the pages were "in" several of them at the same time, nulling one category often had the benefit of partially or fully depopulating others at the same time, so while it was still a boring drudge it wasn't actually as horrific a job as it sounds.)

However, since editors sometimes try to put articles back into redlinked categories again after they've been removed, I regularly check the WantedCategories report a couple of times a day between updates, and have noticed that some of these ghost categories are also becoming repopulated again, though still without actually appearing on any of the pages that are "populating" them, and still clearing back out if I null the pages.

I'd really rather this not become a regular feature of the report, however, so I was wondering if somebody could look into why the template keeps somehow "populating" improperly-named categories that it isn't even coded to generate in the first place, and aren't actually showing up on the pages that are "in" them, before the next update spits 185 more of them out. Bearcat (talk) 17:11, 23 June 2024 (UTC)

I examined around 50 military history categories at Special:WantedCategories and they were all empty. Please give an example of a page which is or was listed in a red category. PrimeHunter (talk) 18:33, 23 June 2024 (UTC)
PrimeHunter, Category:Red-Class military history articles contains Talk:Reverse osmosis water purification unit currently. — Qwerfjkltalk 20:31, 23 June 2024 (UTC)
Thanks. It was caused by this edit to Module:WikiProject banner. The module is used in 10 million pages. It takes a long time to render so many pages again and update link tables like those used in categories. It may still have been ongoing with categories gradually populating when the edit was reverted 23:28, 21 June 2024 (UTC).[36] After that time, I don't think any new pages should be added to categories, but it may take a long time to remove all the old additions. Or can an old waiting link table update be made after the edit which caused it has been reverted?
Template and module edits can cause the rendering of a page to be updated and change the category list at the bottom before the category pages are updated to change whether the page is listed. This is similar to how a purge will update the category list but it requiews a null edit to also update the category pages. PrimeHunter (talk) 21:19, 23 June 2024 (UTC)

table scrollbar suggestion?

Lads and gents, I present an incessantly wide table.

Caption text
Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text
Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example
Legend:
Old version
Older version, still maintained
Latest version
Latest preview version
Future release
 Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example
Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example

Under limited-width Vector 2022 and mobile devices, the table will break our world's barriers, cause mass panic, and apparate a scrollbar onto the entire page. The following is a blocky table, complete with scrollbar.

Caption text
Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text Header text
Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example
Legend:
Old version
Older version, still maintained
Latest version
Latest preview version
Future release
 Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example
Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example Example 
.wikitable {
	display: block;
	overflow-x: auto;
	border: none; /* otherwise we'd have a surrounding border */
	background-color: inherit; /* else we'd have background on the caption */
}
.wikitable tbody {
	background-color: var(--background-color-neutral-subtle,#f8f9fa);
}

Stackoverflow claims that this will bring about "cells not filling the entire table". I don't see that though. Is there any reason we may not want to add this to our CSS styles? Aaron Liu (talk) 14:58, 23 June 2024 (UTC)

You can create a template that calls <templatestyles> to load a styles.css file with the CSS for a class widetable. Then just place the template before the table and add the appropriate class to the table. This approach is used with {{static row numbers}} to add a automatic row number to a table.  —  Jts1882 | talk  15:43, 23 June 2024 (UTC)
I think it'd be very hard to find every table that's too wide for mobile devices. Aaron Liu (talk) 16:14, 23 June 2024 (UTC)
I usually prefer the first type of wide table. Some of it may depend on browser or device. You can scroll with arrows without first clicking inside the table. You can see more of the table in the whole window width while scrolling. If there are related wide tables then you can scroll all at the same time. You don't have to scroll down to find the horizontal scrollbar if you scroll with the mouse. PrimeHunter (talk) 15:53, 23 June 2024 (UTC)
I dunno about you, but in these days I use the mouse a lot. Having it just overflow and cover the toolbar on the right also seems very unclean and sloppy. If users prefer, they could also load CSS for the legacy behavior, or we could even make that a gadget. Aaron Liu (talk) 16:11, 23 June 2024 (UTC)
One advantage of having the entire table shown is that the viewer can use their zoom level (including pinch-zoom on a touch device) to manage the amount of table they can see at once, rather than being constrained to a fixed window of the table. (Note that at narrow window widths, the default styling already adds a horizontal scroll bar to the table.) isaacl (talk) 16:34, 23 June 2024 (UTC)
  1. Stackoverflow is correct. That issue can indeed be caused with something like this. There are other similar issues caused when you set a table to display block also.
  2. Accessibility agents are known to remove the table semantics when display: block is assigned. That's categorically bad.
  3. This is being worked on and you don't need to futz around with your own solution. See phab:T366314 and related.
Izno (talk) 16:49, 23 June 2024 (UTC)
Oops. Well, that settles it. Aaron Liu (talk) 17:50, 23 June 2024 (UTC)
@Izno I wonder if 2 is still the case btw. That used to be for presentational tables, but accessibility agents are not really supposed to look at the display style for interpreting the elements. 'googling' Apparently, this already worked in Firefox, was fixed in Chrome 80 in Feb 2020, and fixed for Safari in October 2023 (see the various update notes at [37]). —TheDJ (talk • contribs) 21:04, 23 June 2024 (UTC)
Oh, that's actually exciting. His linked post is probably more useful for an eyeball's-worth of knowing what's working and what's not. Izno (talk) 01:06, 24 June 2024 (UTC)

What happens when you turn off pending changes?

Domestic duck has had pending changes turned on for the past 10 years. I assume whatever was going on at the time has stopped happening so PC can be turned off. What I'm not clear about is what will happen when I turn it off. Will 10 years of unapproved changes go away? Will they get automatically applied? RoySmith (talk) 13:44, 23 June 2024 (UTC)

Which unapproved changes might those be? --Redrose64 🌹 (talk) 13:51, 23 June 2024 (UTC)
Unclear. I don't actually understand how PC works, so I'm just assuming there might be some. For example, looking at the history list, I see most of the entries are highlighted in blue with the annotation "[automatically accepted]". But some, such as Special:Diff/1211852479 are not, and when I click on that diff I get a dialog offering to let me accept the revision. Is that not a PC which was never approved? RoySmith (talk) 13:56, 23 June 2024 (UTC)
PS, I assume if I was running for WP:RfA today, my nomination would get shot down with "Too soon, apply again in 6 months when you understand how things work better". :-) RoySmith (talk) 13:58, 23 June 2024 (UTC)
(edit conflict) To clarify, as of 13:58, 23 June 2024 (UTC) the latest manually reviewed/accepted/approved version is Special:Permalink/1227191547, published at at 08:36, 4 June 2024. It was reviewed on the same day at 09:22, 4 June 2024. The later three edits (Special:Diff/1227607510, Special:Diff/1227609667, Special:Diff/1227610060) were automatically accepted, because the edits – Rallekralle11 and Chiswick Chap are autoconfirmed. —⁠andrybak (talk) 13:58, 23 June 2024 (UTC)
Page Wikipedia:Pending changes#Effect of various protection levels doesn't mention autoconfirmed users explicitly. Instead, it says Edits by unregistered or new editors (and any subsequent edits by anyone) are hidden [...], until reviewed (emphasis in the original). "unregistered or new editors" means editors who aren't autoconfirmed.
On the other hand, page Wikipedia:User access levels#Autoconfirmed and confirmed users does mention pending changes explicitly: Edits that [autoconfirmed users] make to a page that is under pending changes protection will be accepted [...] without requiring review or approval (unless there are prior pending changes awaiting approval [...]).
Similarly, on page Wikipedia:Protection policy#Pending changes protection: When a page under pending changes protection is edited by an autoconfirmed user, the edit will be immediately visible to Wikipedia readers, unless there are pending edits waiting to be reviewed. —⁠andrybak (talk) 14:05, 23 June 2024 (UTC)
To find the link to the log of review:
  1. go to Domestic duck
  2. hover the mouse over the arrow in the box
      Accepted (latest)  
  3. click on "reviewed"
Hope this helps. —⁠andrybak (talk) 14:21, 23 June 2024 (UTC)
Added the above to Wikipedia:Pending changes#Frequently asked questions as "How can I see the details of review?" —⁠andrybak (talk) 21:07, 23 June 2024 (UTC)
Yes. Unreviewed changes should become visible if you turn off pending changes protection. –Novem Linguae (talk) 04:06, 24 June 2024 (UTC)

Ongoing Phabricator request to remove the spamblacklistlog right from the edit filter helper right

There is an ongoing Phabricator request about this, and the section title is explanatory; see phab:T367683. Codename Noreste 🤔 Talk 04:24, 24 June 2024 (UTC)

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)

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)
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)
This is probably worth a bug report. Izno (talk) 16:09, 22 June 2024 (UTC)
Created phab:T368205. —⁠andrybak (talk) 20:06, 22 June 2024 (UTC)
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)
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)
See phab:T367982 for that issue. Sjoerd de Bruin (talk) 09:08, 23 June 2024 (UTC)
And also see section #Blue link to non-existent user page below. —⁠andrybak (talk) 19:33, 24 June 2024 (UTC)

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)

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)
This sounds a lot like phab:T367982. —⁠andrybak (talk) 07:45, 24 June 2024 (UTC)
Thanks, most likely is the same bug. Liu1126 (talk) 07:58, 24 June 2024 (UTC)
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)
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)
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)
Thanks, works splendidly. Liu1126 (talk) 11:23, 24 June 2024 (UTC)
Thanks @PrimeHunter, that works! :) DoubleGrazing (talk) 11:24, 24 June 2024 (UTC)

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)

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)
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)
And I have had editors thank me for reverting their unconstructive edits. Context matters. Donald Albury 20:36, 23 June 2024 (UTC)
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)
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)
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)
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)
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)
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)

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)

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

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. [39]
  • 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. [40]

Problems

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). [42][43]
  • 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. [44]

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)

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)

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

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! ToadetteEdit! 09:24, 26 June 2024 (UTC)

@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)
Understood. ToadetteEdit! 10:12, 26 June 2024 (UTC)
@ToadetteEdit:   Done — xaosflux Talk 10:35, 26 June 2024 (UTC)

Space aliens ate my map icons.

Tracked in Phabricator
Task T368546
 
Big Duck Screenshot with house icon
 
Big Duck Screenshot with building icon

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)

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

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)

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

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)

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)
  Doing... --Redrose64 🌹 (talk) 20:36, 26 June 2024 (UTC)
@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)
I fixed what I was able to spot, what a mess. – 2804:F1...2D:8B49 (talk) 22:06, 26 June 2024 (UTC)
Thank you very much, both of you! Meluiel (talk) 22:22, 26 June 2024 (UTC)

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)

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

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)

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)
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)
The grouping mode has "n since last visit" links. Nardog (talk) 01:43, 25 June 2024 (UTC)
What is this grouping mode of which you speak? n what? —Tamfang (talk) 03:43, 25 June 2024 (UTC)
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)
Seems to do nothing but show tags. Can't see how it helps me, thanks anyway. —Tamfang (talk) 21:09, 26 June 2024 (UTC)

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)

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.

 
The Wikipedia Glossary has an entry for anchor.

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)

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

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)

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

What tense should be used in articles about obsolete computers?

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

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)

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)

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)

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)
  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)
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)
Welp, I suppose that voids my existing knowledge. Cheers to new solutions to new problems? Folly Mox (talk) 14:49, 29 June 2024 (UTC)

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. ✶Quxyz✶ 13:12, 29 June 2024 (UTC)

This should hopefully fix it. I've also deleted the archive 2 page. --Chris 13:50, 29 June 2024 (UTC)
Thank you! ✶Quxyz✶ 19:44, 29 June 2024 (UTC)

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)

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)

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

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)

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)

Requests for unblock page not updating

I've noticed that the CAT:UNB page is several days out of date. Normally users that use any of the {{unblock}} templates on their talk page have their request listed here, but as of today, the newest one is dated 25 June 2024. It also shows who last updated the user's talk page; I know of one where I was the last user who edited the page, but it displays as the last edit being from the user themselves (the edit prior to mine). It's not a cache issue either, already cleared mine and refreshed the page. Was a change implemented that might have caused something to break? --Drm310 🍁 (talk) 15:23, 30 June 2024 (UTC)

The Category:Requests for unblock#Summary of pending on-wiki appeals table is updated by a bot run by AmandaNP, which appears to have stopped running it on June 25. Category:Requests for unblock#mw-pages should still be up to date. * Pppery * it has begun... 15:27, 30 June 2024 (UTC)
The rare bug causing this has been patched. -- Amanda (she/her) 17:01, 30 June 2024 (UTC)

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)

@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)
I'm not sure Redrose64...my browser gave me a warning so I backed slowly away... Shearonink (talk) 17:58, 28 June 2024 (UTC)
Or WP:URLREQ. — Qwerfjkltalk 18:43, 28 June 2024 (UTC)
(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)
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)
Though it may not be applicable here, WP:URLREQ is an appropriate stop for "the website moved and links need updating". IznoPublic (talk) 19:36, 30 June 2024 (UTC)

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)

Seems to work now? Gawaon (talk) 22:01, 28 June 2024 (UTC)
Weird, so it does! Thanks and sorry! Brad (talk) 23:11, 28 June 2024 (UTC)
There are a couple of open tasks about 0x0 pdfs on Phabricator. Not sure if those document "permanent" issues, which this apparently was not (which may be a separate problem, of course). IznoPublic (talk) 19:40, 30 June 2024 (UTC)

Log-in tedium

Hello! I usually log in at Commons and then, if I've understood correctly, I am supposed to be logged in to all Wikipedia projects automatically. If I then go to French Wikipedia, for example, I am indeed automatically logged in, the same goes for 5-6 other lanugaes, except, recently, here at English Wikipedia, where I now an asked to log in especially, and keep getting "wrong passoword" messages over are over. I can sneak in, though, like I did just now to be able to write this, by using my Watchlist at French Wikipedia, going to a few other language watchlists and then Engish, where I get in like in the good old days, no problem, provided I use that tedious method. Seems to me this should be technically impossible. Any suggestions? SergeWoodzing (talk) 13:50, 30 June 2024 (UTC)

I don't know if this is related, but I just tried to go to Xtools to look at a user's contribution record, and received a message that I had to log in, which I did by clicking the button. I just have never seen that behavior before. No problem switching to Commons, however. Donald Albury 14:57, 30 June 2024 (UTC)
Pretty sure something in that set of happenings isn't supposed to. But WMF is currently working on overhauling authentication due to how browsers have changed how they deal with the technology underpinning our current login experience, a symptom of which you may be experiencing presently. IznoPublic (talk) 19:47, 30 June 2024 (UTC)

Salt loophole?

Tracked in Phabricator
Task T85393
Tracked in Phabricator
Task T74926

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)

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)
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)
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 ScribeEdits! Talk! 23:33, 26 June 2024 (UTC)
Not aware of any. * Pppery * it has begun... 23:33, 26 June 2024 (UTC)
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)
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)
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)
Thanks for the link. Matma Rex talk 21:08, 30 June 2024 (UTC)

Bug report

In Tennis at the 1900 Summer Olympics#Events, {{flagIOCteam|GBR|1900 Summer}}<br>[[Laurence Doherty]]<br>[[Reginald Doherty]] prompts me to create an already existing page Great Britain at the 1900 Summer Olympics. Help? Qwerty284651 (talk) 22:37, 30 June 2024 (UTC)

One of the entries pointed to year 1990 instead of 1900. Fixed: [45] Matma Rex talk 22:43, 30 June 2024 (UTC)
I can't believe I missed that. Lol Qwerty284651 (talk) 22:46, 30 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:
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:
Izno (talk) 00:51, 7 June 2024 (UTC)
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)
Σ'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, ~ LindsayHello 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, ~ LindsayHello 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, ~ LindsayHello 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: [46] – 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)
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)
@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)

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)
@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)
And I've just been informed that Enterprisey has replicated the fix to his version. — The Earwig (talk) 03:45, 20 June 2024 (UTC)
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)
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)
More changes were necessary:
  1. 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?
  2. 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.
  3. 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)
I have published these fixes as a new fork of the script: User:Andrybak/copy-section-link. Users, for whom Enterprisey's or The Earwig's version no longer works, are invited to install User:Andrybak/copy-section-link.js instead. —⁠andrybak (talk) 00:04, 1 July 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! Reywas92Talk 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. Reywas92Talk 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)
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)

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)

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)
Forgot to add...I am editing with Vector 2010 original/legacy if that make a difference. Shearonink (talk) 14:57, 15 June 2024 (UTC)

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:

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)

Script works for me. What kind of skin are you using ? —TheDJ (talk • contribs) 18:41, 14 June 2024 (UTC)
Oh lol, it was in the title :) Anyway. works with vector 2010 for me. —TheDJ (talk • contribs) 18:42, 14 June 2024 (UTC)
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)
@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)
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)
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)

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)

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

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)

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)
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)
This is an interesting example of a large number of concepts piling up on each other to create a mess.
First concept: most non-critical permission checks only check the basic permissions (i.e do you have the rights to edit this namespace at all, is the page directly protected against creation) and not more complicate checks (is the page transcluded in a cascade-protected page, is the page on the title blacklist, etc.).
Second concept: ?action=edit&redlink=1 redirects to the base page (without action=edit) if the user does not have permission to create the page (intentional per mw:Manual:Parameters to index.php#Optional additional data, checking the full permissions).
Third concept: The result displayed when viewing a page that does not exist is entirely MediaWiki:Noarticletext or MediaWiki:Noarticletext-nopermission, depending on whether you pass the basic permission text.
Fourth concept. That goes through MediaWiki:Noarticletext. If you pass the basic permission check, it currently does an extra check if it's on the title blacklist via Module:Title blacklist, displaying "This page is on the title blacklist, so only administrators, template editors, and page movers can create it." if it is. This logic probably could instead display the custom error message if it exists, but when I wrote this part of the chain per Template talk:No article text/Archive 1#Protected edit request on 15 January 2024 I didn't think about that situation. The curly quote error didn't exist (I added it to the blacklist in May 2024) so this issue was much less likely to trigger. If you then click the create tab, it would show the error. And title blacklist error messages are generally large blocks of text that don't fit in the {{no article text}} format.
If you fail the basic permission check, it goes through Module:Effective protection level, which treats the title blacklist the same way as templateeditor (since "templateeditor + pageover" is too complicated to be expressed there), and says "This page is template-protected from creation, so only template editors can create it.".
One possibility would be to special-case curly quotes, so instead of saying "is on the title blacklist" for that specific case mention why. I already do that with {{new page DYM}} if the page with the straight quote exists to fix the reader experience, but page creators are left SOL.
So, nothing is technically a bug, but I agree the workflow here is complicated and unideal. Incidentally, the merits of this blacklisting rule have been challenged at MediaWiki talk:Titleblacklist#Blacklist curly quote?* Pppery * it has begun... 02:13, 1 July 2024 (UTC)

Tech News: 2024-27

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

  • Over the next three weeks, dark mode will become available for all users, both logged-in and logged-out, starting with the mobile web version. This fulfils one of the top-requested community wishes, and improves low-contrast reading and usage in low-light settings. As part of these changes, dark mode will also work on User-pages and Portals. There is more information in the latest Web team update. [47]
  • Logged-in users can now set global preferences for the text-size and dark-mode, thanks to a combined effort across Foundation teams. This allows Wikimedians using multiple wikis to set up a consistent reading experience easily, for example by switching between light and dark mode only once for all wikis. [48]
  • If you use a very old web browser some features might not work on the Wikimedia wikis. This affects Internet Explorer 11 and versions of Chrome, Firefox and Safari older than 2016. This change makes it possible to use new CSS features and to send less code to all readers. [49][50]
  • Wikipedia Admins can customize local wiki configuration options easily using Community Configuration. Community Configuration was created to allow communities to customize how some features work, because each language wiki has unique needs. At the moment, admins can configure Growth features on their home wikis, in order to better recruit and retain new editors. More options will be provided in the coming months. [51]
  • Editors interested in language issues that are related to Unicode standards, can now discuss those topics at a new conversation space in MediaWiki.org. The Wikimedia Foundation is now a member of the Unicode Consortium, and the coordination group can collaboratively review the issues discussed and, where appropriate, bring them to the attention of the Unicode Consortium.
  • One new wiki has been created: a Wikipedia in Mandailing (w:btm:) [52]

Problems

  • Editors can once again click on links within the visual editor's citation-preview, thanks to a bug fix by the Editing Team. [53]

Future changes

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

MediaWiki message delivery 23:56, 1 July 2024 (UTC)

Next section on talk page is indented because of template

I don't know what happened. If I knew how to fix the template I would. I copied it from somewhere else.— Vchimpanzee • talk • contributions • 22:26, 1 July 2024 (UTC)

I added the markup to close the table that your comment started. isaacl (talk) 22:35, 1 July 2024 (UTC)
Thanks. I see now I shouldn't just delete the signature.— Vchimpanzee • talk • contributions • 22:37, 1 July 2024 (UTC)
Don't delete the |} characters, as they close the table. isaacl (talk) 22:40, 1 July 2024 (UTC)
I learned that some time ago. I was thinking of another problem with that template I was unable to solve, but I forgot about that closing.— Vchimpanzee • talk • contributions • 23:10, 1 July 2024 (UTC)
Sure; it's just a separate issue from deleting the signature. isaacl (talk) 00:44, 2 July 2024 (UTC)

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)

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)
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)
Great, thanks! S.A. Julio (talk) 04:50, 2 July 2024 (UTC)

Some users unable to email blocked users?

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

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

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)
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)
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. — Qwerfjkltalk 15:23, 25 June 2024 (UTC)
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)
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 ([54][55]) 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)
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)
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)
+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)
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)
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)
"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)
@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)
@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)

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)

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

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)

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)
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)
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)
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)
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)
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)
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)
  • 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)
    The private WMF config has been removed now, as it was found to be no longer needed after discussion in the task (the abuse it protected against happened more than a year ago). Sending emails in this scenario should work again. Matma Rex talk 08:26, 2 July 2024 (UTC)

"Missing" search result

I'm not the most familiar with how the search on Wikipedia works, but I had a question with a recent query. This search (at the time of posting) says there should be 3,381 results, however it appears that only 3,380 pages show up in the results. I was wondering what might be causing this discrepancy (and which page is missing), I'm not sure if it has anything to do with how pages are indexed, if it's the result of page moves/deletions or something to do with cross-namespace redirects. I decided to sort the pages by creation date and return the results in increments of 5, with this page highlighting where the discrepancy occurs. I would be appreciative of any insight into this. Thanks, S.A. Julio (talk) 05:14, 2 July 2024 (UTC)

Are you sure? If returning the first 3380 pages, there is still one lonely page on the next pagination (see here). — xaosflux Talk 10:22, 2 July 2024 (UTC)
I guess a new page was added after the original post but a page is still missing for me, currently at [56] which doesn't show any page for me. "previous 1" shows Pierre Sage and "next 1" shows Miroslav Vaněk. Maybe the missing page has been deleted but is still cached in the search index. I don't know whether that would actually appear like this. PrimeHunter (talk) 11:46, 2 July 2024 (UTC)
Yeah, it seems to imply a page created between 2 and 4 December 2023 is missing from the results. I've never really come across this type of issue when using search before, results usually update for new/deleted pages fairly quickly. I'm not sure if this is just a quirk or if there's some other explanation. S.A. Julio (talk) 12:40, 2 July 2024 (UTC)

Template-generated redlinked category, vol. 9,584,583

Today's "there's always some template-autogenerated mess, every damn time" story at Special:WantedCategories is ‹The template Category link is being considered for merging.› Category:Language articles with Linguasphere code. It's currently populated by sandbox content, not real stuff that would actually have to be filed in any maintenance queues, but once again it's being smuggled in by a module rather than being directly stated on the pages itself — so I can't just remove it, but I can't create it either as I can't determine whether it's actually needed for any real mainspace content or not.

So could somebody with more expertise in the language-codes domain than I've got either create it if it's desired, or make it go away if it's not? Thanks. Bearcat (talk) 13:04, 2 July 2024 (UTC)

Pinging PK2 who made Template:Infobox language/lingualist which adds the category, and used it in [57]. @Bearcat: If you post troublesome redlinked categories to my talk page in the future then I can look into the situation and keep most cases out of this page. PrimeHunter (talk) 13:24, 2 July 2024 (UTC)

Mobile view problems with {{sfn links}} with special characters

Tracked in Phabricator
Task T348928

This is probably an existing problem, but nothing seems to be happening... Sangwe cooperative is an example. In desktop view it looks fine, but in mobile view I see:

Les coopératives Sangwe sur l’agenda du cabinet. Harv error: link from CITEREFLes_coop%C3%A9ratives_Sangwe_sur_l%E2%80%99agenda_du_cabinet doesn't point to any citation.
...
"Les coopératives Sangwe sur l'agenda du cabinet du gouverneur", ABP: Agence Burundaise de Presse (in French), 8 February 2024, retrieved 2024-07-02 Harv warning: There is no link pointing to this citation. The anchor is named CITEREFLes_coopératives_Sangwe_sur_l’agenda_du_cabinet.

I think this is something to do with a difference in the way special characters like é are handled. Aymatth2 (talk) 13:55, 2 July 2024 (UTC)

@Aymatth2: Others don't see this. It comes from User:Trappist the monk/HarvErrors.js which you load in User:Aymatth2/common.js. You can discuss the script with its author. PrimeHunter (talk) 14:14, 2 July 2024 (UTC)
Not the fault of my script. See the phabricator bug report.
—Trappist the monk (talk) 14:21, 2 July 2024 (UTC)
This is the same thing you complained about at Template talk:Sfn (permalink). That bug report has been more-or-less ignored so don't be holding your breath for a fix.
—Trappist the monk (talk) 14:21, 2 July 2024 (UTC)
Not quite the same. That one was solved by swapping to User:Trappist the monk/HarvErrors.js. This one only appears in mobile view, which I use more and more. It keeps bugging me. I want to see genuine errors, but not these bogus ones. Aymatth2 (talk) 14:48, 2 July 2024 (UTC)
Umm, yeah, it is. At this edit resulting from the discussion at Template talk:Sfn §Special characters, you removed Ucucha's script from your common.js file (21:25, 23 November 2023). Twenty minutes later (21:45, 23 November 2023) you posted at the sfn talk page: That did it. All that that 'did' was remove the error checking code so it did not 'fix' anything. Nearly a month later (12:14, 21 December 2023), you added my script (this edit).
If I look at the article of your original complaint, Collective work, in desktop view I don't see any error messages emitted by my script. In mobile view, however, I do; compare:
For Sangwe cooperative:
Because you installed my script, the error messages that 'went away' when you deleted Ucucha's script are again displayed (in slightly different format). The underlying errors in mobile view (with or without a script to highlight them) are still present in mobile view because MediaWiki is not correctly encoding the anchor links as described in the phabricator bug report.
—Trappist the monk (talk) 15:37, 2 July 2024 (UTC)
O.k. I forgot the history. And it sounds like the phabricator bug report is going nowhere. I suppose we could fix it at the {{sfn}} end by changing the link encoding to match the mobile view. 75% of page views are from mobile devices. But it is only editors like me that have the script who see it... Annoying. Aymatth2 (talk) 17:57, 2 July 2024 (UTC)

Proposed change to 'create article' message shown on search results

Please see MediaWiki_talk:Searchmenu-new#Remove_link_to_the_article_wizard. – Joe (talk) 21:19, 2 July 2024 (UTC)

JavaScript error

So I toggled on the revisionjumper gadget recently and a JavaScript error was popping up whenever I try to see former revisions from a long time ago. Here's the URL to the problem I am having: https://en.wikipedia.org/w/index.php?oldid=139992.

I wasn't expecting this to happen and I have practically zero knowledge how programming language works.

And I'm using Firefox on iPad (but I edit on the app too), no clue what version I'm running on. Tonkarooson (discuss). 06:21, 3 July 2024 (UTC)

That gadget is hosted and managed from a sister project. Bugs may be reported here: w:de:Benutzer Diskussion:DerHexer/revisionjumper. You may want to @ping the author on that project when reporting your bug there. — xaosflux Talk 13:04, 3 July 2024 (UTC)

"coords" vs "coordinates" in infoboxes

I have stumbled upon a weird issue with getting the red outline to appear around the mapped object in infoboxes. It apparently make a difference whether one uses "|coords=" or "|coordinates=". For example, see this edit that I just made to Scottish Parliament Building. This is also the case with other infobox templates, such as infobox park (and might well be the case for all such infoboxes). Note that the red outline appears with the field or parameter "coords", but not with "coordinates", which is, or course, what the vast majority of infoboxes currently use. Is there any way to get this error fixed at its source? Abductive (reasoning) 05:50, 1 July 2024 (UTC)

This is not much help regarding the issue but FYI, editing that article, then previewing it, currently shows an error at the top: Page using Template:Infobox building with unknown parameter "coords". The docs at {{Infobox building}} show only "coordinates" as an allowed parameter although it takes {{coord}} as its value. Johnuniq (talk) 06:17, 1 July 2024 (UTC)
I just did a test where I replaced "coords" with "bonkers", which broke the infobox but somehow the map survived with the red outline. So, and I'm just guessing, "coords" has long been accepted as an alternative to "coordinates" in infoboxes, and then a change was made which breaks the red outline functionality only for the exact string "coordinates". Abductive (reasoning) 07:13, 1 July 2024 (UTC)
No. Templates can have different parameters but {{Infobox building}} hasn't been edited since April 2023. It only accepts |coordinates= while |coords= is an unknown parameter and ignored. If there is no or empty |coordinates= then the infobox automatically pulls data from the Wikidata item Scottish Parliament Building (Q2746031). That works on Scottish Parliament Building where you get a map with a red outline even with {{Infobox building}} without any parameters. If you set |coordinates= to something non-empty then you override the Wikidata pull and may get a different result. PrimeHunter (talk) 11:18, 1 July 2024 (UTC)
|coordinates= should always work in any infobox that would reasonably accept latitude and longitude data, per the massive project we did at Wikipedia:Coordinates in infoboxes in 2016–2017 following a 2016 RFC to standardize on that parameter name. |coords= will work if it was retained, but most other coordinate-related parameters in infoboxes were deprecated, converted, and removed. It was a fun project. If you find an infobox that does not support |coordinates=, feel free to ping me or drop a note on my talk page, and I will fix it. – Jonesey95 (talk) 17:23, 1 July 2024 (UTC)
But here's the thing; nearly all articles that have infoboxes are following the documentation that says to put the coord template after the = sign, and that apparently kills the red outline. Abductive (reasoning) 20:19, 1 July 2024 (UTC)
This appears to be a problem with {{infobox mapframe}}; I have posted a new topic on its talk page. – Jonesey95 (talk) 21:43, 1 July 2024 (UTC)
I've responded with the reason there. Regards, The Equalizer (talk) 23:11, 1 July 2024 (UTC)
Perfect. I have edited {{infobox building}} to show the mapframe shape by default. – Jonesey95 (talk) 23:29, 1 July 2024 (UTC)
What about Infobox park, as I mentioned above and all other infoboxes? Abductive (reasoning) 18:52, 3 July 2024 (UTC)
Any affected infobox can be fixed with an edit like this one that I did at {{infobox park}}. If you think that this problem affects many templates and that the default should be changed for all of them, I recommend that you follow up on the thread at Template talk:Infobox mapframe. – Jonesey95 (talk) 19:06, 3 July 2024 (UTC)
Oh, I thought only certain editors had privileges to edit templates. I'll give it a try. Thanks. Abductive (reasoning) 20:10, 3 July 2024 (UTC)

Auto-archiving not working on Talk:Trail of Tears

I can't quite figure out why it's not working. I thought I had corrected some coding issues on June 30th (and these issues dated back to January of 2023 - see Talk:Trail of Tears#Archiving issues for this talk page) but the bot still hasn't run on the page today and it's July 2nd... I must have overlooked something but can't figure out *what*. Please help and thanks. Shearonink (talk) 16:59, 2 July 2024 (UTC)

@Shearonink: The bot seems to have slowed down a lot lately with only four edits today, 22 yesterday, and many more than that two days ago. I'll write a message on the bot operator's talk page. Otherwise, I've got nothing. Graham87 (talk) 01:23, 3 July 2024 (UTC)
Ok, well at least I know it's not just my poor coding skills. I guess that's something. But only 4 edits today?...Noooooooo. Shearonink (talk) 02:01, 3 July 2024 (UTC)
Graham87 Is it at all possible that User:Lowercase_sigmabot_III was somehow deactivated along with its relative User:Lowercase_sigmabot? Lowercase sigmabot was deactivated on June 29th, see Bots noticeboard. Shearonink (talk) 02:21, 3 July 2024 (UTC)
@Shearonink: Nope, that wouldn't have been what happened. Graham87 (talk) 02:54, 3 July 2024 (UTC)
@Shearonink: Lowercase sigmabot was unflagged early on 2 July (see the most recent entry here). It's not a block: all that it means is that any future edits from that account are not treated as bot edits, and so won't have the b in page histories, watchlists etc. By contrast, Lowercase sigmabot III still has its bot flag (see here). They are different accounts, with different rights. There's a current summary of similarly-named accounts here, but note that the two blocked ones were never bots - they are sockpuppets of people impersonating Σ. --Redrose64 🌹 (talk) 17:39, 3 July 2024 (UTC)
To be fair, it archives ANI and AN threads 2 times a day (unlike every other page), we haven't reached the time of the day where it would be archiving in other pages for the 3rd of July yet. That said, something could have happened at around 12:31, 2 July 2024 that stopped the bot's work halfway. – 2804:F1...7A:B4D (talk) 02:11, 3 July 2024 (UTC)
It's just that I corrected the auto=archiving a couple days ago and it should have archived that page by now... - Shearonink (talk) 02:21, 3 July 2024 (UTC)
Seems the bot worked fine today, it also archived things at Talk:Trail of Tears! Nothing was changed, so I guess it was just a temporary problem with the bot. – 2804:F1...1F:6F8E (talk) 21:28, 3 July 2024 (UTC)

Embedded PDF is not rendering correctly

I uploaded File:Doctrine for the U.S. Public Health Service Commissioned Corps, January 2021.pdf to c: and there, it displays just fine, but locally, it has the generic Adobe Acrobat icon that displays when an PDF cannot render properly and where I inserted it into an article, it does not render correctly as a thumbnail. Can anyone tell me why this is going wrong and what I can do to fix it? ―Justin (koavf)❤T☮C☺M☯ 08:39, 4 July 2024 (UTC)

It displays for me at File:Doctrine for the U.S. Public Health Service Commissioned Corps, January 2021.pdf and United States Public Health Service Commissioned Corps#Purpose. At your old revision link [58] I saw a blue link to the file page (no PDF icon) a few minutes ago but it displayed for me when I previewed the version. Now it also displays in the old revision. I guess the issue is resolved. PrimeHunter (talk) 10:14, 4 July 2024 (UTC)
Samesies. Public shaming works.
  Resolved
 – ―Justin (koavf)❤T☮C☺M☯ 10:37, 4 July 2024 (UTC)
This has been a recurring issue for a while (there are a few tickets). It is a race condition of some sorts. Sometimes the page is requested before the metadata for the file has been read apparently. And then after the size is known, there is no new signal to get pages using the information to update what they know about the image. It's not fully understood what is causing this and its pretty difficult to completely analyse the problem. —TheDJ (talk • contribs) 11:23, 4 July 2024 (UTC)

Missing table of contents

Anyone know why I can't see a table of contents on this talk page? I'm using the desktop site on mobile using my the Vector 2010 skin. If I edit the page and add __TOC__ the preview shows the table of contents correctly, but it's missing otherwise. -- LCU ActivelyDisinterested «@» °∆t° 13:48, 4 July 2024 (UTC)

Should be fixed now, I think. It was because Draft:Sources_about_whether_there_is_a_genocide_in_Gaza_or_not used a header, and it was transcluded into the collapsed box "Scholarly and expert opinions (to be extended)". Which meant that the TOC was also hiding in that collapsed box. --rchard2scout (talk) 14:32, 4 July 2024 (UTC)
Thanks looks correct now. -- LCU ActivelyDisinterested «@» °∆t° 16:52, 4 July 2024 (UTC)

The height of blue border after redirection is wrong (for Infoboxes images)

Tracked in Phabricator
Task T368137

Hi, the height of blue border is shown after redirection for Infoboxes images are wrong. For example, after we click on this image File:Milad Tower in 2023.jpg of this article, (by the scroll button of our mouse) then the result is like this:

 

You can see the blue border has a wrong height. I should note that this bug is happened only for Infobox images of articles (not for ordinary images). Please inspect. Thanks, Hooman Mallahzadeh (talk) 08:50, 4 July 2024 (UTC)

This is a known recent regression. Should hopefully be fixed somewhere in the next two weeks or so. —TheDJ (talk • contribs) 09:29, 4 July 2024 (UTC)
@Hooman Mallahzadeh: See Wikipedia:Village pump (technical)/Archive 213#Blue rectangle when clicking images. --Redrose64 🌹 (talk) 19:29, 4 July 2024 (UTC)

image flow control

I looked at the IMAGE HELP stuff and either missed or it's lacking an option/keyword that would let me insert an image and then have the wikiText that follows just close around in, rather than leave extra whiteSpace.(did I look in the wrong place) Nuts240 (talk) 01:42, 5 July 2024 (UTC)

@Nuts240: See WP:EIS#Location, you probably want |left or |right. --Redrose64 🌹 (talk) 01:52, 5 July 2024 (UTC)

Something weird has happened on an admin's talk page

Not long ago from now, I received a notification saying that a few threads I opened on User talk:Daniel Case were deleted or archived from the talk page. I thought all was normal and that Daniel Case had archived the older messages on his user talk page. All until I started actually looking at the page that I noticed something really odd and strange has happened!

This is the current revision of the talk page, as of writing this very sentence. Scroll all the way down to the bottom of the page, and take a look at the section "Permaban" situation allegedly discussed on arbitration. That thread is from September 2023. From that point, seemingly all the threads from then until the thread left by the second latest messenger are gone! Where did they all go?! (That's a good 3/4 of the entire non-broken page's worth of content, by the way.)

The thread by User:Piyush Chekavar is not rendering correctly at all, too. It's missing a heading for the first thread, and look at the font style of the text! It's all in the code style of text (without the grey 'background'), even though there is no text formatting in the thread. A good chunk of that thread's text is missing, too!

I noticed that User:Piyush Chekavar did try to re-post the thread, maybe they thought the thread didn't publish, or that they were re-publishing it in hopes of getting it right the second time. This permalink where they make the first attempt publishing that thread is badly messed up too.

A few technical notes from me:

  • The first thing I did was to go into the source code editing view, turn on the syntax highlighter, and look for any missing closing brackets, tags, etc. But there are none! The tags on the edits by User:Piyush Chekavar tell me that it was placed using the "New topic" feature, rather than published manually using plain old source code.
  • The next thing I did was to go into the inspect page code function in my web browser ("inspect element"), and look for a "NewPP limit report" HTML comment near the bottom of the main code area. The last time I encountered a problem with pages not rendering correctly on Wikipedia, it was because of the post-expand include size limit being exceeded. So I checked those statistics on that broken talk page, and guess what!? None of the limits seem to be exceeded (or even 9/10 close to being so)!! Even checking the stats of the last page revision by Nyxaros before the unintentional catastrophe, it doesn't look like any of those technical limitations were dangerously close to being exceeded.
  • The third thing I did was check the current raw page size, and as of now it's 588,265 bytes. The last page revision that isn't broken is 583,959 bytes in size. I've been told that the maximum raw page size for Wikipedia's engine is 2 megabytes (2,097,152 bytes?), and the Wikipedia Dramaboard Admins' Noticeboard for Incidents regularly sees page sizes in excess of 700,000 bytes with no problems like this at all.
  • Even comparing the broken and non-broken page revisions' HTML code in the web browser code inspector feature, I can see that a significant quantity of 'nodes' / HTML individual paragraph blocks are missing from the broken page revision.

So what on earth is actually going on here!?!? — AP 499D25 (talk) 13:33, 5 July 2024 (UTC) edited 13:40, 5 July 2024 (UTC)

There was a <code><ref></code> which swallowed up a big chunk and rendered a weird format. I have changed that now. s the problem gone? Graeme Bartlett (talk) 13:44, 5 July 2024 (UTC)
Yeah, it's fixed. Sometimes it's really things as simple as that creating a seemingly epic catastrophic effect, huh?
If there's one takeaway I have from this, it's that always look around where the problem begins for a clue, maybe the culprit is right in there somewhere. — AP 499D25 (talk) 13:58, 5 July 2024 (UTC)

Time on talk pages is light gray

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

And it is still black on some older pages.— Vchimpanzee • talk • contributions • 23:14, 28 June 2024 (UTC)
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)
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)
Thanks. I looked, but apparently not enough.— Vchimpanzee • talk • contributions • 23:19, 28 June 2024 (UTC)
@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)
I'm not seeing a change. I chose blue.— Vchimpanzee • talk • contributions • 15:31, 29 June 2024 (UTC)
Weird, I tested it and it works fine for me. Perhaps WP:BYC might help? Nickps (talk) 16:00, 29 June 2024 (UTC)
@Vchimpanzee: You may need color: #72777d !important; if your skin at Special:Preferences#mw-prefsection-rendering is Vector legacy. PrimeHunter (talk) 14:45, 1 July 2024 (UTC)
Not my skin.— Vchimpanzee • talk • contributions • 16:58, 1 July 2024 (UTC)
@Vchimpanzee: User:Vchimpanzee/common.css is missing a closing } earlier in the page after visibility: hidden;. PrimeHunter (talk) 22:45, 1 July 2024 (UTC)
Thanks. fixed. Looks good now.— Vchimpanzee • talk • contributions • 22:48, 1 July 2024 (UTC)
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)
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)
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)
Link fixed, thanks. – Jonesey95 (talk) 16:47, 29 June 2024 (UTC)
Actually, scratch that, I tried the dark edit summaries and I didn't like them too much. But, as I've explained above, I think the timestamps should be changed because they don't pass the contrast test on closed XFDs. Nickps (talk) 17:43, 4 July 2024 (UTC)
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)
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, ~ LindsayHello 06:07, 30 June 2024 (UTC)
Well, to de-emphasize it compared to regular link styling. The idea was to indicate that the timestamps do something now and that they’re not just plain text, but also not have them jump out in the same way that them being bright blue would. DLynch (WMF) (talk) 12:38, 30 June 2024 (UTC)
I'm curious as to why Gray500 was chosen in particular. Apparently it was chosen [a]fter discussing with Design Systems team members but if you ask me, Gray600 was a better choice. Compare 18:06, 30 June 2024 (UTC) (Gray600) and 18:06, 30 June 2024 (UTC) (Gray500) with 18:06, 30 June 2024 (UTC) (the non codex color originally used). Gray600 would still achieve the desired style consistency since it's a Codex color while being closer to the original color and more accessible. I wish we could get some insight as to why the Design Systems team made this choice. Nickps (talk) 18:06, 30 June 2024 (UTC)
Speaking solely for myself looking at it on the current monitor I'm using, I can barely see that there's a difference between Gray600 and the regular page text. Gray500 looks closer to the original color to me than Gray600 does. (The joys of subjective design issues!) DLynch (WMF) (talk) 00:25, 1 July 2024 (UTC)
I definitely like Gray500 better, it de-emphasizes the timestamp much more than Gray600 (at least on my monitor). I know people don't like changes like this, but I'm reminded of something a forum webmaster once said when he redesigned the entire forum, and all the regulars were complaining: "Give it a week." As in, don't immediately go looking for a way to change things back, take a week to get used to it. If it still bothers you after a week, sure, go implement those CSS fixes, write a plugin to change things back, etc. But you will probably find that you get used to things very quickly, and won't even notice it anymore. --rchard2scout (talk) 07:37, 1 July 2024 (UTC)
I have no reason to doubt that it looks closer to you. But at the same time the delta E of Gray600 to the original color is lower than that of Gray500, so I'll defer to that instead of just saying that my subjective experience is different. Nickps (talk) 09:05, 1 July 2024 (UTC)
In any case, Gray500 does not mesh well with closed Xfd discussions. While {{subst:mfd top}} is the worst accessibility fail with a contrast ratio of 3.19:1, none of the others get above 4.5, although, to be fair, {{subst:RM top}} gets close with a 4.33. Compare with Gray600 which has a high enough contrast against all of the closed XFD templates (I'll only provide mfd top but I tested all of them). Nickps (talk) 17:38, 4 July 2024 (UTC)
This seems to me like a problem with the background color chosen for {{subst:mfd top}}. Even the normal blue links on this background fail the test (contrast ratio 3.8), as does the red warning message (2.83). The background on {{subst:RM top}} also fails the test (link: 3.6, warning: 3.84). Matma Rex talk 19:38, 4 July 2024 (UTC)
Fair point. I don't think the endless bikeshedding it would take to change that colour is worth it, considering that no one has complained about readability, so I guess things should stay as is. Nickps (talk) 14:25, 5 July 2024 (UTC)
How do we disable the linking of timestamps? It isn't explained at the links provided. — Fourthords | =Λ= | 03:45, 29 June 2024 (UTC)
You may add 
.ext-discussiontools-init-timestamplink {
	pointer-events: none;
}
to your CSS. Nardog (talk) 03:56, 29 June 2024 (UTC)
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)
That code seems to be very particularly coded. How best should it be added "inside that block"? — Fourthords | =Λ= | 04:25, 29 June 2024 (UTC)
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)
Your code has fixed this most of the way, but date-text is still generating a cursor upon hover instead of an I-beam, and despite my tinkering I can figure out how to repair that. Any suggestions? Is there any code that just disables this new beta gadget outright? — Fourthords | =Λ= | 18:18, 30 June 2024 (UTC)
That's impossible without JavaScript because pointer-events: none; interferes with cursor: text;. Nardog (talk) 01:17, 1 July 2024 (UTC)
That's really a shame. What about just disabling the gadget's code entirely before it renders anything? Is that possible? — Fourthords | =Λ= | 04:53, 1 July 2024 (UTC)
It's not a gadget. It's already there when the HTML is served. I doubt they'll make it an option for either caching or mw:Just make it a user preference reasons. Nardog (talk) 08:35, 1 July 2024 (UTC)
text-decoration:none too, if you use the underline-links preference. (Like so.) —Cryptic 05:27, 29 June 2024 (UTC)
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)
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)
Which part of MOS:ACCESS? Nardog (talk) 05:11, 29 June 2024 (UTC)
@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)
It's in the editor's draft. —Cryptic 15:57, 29 June 2024 (UTC)
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)
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)
If it's that stable, how come it's never been in the W3C Working Draft? --Redrose64 🌹 (talk) 17:50, 30 June 2024 (UTC)
W3C's work on CSS standardization doesn't make sense to me anymore. There are a ton of properties supported for a half decade or more at working draft or earlier recommendation stage. As such, I think it's completely fair for developers (n.b. not necessarily Wikipedians) to turn to on-the-ground understanding of support for properties (i.e. caniuse.com). Asking such developers why it is what it is seems like the wrong target for your question on the point, and even unnecessarily hostile. IznoPublic (talk) 19:53, 30 June 2024 (UTC)
W3C's work indeed doesn't make much sense (see WHATWG). Personally, I don't know and I don't care why it's never been a "working draft". But I know that the people writing the draft specs are the same people implementing the browsers, so the browsers follow the drafts, and I follow the data that tells me whether the browsers I need to support implement the properties I want to use. Matma Rex talk 21:18, 30 June 2024 (UTC)

Local time gadget makes a textbox appear at the center top of my screen?

Tracked in Phabricator
Task T368701

I have the "Change UTC-based times and dates, such as those used in signatures, to be relative to local time" gadget activated, and it's worked fine overall. However, I've lately noticed that if I click the timestamp on a comment on any talk page (such as WT:RFA), I'll end up with a small textbox appearing on the top of my screen. I'm running Google Chrome version 126.0.6478.127. As far as I know this is the first time this has happened, but I can't find any recent changes to the gadget's script that would cause it to act like this. EggRoll97 (talk) 07:30, 1 July 2024 (UTC)

@EggRoll97 does this textbox say "link copied to clipboard"? See #Tech News: 2024-26 above, it's a change in the system to make timestamps links. Nthep (talk) 08:01, 1 July 2024 (UTC)
That Tech News item is actually not related to the rollout on this wiki, so I've moved that discussion to #Time on talk pages is light gray (which already existed when that comment was made). Nardog (talk) 08:32, 1 July 2024 (UTC)
Thanks, didn't know if this was related to the light gray change or was just a general issue. As far as I know this wasn't a problem before the rollout, because the timestamps just appeared in all-black and weren't clickable. EggRoll97 (talk) 12:48, 1 July 2024 (UTC)
@Nthep: No, but the "link copied to clipboard" does appear when I click a timestamp link after disabling the gadget. When the gadget is enabled, it just jumps down to the comment, and creates a small textbox in the center top of the screen that allows me to type (?) in it, but it doesn't seem to actually do anything. EggRoll97 (talk) 12:46, 1 July 2024 (UTC)
Sounds like it's interfering with the reply tool. Nardog (talk) 12:58, 1 July 2024 (UTC)
As far as I can tell, I don't have the reply tool on, nor do I have any reply links present on any pages. EggRoll97 (talk) 13:05, 1 July 2024 (UTC)
Looks like this issue: T368701 which will be fixed later this week. Matma Rex talk 13:23, 1 July 2024 (UTC)

Module redirects and {{R from move}}

So, today I learned that Module redirects exist and I've been going around adding WP:RCATS to them. I've been doing this by adding the rcats to {{Sandbox other}} per WP:CAT#T and I've updated WP:REDCAT to reflect this. The purpose of this section is twofold. One, I want the community to tell me if there are any objections to the instructions I've added to WP:REDCAT and two, I wonder if there would be any interest to update the moving process so {{R from move}} is added to the module redirect (or, more accurately, to an WP:includeonly block in its doc page) after a move. Nickps (talk) 22:24, 4 July 2024 (UTC)

The documentation you've added at WP:REDCAT is fine. But, in addition to technical feasibility, I would object to doing what you proposed with the doc page. Either the doc page didn't exist prior to the move, in which case creating a separate page just to add rcats is an unnecessary waste, or it did exist, in which case it should itself be a {{R from move}}. * Pppery * it has begun... 23:48, 4 July 2024 (UTC)
You make some good points. Especially the technical feasibility was the reason why I wasn't really hoping that my proposal would be accepted.
I'll note however that I personally don't agree that creating a separate page just to add rcats is an unnecessary waste. Per WP:RCAT: Normal ("hard") redirects should be placed in one of several maintenance categories specifically for redirects. Module redirects are the only case in which there is literally no other way to add categories to them (Module:Module wikitext doesn't work after all), so I feel that creating an empty doc page is justified. Or better yet, one should create a doc page that says something like, "Redirect to [[<target>]]" since for some reason, module redirects don't provide a link to the target module. Nickps (talk) 01:00, 5 July 2024 (UTC)
One more thing. Consider Module:Adjacent stations/HSL. Its doc page is redirected to its target's doc page. I didn't want to disable that redirect since having the target's documentation accesible without an extra click is useful. So I added 
{{#ifeq:{{FULLPAGENAME}}|Module:Adjacent stations/HSL|{{Rcat shell|{{R from subpage}}{{R to subpage}}{{R from short name}}}}}}
to Module:Adjacent stations/Helsinki commuter rail/doc. Assuming we want to go that direction a Template that does this and also checks if the Module is still a redirect would be necessary. Nickps (talk) 16:37, 5 July 2024 (UTC)

Lua error

When I was viewing the page New Mexico, I found that most of the references display a "Lua error in Module:Citation/CS1/Configuration at line 2058: attempt to index a boolean value." I did a search for the error message and found more than 300 articles with the same reference error. I'm not sure what's going on, but something appears to be broken. Johnj1995 (talk) 15:31, 5 July 2024 (UTC)

A WP:NULLEDIT seems to have fixed the problem. That line of code loads data from Commons so maybe there was some issue talking to Commons when the page was rendered? * Pppery * it has begun... 15:35, 5 July 2024 (UTC)
I currently get 240 hits on "Lua error in Module:Citation/CS1/Configuration at line". I examined the first 40 and none of them had the error. Whatever caused it, it appears to be gone. PrimeHunter (talk) 17:12, 5 July 2024 (UTC)
This sort of thing sometimes pops up when the Citation Style 1 modules are updated, which happens a few times per year. (These distractions are one of the reasons for infrequent updates.) No matter how short the time between updates of each of the sub-modules, there is always a bit of time during which the sub-modules may be incompatible with each other, for example because one of them introduces new code that doesn't interact well with the older code in a different sub-module. This extremely temporary discrepancy can cause errors to pop up in at least a few pages. Null edits usually take care of the problem. – Jonesey95 (talk) 18:18, 5 July 2024 (UTC)
I haven't seen a live example of the error but the above search shows it at this in Serom (state constituency):
{{cite news
| title             = Johor 14th General Election Malaysia (GE14 / PRU14)
| work              = [[The Star (Malaysia)|The Star]]
| publication-place = [[Petaling Jaya]]
| date              = 23 March 2019
| url               = https://election.thestar.com.my/johor.html
| archive-url       = https://web.archive.org/web/20180511081855/https://election.thestar.com.my/johor.html
| archive-date      = 11 May 2018
| url-status          = live
| access-date       = 16 April 2019
}}
It currently produces:
"Johor 14th General Election Malaysia (GE14 / PRU14)". The Star. Petaling Jaya. 23 March 2019. Archived from the original on 11 May 2018. Retrieved 16 April 2019.
None of the used modules and templates have been edited recently so the cause was something else this time. PrimeHunter (talk) 18:54, 5 July 2024 (UTC)
Might it be possible to make the edits in such a way that this doesn't happen? All the best: Rich Farmbrough 22:38, 5 July 2024 (UTC).
Seems possible: Update sandbox submodules, update the main module to use the sandbox versions, update the normal submodules, change the main module to use the normal submodules again. Not sure it's worth the effort, and something worse might happen if it isn't done carefully enough. PrimeHunter (talk) 22:57, 5 July 2024 (UTC)

Running counter for figures, equations, linguistic examples, and so forth?

Is there any way to include a running counter for equations, figures, linguistics examples, and so forth, with automatic cross-referencing? The idea being that the third equation in an article would automatically render with the label Equation 3 and that code like As shown in <eqn name = "LEM"/> would produce text like As shown in Equation 3. These numbers would automatically update if equations were added or removed from the article.

As noted by Uanfala (talk · contribs) in a previous discussion, this seems like it should be possible since we already do it with references, but somehow the functionality has proved elusive. Does anybody have any ideas? Botterweg14 (talk) 17:58, 4 July 2024 (UTC)

I'm also gonna ping @Colin M: and @Biktor627:, who both edit in topic areas where this functionality would be useful. Botterweg14 (talk) 18:03, 4 July 2024 (UTC)
@Botterweg14: Automatic numbering is not possible. See Help:Displaying a formula#Equation numbering for a system with manual numbering. PrimeHunter (talk) 20:55, 4 July 2024 (UTC)
Hey, thanks for the reply. Is this something that could in principle be built by a user? Or is this really beyond what the wiki software can do in its current form? Botterweg14 (talk) 14:53, 5 July 2024 (UTC)
@Botterweg14: It might be possible with a module which reads the whole page source at each location and cross-reference in order to count occurrences but it would be expensive (resource-demanding on the servers) and doesn't seem worth the cost. It wouldn't merely make rendering slower but also break some pages which are near a resource limit. PrimeHunter (talk) 19:15, 5 July 2024 (UTC)
Ah, and there's no way this could be floated on top of the pre-existing architecture used by <ref>? Botterweg14 (talk) 20:57, 5 July 2024 (UTC)
A more specific problem is that MediaWiki is intended to work section-by-section: someone can edit a section and preview it, and that should not require the system to process the rest of the page. Johnuniq (talk) 02:14, 6 July 2024 (UTC)

MW Dark Mode bug when Software notices shown on page

 
Light mode footer appears when a software notice is shown above. [logged out]
 
Dark mode footer (normal behaviour) appears when software notice is dismissed and page refreshed (or notice not shown at all). [logged out]
 
Dark mode footer appears even when software notice is shown on Commons Main Page. [logged in]

Hi all, recently I was scrolling through the mobile version of Wikipedia as an anonymous user, and got advertised with a pop up to try the new Dark Mode feature, and came across this bug: When a software notice is shown to a logged-out user, the footer does not respect the dark mode, and continues in light mode. This happens to all pages.

But, if one dismisses the notice and refreshes the page, the footer behaves normally. Similarly opening any page without the notice also causes the footer to behave normally. When I was logged-on to Commons, I saw another software notice, but the footer behaves normally. I don't know if this bug is already reported or not. Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 17:47, 5 July 2024 (UTC)

@CX Zoom Hi, looks like it was just an issue with that Bangla Wiktionary centralnotice banner. I've fixed it now. The banner templates were updated to fix this back in May, so hopefully we won't see any more banners with the same problem. Peter Coombe (WMF) (talk) 23:47, 5 July 2024 (UTC)
Thank you very much! —CX Zoom[he/him] (let's talk • {C•X}) 15:25, 6 July 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_213&oldid=1233912913"