Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Dylsss (talk | contribs) at 03:03, 26 February 2022 (→‎Non-free file uploader not working: Reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
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).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. 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.


Not seeing tools or notifications

I use Opera and recently had to reinstall it. Since reinstalling, I can't see the Tools tabs at the top of the page and when I click the Notifications icon the page is blank. I know that this is some setting about privacy or scripting but I can't remember or figure out which. Anyone have any ideas? Thanks in advance. Eggishorn (talk) (contrib) 20:43, 14 February 2022 (UTC)[reply]

@Eggishorn, which skin are you using? You should be able to tell by looking at Special:Preferences#mw-prefsection-rendering. Whatamidoing (WMF) (talk) 23:59, 14 February 2022 (UTC)[reply]
@Whatamidoing (WMF) and WhatamIdoing:, Apparently, whatever problem I'm having is also preventing me from seeing the "Appearance" tab of the Preferences page, so I can't tell for sure. to the best of my memory, I think it's Monobook. Eggishorn (talk) (contrib) 15:20, 15 February 2022 (UTC)[reply]
Have a look at the images near the top of Wikipedia:Skin, see which is closest to what you have. The main details to consider are the items around the edges, rather than the main content. --Redrose64 🌹 (talk) 19:43, 15 February 2022 (UTC)[reply]
@Redrose64:, I think it looks most like vector Legacy, if that's any help. Thanks again. Eggishorn (talk) (contrib) 20:09, 15 February 2022 (UTC)[reply]
@Eggishorn, please click https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&safemode=1 and see if mw:safemode fixes anything. Whatamidoing (WMF) (talk) 17:21, 16 February 2022 (UTC)[reply]
@Whatamidoing (WMF) and WhatamIdoing: Sorry for the delay in answering. The safe mode didn't change anything but everything started working correctly shortly before your last question. I didn't change any settings either on WP or my browser or restart the browser either, so I was at a loss as to why what didn't work before suddenly did. I was holding off on answering until it seemed like the changes "held" but the tools seem to be working now. I'm kind of stumped but the immediate problem seems solved. Thanks for your help. Eggishorn (talk) (contrib) 20:10, 18 February 2022 (UTC)[reply]
Thanks for the update. I'm glad that the problem is solved, even if the solution is unknown. Whatamidoing (WMF) (talk) 22:22, 18 February 2022 (UTC)[reply]

@Eggishorn: this is a bit o/t, but I'm an Opera user of long standing, until I discovered the Vivaldi browser, which I now use almost exclusively. If you're an Opera fan, try out Vivaldi; you might become a new fan and love it as much as I do. Mathglot (talk) 07:04, 22 February 2022 (UTC)[reply]

Changed behaviour for the thumb image option

Moonraker (talk · contribs) has made edits like this on a number of articles. I see no point to this, since it is merely doubling up the styles that are applied by the inbuilt CSS rule

div.tright,
div.floatright,
table.floatright {
  clear: right;
  float: right;
}

that is triggered by the use of |thumb on the image. I brought it up on their talk page, and removed some such additions (example), but several of my edits have been reverted (example), reinstating the markup that is, to me, absolutely unnecessary.

So, has there been some change to the way that |thumb behaves, either in the site's CSS or in the MediaWiki software? It seems strange that such a radical change in behaviour (floated images failing to float) would not be noticed by several other people and at least one thread started here. But if there has been a change, fixing this in one or two places would surely be easier than adding <div style="float:right;clear:right">...</div> tag pairs around millions of images one by one. --Redrose64 🌹 (talk) 10:22, 19 February 2022 (UTC)[reply]

I see on their talk page that the user claims that it only affects small-screen mobile devices, which is probably true as floats don't make much sense at low widths. But as far as I know the relevant CSS rules have existed for years. And I doubt wholesale forcing of floats on mobile devices is really going to be a good experience for such readers. Anomie 13:11, 19 February 2022 (UTC)[reply]
This indeed has an effect on mobile devices, but it's a negative effect! Here's how the article you linked (Stewart Orr) looks like on my phone: https://phabricator.wikimedia.org/F34958172. Images are made to display at full width on mobile for a reason, please don't override that. Matma Rex talk 13:59, 19 February 2022 (UTC)[reply]
I'm not overriding it, Moonraker is. --Redrose64 🌹 (talk) 14:19, 19 February 2022 (UTC)[reply]
Yes, sorry, I meant to say "let's not override that". Matma Rex talk 14:22, 19 February 2022 (UTC)[reply]
Moonraker Please stop making this change. Izno (talk) 17:33, 19 February 2022 (UTC)[reply]
Redrose64 and Izno, it seems to me you need to link some policy, rather than putting forward personal preferences. Most people (including me) are now using mobile devices. If I create an article and want a marginal image in it, one which does not split the text across the whole page width, the “thumb” option no longer works for me on the English Wikipedia, as it did until a few months ago. It still works fine on the French, German, and Italian Wikipedias, and perhaps on all others. By all means point me towards some other standard option. {{Main page image}} does the trick for me, but I believe it was GKFX who said that should only be used on the main page. If there is a policy which claims that marginal images are a problem, I am not aware of it. There must surely be a correct way to achieve them. Also, can someone please find out exactly what change has been made to the “thumb” mobile display on this Wikipedia, I believe it was last October, and why it was made? Moonraker (talk) 00:35, 20 February 2022 (UTC)[reply]
@Moonraker Marginal images still display on the mobile site, but they depend on your device's width and text zoom level. On my device, they appear like that when I turn it to landscape and zoom out to 75%: [1] (85% for comparison: [2]) (the example I tested is The Fighting Temeraire#Symbolism). If you see different results on different language Wikipedias, maybe you zoomed in on one of them accidentally or something? Matma Rex talk 01:05, 20 February 2022 (UTC)[reply]
This is actually irrespective of my personal preference. The irony is that you are installing your own personal preference without actually understanding the implications of what you are doing.
As for 'marginal' images, Matma Rex seems to have explained how and why they aren't working for you, and why in fact you should not try to enforce your preference. While it is possible something did actually change or break for you in October (there has been work on skinning for the past couple years), I have some doubts (Matma would know if it had -- he is a reasonably diligent software engineer for the movement). Izno (talk) 01:15, 20 February 2022 (UTC)[reply]
With respect, Izno, I have today checked on two other mobile devices, and on all of them the English Wikipedia is behaving differently from the other three Wikipedias I mentioned above, Fr, De, and It. I noticed it doing that about the middle of last October. I have just checked the Spanish WP (where the “thumb” option can be used as “thumb” or “miniatura”), plus Latin, Hungarian, and Polish, and on all of them “thumb” is still producing small marginal images which do not spread across the whole page width. On my “personal preference”, sure, it is simply for marginal images to go on displaying as they do everywhere else, at least on the pages I have designed. I understand the preference of Redrose64, which is to cut out unnecessary surplus text which he believes achieves nothing. That would make good sense if it did achieve nothing. He has said on my talk page he is using Windows 10 on a PC. Moonraker (talk) 05:37, 21 February 2022 (UTC)[reply]
What makes it your preference is that you are adding non-responsive HTML which inhibits the display for everyone else. Yes, everyone else.
Stop. Izno (talk) 05:45, 21 February 2022 (UTC)[reply]
Matma Rex, no, no accidental zooming in. It would be really helpful to get to the bottom of what the difference is between the way “thumb” is programmed to perform on this Wikipedia and the others. Do you have time to check that out? Moonraker (talk) 05:37, 21 February 2022 (UTC)[reply]
Moonraker, if you log out of the English Wikipedia, do images display differently? If so, your thumb size preferences on en.WP may be causing the different rendering between en and fr/de/it. – Jonesey95 (talk) 06:02, 21 February 2022 (UTC)[reply]
@Moonraker Can you link to the articles you're testing, and provide screenshots of what you're seeing? There is no difference between English and Polish Wikipedia for me, and I don't see any differences in configuration options that could affect how thumbnails are shown. Matma Rex talk 08:04, 21 February 2022 (UTC)[reply]
Matma Rex, I can do screenshots, but how do I post them here or somewhere else? Do you suggest I upload them to this Wikipedia or Commons, or is there another way to do it? As an example of the difference between En and Pl, the England page gives me about fifty “thumb” images in windows that take up the whole page width, but the Pl Anglia page shows “thumb” images to the right, each taking up about a third of the page width, with the text running down continuously. Moonraker (talk) 09:08, 21 February 2022 (UTC)[reply]
It doesn't really matter to me where you upload them. I used https://phabricator.wikimedia.org/file/upload/ (which is a part of our bug tracking software), you can use your favorite image hosting service. Matma Rex talk 11:53, 21 February 2022 (UTC)[reply]
Here's a link to a pl.WP copy of the English version of "England" (hosted on pl.WP). The templates and links generally don't work, but it should allow for straightforward comparison of the same image code on two different instances of Wikipedia. When I switch to mobile view, both pages stop flowing text around images and place them alone in the center of the page when my viewport window width gets below about 710 pixels, even though my thumb size preferences are different at en.WP and pl.WP. I see no difference. – Jonesey95 (talk) 14:27, 21 February 2022 (UTC)[reply]
When posting here, you should have seen this notice, which includes the line
Some external image hosting services have objectionable advertising, or run untrustworthy JavaScript. Even imgur gives me problems - when visiting it my PC slows to a crawl and I need to reboot. So please can we stick with WP:WPSHOT which is as trustworthy as the rest of Wikipedia. --Redrose64 🌹 (talk) 11:35, 22 February 2022 (UTC)[reply]

Edit Watchlist times out

I've got over 23,000 pages but I wouldn't think that's a problem. In theory I could also try editing my raw watchlist, but that loads, shows pages for a second, and goes blank. Doug Weller talk 17:49, 19 February 2022 (UTC)[reply]

Yes, that's too many these days. Raw watchlist failing is probably a separate issue totally though. Izno (talk) 17:59, 19 February 2022 (UTC)[reply]
Try rawmode with safemode link, trim that way down. — xaosflux Talk 18:10, 19 February 2022 (UTC)[reply]
You could try trimming some of the cruft from your watchlist with my watchlist cleaner tool. You might want to skip the slow options the first time round, but I've been able to test it successfully on a 10,000 item watchlist. --Ahecht (TALK
PAGE
) 22:16, 19 February 2022 (UTC)[reply]
Thanks all. @Xaosflux: safe mode worked very well. I was then able to get it down to just under 12,000. But the normal way just displays it, it won't actually delete anything, just leaves a message "There are too many pages to display here." despite having shown them all. @Ahect: I installed it but I use User talk:The Transhumanist/WatchlistSorter.js which I think stops your script from working. At least I think I am, User:Doug Weller/watchlistSorter.js really puzzles me as it doesn't seem installed and I can't find it elsewhere. I've got three watchlists, one for articles/article talk page, main space and talk pages, userpage and talk pages, with colours. Doug Weller talk 14:21, 21 February 2022 (UTC)[reply]
@Doug Weller: The message "There are too many pages to display here", displayed after you've hit the "Remove titles" button, is misleading. I think it is trying to say "I have removed the titles as you requested; if there were only a few, I would have listed them here as part of the confirmation message, but you've removed so many that I'm not going to list them." -- John of Reading (talk) 14:55, 21 February 2022 (UTC)[reply]
@John of Reading: It certainly is misleading, as I've just discovered. I've been able to trim my watchlist to under 10,000 and it now shows the pages I've deleted. I think with everyone's help I've accomplished what I was trying to accomplish, and I've reset ordinary and Twinkle preferences to add fewer pages. That plus the ability to set a time limit should keep it under control. Thanks all. Doug Weller talk 15:00, 21 February 2022 (UTC)[reply]
I was wondering if there was a script that allowed me to clean out my watchlist. ― Blaze WolfTalkBlaze Wolf#6545 15:03, 21 February 2022 (UTC)[reply]
Geez anti-vandal work sure fills up your watchlist. The majority of the pages in my watchlist were userpages of either indef blocked users or IPs. Some of these I wish I could keep the talk page watchlisted but not the userpage but unfortunately that's not how it works. ― Blaze WolfTalkBlaze Wolf#6545 15:12, 21 February 2022 (UTC)[reply]

Effect of article size on references (and of transclusions on article size)?

Hi, can someone please give a look at Talk:2022 United States House of Representatives elections § Wonky footnotes? As of now, reference #1003 and all after it won't show up as it ideally should. Someone explored the possibility that expansion of templates in the article caused it to exceed limits imposed by software. However, when I simply copy-pasted the page contents in User:CX Zoom/TestPage8, with some portions being pasted in User:CX Zoom/TestPage5 instead and being transcluded from there. Despite the total content being slightly lesser than original article, references #938 and all after it won't show up. Is the issue of references not showing up not dependent on article size or transclusions somehow significantly increase the post-expand size? Also, if someone can fix the main issue in question, it will be very helpful. Thanks! ---CX Zoom(he/him) (let's talk|contribs) 15:12, 20 February 2022 (UTC)[reply]

If the article is way too damn big now, with the election still nine months away, you know that the article will continue to grow for the next year and a half – longer if the election is in any way controversial. Time to split or consider severely paring it back to the essentials.
As a stop-gap, you might replace all {{cite web with {{#invoke:cite web|| and all {{cite news with {{#invoke:cite news|| (note the double pipe). That might be problematic because I suspect that that construct is not recognized by the bots and user scripts that cleanup after careless editors. It will not stop the growth of the article. Best that editors exercise editorial discipline and edit the article back to a reasonable size.
Trappist the monk (talk) 15:33, 20 February 2022 (UTC)[reply]
Actually the problem is that it's still primary season. This same issue happened four years ago, indeed then all the references were broken! Only after the losers in the primaries are culled out the the article does it reduce down to a reasonable size. – wbm1058 (talk) 19:58, 20 February 2022 (UTC)[reply]
Thanks Trappist the monk. Thanks wbm1058. ---CX Zoom(he/him) (let's talk|contribs) 07:16, 22 February 2022 (UTC)[reply]
...but one thing I don't understand is why the page with the same content but one of its parts being transcluded from other page will load less number of references than a page that has all contents within itself. ---CX Zoom(he/him) (let's talk|contribs) 07:24, 22 February 2022 (UTC)[reply]

Non-free file uploader not working

Hello, I have noticed that the Wikipedia's non-free file uploader is not working in mobile phones. This is happening in the Wikipedia's file upload wizard. When we click on 'upload a non-free file' on mobile phones, so nothing happens. Just the page reloads. We have to switch to desktop website for uploading such files. GoldenHayato (talk) 03:24, 21 February 2022 (UTC)[reply]

Yes, it's because it is a custom tool which uses the parameter ?withJS to load JavaScript. the ?withJS parameter is only implemented on the desktop site in MediaWiki:Common.js. Dylsss(talk contribs) 03:03, 26 February 2022 (UTC)[reply]

poor visibility of ins and del-tag background colors in diffs

Hi, to me (as a visually impaired person) it's very hard to find the (often small) pieces of text that are added or deleted in a diff. Texts that are added or deleted are placed within a <ins> or <del>-tag. The contrast ratio of the background color for these tags to the normal background color is 1:1.2 . WCAG 2.0 actually advises a ratio of at least 1:3 for user interface components. Since the added or deleted parts in a diff are a vital part of a wiki, I think this should be better accessible for all people by changing the background color of these elements (globally, through MediaWiki:Common.css?). I would like to propose this background color, which is #ADD6FF for the ins- and del-tags. This is a darker variant based on the same color that is used now. This considerably increases contrast to the normal background-color (#FFFFFF). Still not a 1:3 contrast-ratio, but this would make it far more easy for visually impaired people and actually anyone to find the changes within a diff. Novopas (talk) 09:46, 21 February 2022 (UTC)[reply]

That change would also make diff usable in dark mode, where ins and del are currently almost invisible even with average vision. Certes (talk) 12:17, 21 February 2022 (UTC)[reply]
@Novopas: Registered users can choose "wikEdDiff" and "Display diffs with the old yellow-and-green colors and design" at Special:Preferences#mw-prefsection-gadgets. PrimeHunter (talk) 13:57, 21 February 2022 (UTC)[reply]
Thank you, PrimeHunter, I wasn't aware of this option. On the Dutch Wikipedia I also changed my personal CSS to improve visibility of the ins/del-tags. But I still think that a lot of people, both registered and unregistered, could benefit from this change. Novopas (talk) 14:26, 21 February 2022 (UTC)[reply]
I have the settings suggested by PrimeHunter and still have problems finding small changes. MB 17:22, 21 February 2022 (UTC)[reply]
@MB: So do I, so I created two CSS rules:
td.diff-deletedline del.diffchange { background-color: #cfc; }
td.diff-addedline ins.diffchange { background-color: #ffa; }
I put them in m:Special:MyPage/global.css so that they would be effective on all Wikimedia Wikis, but you can put them in Special:MyPage/common.css so that they only affect English Wikipedia. Basically, the unchanged portions of lines retain the yellow (old)/green (new) backgrounds yielded by that gadget, as do lines wholly added or wholly removed, but changed content within an existing line gets the background colours exchanged - green for old removed text, yellow for new added text. This method even works for single spaces added or removed, which the basic gadget doesn't. --Redrose64 🌹 (talk) 13:26, 22 February 2022 (UTC)[reply]
  • phab:T90948 is opened to determine better styling for diffs, feedback is welcome there! — xaosflux Talk 17:25, 21 February 2022 (UTC)[reply]
    No one is touching this with a ten foot pole, I think. It’s one of those typical, whatever u do, no one is satisfied and everyone is angry issues unfortunately. And then status quo tends to prevail for a long time. —TheDJ (talkcontribs) 19:47, 21 February 2022 (UTC)[reply]
    Make it a per-user preference then, with the current wishy-washy pastels as the default. Certes (talk) 20:17, 21 February 2022 (UTC)[reply]
    Something I never understood is why desktop and mobile have as differing schemes as #a3d3ff/#ffe49c and #75c877/#e07076. To me the former is far superior and the latter barely legible, but I guess Novopas would disagree? Nardog (talk) 23:03, 21 February 2022 (UTC)[reply]
    Novopas is saying he can't distinguish (or not easily, anyway) the pastel backgrounds of the former from white, so it's as if the changes don't exist.
    Mobile is on the other color scheme because mobile use its own diff machinery and it wasn't updated when core was, in case you didn't read the task. Izno (talk) 23:20, 21 February 2022 (UTC)[reply]
    @Certes: a per-user preference would be great, but I'd suggest that the accessible option always be the default (also, because unregistered users won't be able to choose any preference). Thanks for the phabricator link, Xaosflux, although I'm really not proposing any different color scheme per se, rather proposing to make the current scheme more accessible to visually impaired people, by changing the background to a (slightly) darker shade. Izno is right in saying that the current background is practically invisible for me and other visually impaired users. (and as Certes pointed out, people with normal sight who are using dark mode) Novopas (talk) 09:55, 22 February 2022 (UTC)[reply]

19:10, 21 February 2022 (UTC)

Lua error: too many expensive function calls.

I'm seeing this error message on Module:Authority control. From the additional info provided it seems the error is actually coming from Module:Documentation. Can anyone advise how to fix this? Thanks — Martin (MSGJ · talk) 19:10, 21 February 2022 (UTC)[reply]

Module:Authority control/doc currently uses exactly 500 expensive function calls. Prior to Special:Diff/1073247698 it was at 480. Module:Documentation probably adds a few more for testing if various subpages exist. The fix would be to reduce the number of expensive calls used in Module:Authority control/doc. Anomie 22:14, 21 February 2022 (UTC)[reply]
And a good to start that would be to remove all the calls to mw.site.stats.pagesInCategory. Johnuniq (talk) 22:29, 21 February 2022 (UTC)[reply]

Adding WikiEd banner shell moves TOC within banner shell somehow

Hello! So in this edit I had attempted to add the WikiEd banner shell to improve the look of the talk page, however somehow doing so also made it so the table of contents was in the banner shell. I checked to make sure I didn't somehow include a table of contents template in it but I didn't. Anyone know what's going on here? ― Blaze WolfTalkBlaze Wolf#6545 19:16, 21 February 2022 (UTC)[reply]

That is actually normal behaviour because {{Dashboard.wikiedu.org assignment}} produces a level 2 heading and the table of contents automatically appears above the first heading. It is better not inside the shell. — Martin (MSGJ · talk) 19:51, 21 February 2022 (UTC)[reply]
@MSGJ: Ah alright. Seems weird since it makes the template look like a talk page entry rather than a template but since it's normal behavior then I'll leave it. But since the ToC appears above the first heading, then what's the point of the shell if it'll just screw up the ToC when used properly? ― Blaze WolfTalkBlaze Wolf#6545 19:54, 21 February 2022 (UTC)[reply]
There are a couple of ways to avoid this. One is to specify where you want the table of contents to display by typing __ToC__. Alternatively we could change it from a level 2 heading to something else which would not trigger the contents table. But that would probably stop it working properly when used outside the shell! — Martin (MSGJ · talk) 19:59, 21 February 2022 (UTC)[reply]
Pinging @Ragesoss about this. Whatamidoing (WMF) (talk) 18:35, 25 February 2022 (UTC)[reply]

Hatnote engulfs other post

Hello! So at WT:TEA, the hatnote Vchimpanzee added to his post is now engulfing the lower post. It appears it's been closed correctly so I'm not sure how to fix it. ― Blaze WolfTalkBlaze Wolf#6545 14:25, 22 February 2022 (UTC)[reply]

@Blaze Wolf: looks like GIGO, reverted in this edit. — xaosflux Talk 15:10, 22 February 2022 (UTC)[reply]
The problem was that {{hab}} was in the middle of a line. It only works when it is at the very start of a new line. --Redrose64 🌹 (talk) 17:13, 22 February 2022 (UTC)[reply]
Sorry about that. I was thinking maybe people would object to reading all that but I felt I needed to say it somewhere.— Vchimpanzee • talk • contributions • 19:31, 22 February 2022 (UTC)[reply]

Footnotes and line wrapping issue

 – Pointer to relevant discussion elsewhere.

Somebody please pitch in at Wikipedia talk:Manual of Style#Footnotes and line wrapping issue. I am getting tired of explaining why it is unfeasible to make millions of changes just because of one user's borderline sub-optimal reading experience. --Redrose64 🌹 (talk) 19:22, 22 February 2022 (UTC)[reply]

Thumbnail image vertical alignment

Why is it that thumbnail images cannot provide vertical alignment as non-thumbnail images can? Can we add vertical alignment to thumbnail images? This would greatly enhance the placement of images to accommodate a wide range browser window widths. Yours aye,  Buaidh  talk e-mail 20:21, 22 February 2022 (UTC)[reply]

Buaidh Can you point to an example of what non-thumbnails are doing that you think thumbs should be able to do? Izno (talk) 20:25, 22 February 2022 (UTC)[reply]
I would like to vertically align the thumbnail image with the relevant point or paragraph. The vertical alignment default for thumbnails is always top. The following is a trivial example with equal line spacing and similar image sizes. If the paragraphs and images are of substantially unequal sizes, the discrepancy becomes far greater.
What I get is this:
  1. George Washington
  2. John Adams
  3. Thomas Jefferson
  4. James Madison
  5. James Monroe
  6. John Quincy Adams
    John Quincy Adams
  7. Andrew Jackson
  8. Martin Van Buren
  9. William Henry Harrison
  10. John Tyler
  11. James K. Polk
  12. Zachary Taylor
  13. Millard Fillmore
  14. Franklin Pierce
  15. James Buchanan
  16. Abraham Lincoln
  17. Andrew Johnson
  18. Ulysses S. Grant
  19. Rutherford B. Hayes
    Rutherford B. Hayes
  20. James A. Garfield
  21. Chester A. Arthur
  22. Grover Cleveland
  23. Benjamin Harrison
  24. Grover Cleveland
  25. William McKinley
  26. Theodore Roosevelt
  27. William Howard Taft
  28. Woodrow Wilson
What I want is this:
  1. George Washington
  2. John Adams
    John Quincy Adams
  3. Thomas Jefferson
  4. James Madison
  5. James Monroe
  6. John Quincy Adams
  7. Andrew Jackson
  8. Martin Van Buren
  9. William Henry Harrison
  10. John Tyler
  11. James K. Polk
  12. Zachary Taylor
  13. Millard Fillmore
  14. Franklin Pierce
  15. James Buchanan
    Rutherford B. Hayes
  16. Abraham Lincoln
  17. Andrew Johnson
  18. Ulysses S. Grant
  19. Rutherford B. Hayes
  20. James A. Garfield
  21. Chester A. Arthur
  22. Grover Cleveland
  23. Benjamin Harrison
  24. Grover Cleveland
Aren't John Q. and Rutherford cute? Yours aye,  Buaidh  talk e-mail 23:11, 22 February 2022 (UTC)[reply]
The basic explanation is that this is not how the web tech of interest here works. Izno (talk) 00:09, 23 February 2022 (UTC)[reply]
If you are just playing around in User space, you could do something hacky like {{float |top=-7em |[[File:John Q. Adams.jpg|upright=0.5|thumb|[[John Quincy Adams]]]]}}. I wouldn't use that construction in article space, though, unless I were prepared to test and maintain the affected pages with a variety of browsers, skins, and mobile/desktop viewers in perpetuity. – Jonesey95 (talk) 01:39, 23 February 2022 (UTC)[reply]
Which still doesn't work because user preferences. Izno (talk) 01:50, 23 February 2022 (UTC)[reply]
Works for me, but as I said, I would only do it in user space. – Jonesey95 (talk) 04:55, 23 February 2022 (UTC)[reply]

Awards parameters for Video games reviews template not working

Hello! I'm working on improving the Euro Truck Simulator 2 article and was told that I could use the awards parameter for the video games review template to get rid of the awards section, however for whatever reason when I attempt to add the publisher of the award, it results in the publisher section for that being blank. Anyone know what I"m doing wrong? ― Blaze WolfTalkBlaze Wolf#6545 23:41, 22 February 2022 (UTC)[reply]

Blaze Wolf, questions specific to a specific template should be asked first on the relevant template talk page or to the person who thinks they know what they're talking about. Izno (talk) 00:04, 23 February 2022 (UTC)[reply]
@Izno: Ah alright. I just asked here because I knew I would find people here that would know the answer to my question. Shall I ask this question there then or should I wait for someone to answer it here? ― Blaze WolfTalkBlaze Wolf#6545 00:10, 23 February 2022 (UTC)[reply]
Go ask it there. Izno (talk) 00:10, 23 February 2022 (UTC)[reply]

oversight group renamed (breaking change)

With T112147, the oversight group has been internally renamed to suppress. This does not change anything in terms of how the group is referred to in system messages or policies, but it does mean:

In all three cases, this can be fixed by changing oversight or oversighter to suppress (looks like that's replaced both names; see e.g. [9]).

I've updated all instances of the first two I could find in important places (policy pages, ArbCom documentation... for a period of time today several pages proudly claimed we had 0 oversighters), but have for the time being let be the 100 or so archives, historic pages, and userspace pages with that markup. I think it would be reasonable for someone to go through with AWB and just update the lot of them, though. Even for some random talkpage comment from 10 years ago, it's truer to the commenter's original intention to correct the links. Remaining instances: ListUsers · NUMBERINGROUP.

As to scripts, well, pretty quick fix. If you see a script that needs to be updated for this, ping the maintainer if they're around, or an IntAdmin if not. -- Tamzin[cetacean needed] (she/they) 06:20, 23 February 2022 (UTC)[reply]

@Chlod and Pythoncoder: Pinging creators of the mentioned scripts so they can work on a fix. ― Blaze WolfTalkBlaze Wolf#6545 15:47, 23 February 2022 (UTC)[reply]
I {{bcc}}'d. :P There's more than those two, they're just the first whose script documentation pages came up in the search. -- Tamzin[cetacean needed] (she/they) 15:53, 23 February 2022 (UTC)[reply]
@Blaze Wolf: We were both pinged above in a {{bcc}}. In any case, this isn't something I can fix myself since I rely on the data for MarkAdmins, operated by Mdaniels5757. Chlod (say hi!) 15:54, 23 February 2022 (UTC)[reply]
@Tamzin: Ah alright. Also I know there's more than just them. @Chlod: Sounds good. I would attempt to fix it myself but uh... I wouldn't know what I'm doing and would probably break something. ― Blaze WolfTalkBlaze Wolf#6545 15:59, 23 February 2022 (UTC)[reply]
@Chlod: Mdaniels doesn't seem to be active right now, but I've put in a pull request and cross-posted it to their talk in hopes that'll get their attention. If they don't respond, someone will have to fork the bot in order for scripts to be able to see who's an oversighter. It's a BRFA-exempt task, so should be simple enough. -- Tamzin[cetacean needed] (she/they) 16:09, 23 February 2022 (UTC)[reply]
And I use data from AmoryBot so it looks like Amorymeltzer will have to update their code. —pythoncoder (talk | contribs) 13:46, 25 February 2022 (UTC)[reply]
Was updated a few days ago, should be all set now. ~ Amory (utc) 15:04, 25 February 2022 (UTC)[reply]
Also, nbd, but your ping didn't work, not sure why ~ Amory (utc) 15:24, 25 February 2022 (UTC)[reply]
Unless someone objects I'll run AWB through those soonishly -- Asartea Talk | Contribs 12:00, 24 February 2022 (UTC)[reply]
I've run AWB through, which caught most pages, and have filed edit requests for the five pages I couldn't edit because they were full protected. That only leaves User:Stepshep/userpage.js which I'm A) not really sure how they managed to create (I could have sworn there were sanity checks), and B) would require a interface admin. -- Asartea Talk | Contribs 14:03, 24 February 2022 (UTC)[reply]
I did that one. — xaosflux Talk 15:17, 24 February 2022 (UTC)[reply]
It seems the second script runs of bot data by @Amorymeltzer; pinging them to this discussion -- Asartea Talk | Contribs 18:34, 24 February 2022 (UTC)[reply]
Sorry, @Asartea, I'm confused by your sentence there, what are you trying to say? ~ Amory (utc) 18:42, 24 February 2022 (UTC)[reply]
@Amorymeltzer basically what @Pythoncoder said above; their userhighlighter is running of the AmoryBot data, so I pinged you just in case you hadn't seen this yet (sorry for the late reply: I apparently forgot to hit publish changes yesterday) -- Asartea Talk | Contribs 14:46, 25 February 2022 (UTC)[reply]
Ahh, gotcha, that clears it up. Yeah, bot was updated a few days ago, cheers. ~ Amory (utc) 15:04, 25 February 2022 (UTC)[reply]

Template documentation: whether to use a subpage or not

Editors are welcome to share their views on the placement of a template's documentation, and in particular if using subpages for this purpose should be required across the board for all templates. The discussion is at Wikipedia talk:Template documentation#Subpage or not. – Uanfala (talk) 15:36, 23 February 2022 (UTC)[reply]

Web cite

In some cases "url-status = live" results in no link to original or archived version and "url-status = dead" not results in hiding dead link. Eurohunter (talk) 19:01, 23 February 2022 (UTC)[reply]

Real life examples?
Trappist the monk (talk) 19:07, 23 February 2022 (UTC)[reply]
@Trappist the monk: Reference 29 and 30 with dead status. Eurohunter (talk) 20:55, 23 February 2022 (UTC)[reply]
Do you have any idea how many Reference 29 and 30 citations there are in en.wiki? Which of them are you talking about?
Trappist the monk (talk) 20:57, 23 February 2022 (UTC)[reply]

Difficulty clicking links and text fields

Starting yesterday, some wikilinks and text fields not selectable or take multiple attempts to register a click. Typing in the edit summary field is sometimes impossible. On LAV II, Category:General Dynamics land vehicles is not clickable (Navigation popups also not working for this specific link). As I type this using Discussion Tools, moving the curser sometimes takes multiple clicks. Purging the cache does not help. I am using Edge stable v. 98.0.1108.56 and Windows 11. Haven't yet reproduced on Chrome. Schierbecker (talk) 20:03, 23 February 2022 (UTC)[reply]

Closing and reloading the browser also does not help. I still can't click that category on LAV II. I temporarily couldn't click edit source on this section. Had to leave this reply using Discussion Tools. Schierbecker (talk) 20:13, 23 February 2022 (UTC)[reply]
 Works for me what view (Desktop, App, Mobile Web), skin, and browser are you using? — xaosflux Talk 20:22, 23 February 2022 (UTC)[reply]
Disabling Discussion Tools does not help. I removed my only script from User:Schierbecker/vector.js the day before yesterday. Could that be related? I also have one script on my User:Schierbecker/vector.css that turns wikilinks to redirects the color green. I am using Vector, Microsoft Edge stable v. 98.0.1108.56 and Windows 11. I don't use Visual Editor, but I do use the Discussion Tools beta. Schierbecker (talk) 20:27, 23 February 2022 (UTC)[reply]
If you open a private browsing window and don't log in - are you having the same issue? — xaosflux Talk 20:36, 23 February 2022 (UTC)[reply]
Logging out did fix the category issue on LAV II. Opening in InPrivate while logged out brings up more problems, however. Category:Wheeled infantry fighting vehicles and Category:General Dynamics land vehicles are clickable, but only intermittently. Schierbecker (talk) 20:42, 23 February 2022 (UTC)[reply]
Actually, maybe this is now fixed. Schierbecker (talk) 20:51, 23 February 2022 (UTC)[reply]
If it comes back, then try mw:safemode for testing. Whatamidoing (WMF) (talk) 18:44, 25 February 2022 (UTC)[reply]

Something causing error in navigation pop-ups

When I point my mouse at Demi Lovato the pop-up shews the picture and the usual "Demi Lovato ⋅ actions ⋅ popups 185.6kB, 787 wikiLinks, 10 images, 52 categories, 4 days 4 hours old" bit, but instead of any text I only see }}. I think this is something to do with hidden comments in or near the infobox. If anyone could fix this I would be grateful. The article in question will be on the front page soon in DYK. DuncanHill (talk) 00:30, 24 February 2022 (UTC)[reply]

Fixed. It was because the MDY template was on the same line at the end of the hidden comment. I moved it to its own line, and now the popup displays properly. Schazjmd (talk) 00:36, 24 February 2022 (UTC)[reply]
Many thanks. DuncanHill (talk) 00:38, 24 February 2022 (UTC)[reply]

Thursday?

Just got the error from a few weeks ago (Cant' remember what it was). Is there some update to Wikimedia (mediawiki? I can never which one it is) that broke something? ― Blaze WolfTalkBlaze Wolf#6545 02:47, 24 February 2022 (UTC)[reply]

I just saw upstream connect error or disconnect/reset before headers. reset reason: overflow after something like "waiting for intake analytics" or something like that. A temporary problem. – wbm1058 (talk) 02:58, 24 February 2022 (UTC)[reply]
phab:T301505 is the report from 10 February. PrimeHunter (talk) 03:34, 24 February 2022 (UTC)[reply]
That's still happening? I thought they would've fixed it! ― Blaze WolfTalkBlaze Wolf#6545 13:19, 24 February 2022 (UTC)[reply]

Messed up inter-language links

Hi, I'm facing some issue and asked for support at mw:Topic:Wqm5gq0lh7n23smn. I'm not sure if that was the correct place to ask it, and because this issue is happening with inter-language links to English Wikipedia, I'm leaving a link here for those who would like to see the matter. Thanks! ---CX Zoom(he/him) (let's talk|contribs) 07:29, 24 February 2022 (UTC)[reply]

It says: I just found out that on clicking the link to English language from bn:উইকিপিডিয়া:আলোচনাসভা & hi:विकिपीडिया:चौपाल, I am taken to en:Ministry of Foreign Affairs of Ukraine. However, on clicking the English language link from sa:विकिपीडिया:विचारसभा, I am taken to the correct destination, i.e., en:Wikipedia:Village Pump. Despite all of them being connected together in the same Wikidata item. Can someone explain what's happening here, or is it happening just for me? ---CX Zoom(he/him) (let's talk|contribs) 07:29, 24 February 2022 (UTC)[reply]
See section Ukraine's Cultural Diplomacy Month: We are back in 2022! on those pages. The message writer forgot the colon, so [[en:Ministry of Foreign Affairs of Ukraine|Ministry of Foreign Affairs of Ukraine]] in ...with the [[en:Ministry of Foreign Affairs of Ukraine|Ministry of Foreign Affairs of Ukraine]] and [[en:Ukrainian Institute|Ukrainian Institute]] acts as an interwiki link (those old links used to be at the end of every pages before Wikidata was established). NguoiDungKhongDinhDanh 08:21, 24 February 2022 (UTC)[reply]
I was about to explain the above. I fixed bn:উইকিপিডিয়া:আলোচনাসভা. Johnuniq (talk) 08:24, 24 February 2022 (UTC)[reply]
@User:ValentynNefedov (WMUA): I couldn't easily find a way to contact you on-wiki so am pinging to ask that next time you include the colon. If possible, please fix the pages where the message was posted. Johnuniq (talk) 08:30, 24 February 2022 (UTC)[reply]
Thanks for notification. I have noted this problem.--ValentynNefedov (WMUA) (talk) 09:03, 24 February 2022 (UTC)[reply]

Anyone mind lending a hand? NguoiDungKhongDinhDanh 08:35, 24 February 2022 (UTC)[reply]

 Done All pages fixed except for user talk ones. Interwiki links don't work on talk pages and I really don't want to notify ~160 users about such a tiny thing. NguoiDungKhongDinhDanh 09:22, 24 February 2022 (UTC)[reply]

Your edit was saved

It's just annoying.— Vchimpanzee • talk • contributions • 20:19, 24 February 2022 (UTC)[reply]

Hi. In the past hour or so, I get a little notification in the right-hand side of the page saying "Your edit was saved", complete with a green tick. I'm using the Monobook skin in Firefox. How do I switch this off? Thanks. Lugnuts Fire Walk with Me 20:22, 24 February 2022 (UTC)[reply]
I would assume this has to do with the discussion tools? ― Blaze WolfTalkBlaze Wolf#6545 20:23, 24 February 2022 (UTC)[reply]
Nevermind, I see it applies to other edits as well. I thought there was a new update to discussion tools that added that, but no. Please shut this off. ― Blaze WolfTalkBlaze Wolf#6545 20:27, 24 February 2022 (UTC)[reply]
This has actually been a feature for some time in case you haven't seen it before, it may just be more noticeable because green. The relevant task is phab:T58313. Izno (talk) 20:39, 24 February 2022 (UTC)[reply]
I have to ask, who cares that they aren't in the exact same style as other notices? It's not really something that a lot of people would notice, and changing the text color has made it worse. ― Blaze WolfTalkBlaze Wolf#6545 20:43, 24 February 2022 (UTC)[reply]
Thanks Izno and Wolfy. Hopefully a css. hack or toggle can be done to fix it. Lugnuts Fire Walk with Me 20:48, 24 February 2022 (UTC)[reply]
That's the first time someone has called me "Wolfy" outside of Discord, but I certainly don't mind it.Blaze WolfTalkBlaze Wolf#6545 20:50, 24 February 2022 (UTC)[reply]
It's not broken. You can certainly change it with your own personal CSS, but chances are it only stands out simply because you're not used to it. There's no reason to change anything site-wide. Staying consistent with the styleguide is a good thing. MusikAnimal talk 20:56, 24 February 2022 (UTC)[reply]
You have to remember that not everyone knows how to change it with their personal CSS (including me, and i'd rather not try because I'll probably end up breaking something on my end). ― Blaze WolfTalkBlaze Wolf#6545 20:57, 24 February 2022 (UTC)[reply]
Not everyone gets to decide on any other website they use what the notifications look like either and they just get by. —TheDJ (talkcontribs) 21:13, 24 February 2022 (UTC)[reply]
My point is, after a week or even a few days, you'll likely forget all about it and it won't bother you anymore. But anyways, you could try:
.mw-notification-content .oo-ui-flaggedElement-success { color: inherit !important; }
That won't change the color of the check mark, though. You could do that with CSS filters if you really wanted to, or just hide it with:
.mw-notification-content .oo-ui-icon-check.oo-ui-image-success { display: none }
But again I think this is just adding cruft to your personal CSS for a minor detail that is only a temporary distraction. New UI changes always look weird when they're first deployed. MusikAnimal talk 21:25, 24 February 2022 (UTC)[reply]
I tried that code in my .css page, but it didn't work. To men, it's a bit of a Noddy notification. "Your edit was saved" - no shit! Lugnuts Fire Walk with Me 08:17, 25 February 2022 (UTC)[reply]
When they introduced this years ago, the user testing indicated that newcomers found it informative and reassuring. For someone like you, who's made more than a million edits, it is presumably superfluous. Whatamidoing (WMF) (talk) 18:53, 25 February 2022 (UTC)[reply]
Maybe they should add a way to disable it? ― Blaze WolfTalkBlaze Wolf#6545 19:20, 25 February 2022 (UTC)[reply]
  • <sarc>Well, at least we know if this was T58313 that the backlog of super-important-features that are certainly needed is only 9 years old.... </sarc>— xaosflux Talk 22:28, 24 February 2022 (UTC)[reply]
    I count the small ones as easy wins. Izno (talk) 23:04, 24 February 2022 (UTC)[reply]
    But that task is still marked "Open, Low". Why is it still open, if it's been done? How did this "low" priority task get done without having its priority raised? wbm1058 (talk) 23:14, 24 February 2022 (UTC)[reply]
    Well, notice that the change was first uploaded to gerrit in October 2020. A change unreviewed for nearly a year and a half might reasonably be said to be low priority. (Besides that, the magic of priority changing depending on who's looking at it on any given day.)
    As for open, probably because no one closed it. Looks like Esanders finished the change off, so it should probably be reassigned to him. Izno (talk) 23:37, 24 February 2022 (UTC)[reply]

@Vchimpanzee and Lugnuts: You're only finding this a big deal because you've already hidden the notification by .postedit { display: none; } in your CSS. To everybody else it's just a change from a centered beige notification to a right-aligned white one. There doesn't appear to be a CSS way to hide it, but you can put mw.config.set('wgPostEditConfirmationDisabled', true); in your .js to force-disable it in the meantime. Nardog (talk) 10:42, 25 February 2022 (UTC)[reply]

That's fixed the bugger. Thanks! Lugnuts Fire Walk with Me 11:03, 25 February 2022 (UTC)[reply]
Is it still possible to move the notification from right-aligned back to center-aligned? I think that the right-aligned notification is not immediately noticeable. LSGH (talk) (contributions) 16:43, 25 February 2022 (UTC)[reply]
So let's see if that worked.— Vchimpanzee • talk • contributions • 17:44, 25 February 2022 (UTC)[reply]
And it did.— Vchimpanzee • talk • contributions • 17:45, 25 February 2022 (UTC)[reply]

LintHint not working anymore

Hello, there. I added the following code to my common.css files, but after using it for 3 days, it stopped highlighting the errors on wiki pages...I cleared cache, purged, removed and re-added the code in my common.js files, but to no avail. Does anyone here know why would that be the case? Any help would be appreciated. Qwerty284651 (talk) 00:18, 25 February 2022 (UTC)[reply]

@Izno, do you think anyone at WP:CHECKWIKI might know about this? Whatamidoing (WMF) (talk) 18:54, 25 February 2022 (UTC)[reply]
Basically, CSS import is broken in MediaWiki because CSS import declarations are required to be first on a page. What happens is that all the various custom style declarations get squished into a single sheet before being served, which means that CSS import in personal CSS inevitably ends up somewhere other than the top. (I should consider submitting a task for that, but it's not exactly a priority, and tinkering with CSS can lead to other issues.)
Here are two things you can do instead: Copy-paste the relevant declarations to your own user space (perhaps with a self pointer to look to see if the source changes in the future) or load it as a JavaScript script instead with something like mw.loader.load('https://meta.wikimedia.org/w/index.php?title=User:SMcCandlish/lint.css&action=raw&bcache=1&maxage=86400&ctype=text/css', 'text/css'); in User:Qwerty284651/common.js. Izno (talk) 20:47, 25 February 2022 (UTC)[reply]
@Izno How do I use a self pointer? I am new in this. I just happened to come across LintHint, because wanted to try out repairing lint errors, to decrease the overall backlog of pages with lint errors. I even had someone help me how to save it properly in my .css page. Javascripts I have never used before. So, all that is German village to me. I tried out Template data, which is kind of similar, but I have little to no experience in the programming department. So, you suggesting me copy-paste the relevant declaration...Heck, I don't know even what that means. I wish I did, but I don't. Enough whining from my side...I just,..uhm...I got nothing...Maybe go physically into page information, lint errors on page,...and then do it manually....maybe, I don't know. I will see what I can do. Thanks for the advice, nonetheless. Much appreciated from you, technically-adept people. Cheers, Qwerty284651 (talk) 21:32, 25 February 2022 (UTC)[reply]
With the JavaScript solution, do as already suggested, just copy-paste. It is a slightly slower solution. With the CSS solution, go to and copy the rules on m:User:SMcCandlish/lint.css that aren't commented out (comments are delimited with /* comment */), then go to and paste in your common.css, then consider adding a comment like /* From [[:m:User:SMcCandlish/lint.css]] */. Izno (talk) 22:03, 25 February 2022 (UTC)[reply]
Do I copy-paste the declarations in my .js or .css? Qwerty284651 (talk) 23:11, 25 February 2022 (UTC)[reply]
For the CSS solution, the .css page. For the JavaScript solution, the .js page. Izno (talk) 23:15, 25 February 2022 (UTC)[reply]
P. S. I copy-pasted from m:User:SMcCandlish/lint.css to my User:Qwerty284651/common.css and still nothing. Qwerty284651 (talk) 23:20, 25 February 2022 (UTC)[reply]
Then something else is probably wrong. I can't help past that. Izno (talk) 23:26, 25 February 2022 (UTC)[reply]
Whom do I turn to then for help? Any suggestions? Qwerty284651 (talk) 23:39, 25 February 2022 (UTC)[reply]
@Izno My common.js is littered with many different codes and declarations. Where do I add the code exactly? Qwerty284651 (talk) 23:22, 25 February 2022 (UTC)[reply]

What may be the best phrasing for MediaWiki:Infiniteblock?

The page has only been updated twice and has been untouched in several years. This term is used for describing indefinite blocks on Special:BlockList and MediaWiki:Blockedtext and other block messages. I believe there is a wrong connotation associated with "no expiry set". While it accurately represents an indefinite block, it does not make clear that it does not mean infinite. So I am asking here.

Which phrasing looks best for the block message as well as the block list?

  • No expiry set (currently used)
  • Never (the term previously used before changed in October 2007)
  • Infinite (default message)
  • Indefinite
  • Until removed
  • Something else?

What I am exactly trying to figure out is how do we communicate to both the blocked user in the block message and other users on Special:BlockList that they are blocked, the block does not have a fixed duration, but the block can be removed on appeal? Aasim - Herrscher of Wikis 02:31, 25 February 2022 (UTC)[reply]

On the block list, the "expires" column is populated with whatever the contents of MediaWiki:Infiniteblock are, but in the block messages (MediaWiki:Blockedtext), the $6 parameter is replaced with the contents of MediaWiki:Infiniteblock whenever the blocked user tries to edit. Aasim - Herrscher of Wikis 02:33, 25 February 2022 (UTC)[reply]
  • Note this is a WP:BRD follow up from MediaWiki_talk:Infiniteblock. I think this is fine the way it is, (second choice: use system default, third choice use 'indefinite') see it in use on Special:BlockList as the 'time' value when the block is indefinite. That it is possible to be changed doesn't mean it isn't still a time unit. — xaosflux Talk 10:15, 25 February 2022 (UTC)[reply]

recent HTML changes in contributions/history pages, etc. causing disruption for screen readers

Just a heads-up: the HTML changes mentioned in the last tech news to the history and contributions pages, which added headers for dates for the mobile skin which are hidden on desktop devices, have caused disruption to my workflow as a screen reader user, since what used to be a list of, say, 50 items in a page history is now several smaller lists. When I was checking page history at Wikidata for this section, I was extremely confused by the history display, but now I understand what's going on. I think I might add the CSS mentioned in the Phabricator ticket to my user CSS page to make things a bit more usable for now. In the task, there is talk of maybe adding the date headers to the desktop history/contributions page, etc., which I'm not sure about at all. I've already commented in the task itself but I thought it was worth giving a heads-up here too. Graham87 02:32, 25 February 2022 (UTC)[reply]

Hmmm, the line I just added to the end of User:Graham87/monobook.css doesn't seem to have any effect ... did I add it incorrectly? Graham87 02:43, 25 February 2022 (UTC)[reply]
@Graham87: I've adjusted it. In general, you probably don't need the !important, and in this case you don't. If you really wanted it, the correct CSS for important would have been something like .mw-index-pager-list-header { display: block !important; }. --Izno (talk) 03:31, 25 February 2022 (UTC)[reply]
@Izno: Thanks, that works. Graham87 04:52, 25 February 2022 (UTC)[reply]
@Graham87 Thank you for commenting.
I've proposed patches for the issues you noted, that is:
  • Reveal the headers to screen-readers to make it more clear that there are multiple lists
  • Group the edits by date in the user's timezone
  • Add a <section> wrappers around the lists to make it easier to jump to the end (at least, I hope this helps, I'm only an amateur screen reader user – if it doesn't, then we should think about other approaches)
If you have a moment, you can try these fixes out on a demo wiki I just created. I imported the recent history of the page "Kenneth and Mamie Clark" here: https://patchdemo.wmflabs.org/wikis/962b298fe3/w/index.php?title=Kenneth_and_Mamie_Clark&action=history
Please also say if anything else should be changed. I'll make sure that next week, either those changes are deployed (if you confirm that they are helpful), or that the original change is reverted and I'll ask the team to consider other options.
(I'm posting the reply both here and on Phabricator, because I'm not sure where you prefer to discuss… Let me know and let's discuss there.) Matma Rex talk 13:32, 25 February 2022 (UTC)[reply]
@Matma Rex: Thanks very much. I'm OK with using either this village pump page or Phabricator, but since Phabricator is where the MediaWiki work is done, I've commented there. Graham87 14:30, 25 February 2022 (UTC)[reply]

Solution found for banner ads

My original thread is archived, but I thought ppl might appreciate an answer. I asked at MediaWiki, and they said,

put the following in meta:Special:mypage/global.css:
#centralNotice { display:none !important}

I tried this, and so far it seems to have taken care of the majority of the problem. I'm still getting local banner ads for Covid and the like, but that code appears to have stopped the same ad from reappearing hundreds of times after it's dismissed. — kwami (talk) 07:21, 25 February 2022 (UTC)[reply]

@Kwamikagami first, these are not "banner ads", they seem like "notices". If you are actually getting advertisements, it isn't coming from us. As far as not wanting to see central notices, a much better option for most users is to opt-out of them at Special:Preferences#mw-prefsection-centralnotice-banners instead of mucking around with CSS in this way, which may make you miss very important banners. A "better" solution for doing this "globally" is likely in phab:T302585.xaosflux Talk 13:49, 25 February 2022 (UTC)[reply]
For global settings, Special:GlobalPreferences#mw-prefsection-centralnotice-banners can be configured as well. — xaosflux Talk 17:13, 25 February 2022 (UTC)[reply]
@Xaosflux: They're all internal from WP. You might call them "notices", but they're still ads.
I'd tried both those options, with everything deselected. Neither worked. Both let hundreds of "important" notices through. If I had to guess, it's that nearly everyone who posts a notice thinks that their notice is "important". So many "important" notices get through that I can't even see the article without scrolling down, and that's on a full screen. If the WP notice ppl were responsible with their oversight, I wouldn't need to block everything in order to block the flood of garbage.
It didn't use to be this way. Until recently, the ads were a minor annoyance. They didn't interfere with browsing or editing WP. — kwami (talk) 19:49, 25 February 2022 (UTC)[reply]
You can see all the current notices at meta:Special:CentralNotice, all of the enabled banners are set to types that you can disable. If you properly disable all the banners, you should not be seeing any. You are free to use the CSS, but you may miss actual important notices, e.g. site maintenance, or you may want certain types e.g. governance so you don't miss elections for example. Dylsss(talk contribs) 02:55, 26 February 2022 (UTC)[reply]

How can Template:Graph:Map be expanded to show more areas e.g states, regions etc?

Hi all

Village pump
Scientific classification Edit this classification
Kingdom: Plantae
Clade: Tracheophytes
Clade: Angiosperms
Clade: Monocots
Order: Asparagales
Family: Asparagaceae
Subfamily: Asparagoideae
Genus: Asparagus
Species:
A. stipularis
Binomial name
Asparagus stipularis
L.
Synonyms

Asparagus horridus

I'm working on improving species articles and would really like to include more distribution maps (where the species lives). Alicia at Wikimedia Sweden has kindly helped me put together an example of how this could possibly work using Template:Graph:Map and data from Plants of the World Online to find issues etc. The main issue with using this is that you can only show countries, islands, areas of countries etc cannot be listed so the data cannot be described correctly. For example this plant is native to Sicily but not the rest of Italy.

Does anyone know how this issue could be fixed? Is there some way of importing a database of areas in each country, islands etc into the database that Template:Graph:Map uses? Or is there something else that could be used that wouldn't rely on hand making SVG maps on Commons for each species?

There are also some smaller issues

  • The map should have the option to zoom in on the area where the species are present, not only a world view (if the species is only present in a small area it won't show up on a world map. Is there a fix for this?
  • Would it be possible to use the Wikidata IDs to pull up the location data? This would be extremely helpful for importing data from external sources.

Thanks very much

John Cummings (talk) 08:44, 25 February 2022 (UTC)[reply]

@John Cummings, there is a basemap parameter that lets you change the map used. The default map is the world map Template:Graph:Map/Inner/Worldmap2c-json specified in TopoJSON, and is limited to countries. You might ask about creating other maps at Wikipedia:Graphics Lab/Map workshop. StarryGrandma (talk) 20:39, 25 February 2022 (UTC)[reply]

Hi there. At List of years in Philippine television, several of the years listed in the 1970s redirect back to the article. Also, I don't think it's necessary to list all the red-linked years up to 2029. I tried to edit the article, but it uses templates such as "years in decade|1970|Philippine television".

What led me to that article was the template "Year nav topic5|2022|Philippine television", at 2022 in Philippine television. It's really unsightly to have all those redliked articles in the template.

Template:Year nav topic doesn't have a way to omit specific years. When I tried to manually edit both the list, and the template, the result looked awful. Any help would be appreciate. Thanks. Magnolia677 (talk) 11:08, 25 February 2022 (UTC)[reply]

Synchronizing pages

Hello! Is there any way without utilizing bots to keep pages from different projects synchronized?

The CS1 module suite is made up of 10 module pages. Those 10 pages are identic for SqWiki and SqQuote. Every time I update SqWiki's modules I need to copy-paste (x10) everything to SqQuote. Anyway to have that procedure happen automatically? - Klein Muçi (talk) 02:38, 26 February 2022 (UTC)[reply]