Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

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

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, ~ Lindsay^Hello 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)

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

Saving user preferences

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) 20:32, 1 July 2024 (UTC)

Try accessing Special:Preferences and saving the preferences with JavaScript off (google how to turn it off, it depends on browser). Nardog (talk) 02:45, 2 July 2024 (UTC)

Or try another browser or device. PrimeHunter (talk) 03:23, 2 July 2024 (UTC)

I have tried on both iPhone and laptop and it doesn’t work :( Longhorncowfish (talk) 01:59, 3 July 2024 (UTC)

I cannot do that on my current device, but I will try when possible Longhorncowfish (talk) 02:00, 3 July 2024 (UTC)

This is supposed to happen at Special:Preferences#mw-prefsection-personal in desktop:

1. The Save button is grey
2. Click once in the box at "Email me when a page or a file on my watchlist is changed"
3. The box changes state between empty white and blue with checkmark.
4. The Save button is now blue
5. Click the Save button
6. The Save button is now grey
7. "Email me when a page or a file on my watchlist is changed" still has the new setting
8. If you leave preferences and come back then it still has the new setting

If it's different for you then at which step? PrimeHunter (talk) 10:20, 3 July 2024 (UTC)

The button never goes gray. If I click it nothing happens Longhorncowfish (talk) 03:35, 5 July 2024 (UTC)

Not even a page reload? Nardog (talk) 06:16, 5 July 2024 (UTC)

@Longhorncowfish: What is your skin at Special:Preferences#mw-prefsection-rendering? What is your browser and operating system on the laptop? If you change a setting so the Save button becomes blue then does it become lighter blue with a hover-text like "Save preferences [Alt+Shift+s]" when you hover over it? Does it turn grey if you use the keyboard shortcut? Alt+Shift may be different for you, see Help:Keyboard shortcuts#Using access keys. Can you save by pressing Tab ↹ until the Save button is marked and then ↵ Enter? PrimeHunter (talk) 20:25, 7 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:

• desktop view: https://en.wikipedia.org/wiki/Collective_work#Notes – no errors
• mobile view: https://en.m.wikipedia.org/wiki/Collective_work#Notes – errors

For Sangwe cooperative:

• desktop view: https://en.wikipedia.org/wiki/Sangwe_cooperative#References – no errors
• mobile view: https://en.m.wikipedia.org/wiki/Sangwe_cooperative#References – errors

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)

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)

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)

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 [1] 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)

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)

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)

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)

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)

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)

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)

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)

Article preview showing completely different article

The page preview, which for some reason links to a different article

The article itself, which shows that the page previewer is jacked up

I was working on an article, Downtown One (which is not a redirect), when I realized that the article preview links to a completely different article, which is List of tallest buildings in Albania. A redirect from the former to the latter did exist at one point in time, but was deleted in 2023. The bug should be visible to others, if it's not just let me know, I can post an image up. This is a relatively serious bug aswell, because it basically removes the ability to visit that page, effectively eliminating the purpose of Wikipedia. I've never seen this before, so I thought I'd let yall know. (Also I attempted to report it over at Phabricator, but for some reason the ver. email link never sent). At least one person over at WP:TEAHOUSE is completely clueless as to why that happens, and honestly so am I. Thanks :) Sir MemeGod ._. (talk - contribs - created articles) 03:32, 6 July 2024 (UTC)

I failed to reproduce the problem. Graeme Bartlett (talk) 05:17, 6 July 2024 (UTC)

It just fixed itself. That is the weirdest thing. Sir MemeGod ._. (talk - contribs - created articles) 05:20, 6 July 2024 (UTC)

Sir MemeGod ._. (talk - contribs - created articles) 05:23, 6 July 2024 (UTC)

The redirect existed for 15 hours on 7 August 2023. Page Previews uses caching. I guess the cache was never updated after the deletion. I don't know whether this is normal for deleted redirects or pages. Page Previews doesn't activate on red links so it wouldn't normally affect users but it did when you recreated the page with other content. The cache was apparently updated between your first and second post, meaning between one and three hours after page creation. There are reasons for caching but 11 months is too much so I would call this a bug. PrimeHunter (talk) 10:33, 6 July 2024 (UTC)

absent section links & popups

If I click on a link to WP:ANI#Pizza (but not Mars#Pizza), a popup appears in the upper-right hand corner of the browser satating the obvious, This topic could not be found. It might have been deleted, moved or renamed. [sic] Which preference or gadget has enabled this? I can't find anything that describes such in my preferences, and I don't see anything documented at WP:ANCHOR, Help:Section#Section linking, or MOS:SECTIONLINKS. Anybody know what's causing this? — Fourthords | =Λ= | 04:49, 6 July 2024 (UTC)

mw:Extension:DiscussionTools. Just curious, why "[sic]"? Nardog (talk) 04:56, 6 July 2024 (UTC)

I don't see that specific popup listed at that link, but I'll take your word for it. As it's both new and woefully superfluous, is that something still being experimented upon (and we can wait it out), or does it need to be fixed at the project or individual-editor level? (I just used {{sic}} to denote that the missing serial comma was original to the popup, and not a mistake on my part.) — Fourthords | =Λ= | 10:28, 6 July 2024 (UTC)

It's a MediaWiki feature that has existed for several weeks. The HTML is

<div class="mw-notification-area-overlay">
  <div class="mw-notification-area mw-notification-area-layout" id="mw-notification-area" style="">
    <div role="status" class="mw-notification mw-notification-noautohide mw-notification-type-warn mw-notification-visible">
      <div class="mw-notification-content">This topic could not be found. It might have been deleted, moved or renamed.</div>
    </div>
  </div>
</div>

and it's right at the end of the HTML source that is served to your browser. The same <div class="mw-notification-area-overlay">...</div> is used to contain the "Your edit was published." message that you get when you save an edit, also some other messages. --Redrose64 🌹 (talk) 14:09, 6 July 2024 (UTC)

I don't know how to remove only this message. This in your CSS removes all mw-notification-area-overlay:

.mw-notification-area-overlay {display:none;}

This in your common JavaScript only works if it runs after the popup has appeared but it normally runs before:

$('.mw-notification-area-overlay:contains("This topic could not be found")').hide()

PrimeHunter (talk) 14:21, 6 July 2024 (UTC)

I've found two more messages that go in the same area - '"(page name)" and its talk page have been added to your watchlist permanently.' and '"(page name)" and its talk page have been removed from your watchlist.', so that makes four, although there may be others. @Fourthords: I've worked out how to hide the "This topic could not be found. It might have been deleted, moved or renamed.", leaving the other three visible:

#mw-notification-area:has(div.mw-notification-noautohide.mw-notification-type-warn) {
  display: none;
}

which goes in your CSS. The selector might be overspecific. --Redrose64 🌹 (talk) 16:12, 6 July 2024 (UTC)

Oh gosh, I hadn't mean to attract so much attention and assistance; I was just expecting a point in the correct direction. Thanks so much! — Fourthords | =Λ= | 18:09, 6 July 2024 (UTC)

A problem with all these approaches is that it would also hide a notification which does point to an archived section (e.g. WP:VPT#Heading markup changes). Nardog (talk) 04:09, 7 July 2024 (UTC)

The two messages have the same classes and id's and the unwanted message doesn't have anything unique apart from the actual text which cannot be selected with CSS, but only the wanted message has <p>. We can use this to hide both and then unhide the wanted:

#mw-notification-area:has(div.mw-notification-noautohide.mw-notification-type-warn) {
  display: none;
}
#mw-notification-area:has(div.mw-notification-noautohide.mw-notification-type-warn p) {
  display: inline;
}

PrimeHunter (talk) 09:32, 7 July 2024 (UTC)

@PrimeHunter: Which two messages have the same classes and id's? --Redrose64 🌹 (talk) 18:26, 7 July 2024 (UTC)

The "This topic could not be found..." popups on WP:ANI#Pizza and WP:VPT#Heading markup changes. PrimeHunter (talk) 19:05, 7 July 2024 (UTC)

Unseen search box

When I do not login, the search box is not visible (on my HP laptop running Windows 11, using Firefox or Brave) unless I hit ctrl and the minus key at least three times. I wouldn't be surprised if there aren't potential users who have come to Wikipedia and left after not finding a way to search. Can't this set-up be changed? (When I'm logged in, the issue does not occur.) Kdammers (talk) 03:48, 7 July 2024 (UTC)

If I zoom in 175% it turns into a magnifying glass symbol, which I can then click to display the searchbox. – 2804:F1...04:60E (talk) 04:06, 7 July 2024 (UTC)

@Kdammers: See Wikipedia:Village pump (technical)/Archive 213#Search box and Wikipedia:Village pump (technical)/Archive 213#Bugs persisting after last week. --Redrose64 🌹 (talk) 18:23, 7 July 2024 (UTC)