Wikipedia:Village pump (technical)

Village pump
Scientific 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.
	Graphs are unavailable due to technical issues. There is more info on Phabricator and on MediaWiki.org.
Synonyms
	Asparagus horridus

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.

view · edit

Frequently asked questions (see also: Wikipedia:FAQ/Technical)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

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

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]

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 Wolf^Talk_{Blaze 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 Wolf^Talk_{Blaze 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]

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:

Special:ListUsers/oversight will now link to a subset of the list of all users, starting with User:Oversight.
{{NUMBERINGROUP:oversight}} is now 0
Any tools or scripts explicitly looking for an "oversighter" group (e.g. User:Chlod/Scripts/UserHighlighter and User:Pythoncoder/Scripts/userHighlighter ) will no longer find it.

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

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 Wolf^Talk_{Blaze 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 Wolf^Talk_{Blaze Wolf#6545} 15:59, 23 February 2022 (UTC)[reply]

Tracked in github.com
Issue #2

@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 (u • t • c) 15:04, 25 February 2022 (UTC)[reply]

Also, nbd, but your ping didn't work, not sure why ~ Amory (u • t • c) 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 (u • t • c) 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 (u • t • c) 15:04, 25 February 2022 (UTC)[reply]

For the scripts: this search query should find all occurrences of "oversight" on a .js page in the user or mediawiki namespace. Note that most of this is false positives caused by either oversight in a display string (which is fine, since its still the actual name of the group) or config options. -- Asartea ^Talk ^| ^Contribs 13:17, 26 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]

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 Wolf^Talk_{Blaze 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 Wolf^Talk_{Blaze 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 Wolf^Talk_{Blaze 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 Wolf^Talk_{Blaze 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 Wolf^Talk_{Blaze 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 Wolf^Talk_{Blaze 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 Wolf^Talk_{Blaze 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 (talk • contribs) 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 Wolf^Talk_{Blaze Wolf#6545} 19:20, 25 February 2022 (UTC)[reply]

Not really – see mw:Just make it a user preference. – SD0001 (talk) 06:46, 26 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]

For me as well, although the top of my .js page says "Cannot install" (next to "Manage user scripts"). Miniapolis 20:56, 26 February 2022 (UTC)[reply]

Okay, what's a .js, and how do I edit it? Clarityfiend (talk) 06:47, 26 February 2022 (UTC)[reply]

@Clarityfiend: Special:Edit/Special:Mypage/common.js ― Qwerfjkl talk 07:40, 26 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]

I seem to remember being able to disable this in preferences; it is distracting, and I feel like I have to wait for the damn thing to go away before moving on. Miniapolis 20:45, 26 February 2022 (UTC)[reply]

the sky is blue

Hi, how do I disable this wonderful and extremely useful new "feature" that demands my attention at the top right hand of my screen to let me know that I've made an edit when I've made an edit? Thank you. Dr. Vogel (talk) 17:28, 26 February 2022 (UTC)[reply]

See § Your edit was saved. ― Qwerfjkl talk 17:32, 26 February 2022 (UTC)[reply]

It looks like you're editing a page. Would you like an unhelpful interruption? Certes (talk) 21:07, 26 February 2022 (UTC)[reply]

I wonder how many people here are old enough to remember the debut of the infamous "clippy", and the wave of interface "enhancements" that ensued. Dr. Vogel (talk) 03:51, 27 February 2022 (UTC)[reply]

I've followed the instructions kindly provided by the people above, and I seem to have got rid of it. Luckily it worked first time, and I didn't have to spend the next hour trying to get the solution to work. It feel like it's a lot of hassle just to get rid of this pointless thing. Dr. Vogel (talk) 04:10, 27 February 2022 (UTC)[reply]

I don't see why people are acting all surprised. This allegedly-new feature has been there for at least seven years - all that has happened is that it's been repositioned from top centre to top right; less noticeable is the change of text colour (black to dark green) ~~and (I think) the slight rewording from "Your edit has been saved" to "Your edit was saved"~~. For me, all this makes it less obtrusive than it previously was. --Redrose64 🌹 (talk) 08:23, 27 February 2022 (UTC)[reply]

The difference is that the older design was easily hidden with css. The update requires a js solution and to those people who had hidden the population using css (and possibly forgotten that they had hidden it) it looks like a new festure. Nthep (talk) 14:04, 27 February 2022 (UTC)[reply]

I've traced it back more than nine years, see Wikipedia:Village pump (technical)/Archive 105#Small new feature coming on Thursday. --Redrose64 🌹 (talk) 22:10, 27 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

Tracked in Phabricator
Task T298638

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]

If it's so difficult to properly disable the banners that I still haven't figured out how to do it, then I wonder how accessible that option is for most people. — kwami (talk) 21:21, 28 February 2022 (UTC)[reply]

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

Hi all

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]

List of years in Philippine television

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]

Not yet. But what you want is basically covered by phab:T121470. – Ammarpad (talk) 06:27, 26 February 2022 (UTC)[reply]

@Ammarpad, eh, if that does happen in this decade. :P - Klein Muçi (talk) 09:57, 26 February 2022 (UTC)[reply]

Wasn't there a bot, a community could grant admin and setup to do these copies automatically for them ? Maybe User:MusikAnimal remembers. —TheDJ (talk • contribs) 09:17, 28 February 2022 (UTC)[reply]

According to phab:T121470#5106106 Yurik made a bot, though Klein will probably need to ask him since the page pointed to in that comment does not obvious contain a comment on the point. Izno (talk) 17:42, 28 February 2022 (UTC)[reply]

@Yurik, any help? :P - Klein Muçi (talk) 00:45, 1 March 2022 (UTC)[reply]

Redirect + red link

We want blue links than green redirects and I think we want keep redirects but I think there is a need for red links too. For exaple in template Interlanguage link if there is no article but there is a redirect - redirect will be shown instead of red link and you also can't add "internal link" ([[Article#Header|Article]]) to is to it's blue instead of green. Eurohunter (talk) 09:17, 26 February 2022 (UTC)[reply]

Eurohunter, if you don't get any other reply besides mine, it's because, once again, it is impossible to discern what you are talking about. Can you get a friend to help you with the English (and adding some context)? Then maybe can somebody can help you with whatever your technical issue is. — JohnFromPinckney (talk / edits) 10:00, 26 February 2022 (UTC)[reply]

I am also confused but I think this may be about templates such as {{ill|Tatsuyuki Maeda|fr}} (displayed as Tatsuyuki Maeda [fr]) linking only to the redirect when there is a whole article about the person on frwp. The non-English links are removed when an enwp article appears; |preserve= and |display= can be used to prevent this. Further details are in Template:Interlanguage link/doc. I don't fully understand the bit about sections but Template:Further ill may be useful. Certes (talk) 13:53, 26 February 2022 (UTC)[reply]

@JohnFromPinckney: @Certes: In short it would be that you can't add [[Article#Header|Article]] or red link to template Interlanguage link? I want to have Tatsuyuki Maeda (red link here instead of redirection) [fr]). Eurohunter (talk) 14:31, 26 February 2022 (UTC)[reply]

The template won't produce a redlink if enwiki has a page with that title, even if the page is a redirect. I don't think we'd want to: readers are used to red meaning "no page". {{ill|Tatsuyuki Maeda#Software research and development|fr}} links to a section (of Sega) on enwp: Tatsuyuki Maeda#Software research and development [fr]. {{ill|Tatsuyuki Maeda|fr|Tatsuyuki Maeda#Ludographie}} links to a section on frwp: Tatsuyuki Maeda [fr]. The two can be combined to link to sections in both languages. Certes (talk) 18:25, 26 February 2022 (UTC)[reply]

@Certes: So how to link to section without result in redirect? Eurohunter (talk) 19:44, 26 February 2022 (UTC)[reply]

What do you want instead of the redirect? If you want a direct link to the article, {{ill|Sega#Software research and development|fr|lt=Tatsuyuki Maeda}} looks right (Tatsuyuki Maeda) but will not update if someone creates a biography. If you want a redlink, that option is not available, because we do not confuse readers by displaying redlinks for pages which exist. Certes (talk) 19:54, 26 February 2022 (UTC)[reply]

Response of visual elements on using Dark mode (gadget)

Hi, I want to raise some issues caused with visual elements when WP:Dark mode (gadget) is used.

First of all, .svg rendering. There are at least 4 different manners in which .svgs behave on using dark mode.
For the first two manners, I wish to invite you to visit my userpage. If you look at all those userboxes, you'll find that all of those .svgs have a transparent background. Yet only two of them respond when the userbox background colors change as a result of using dark mode: the "This user has been on Wikipedia for..." and "WikiProject Redirect" ones. All rest .svgs for some reason switch to a simple white background, for example the "Bengali is the mother tongue..." userbox.

Now, let's go to Chennai Super Kings, there's an image for the team's T20 kit in infobox, instead of the .svg background responding to dark mode, the actual jersey colors do, which makes it "factually incorrect".

For the 4th behaviour, let's go to 2020 New Zealand general election#Background. On using dark mode on desktop, the background of parliamentary makeup .svg is white, on mobile however it would switch to black instead. All other .svgs on the same page would not respond to dark mode & remain white irrespective of desktop/mode site.

What I don't understand here is why they all behave differently and not in the same one way or another?
Secondly, the issue with visual elements used to portray information. See the infobox at 2019 United Kingdom general election, dark mode causes SNP's party colors to switch from yellow to black. Similarly, Harvard University's university color in infobox looks less crimson and more like light pink. And then there is this Shades of pink article, whose whole world is turned on its head by dark mode. There must be a way for such usage of colors to escape from being modified when dark mode is used.

Thank you for bearing with me through this section. I hope y'all will be able to find solutions to the above-mentioned problems. Thanks! ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 10:26, 27 February 2022 (UTC)[reply]

The white background is because many SVGs have hardcoded black text, they are forced to have a white background for that reason
The non-white background on some SVGs, is because these svgs are not linked to their description page. The rule for #1 did not take this scenario into account.
"factually incorrect colors". Yes, the gadget uses two filters and this causes information loss, making it impossible to invert back to the original colours. Especially in the yellow spectrum this is very visible.
"the background of parliamentary makeup .svg" its a png, not an svg. It shows the default background of any thumb image (white).
"visual elements used to portray information" yes. See #3.

The dark gadget does a double application of filters, causing loss of color information. This double hue offset can be removed, but then the darkgadget will basically use a yellow/orange style, which many ppl might also not prefer. The only way to deal with ALL problems is to make a complete CSS dark theme AND maintain that. The dark gadget is only a 'quick-fix' that basically works most of the time, by making a few shortcuts. Shortcuts tend to have problems that people will complain about. This is exactly why the Wikimedia foundation didn't bring this mode to production when they experimented with it, but turned it over to the community who made this gadget out of it. —TheDJ (talk • contribs) 09:14, 28 February 2022 (UTC)[reply]

I wasn't able to see black-colored logos, like File:Epic Records 1970s.png and File:Threes-company black logo.svg, in file pages in dark mode. At least I can barely see the logo in the "File history" log and can fully see the image-only page, which is using white background. George Ho (talk) 05:58, 1 March 2022 (UTC)[reply]

Those should be things that we can easily fix. thx for pointing them out. —TheDJ (talk • contribs) 15:49, 1 March 2022 (UTC)[reply]

Make working with templates easier: Several improvements coming to your wiki soon.

Hello! A few months ago, English Wikipedia received these improvements from the Templates project by Wikimedia Deutschland’s Technical Wishes team:

A new attribute “suggested values” was introduced to help you clarify what values a parameter may expect. (1)
When using syntax highlighting (CodeMirror extension), line numbers are shown in the template namespace. (2)
A few wikis have these line numbers activated in all namespaces. If you want this for your wiki as well, please reach out to us.

More improvements from the Templates project are coming to English Wikipedia soon:

Finding and inserting templates will become easier with an improved search and added warnings (in the TemplateWizard & in the template dialog of VisualEditor and New Wikitext mode). (3)
In VisualEditor, you’ll be able to remove a template from a page via the context menu, just like removing a table or an image. (4)
Also in VisualEditor, the template dialog will become bigger and descriptions will be more visible. (5)
Matching brackets will be highlighted (when you use syntax highlighting). (6)
The color scheme in syntax highlighting will be updated for better readability. (7)

These improvements have been tested on a few wikis for some months now, and will be deployed to all wikis except English Wikipedia on March 9. Assuming no severe issues emerge during this deployment, we’ll deploy this set of changes to English Wikipedia on March 16, 2022. We’d love to hear what you think of these changes on the talk pages of the project pages linked above ([1] - [7]).

A few weeks later, we’re also going to deploy the last round of improvements from our Templates focus area:

A colorblind-friendly color scheme will be added in syntax highlighting (CodeMirror extension). You’ll be able to activate it via a user setting.
A range of fundamental changes to the VisualEditor template dialog will be deployed. They will make it easier to understand what is expected from a template, to navigate the template dialog, and to add parameters to a template.

– Greetings from the Technical Wishes project, Johanna Strodt (WMDE) (talk) 13:03, 28 February 2022 (UTC)[reply]

"Matching brackets will be highlighted (when you use syntax highlighting)" This sounds like it'll be really helpful when using a bunch of nested templates. Not so much when just using a single template but still helpful. How do I know if I have syntax highlighting enabled? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:04, 28 February 2022 (UTC)[reply]

There are several features at Wikipedia:Syntax highlighting#Syntax highlighting of wiki-code for editors. This is about the first, on a highlighter marker button

, to the left of "Advanced" in some toolbars. It has been deployed at de:, for example de:Wikipedia:Sandbox. When the cursor is at a bracket, the matching bracket is highlighted. PrimeHunter (talk) 16:21, 28 February 2022 (UTC)[reply]

I've started a discussion about these changes at meta:User talk:Johanna Strodt (WMDE)#Template changes - Tags autocompletion. If anyone is interested to join. :) - Klein Muçi (talk) 11:25, 1 March 2022 (UTC)[reply]

Page sections links

When I'm at the top of a page, I can look at the TOC, click a certain section and I will be sent to it while the URL reflects that.

When I'm scrolling down to a certain section, the URL will not change. Any way I can get the section link without having to scroll back to the TOC or adding it manually? I'd hope for a functionality that allows for double-clicking the section's title or right-clicking it or anything similar and it automatically gave you the URL for it. Maybe you can also choose between getting the URL or a permanent link (or a [inter-]wikilink). I have to link to different discussions in and out of EnWiki often and having an easy way to link to certain sections, while looking at the said sections, often in the permanent way (discussions get archived rather quickly and the permanent link is deemed more desirable in some cases) would be greatly appreciated. I'm guessing something similar would be appreciated even with articles' sections (but there [inter-]wikilinks can be more desirable).

Any gadgets? User scripts? A Phab request to a new feature? - Klein Muçi (talk) 17:30, 28 February 2022 (UTC)[reply]

Desktop Improvements will bring a lot of features to the table of contents in the new Vector-2022 skin. I'm not sure if changing the URL as you scroll is something they're considering, but you could suggest it on the talk page.

An existing script (that works in all skins) that might help you User:The Earwig/permalink.js. Next to each section heading you'll see buttons to copy the URL to the clipboard, as well as a permanent link. The task to bring this functionality into MediaWiki is at phab:T18691. — MusikAnimal ^talk 17:44, 28 February 2022 (UTC)[reply]

@MusikAnimal, thank you very much for the insight provided! The script's description looks exactly what I'm looking for. I'd only wish that if it would become a native MediaWiki functionality, it would also allow for wikilinks and interwikilinks beside URLs and permanent links. - Klein Muçi (talk) 00:50, 1 March 2022 (UTC)[reply]

@MusikAnimal, am I doing something wrong here? - Klein Muçi (talk) 01:34, 1 March 2022 (UTC)[reply]

@Klein Muçi Yes, you have a /load.js in there where it shouldn't be for The Earwig's script. Removing that should make it work. — MusikAnimal ^talk 03:04, 1 March 2022 (UTC)[reply]

@MusikAnimal, thank you! It works now. :)) - Klein Muçi (talk) 09:47, 1 March 2022 (UTC)[reply]

I don't know of any websites where the content of the URL bar changes as you scroll up or down, it only changes when links are followed (or moved back from). But regarding a means for obtaining the URL for a section, some websites do indeed do this - the W3C's own website does it on many pages, see for example CSS Cascading and Inheritance Level 3, where most section headings (from 1. Introduction on) are preceded by a § section sign - clicking this alters the URL in the browser's address bar - or you can right-click it and select "Copy link". --Redrose64 🌹 (talk) 23:20, 28 February 2022 (UTC)[reply]

There are many SPA-type websites where the URL changes as you scroll. Izno (talk) 23:29, 28 February 2022 (UTC)[reply]

@Redrose64, to be honest, I wasn't expecting the URL to change as I scroll down (although that doesn't look like a bad idea). I was just hoping for a kind of interaction with the section heading that would bring me the links for it (having a share button would be the easiest way). The example you brought was a good one and it was elegant too. - Klein Muçi (talk) 00:56, 1 March 2022 (UTC)[reply]

Reply tool next Monday

Just in case anyone missed the 8,000-word-long thread at Wikipedia:Village pump (proposals)#Offering the Reply Tool as an opt-out feature over the last 25 days, the WP:REPLYTOOL should be enabled by default by this time next week. Usual caveats and schedule restrictions apply.

As you are probably tired of hearing me say, anyone who doesn't like it need only go to Special:Preferences#mw-prefsection-editing-discussion and turn it back off. No complicated gadgets or user scripts are needed to make it disappear.

However, if someone wants to make it stop saying [reply] and instead say something else (e.g., to shorten it to r or an emoji), then see the script in Wikipedia:Village pump (miscellaneous)/Archive 68#Radical changes from last November. Whatamidoing (WMF) (talk) 20:37, 28 February 2022 (UTC)[reply]

As was also posted, including on watch list notice: Last chance (we're already in an extended Alpha->Beta->Gamma tranche of opt-in testing) to report any show-stopping bugs to Wikipedia talk:Talk pages project. — xaosflux ^Talk 21:24, 28 February 2022 (UTC)[reply]

small caps inconsistent with Greek

I needed a small-cap delta for a non-Unicode character. But the small-cap template had no effect. I am told there that how the letters display depends on my browser. Could something be done to ensure that small caps display correctly?

On my browser (Firefox), the following basic Greek letters display as small caps:

εζηικνξοςτυψϝ

and these do not:

αβγδθλμπρσφχω

That's true whether or not I log in.

However, in the Falkon browser, all are correctly small-cap.

Is this a bug that needs to be fixed at Firefox?

Please ping me if you respond. Thanks. — kwami (talk) 21:22, 28 February 2022 (UTC)[reply]

@Kwamikagami: You posted exactly the same question a few minutes earlier at MediaWiki talk:Common.css#small caps inconsistent with Greek. Please observe WP:MULTI. --Redrose64 🌹 (talk) 23:43, 28 February 2022 (UTC)[reply]

I didn't know whether I should ask at WP-en or at MediaWiki. It looks like it's being adequately addressed there. — kwami (talk) 23:59, 28 February 2022 (UTC)[reply]

If you want to continue the discussion, I think you should move it here. It's technical question but seems unconnected to Common.css. Certes (talk) 12:13, 1 March 2022 (UTC)[reply]

If I revert and then realize I reverted incorrectly, does the person still get notified?

Something weird was happening and I couldn't advance to "next edit" on Talk:Hello (Adele song) so I thought the vandalism (or unconstructive edit) was still there. I couldn't undo so I went back to the last good version before the person's bad edits. Somehow I discovered what I was reverting had already been reverted, and I had actually reverted something constructive.

I checked the history again. The reason it wasn't working to move forward was the same unconstructive edit was done three different times, which made me think I wasn't moving forward.— Vchimpanzee • talk • contributions • 22:49, 28 February 2022 (UTC)[reply]

Yes, they are still notified. Izno (talk) 23:32, 28 February 2022 (UTC)[reply]

And the edit was neither vandalism nor unconstructive; the article was in fact stating that the video achieved a milestone "As of October 2022" which I have corrected.--John Cline (talk) 00:14, 1 March 2022 (UTC)[reply]

Yes, I know. Because of the peculiar way the unconstructive edits were added, I thought I was seeing the current version with the unconstructive edits still there. That's why my only option seemed to be to go back to the last good version.— Vchimpanzee • talk • contributions • 22:50, 1 March 2022 (UTC)[reply]

Tech News: 2022-09

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

Recent changes

When searching for edits by change tags, e.g. in page history or user contributions, there is now a dropdown list of possible tags. This was a request in the 2022 Community Wishlist Survey. [2]
Mentors using the Growth Mentor dashboard will now see newcomers assigned to them who have made at least one edit, up to 200 edits. Previously, all newcomers assigned to the mentor were visible on the dashboard, even ones without any edit or ones who made hundred of edits. Mentors can still change these values using the filters on their dashboard. Also, the last choice of filters will now be saved. [3][4]
The user group oversight was renamed suppress. This is for technical reasons. You may need to update any local references to the old name, e.g. gadgets, links to Special:Listusers, or uses of NUMBERINGROUP.

Problems

The recent change to the HTML of tracking changes pages caused some problems for screenreaders. This is being fixed. [5]

Changes later this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 1 March. It will be on non-Wikipedia wikis and some Wikipedias from 2 March. It will be on all wikis from 3 March (calendar).

Future changes

Working with templates will become easier. Several improvements are planned for March 9 on most wikis and on March 16 on English Wikipedia. The improvements include: Bracket matching, syntax highlighting colors, finding and inserting templates, and related visual editor features.
If you are a template developer or an interface administrator, and you are intentionally overriding or using the default CSS styles of user feedback boxes (the classes: successbox, messagebox, errorbox, warningbox), please note that these classes and associated CSS will soon be removed from MediaWiki core. This is to prevent problems when the same class-names are also used on a wiki. Please let us know by commenting at phab:T300314 if you think you might be affected.

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

22:58, 28 February 2022 (UTC)

WantedFiles - link cleanup

If someone creates a link to a file that doesn't exist, it shows up at Special:WantedFiles, no? Is there any fast way to cleanup articles that have links to files in them that don't exist? - Klein Muçi (talk) 11:20, 1 March 2022 (UTC)[reply]

Use the category specified in MediaWiki:Broken-file-category. English Wikipedia has split it into several categories, Category:Articles with missing files, Category:Pages with missing files and Category:Templates with missing files. The category(ies) are autopopulated by mediawiki. The special page on the other hand is cluttered with commons.wikimedia links.--Snævar (talk) 12:00, 1 March 2022 (UTC)[reply]

@Snævar, thank you. I was wondering what those striked through entries actually were. Is there any automatic tool I can use for quickly removing those links from the articles though? Any AWB command or a bot related to that job? - Klein Muçi (talk) 12:03, 1 March 2022 (UTC)[reply]

Send Mass Message

Tracked in Phabricator
Task T302840

Hello, is there a problem with the Send Mass Message function? The page Special:MassMessage has gained some none English text and attempting to send a message results in no pages being sent. Keith D (talk) 19:09, 1 March 2022 (UTC)[reply]

@Keith D: as far as the non-english text, I'm going to 99% guess you have a deprecated interface language set, such as en-gb, and that there is something broken on that upstream, or at translatewiki. Try changing your interface language to "English". I'll check the sending part. — xaosflux ^Talk 19:29, 1 March 2022 (UTC)[reply]

Works for me I was able to send an MMS just now. Please try again, if it is failing still please let us know the exact steps you are doing. — xaosflux ^Talk 19:32, 1 March 2022 (UTC)[reply]

Special:MassMessage is English for me but https://en.wikipedia.org/wiki/Special:MassMessage?uselang=en-gb is not so I guess you have selected "en-gb - British English" at Special:Preferences. Somebody used the wrong language somewhere. If you report interface issues then please always say if you don't have the recommended default "en - English". See also Help:Preferences#Internationalisation. PrimeHunter (talk) 19:36, 1 March 2022 (UTC)[reply]

I have created phab:T302840 about the non-English messages. PrimeHunter (talk) 21:26, 1 March 2022 (UTC)[reply]

Yes switching to English does remove the non-English text, I also tried sending again and it worked OK. Must be some sort of glitch. Many thanks for the help. Keith D (talk) 23:05, 1 March 2022 (UTC)[reply]

Can you recommend anybody who likes to do user boxes?

I realize there are how-to-pages and templates for the DYI of user boxes, but I'm not particularly good with visual design — many others have more innate ability with that.

Can you recommend anyone who likes to create user boxes?

I can contribute my part, because I have an idea that I can describe in sufficient detail. Thanks.Joel Russ (talk) 19:39, 1 March 2022 (UTC)[reply]

@Joel Russ see Wikipedia:WikiProject Userboxes, and its talk page. — xaosflux ^Talk 19:45, 1 March 2022 (UTC)[reply]

Advice about disambiguation links appears on screen

Tracked in Phabricator
Task T285508

It's nice but annoying. I have the ability to see disambiguation links in orange after I finish. At the very least I want that box to go away when I click.— Vchimpanzee • talk • contributions • 22:52, 1 March 2022 (UTC)[reply]

@Vchimpanzee: seems like this is a feature, not a bug. I asked about a way to disable it at meta:Talk:Community_Wishlist_Survey_2021/Warn_when_linking_to_disambiguation_pages. @MusikAnimal: mentioned that work to have these use a class that you could then hide may be happening, but I don't see a task for that? MA - should we open a feature request? — xaosflux ^Talk 23:58, 1 March 2022 (UTC)[reply]