Commons:Village pump/Technical/Archive/2026/03
| This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Puzzling category placement of a video file
Does, other than me, somebody see why this video file is placed into category Pages using duplicate arguments in template calls (with an according error message)? If there is no valid reason, how to fix this? — Speravir – 03:16, 1 March 2026 (UTC)
- Looks like a problem with {{Media of the day}} Bawolff (talk) 03:23, 1 March 2026 (UTC)
- Aah, yes, this was the last added template, and afterwards the error message appeared. I forgot to mention this. — Speravir – 03:27, 1 March 2026 (UTC)
- Fixed https://commons.wikimedia.org/w/index.php?title=Template:Motd/2026-04-28_(de)&diff=prev&oldid=1173830105 Bawolff (talk) 03:33, 1 March 2026 (UTC)
- Aaargh!
Thank you. — Speravir – 03:38, 1 March 2026 (UTC)
- Aaargh!
- Fixed https://commons.wikimedia.org/w/index.php?title=Template:Motd/2026-04-28_(de)&diff=prev&oldid=1173830105 Bawolff (talk) 03:33, 1 March 2026 (UTC)
- Aah, yes, this was the last added template, and afterwards the error message appeared. I forgot to mention this. — Speravir – 03:27, 1 March 2026 (UTC)
- This section was archived on a request by: --Speravir 03:38, 1 March 2026 (UTC)
Quarry querry for total size in bytes for specific file names
Hi, I have this query. How do I modify this so that the query only counts files within a category that have the string “ABCD” in their name? Thank you :) --PantheraLeo1359531 😺 (talk) 13:48, 3 March 2026 (UTC)
AND p.page_title LIKE '%ABCD%'should do the trick. — Alien 3
3 3 17:47, 3 March 2026 (UTC)- Perfect, thank you, that's it :D --PantheraLeo1359531 😺 (talk) 10:46, 4 March 2026 (UTC)
Massrename & Global replace glitch
I have User:Perhelion/massrename.js in my common.js. I'm no longer seeing the choice when I'm in a category. Pretty sure I've used it within the last week, so this is new. Using Vector (2022) on a PC with Firefox, if that matters. Any clues would be appreciated. - Jmabel ! talk 18:33, 5 March 2026 (UTC)
- @Jmabel, due to an earlier incident affecting multiple wikis, all site and user javascripts are temporarily disabled. Thanks. Tvpuppy (talk) 18:36, 5 March 2026 (UTC)
- @Tvpuppy: Thank you! And I wondered why "Global replace" was no longer in my list. This must be the reason. Best regards, זיו「Ziv」 • For love letters and other notes 22:04, 5 March 2026 (UTC)
- You can follow phab:T419154 for the scripts in particular. —Justin (koavf)❤T☮C☺M☯ 23:34, 5 March 2026 (UTC)
- @Tvpuppy: Thank you! And I wondered why "Global replace" was no longer in my list. This must be the reason. Best regards, זיו「Ziv」 • For love letters and other notes 22:04, 5 March 2026 (UTC)
Info, see announcement by WMF, it appears all site and user javascripts have now been re-enabled. Thanks. Tvpuppy (talk) 01:17, 6 March 2026 (UTC)
Upload from Flickr not working
I am unable to upload my Flickr photos using the Upload Wizard. No errors, just does nothing upon entering link and clicking the button. I am guessing this has to do with the incident from earlier today? Hope it works again soon, Flickr2Commons also doesn't work, as usual. PascalHD (talk) 05:12, 6 March 2026 (UTC)
Comment, see related discussion at Commons:Help desk#Commons Upload Wizard is broken. Thanks. Tvpuppy (talk) 15:38, 6 March 2026 (UTC)
- (I noted this there as well; but for the record, but I've filed phab:T419263 about this.) —a smart kitten[meow] 16:40, 6 March 2026 (UTC)
- This should work now. Nemoralis (talk) 10:49, 7 March 2026 (UTC)
- Mostly I believe it now does, yeah — as far as I'm aware, there's now just an issue with some image thumbnails not being displayed when UploadWizard is given the link to a Flickr album (as opposed to a single file). Best, —a smart kitten[meow] 19:45, 7 March 2026 (UTC)
Can't update map data
I'm trying to update Data:Wikivoyage/Hyderabad.map to improve the coverage of the Wikivoyage article on voy:Hyderabad. However, when I try to update it, it says, "The text you have submitted is 2,238.514 kilobytes long, which is more than the maximum of 2,048 kilobytes." The main changes I wanted to do are:
- To merge Southern Suburbs with South, and
- To expand North, West, and East to cover the entire metropolitan region.
And it's strange to find that there's a 2048 kB limit on updates. So, how to divide my update into chunks? Sbb1413 (he) (talk • contribs • uploads) 06:08, 17 March 2026 (UTC)
- Well, I overcome this by uploading South Hyderabad separately as Data:Wikivoyage/Hyderabad/South.map, which is the biggest of the geoshapes in my original GeoJSON file. Sbb1413 (he) (talk • contribs • uploads) 06:34, 17 March 2026 (UTC)
librsvg does not support fallback font set (more than one font family)
See Phab:T64986: "librsvg does not support fallback font set (more than one font family)"
"I believe after purging SVGs are now obeying the font list. Not closing until this is confirmed"
That was from June 6, 2024! Has anybody confirmed this yet?
I guess you would need to upload an SVG file with sections using different fonts for the same line of text.
1st section:
font-family="Verdana"
2nd section:
font-family="Verdana,Liberation Sans"
3rd section:
font-family="Liberation Sans"
See Help:SVG#Font substitution and fallback fonts: For the user agent librsvg, the default font is Liberation Serif.
According to this Google search Verdana does not have a substitution font provided by Wikimedia. I don't know if this is true. So the top section should show the default serif font (Liberation Serif) instead of the sans-serif font Verdana.
If font fallback is working the 2nd section should be using Liberation Sans. If it is not working then it should show Liberation Serif, and should look exactly the same as the first section.
The 3rd section will show Liberation Sans, which Wikimedia definitely has.
So if font fallback is working, then sections 2 and 3 should look exactly the same.
If font fallback is not working, then sections 1 and 2 should look exactly the same.
I don't know how to create SVG files, and so somebody else will have to do this. --Timeshifter (talk) 01:00, 18 March 2026 (UTC)
- Pinging people from the Phab thread, and more: Pppery. HNowlan (WMF). cmglee. Glrx. I also asked for people to come here from Commons:Graphic Lab/Illustration workshop. Between all of us someone should be able to create a test SVG file. --Timeshifter (talk) 02:05, 18 March 2026 (UTC)
Thanks Abemos! It looks like I can increase the text size via the image wikitext:
[[File:SVG_font_fallback_test.svg|800px|none]]

I added 2 recently created sans-serif fonts (according to a Google search): NeuSans and Salsiccia.
It looks like Wikimedia is using the same default sans-serif font to replace Verdana, NeuSans, and Salsiccia if they are the only font listed in the font-family. I think it is DejaVu Sans. Look at f and r and a. See the font characters listed here:
If Liberation Sans is also listed, then Wikimedia uses it. That means font fallback is working. You can recognize Liberation Sans by looking at f and r and a. See it listed in the above-linked file. --Timeshifter (talk) 01:03, 19 March 2026 (UTC)
- I just want to mention that I choose the fonts directly through the
font-familyproperty. It might display differently if done through thestyleproperty. If the original theory is correct. That could be the reason. I'll try testing this too. ᛅᛒᛁᛘᚢᛋ (talk) 21:36, 19 March 2026 (UTC)
This graphic uses the style property instead:

This looks correct too. ᛅᛒᛁᛘᚢᛋ (talk) 21:48, 19 March 2026 (UTC)
- Thanks Abemos. I uploaded them both to Shoutwiki too: . I use Vector 2010 or Vector 2022 skin on the wiki I edit on there. The files look exactly the same there as here. I did not have to purge or do anything special. They looked the same before and after using ctrl-F5 with my Firefox browser.
- I left a note at the Phabricator task linking to here, and pointing out that I think font fallback is working. --Timeshifter (talk) 04:08, 20 March 2026 (UTC)
- Phab:T64986 has been closed as resolved. --Timeshifter (talk) 13:52, 20 March 2026 (UTC)
- Is this thread issue solved then? Prototyperspective (talk) 14:35, 20 March 2026 (UTC)
- Prototyperspective. Yes. --Timeshifter (talk) 15:00, 20 March 2026 (UTC)
- Is this thread issue solved then? Prototyperspective (talk) 14:35, 20 March 2026 (UTC)
- Phab:T64986 has been closed as resolved. --Timeshifter (talk) 13:52, 20 March 2026 (UTC)
COM:LRR archiving
It looks like SpBot has stopped archiving closed discussion at COM:LRR after the changes implemented at and after Revision #1181980614. (Existing level 2 header was replaced with level 3 header and a seperate level 2 header was introduced) Maybe some config needs to be changed or anything else so that the bot re-starts archiving. @The user who changed it at LRR has already implemented level 3 headings at Revision #1181981624 in the archives for 2026. Shaan SenguptaTalk 10:44, 18 March 2026 (UTC)
Taken care of Thanks to Armbrust. Shaan SenguptaTalk 10:40, 20 March 2026 (UTC)- This section was archived on a request by: Shaan SenguptaTalk 10:40, 20 March 2026 (UTC)
User:YiFeiBot seems to have stopped working
Hi all,
It seems that User:YiFeiBot has stopped working. It hasn't made an update (Special:Contributions/YiFeiBot) since March 12 when normally it would scour changes one a day. At a minimum it was adding and removing entries from Category:Pages using Information template with parsing errors and Category:Media missing infobox template.
As far as I could tell the bot wasn't blocked for misbehaving or anything of the sort. It also looks like User:Zhuyifei1999, who I assume was its owner has retired and not made any edits for almost a year. I was pointed in this direction from Commons:Administrators' noticeboard (the only other authoritative link on User:YiFeiBot.)
Any assistance in this matter would be greatly appreciated.
Thanks, --Stux (talk) 18:23, 19 March 2026 (UTC)
- Broken by phab:T299951. Should be fixed now, I think --Zhuyifei1999 (talk) 21:31, 19 March 2026 (UTC)
- Thank you @Zhuyifei1999! And you're alive! Next time if something happens I'll ping you directly as well. But I can confirm that the bot is now working again! --Stux (talk) 10:27, 20 March 2026 (UTC)
- I would prefer email. The only reason I saw this thread was because someone emailed me about something regarding Commons. I'm likely to not see pings --Zhuyifei1999 (talk) 10:33, 20 March 2026 (UTC)
- Thank you @Zhuyifei1999! And you're alive! Next time if something happens I'll ping you directly as well. But I can confirm that the bot is now working again! --Stux (talk) 10:27, 20 March 2026 (UTC)
Lua error
File:Relief depicting Ptolemy XII offering wine to Geb 01.jpg, which I'm pretty certain was fine when I created it on 4 January 2026 and until very recently, was recently tagged by YiFeiBot with Category:Pages using Information template with parsing errors. There is no overt {{Information}} template on that page, but I assume that was invoked by {{Art Photo}}. The page does, indeed, now give an error "Lua error in Module:Size at line 235: attempt to index field 'P518' (a nil value)." That's presumably applies to part (P518). FWIW, Relief depicting Ptolemy XII offering wine to Geb (Q137685825) has no changes since I created it on 4 January 2026 and does not overtly use applies to part (P518), so I'm pretty sure the error must be a recent change in the Lua module, not in my content on either Commons or Wikidata.
Following that up, I would guess that Special:Diff/1179794875 (about a week ago) by Marsupium is at fault, but honestly I've never worked with LUA and it's about midnight here as I write this, so I'm not going to investigate further myself right now. - Jmabel ! talk 07:00, 20 March 2026 (UTC)
- @Mike Peel reverted the change, so everything should be back to normal. --HyperGaruda (talk) 08:25, 20 March 2026 (UTC)
Tech News: 2026-10
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
- Wikipedia 25 Birthday mode is now live on Betawi, Breton, Chinese, Czech, Dutch, English, French, Gorontalo, Indonesian, Italian, Luxembourgish, Madurese, Sicilian, Spanish, Thai, and Vietnamese Wikipedias! This limited-time campaign feature celebrates 25 years of Wikipedia with a birthday mascot, Baby Globe. When turned on, Baby Globe is shown on ~2,500 articles, waiting to be discovered by readers. Communities can choose to turn Birthday mode on by getting consensus from their community and asking an admin to enable the feature and customize it via community configuration on the local wiki.
Updates for editors
- Sub-referencing, a new feature to re-use references with different details has been released to Swedish Wikipedia, Polish Wikipedia and a couple of other wikis. You can try the feature on these projects or on testwiki and betawiki. Learnings from the first pilot wiki German Wikipedia have been published in a report. Reach out to the Wikimedia Deutschland team if you are interested in becoming a pilot wiki.
- Paste Check will become available at all Wikipedias this week. The feature prompts newcomers who are pasting text they are not likely to have written into VisualEditor to consider whether doing so risks a copyright violation. Paste Check tags all edits where it is shown for potential review. Local administrators can configure various aspects of the feature via Special:EditChecks. Research across 22 wikis found that Paste Check resulted in an 18% decrease in relative reverted-edits compared to the control group. Translators can help to localize this and related features.
- The Reader Experience team will be standardizing the user menu in the top right for all mobile users so that it is closer to the desktop experience. Currently this user menu is only visible to users with Advanced Mobile Controls (AMC) turned on. The only change is that a couple buttons previously in the left-side menu will move to the top right for users who do not have AMC turned on. This change is expected to go out March 9 and seeks to improve the user interface.
- Starting in the week of March 2, the emails sent out when an email address was added, removed, or changed for an account will switch to a substantially nicer and clearer HTML email from the prior plaintext one.
- Notifications are currently limited to 2,000 historic entries per user, and extend back to 2013 when the feature was released. This is going to be changed to only store Notifications from the last 5 years, but up to 10,000 of them. This will help with long-term infrastructure health and help to prevent more recent notifications from disappearing too soon.
- The Global Watchlist which lets you view your watchlists from multiple wikis on a single page continues to see improvements. The latest update improves label usage experience. The extension now allows activating the language fallback system for Wikidata items without labels in the viewed language, and showing those labels in the user’s preferred Wikidata language if no
uselang=URL parameter is provided. - The Wikipedia Android team has started a beta test of hybrid search on Greek Wikipedia. Hybrid search capabilities can handle both semantic and keyword queries enabling readers to find what they’re looking for directly on Wikipedia more easily.
- For security reasons, members of certain user groups are required to have two-factor authentication (2FA) enabled. Currently, 2FA is required to use the group, but not to be a member of it. Given that this model still has some vulnerabilities, the situation will gradually change in March. Members of these groups will be unable to disable last 2FA method on their account, and it will be impossible to add users without 2FA to these groups. Users will still be able to add new authentication methods or remove them, as long as at least one method is continuously enabled. In the second half of March, users without 2FA will be removed from these groups. This applies to: CentralNotice administrators, checkusers, interface administrators, suppressors, Wikidata staff, Wikifunctions staff, WMF Office IT and WMF Trust & Safety. Nothing will change for other users. See the linked task for deployment schedule.
View all 27 community-submitted tasks that were resolved last week. For example, the issue preventing users from creating an instance in Wikibase.cloud has now been fixed.
Updates for technical contributors
- To help ensure fair use of infrastructure, over the next month the Wikimedia Foundation will implement global API rate limits across our APIs. In early March, stricter limits will be applied to unidentified requests from outside Toolforge/WMCS and API requests that are made from web browsers. In April, higher limits will be applied to identified traffic. These limits are intentionally set as high as possible to minimise impact on the community. Bots running in Toolforge/WMCS or with the bot user right on any wiki should not be affected for now. However, all developers are advised to follow updated best practices. For more information, see Wikimedia APIs/Rate limits.
- The Wikidata Query Service Linked Data Fragment (LDF) endpoint will be decommissioned in February. This endpoint served limited traffic, which was successfully migrated to other data access methods that were better suited to support existing use cases. The hardware used to support the LDF endpoint will be reallocated to support the ongoing backend migration efforts.
- The new Parsoid parser continues to be deployed to additional wikis, improving platform sustainability and making it easier to introduce new reading and editing features. Parsoid is now the default parser on 488 WMF wikis (268 Wikipedias), now covering more than 10% of all Wikipedia page views.
- The process and criteria for requesting exceptional access to the high volume feed of the Wikimedia Enterprise APIs (at no cost for mission-aligned usecases), have now been published. This is to provide more thorough and clearer documentation for users.
- Tech Blog, the blog dedicated to the Wikimedia technical community will be migrating to Diff, the community news and event blog. The migration should be complete in April 2026, after which new posts will be accepted for publishing. Readers will be able to access posts – old and new – on the landing page at https://diff.wikimedia.org/techblog.
Detailed code updates later this week: MediaWiki
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 17:48, 2 March 2026 (UTC)
Exploratory: Handling the uploading of images better
This is nowhere near any form of proposal. If it were I would have formulated it as such. This is separate from the question "Should this be done?" which is when a proposal might be made in order to determine that greater decision.
- Background / problem
A strong example of the issues Commons faces, especially with bulk uploads, is discussed with respect to a particular uploader at Commons:Administrators' noticeboard/User problems § Uploads by Fabe56. I do not anticipate that we shoudl discuss uploader specific issues here. I use ut purely as an example. Distilling the key points from the tl;dr discussion for those without the inclination to take a deep dive, it is all too easy, and with good faith, to Upload great swathes of files which are correctly licenced for onward use, without:
- using sensible file names. "DSC, IMG etc are useless for descriptive and retrieval purposes
- entering the uploaded files into a meaningful category scheme which is part of a full Commons hierarchy
- using critical judgement and uploading many files of high'y similar nature
This results in the use of Commons as what may appear to be a personal file store by some uploaders, perhaps even a kind of vanity of the "I have uploaded more than you" sort
- Solving the existing issues
Nothing obvious springs to mind to solve the existing problem. We are not speaking of a small number of files. The example has over two hundred thousand files of varying quality and variable retrievability. It might be that Commons has to bite the bullet on legacy uploads and work towards a future which seeks to promote good housekeeping at upload time.
- Working for the future
I assume there is some form of Edit Filter which is, or can be implemented on Commons which would seek to control this at upload time. This is the reason I have posted this at the technical Village Pump, not the one for proposals. I hope that those who understand filtering tools and enjoy technical puzzles can look at the issues form above, and consider how uploads might be better handled to seek to ensure the ability to catalogue them for retrieval and, where desirable, use.
I'm posting this exploratory post because I do not have the skill to formulate even in plain language, how a technical solution might be created. But we have experts in all fields here who have that skill. 🇵🇸🇺🇦 Timtrent 🇺🇦 talk to me 🇺🇦🇵🇸 12:59, 2 March 2026 (UTC)
- Please see Commons:File naming and Commons talk:WMF support for Commons/Upload Wizard Improvements#Guidance/facilitation of categorization. Further comments there as well as specific ideas what else could be done (how) would be welcome. Prototyperspective (talk) 14:01, 2 March 2026 (UTC)
- @Timtrent: Sorry, I seemingly fail to understand what you wanted to express in your section heading. The sequence of an adjective and two -ING words is puzzling for me, who's not a native English speaker, so I can't correct that in my head. Did you use some kind of autocompletion tool while writing who bungled the wording? Going by the main body of text, did you perhaps mean something along the lines of "Exploration of possible new ways to better handle file uploads"? Please confirm or fix the wording according to your actual idea. Regards, Grand-Duc (talk) 16:06, 2 March 2026 (UTC)
- I amended the title. 🇵🇸🇺🇦 Timtrent 🇺🇦 talk to me 🇺🇦🇵🇸 18:26, 2 March 2026 (UTC)
- Since Commons:File naming already says that images should not have generic names such as DSC123456.jpg it does seem appropriate that an Abuse filter would at least log such uploads if not outright block them. For Fabe56 to have uploads 18000+ DSC... images without challenge is odd, I'm sure there are other automatic meaningless names they used.
- Since the filter is just on an per edit basis, a bot would presumably be required to spot a pattern of possible bad upload behaviour. It would also be useful if a bot made regular lists of batch uploads with a common factor, such as all from a Flickr account; all named in a format {prefix} {number}.{extension}; etc. This would make it easier to review mass uploads to flag as problematic, raise a deletion discussion or if useful to better name/categorise/etc as a group. It would also be easier to go back and review past batches for an uploader if a problem is identified. KylieTastic (talk) 19:27, 3 March 2026 (UTC)
- Looking into that, Flickr transfers of DSC filenames aren't caught by the MediaWiki:Titleblacklist. A Fabe56 upload like File:DSC 8266 (13991064494).jpg wouldn't have triggered the
File:DSC.[\d\s]+\.JPGblacklist entry because of the Flickr ID in parentheses. It's only looking for a plain File:DSC 8266.jpg. We might want to add a few more possibilities for Flickr in the "Other common patterns" section of the blacklist. Belbury (talk) 19:46, 3 March 2026 (UTC)
- Looking into that, Flickr transfers of DSC filenames aren't caught by the MediaWiki:Titleblacklist. A Fabe56 upload like File:DSC 8266 (13991064494).jpg wouldn't have triggered the
- @Timtrent: Sorry, I seemingly fail to understand what you wanted to express in your section heading. The sequence of an adjective and two -ING words is puzzling for me, who's not a native English speaker, so I can't correct that in my head. Did you use some kind of autocompletion tool while writing who bungled the wording? Going by the main body of text, did you perhaps mean something along the lines of "Exploration of possible new ways to better handle file uploads"? Please confirm or fix the wording according to your actual idea. Regards, Grand-Duc (talk) 16:06, 2 March 2026 (UTC)
Just a finding.
Whenever I nominate a file for deletion, I start to receive notifications about unrelated deletion requests, and I have to turn off notifications manually. Can someone fix this? Candidyeoman55 (talk) 10:01, 5 March 2026 (UTC)
- See the prior discussions about this at Receiving reply notification when subsequent DRs are added to daily page. Looks like by now phab:T412462 is solved but in practice one still needs to manually unsubscribe from the DR page to stop getting these notifications. Prototyperspective (talk) 15:13, 5 March 2026 (UTC)
The Challenge Speedy Delete button worked but there was an unfortunate anomaly
Please examine Commons:Deletion requests/File:Baswanthrao Patil TRS.jpg
Salient points:
- I challenged an SD on the file using the big grey button
- There had been a prior DR
- The SD challenge grabbed the prior DR rationale instead of the SD nominator's rationale
- This caused confusion between me and Shaan Sengupta who was the SD nominator.
While the circumstances are unusual they are unlikely to be unique. Please will someone who understands this record it as an issue to be investigated? 🇵🇸🇺🇦 Timtrent 🇺🇦 talk to me 🇺🇦🇵🇸 15:23, 5 March 2026 (UTC)
- I went to the old revision, and clicked the "Challenge speedy deletion" button to check, and I got the same incorrect DR message as you did. I have no idea what is the reason for this, since for me the gadget is working fine for the other files in similar situations. Thanks. Tvpuppy (talk) 03:27, 6 March 2026 (UTC)
- I just tested with other files, I found out that if you clicked the "Challenge speedy deletion" button, it will always get the delete reason of the earliest instance of that specific SD template, not the current instance.
- So, for the case of File:Baswanthrao Patil TRS.jpg, if other users nominated the file for speedy using {{Copyvio}} again, and then you challenge it, it will always incorrectly get the earliest delete reason made by User:আফতাবুজ্জামান in 2024, not the latest one made by other users (the correct one).
- The problem is most likely in MediaWiki:Gadget-AjaxQuickDelete.js, probably somewhere between line 735 and 811. However, I have still no idea what the cause of the problem. Perhaps someone more knowledgeable can help fix this.
- Thanks. Tvpuppy (talk) 04:01, 6 March 2026 (UTC)
Critical error with ‘use this file on web’ functions
The integration of images from Commons no longer works to a large extent. I described the problem here: https://commons.wikimedia.org/wiki/Commons:Help_desk#Warum_funktioniert_das_Einbinden_eines_Bildes_in_eine_externe_Website_nicht_ (see example). The cause (according to my tests) is that ‘use this file on web’ (or ‘embed’) works with image sizes such as ‘256’ or ‘512’, while technically it has obviously been changed to “250” and ‘500’! If I manually change the 256 or 512 to 250 or 500 in the ‘Embeds’ in the ‘Thumbnail Link’, it works again. With my extremely large number of affected pages from the last 10 years (which I cannot automatically adjust myself), this is extremely annoying. But even the current ‘use this file on web’ template (on German Wikimedia Commons) still offers the old values (which no longer work) – so it is currently inoperable (no longer works). However, it would make sense for the ‘previous solutions’ in the existing world, such as my many pages, to continue to work, e.g. by redirecting the “256” link versions to the new ‘250’ versions. (This applies to the other sizes as well, of course: 512=>500, etc.) Or is there already an elegant solution for automatically changing the format in ‘externally hosted’ websites (in my case, Strato)? It would also be very unfavourable for the ‘use this file on web’ function as a whole if there were no guarantee that the integrations would continue to work in the long term and could not suddenly fail at any time (as is currently the case). Is anyone already working on a solution? Unfortunately, I am unable to do so. What does the solution will look like? Dirk Liesch (talk) 10:54, 5 March 2026 (UTC)
- Seems like the stockphoto gadget needs an update to suggest the recommended file sizes. Johannnes89 (talk) 12:44, 5 March 2026 (UTC)
- I have a proposed fix on the stockphoto gadget talk page. Bawolff (talk) 10:20, 9 March 2026 (UTC)
- @Bawolff: Where? I see nothing at File talk:Wikimedia Commons - Stockphoto gadget.png. - Jmabel ! talk 19:16, 9 March 2026 (UTC)
- @Jmabel at mediawiki talk:Gadget-Stockphoto.js Bawolff (talk) 20:13, 9 March 2026 (UTC)
- @Bawolff: Thanks!
- Question: wouldn't it make sense that when we get a request for a thumbnail size that is no longer supported, we round up to the next higher supported thumbnail size? - Jmabel ! talk 22:40, 9 March 2026 (UTC)
- Yes it would, and it would have made everyone's life easier if they did that. Unfortunately they did not and its a giant pain (this script is not the only thing that broke, there has been breakage all over the place). Honestly i find the whole situation annoying and frustrating. Note that special:filepath will round up, if you use it. Bawolff (talk) 01:03, 10 March 2026 (UTC)
- @Jmabel at mediawiki talk:Gadget-Stockphoto.js Bawolff (talk) 20:13, 9 March 2026 (UTC)
- @Bawolff: Where? I see nothing at File talk:Wikimedia Commons - Stockphoto gadget.png. - Jmabel ! talk 19:16, 9 March 2026 (UTC)
Help fixing template i18n
Since no one else would do it, I finally created an {{AI modified}} template, so that we can track media altered by AI software (as required by the new Commons:AI images of identifiable people guidelines). However, I'm sure I fucked up the i18n set-up (which is quite confusing). If anyone could fix it and get it to use the translate extension for i18n, that would be awesome! Nosferattus (talk) 23:53, 8 March 2026 (UTC)
- Perhaps it's better to post this at Commons:Translators' noticeboard, since this issue may require a translation admin to fix. Thanks. Tvpuppy (talk) 22:21, 9 March 2026 (UTC)
Tech News: 2026-11
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
- All wikis will be read-only for a few minutes on Wednesday, 25 March 2026 at 15:00 UTC. This is for the datacenter server switchover backup tests, which happen twice a year. During the switchover, all Wikimedia website traffic is shifted from one primary data center to the backup data center to test availability and prevent service disruption even in emergencies.
- Last week, all wikis had 2 hours of read-only time, and extended unavailability for user-scripts and gadgets. This was due to a security incident which has since been resolved. Work is ongoing to prevent re-occurrences. For current information please see the post on the Stewards' noticeboard (translations).
Updates for editors
- Users facing multiple blocks on mobile will now see the reasons for each block separately, instead of a generic message. This helps them understand why they are blocked and what steps they can take to resolve the issue. For example, users affected for using common VPNs (such as iCloud Private Relay) will receive clearer guidance on what they need to do to start editing again.
- Later this week, Suggestion Mode will become available as a beta feature within the visual editor at all Wikipedias. This feature proactively suggests various types of actions that people can consider taking to improve Wikipedia articles, and learn about related guidelines. The feature is locally configurable, and can also be locally expanded with custom Suggestions. Current settings can be seen at Special:EditChecks and there are instructions for how administrators can customize the links to point to local guidelines. The feature is connected to Edit check which suggests improvements while someone is writing new content. In the future, the Editing team plans to evaluate the feature's impact with newcomers through a controlled experiment.
View all 23 community-submitted tasks that were resolved last week. For example, the issue where the cursor became misaligned during the use of CodeMirror’s syntax highlighting, which makes wikitext and code easier to read, has now been fixed. This problem specifically affected users who defined a font rule in a custom stylesheet while creating a new topic with DiscussionTools.
Updates for technical contributors
- API rate limiting update: To help ensure fair use of infrastructure, global API rate limits will be applied this week to requests without a compliant User-Agent that originate from outside Toolforge/WMCS and to unauthenticated requests made from web browsers. Higher limits will be applied to identified traffic in April. Bots running in Toolforge/WMCS or with the bot user right on any wiki should not be affected for now. However, all developers are advised to follow updated best practices. For more information, see Wikimedia APIs/Rate limits.
- The new GraphQL API has been released. The API was developed as a flexible alternative to select features of the Wikidata Query Service (WDQS), to improve developer experience and foster adaptability, and efficient data access. Try it out and give feedback. You can also sign up for usability tests.
- The PTAC Unsupported Tools Working Group continued improvements to Video2Commons in February, with fixes addressing authentication errors, large-file handling, task queue visibility, and clearer upload behavior. Work is still ongoing in some areas, including changes related to deprecated server-side uploads. Read this update to learn more.
Detailed code updates later this week: MediaWiki
In depth
- The Article Guidance team invites experienced Wikipedia editors from selected pilot wikis and interested contributors from other Wikipedias to fill out this questionnaire which is available in English, Arabic, Bengali, Japanese, Portuguese, Persian, and Turkish. Your answers will help the team customize guidance for less experienced editors and help them learn community policies and practices while creating an article. Learn more on the project page.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 18:50, 9 March 2026 (UTC)
Requesting bulk data cleanup - Scheer photos with credit in EXIF
Andrew Scheer, formerly leader of the opposition in Canada's parliament, has a Flickr stream that releases photos as CC-0, resulting in 1,901 files in Category:Files from Andrew Scheer's Flickr stream. When these files were uploaded from Flickr, since the account's under his name, Scheer was listed as the 'Author'. Poking around some of the files, I see many whose EXIF credits Andre Forget (e.g. File:088A0780 (41365002220).jpg with "Photos Andre Forget / OLO", where I assume OLO refers to Office of the Leader of the Opposition; another with slightly different credit is File:Andrew Scheer (40839023063).jpg).
Request: Is it possible to, in bulk, identify all of those which credit Andre Forget in the EXIF, and update him as the Author/Photographer of those images? Even though we don't need to credit the photographer as the files are CC-0, I think it's still worthwhile to credit the right person. -Consigned (talk) 01:32, 10 March 2026 (UTC)
- I know we have bots that access EXIF data and act accordingly; given that Category:Files from Andrew Scheer's Flickr stream is not a large universe, certainly a bot could run over this data file-by-file and edit accordingly.
- I don't think there is any user-facing way to search for particular content in EXIF data. - Jmabel ! talk 04:19, 10 March 2026 (UTC)
- At worst, we could make sure the existing bot that extracts author info from EXIF data to SDC runs on all files in this category, after which I believe a Quarry query could find the relevant files. - Jmabel ! talk 04:21, 10 March 2026 (UTC)
- Quarry can't access SDC, however it can access exif, so it should be posdible to get it to make a list. Bawolff (talk) 22:00, 10 March 2026 (UTC)
- @Bawolff: ah, I thought it was the other way around! (Shows what tools I don't use.) - Jmabel ! talk 05:30, 11 March 2026 (UTC)
- I can get a list with Quarry - can VFC perform an update using a manual list? I don't think EXIF shows up in VFC's search query. But looking deeper into VFC at Help:VisualFileChange.js/samples#Inserting variables, there seem to be examples of pulling information EXIF out and duplicating it elsewhere - seems like this might work, will look into it further. I've never worked with bots and would prefer to do this on my own if possible. -Consigned (talk) 10:11, 11 March 2026 (UTC)
- In case its helpful: https://quarry.wmcloud.org/query/103004 Bawolff (talk) 18:05, 11 March 2026 (UTC)
- Quarry can't access SDC, however it can access exif, so it should be posdible to get it to make a list. Bawolff (talk) 22:00, 10 March 2026 (UTC)
Croptool won't let me overwrite
Hello, I was trying to crop this image, and I decided to overwrite instead of uploading new (which I haven't tried before), but I got this text: "Upload failed! [api] Received error: abusefilter-disallowed : ⧼abusefilter-warning-file-overwriting⧽". I would have assumed it would let me, considering I'm Autoconfirmed, so I'm allowed to do most other actions. Does this require a higher level of permission? LetmeEditit (talk) 19:15, 10 March 2026 (UTC)
- @LetmeEditit Yes, you need autopatrol to overwrite files. Please see COM:OVERWRITE. You may request an exception for that specific file, or you can request the autopatrol permission. Thanks. Tvpuppy (talk) 19:45, 10 March 2026 (UTC)
- You would need "Autopatrol" for that, see Commons:Overwriting existing files. Please request that right on COM:RFR#Autopatrol, with your 4k edits, it should be a no-brainer to get it. If you don't want to wait for it, ping me, I'll add {{Allow Overwriting}} for a short time. Regards, Grand-Duc (talk) 19:46, 10 March 2026 (UTC)
- Thank you both for informing me. I've put in a request for autopatrol now. I probably won't use it much, since most of the time I think uploading a separate file is better, but it seems like a nice thing to have the option. Side note — I think the error message should be changed to be more clear, it's very vague. LetmeEditit (talk) 20:02, 10 March 2026 (UTC)
- @LetmeEditit: but how could it be appropriate to crop in place a file that is used in articles in multiple Wikipedias, rather than upload your own version? You are forcing a change on every one of those Wikipedias. Have you properly read COM:OVERWRITE? - Jmabel ! talk 05:32, 11 March 2026 (UTC)
- COM:OVERWRITE is kind of confusing, and it seems like a lot of the policy on here should really be re-written for more clarity. I personally feel like a crop to the image fits the example provided at Commons:Overwriting existing files#Substantial crop or un-crop, since the grass is a fairly repetitive negative space, which IMO doesn't add any value to the image. The image's use case in each article is to illustrate the unique colour of the fox, and I think the large section of grass detracts from that, as it makes the fox hard to see.
- I think the best solution would be to re-write this section of policy, as a new user it's confusing and seems contradictory in places. LetmeEditit (talk) 12:13, 11 March 2026 (UTC)
- Pinging @Tvpuppy, Grand-Duc, since you both apparently see no problem here. What am I missing? - Jmabel ! talk 05:34, 11 March 2026 (UTC)
- You're right, in this case, a new file should be created instead of overwriting. Admittedly, I didn't pay much attention to the file, as I was focused on answering the part about permission to overwrite. Thanks for your additional comment above. Tvpuppy (talk) 10:28, 11 March 2026 (UTC)
- I feel a comradeship in spirit with Tvpuppy here... I also only thought about the technological prerequisites of overwriting, not so much about whether the actual act would be sensible here. When I looked at the fox image, I thought, "Yeah, there's lot of background, a crop to the main motif is not a bad idea", but failed to notice the pages where it's used. Regards, Grand-Duc (talk) 11:00, 11 March 2026 (UTC)
- @LetmeEditit: but how could it be appropriate to crop in place a file that is used in articles in multiple Wikipedias, rather than upload your own version? You are forcing a change on every one of those Wikipedias. Have you properly read COM:OVERWRITE? - Jmabel ! talk 05:32, 11 March 2026 (UTC)
- Thank you both for informing me. I've put in a request for autopatrol now. I probably won't use it much, since most of the time I think uploading a separate file is better, but it seems like a nice thing to have the option. Side note — I think the error message should be changed to be more clear, it's very vague. LetmeEditit (talk) 20:02, 10 March 2026 (UTC)
Creating a WD item from Artwork information
Hi, Please see Template talk:Artwork#Creating a WD item from Artwork information. Yann (talk) 18:15, 11 March 2026 (UTC)
Overwrite files per OpenRefine
Hi!
--PantheraLeo1359531 😺 (talk) 09:01, 13 March 2026 (UTC)
- Might help if you would indicate at least one of the files in question, and if the file page does not name the relevant URL(s), please be explicit about that too. - Jmabel ! talk 18:41, 13 March 2026 (UTC)
- Of course, sorry! We have File:DOP20 RGB Berlin Sommer 2025 - 373000 5808000 (Senatskanzlei Berlin).tif from TIF source. I would overwrite this file per OpenRefine from the URL GeoTIFF source. --PantheraLeo1359531 😺 (talk) 13:35, 14 March 2026 (UTC)
Rewriting the RotateLink gadget
So, I'm rewriting the RotateLink gadget.. The current UI is pretty old - no dark theme, image preview sometimes doesn't load, and the interface isn't very user-friendly. I'm thinking about putting a slider at the bottom of the file preview while keeping the preview centered. Here's what I'm designing now: imgur (direct video: ). Open to suggestions; I've been reading some comments on MediaWiki talk:Gadget-RotateLink.js. Nemoralis (talk) 23:43, 21 March 2026 (UTC)
Comment, the new UI looks very nice, thanks for creating it. Just a minor suggestion, can you specify in the gadget text that the rotation is "clockwise"? I know it is quite obvious, but I think it's better to be clear. Thanks. Tvpuppy (talk) 11:36, 22 March 2026 (UTC)
- @Tvpuppy, thanks, I added it. New UI is now live: MediaWiki talk:Gadget-RotateLink.js#Rewrite. Nemoralis (talk) 18:27, 22 March 2026 (UTC)
Need help for MassRename
--PantheraLeo1359531 😺 (talk) 20:30, 28 March 2026 (UTC)
- In der Datei liegen Datensätze in der folgenden Form vor: „https://gdi.berlin.de/services/wms/truedop_2020_sommer?service=WMS&version=1.3.0&REQUEST=GetMap&LAYERS=truedop_2020_sommer_rgb&CRS=EPSG:25833&WIDTH=5000&HEIGHT=5000&FORMAT=image/geotiff&STYLES=&BBOX=396000,5816000,397000,5817000;DOP20 RGB Berlin 2020 - 397000 5828000 (Senatskanzlei Berlin).tif;DOP20 RGB Berlin 2020 - 396000 5816000 (Senatskanzlei Berlin).tif;DOP20RGB Berlin 2020 (Senatskanzlei Berlin)“ . Für einen Bot wäre folgende Angabe besser geeignet: „ 'DOP20 RGB Berlin 2020 - 397000 5828000 (Senatskanzlei Berlin).tif';'DOP20 RGB Berlin 2020 - 396000 5816000 (Senatskanzlei Berlin).tif' “ . Nur der alte und der gewünschte Dateiname in einer Zeile. GeorgDerReisende (talk) 20:56, 28 March 2026 (UTC)
Done So, jetzt sind nur noch die Namen vorhanden :) --PantheraLeo1359531 😺 (talk) 21:05, 28 March 2026 (UTC)
- Es braucht einen neuen öffentliche Link. GeorgDerReisende (talk) 21:25, 28 March 2026 (UTC)
- Ah entschuldige, ich dachte, der alte Link bleibt aktiv. Damit sollte es klappen. --PantheraLeo1359531 😺 (talk) 21:51, 28 March 2026 (UTC)
- In der vorliegenden Reihenfolge dürfen die Dateien nicht verschoben werden! Sonst würden verschiedene Dateien mehrfach überschrieben werden und damit viele Dateien verloren gehen. Nur als Beispiel: in einmal soll „370000 5808000“ auf „370000 5810000“ verschoben werden, dann soll „370000 5810000“ auf „370000 5814000“ verschoben werden, dann „370000 5814000“ auf „371000 5812000“! Usw. Außerdem heißt es auf der Dateibeschreibung, dass es sich um Quadrate von 2x2 km handeln soll, die Koordinaten verweisen aber auf 1x1 km-Quadrate. Ich würde das gerne überprüfen, kann das aber erst am Dienstag machen. GeorgDerReisende (talk) 22:18, 29 March 2026 (UTC)
- Du hast Recht! Ich kann das aufklären :). Die erwähnten 2×2km sind der Blattschnitt, die die Senatskanzlei vorgibt. Da die Bilder über den Web Map Service bezogen wurden (und nicht bereits gekachelt), habe ich den Zuschnitt aller Kacheln auf 1km×1km begrenzt, um die Konsistenz über alle Jahre hinweg zu gewährleisten (wenn ich also ein Koordinatenpaar in der Suche eingebe, bekomme ich für jedes Jahr denselben Ausschnitt) (leider gibt es einige Inkonsistenzen über die Jahre, die ich versucht habe, zu überwinden). Es ist richtig, dass einige Namen bereits "belegt" sind. Kann man da vielleicht die betreffenden Dateien zu Namen verschieben, die einen "temporären Platzhalter" im Namen haben, sodass dann die richtigen Namen frei werden? Danke und liebe Grüße! --PantheraLeo1359531 😺 (talk) 16:15, 30 March 2026 (UTC)
- @GeorgDerReisende (Ping) --PantheraLeo1359531 😺 (talk) 16:15, 30 March 2026 (UTC)
- (Die Originalbeschreibungen wurden pro Forma übernommen. Es kann bei einigen Fällen gekachelte Downloads geben, die allerdings im JP2-Format vorliegen und verlustfrei komprimiert sein können) --PantheraLeo1359531 😺 (talk) 16:17, 30 March 2026 (UTC)
- 1. In der Dateiverschiebungsliste sind die Dateien der Serie „RGB Berlin 2021“ doppelt vorhanden, wenn noch auf Basis dieser Liste gearbeitet werden soll, muss die zweite Erwähnung der Serie (ab Zeile 6001) gelöscht werden.
- 2. Die Dateien mit den Koordinaten 368000/5808000, 368000/5809000, 369000/5808000, 369000/5809000, 370000/5806000, 370000/5807000, 371000/5814000, 371000/5815000, 372000/5804000, 372000/5805000, 373000/5828000, 373000/5829000, 374000/5806000, 374000/5807000, 375000/5828000, 375000/5829000, 376000/5806000, 376000/5807000, 377000/5830000, 377000/5831000, 378000/5806000, 378000/5807000, 379000/5832000, 379000/5833000, 380000/5806000, 380000/5807000, 381000/5832000, 381000/5833000, 382000/5806000, 382000/5807000, 383000/5836000, 383000/5837000, 384000/5806000, 384000/5807000, 385000/5836000, 385000/5837000, 386000/5806000, 386000/5807000, 387000/5834000, 387000/5835000, 388000/5804000, 388000/5805000, 390000/5806000, 390000/5807000, 392000/5810000, 392000/5811000, 394000/5826000 und 394000/5827000 brauchen nicht bearbeitet zu werden, da sie laut Liste nicht verschoben werden sollen.
- 3. Ich finde den Fehler nicht, der zu dieser Situation geführt hat.
- 3a. Lösung 1 — die dreckige Methode: du lädst einfach alle Dateien mit dem richtigen Namen nochmal über die Dateien mit dem falschen Namen hoch. Ergebnis: für jede Datei werden 37 MB Speicherplatz zusätzlich benötigt und in der Versionsgeschichte taucht die falsche Dateiversion mit auf, was in der Zukunft Probleme mit sich bringen könnte.
- 3b. Lösung 2 — die saubere Methode: du beantragst die Löschung dieser 7200 Dateien und sie wird so durchgeführt und dann lädst du die Dateien mit den richtigen Namen erneut hoch. Ergebnis: für jede Datei werden nur die 37 MB einmalig benötigt und es gibt eine saubere Versionsgeschichte. Nachteil: ein Dateilöscher-Admin muss die 7200 Dateien einzeln händisch löschen, offenbar gibt es für solche Massenlöschungen keinen Bot.
- 3c. Lösung 3 — die extrem arbeitsintensive Lösung: wie von mir schon anfangs beschrieben, gibt es Ketten von notwendigen Dateiverschiebungen. Diese Ketten musst du alle identifizieren. Dann kann mit einem Bot so gearbeitet werden: move( Datei987 nach DateiTemp ), move( Datei765 nach Datei987 ), move( Datei444 nach Datei765 ), move( DateiTemp nach Datei444 ). Usf.
- Ich für mich würde die Lösung 2 vorschlagen und dem Dateilöscher-Admin eine Palette Gummibären oder so zukommen lassen. GeorgDerReisende (talk) 13:46, 31 March 2026 (UTC)
- Alles klar, ich würde dann die Tage ggf. die Löschung der betroffenen Dateien beantragen und die Dateien mit korrektem Namen neu hochladen. Danke Dir für Deinen Einsatz! --PantheraLeo1359531 😺 (talk) 08:43, 2 April 2026 (UTC)
- Du hast Recht! Ich kann das aufklären :). Die erwähnten 2×2km sind der Blattschnitt, die die Senatskanzlei vorgibt. Da die Bilder über den Web Map Service bezogen wurden (und nicht bereits gekachelt), habe ich den Zuschnitt aller Kacheln auf 1km×1km begrenzt, um die Konsistenz über alle Jahre hinweg zu gewährleisten (wenn ich also ein Koordinatenpaar in der Suche eingebe, bekomme ich für jedes Jahr denselben Ausschnitt) (leider gibt es einige Inkonsistenzen über die Jahre, die ich versucht habe, zu überwinden). Es ist richtig, dass einige Namen bereits "belegt" sind. Kann man da vielleicht die betreffenden Dateien zu Namen verschieben, die einen "temporären Platzhalter" im Namen haben, sodass dann die richtigen Namen frei werden? Danke und liebe Grüße! --PantheraLeo1359531 😺 (talk) 16:15, 30 March 2026 (UTC)
- In der vorliegenden Reihenfolge dürfen die Dateien nicht verschoben werden! Sonst würden verschiedene Dateien mehrfach überschrieben werden und damit viele Dateien verloren gehen. Nur als Beispiel: in einmal soll „370000 5808000“ auf „370000 5810000“ verschoben werden, dann soll „370000 5810000“ auf „370000 5814000“ verschoben werden, dann „370000 5814000“ auf „371000 5812000“! Usw. Außerdem heißt es auf der Dateibeschreibung, dass es sich um Quadrate von 2x2 km handeln soll, die Koordinaten verweisen aber auf 1x1 km-Quadrate. Ich würde das gerne überprüfen, kann das aber erst am Dienstag machen. GeorgDerReisende (talk) 22:18, 29 March 2026 (UTC)
- Ah entschuldige, ich dachte, der alte Link bleibt aktiv. Damit sollte es klappen. --PantheraLeo1359531 😺 (talk) 21:51, 28 March 2026 (UTC)
- Es braucht einen neuen öffentliche Link. GeorgDerReisende (talk) 21:25, 28 March 2026 (UTC)
Request for privacy: Change Author field to "Unknown" on my uploads
Hello,
For privacy and safety reasons, I would like to request a batch update for all files uploaded by my account (formerly Risantana or "Cheposo", now Stratos 499).
I need the |Author= field in the {{Information}} template of all my previous uploads to be changed from "Risantana" to "Unknown" or "Anonymous". My goal is to ensure that my current or former username is no longer linked to these files' metadata or description fields.
Could a bot operator or an administrator assist me with this mass edit?
Thank you for your understanding and help regarding this privacy matter.
Regards, --Stratos 449 (talk) 13:36, 11 March 2026 (UTC)
- @Stratos 449: Hi, Works created by you, and uploaded under a free license, cannot be credited to "Unknown". However you can choose whatever pseudonym you want. Yann (talk) 17:07, 11 March 2026 (UTC)
- Including you can use your current account name, if that will do. - Jmabel ! talk 21:18, 11 March 2026 (UTC)
Thumbnails not generating for external wikis
In the past several days, thumbnails are not being properly generated acrsso multiple wiki farms that use the wikimedia commons. Clicking through on the thumbnail returns a " Error Use thumbnail steps listed on https://w.wiki/GHai. Please contact noc@wikimedia.org for further information (a765913)"
Has something changed which has broken the standard functionality used by literally thousands of mediawiki wikis that rely on the wikimedia commons shard libraries? - 17:08, 7 March 2026 (UTC) Lestatdelc (talk) 17:08, 7 March 2026 (UTC)
- @Lestatdelc, as stated in mw:Common thumbnail sizes#FAQ, the error is probably due to the wikis not using one of the "standard" thumbnail sizes. Previously, the thumbnail will generate for any specified size via URL, but now MediaWiki requires one of the "standard" size to be specified when requesting via URL.
- However, this change was made in January 2026, so the problem might be something else if it only occurred in the past several days. Thanks. Tvpuppy (talk) 19:40, 7 March 2026 (UTC)
- If you are using mw:Extension:QuickInstantCommons, please update to the latest version. I just recently (like last week) fixed a bug in it to make it compatible with these changes. Bawolff (talk) 10:19, 9 March 2026 (UTC)
- And what if I don't want to use a "standard" thumbnail sizes? Then what? You used to be able to change the size of an SVG converted to PNG in the URL. Now you can't
- Can't you stop fucking up the site holy shit??!!! First you ban 90% of the users from editing images and now this, what are you going to break next? Yilku1 (talk) 19:49, 14 March 2026 (UTC)
- Please be civil and remember to be respectful to others. The change was implemented by MediaWiki and not by users here in Commons, but I certainly believe the change was made to improve the site rather than worsening it. Regarding your second point, I have no idea what you are referring to as I'm pretty sure "90% of the users" are not "banned from editing images". Thanks. Tvpuppy (talk) 20:04, 14 March 2026 (UTC)
- I'm fucking tired of EVERYTHING enshittifing, and now it's happening to wikipedia. Who asked for this?
- 90% of the users can't edit images. You have to ask like a pleb to the admins so you can edit, but only one for the image you asked. Another stupid change nobody asked. Yilku1 (talk) 20:15, 14 March 2026 (UTC)
- Explain me how breaking most thumbnails is improving the site? Yilku1 (talk) 03:08, 15 March 2026 (UTC)
- If you are using instant commons (not quickinstantcommons) there is a setting you can set where it downloads the original and then resizes locally (to any size you want). Bawolff (talk) 20:40, 14 March 2026 (UTC)
- Please be civil and remember to be respectful to others. The change was implemented by MediaWiki and not by users here in Commons, but I certainly believe the change was made to improve the site rather than worsening it. Regarding your second point, I have no idea what you are referring to as I'm pretty sure "90% of the users" are not "banned from editing images". Thanks. Tvpuppy (talk) 20:04, 14 March 2026 (UTC)
Tech News: 2026-12
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
- The ⧼codemirror-beta-feature-title⧽ beta feature, also known as CodeMirror 6, has been used for wikitext syntax highlighting since November 2024. It will be promoted out of beta by May 2026 in order to bring improvements and new features to all editors who use the standard syntax highlighter. If you have any questions or concerns about promoting the feature out of beta, please share.
- Some changes to local user groups are performed by stewards on Meta-Wiki and logged there only. Now, interwiki rights changes will be logged both on Meta-Wiki and the wiki of the target user to make it easier to access a full record of user's rights changes on a local wiki. Past log entries for such changes will be backfilled in the coming weeks.
- On wikis using Flagged Revisions, the number of pending changes shown on Special:PendingChanges previously counted pages which were no longer pending review, because they have been removed from the system without being reviewed, e.g. due to being deleted, moved to a different namespace, or due to wiki configuration changes. The count will be correct now. On some wikis the number shown will be much smaller than before. There should be no change to the list of pages itself.
- Wikifunctions composition language has been rewritten, resulting in a new version of the language. This change aims to increase service stability by reducing the orchestrator's memory consumption. This rewrite also enables substantial latency reduction, code simplification, and better abstractions, which will open the door to later feature additions. Read more about the changes.
- Users can now sort search results alphabetically by page title. The update gives an additional option to finding pages more easily and quickly. Previously, results could be sorted by Edit date, Creation date, or Relevance. To use the new option, open 'Advanced Search' on the search results page and select 'Alphabetically' under 'Sorting Order'.
View all 28 community-submitted tasks that were resolved last week. For example, the bug that prevented UploadWizard on Wikimedia Commons from importing files from Flickr has now been fixed.
Updates for technical contributors
- A new special page, Special:LintTemplateErrors, has been created to list transcluded pages that are flagged as containing lint errors to help users discover them easily. The list is sorted by the number of transclusions with errors. For example: Special:LintTemplateErrors/night-mode-unaware-background-color.
- Users of the ⧼codemirror-beta-feature-title⧽ beta feature have been using CodeMirror instead of CodeEditor for syntax highlighting when editing JavaScript, CSS, JSON, Vue and Lua content pages, for some time now. Along with promoting CodeMirror 6 out of beta, the plan is to replace CodeEditor as the standard editor for these content models by May 2026. Feedback or concerns are welcome.
- The CodeMirror JavaScript modules will soon be upgraded to CodeMirror 6. Leading up to the upgrade, loading the
ext.CodeMirrororext.CodeMirror.libmodules from gadgets and user scripts was deprecated in July 2025. The use of theext.CodeMirror.switchhook was also deprecated in March 2025. Contributors can now make their scripts or gadgets compatible with CodeMirror 6. See the migration guide for more information. - The MediaWiki Interfaces team is expanding coverage of REST API module definitions to include extension APIs. REST API modules are groups of related endpoints that can be independently managed and versioned. Modules now exist for GrowthExperiments and Wikifunctions APIs. As we migrate extension APIs to this structure, documentation will move out of the main MediaWiki OpenAPI spec and REST Sandbox view, and will instead be accessible via module-specific options in the dropdown on the REST Sandbox (i.e., Special:RestSandbox, available on all wiki projects).
- The Scribunto extension provides different pieces of information about the wiki where the module is being used via the mw.site library. Starting last week, the library also provides a way of accessing the wiki ID that can be used to facilitate cross-wiki module maintenance.
Detailed code updates later this week: MediaWiki
In depth
- The 2026 Coolest Tool Award celebrating outstanding community tools, is now open for nominations! Nominate your favorite tool using the nomination survey form by 23 March 2026. For more information on privacy and data handling, please see the survey privacy statement.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 19:33, 16 March 2026 (UTC)
Opera browser data saver mode
this probably niche problem happened to me today. writing here in case anyone might have it too.
i couldnt edit using opera browser on my android phone. after some testing i realised that my ip is different (according to whatismyipaddress.com) when i use chrome and opera. turning off data saver finally makes ip the same and lets me be no longer affected by ip blocks. RoyZuo (talk) 20:22, 17 March 2026 (UTC)
simpleSVGcheck.js is defect
The script User talk:Chealer/simpleSVGcheck.js doesn't work anymore. @Flexagoon wrote:
The script no longer works for me, because requests to the validator API are blocked by Content-Security-Policy
What can we do to fix this? Kind regards, --Sebastian Wallroth (talk) 12:38, 19 March 2026 (UTC)
- @Sebastian Wallroth (and others): Please do file a subtask of phab:T419265 for any CSP issues in userscripts/gadgets that have started happening -- my comment here (on metawiki) has links to some partially-prefilled task templates I put together in case they're helpful, though it's not required to use them! Best, —a smart kitten[meow] 14:09, 19 March 2026 (UTC)
- Thanks! I created a report and added @Sebastian Wallroth as a subscriber. Flexagoon (talk) 18:22, 19 March 2026 (UTC)
Images seem to be broken
I'm into computer programming, and I've heard that wikimedia commons recently archived most of their images, but now none of them show up on my webpages. I don't know how to input images into my HTML code anymore.
here is a link that doesn't work.
pretty much all of the old images are broken like this, and they simply don't show up on my webpages. Dragonstudios36 (talk) 14:52, 20 March 2026 (UTC)
- Use https://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Snowy_Mountain_Valley.jpg/1920px-Snowy_Mountain_Valley.jpg instead. Try using one of the sizes from this list: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px [Personally I find it really silly we are just breaking everything instead of just using redirects]. Near the top of the image page there should be a button labelled "use this file" which will give you html code to include the file. Bawolff (talk) 19:24, 20 March 2026 (UTC)
Tech News: 2026-13
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
- Wikimedia site users can now log in without a password using passkeys. This is a secure method supported by fingerprint, facial recognition, or PIN. With this change, all users who opt for passwordless login will find it easier, faster, and more secure to log in to their accounts using any device. The new passkey login option currently appears as an autofill suggestion in the username field. An additional "Log in with passkey" button will soon be available for users who have already registered a passkey. This update will improve security and user experience. The screen recording demonstrates the passwordless login process step by step.
- All wikis will be read-only for a few minutes on Wednesday, 25 March 2026 at 15:00 UTC. This is for the datacenter server switchover backup tests, which happen twice a year. During the switchover, all Wikimedia website traffic is shifted from one primary data center to the backup data center to test availability and prevent service disruption even in emergencies.
Updates for editors
- Wikimedia site users can now export their notifications older than 5 years using a new Toolforge tool. This will ensure that users retain their important notifications and avoid them being lost based on the planned change to delete notifications older than 5 years, as previously announced.
- Wikipedia editors in Indonesian, Thai, Turkish, and Simple English now have access to Special:PersonalDashboard. This is an early version of an experience that introduces newer editors to patrolling workflows, making it easier for them to move from making edits to participating in more advanced moderation work on their project.
- The Special:Block now has two minor interface changes. Administrators can now easily perform indefinite blocks through a dedicated radio button in the expiry section. Also, choosing an indefinite expiry provides a different set of common reasons to select from, which can be changed at: MediaWiki:Ipbreason-indef-dropdown.
- Mobile editors at several wikis can now see an improved logged-out edit warning, thanks to the recent updates from the Growth team. These changes released last week are part of ongoing efforts and tests to enhance account creation experience on mobile and then increase participation.
View all 36 community-submitted tasks that were resolved last week. For example, the bug that prevented mobile web users from seeing the block information when affected by multiple blocks has been fixed. They can now see messages of all the blocks currently affecting them when they access Wikipedia.
Updates for technical contributors
- Images built using Toolforge will soon get the upgraded buildpacks version, bringing support for newer language versions and other upstream improvements and fixes. If you use Toolforge Build Service, review the recent cloud-announce email and update your build configuration as necessary to ensure your tools are compatible.
- The API Portal documentation wiki will shut down in June 2026. API keys created on the API Portal will continue to work normally. api.wikimedia.org endpoints will be deprecated gradually starting in July 2026. Documentation on the API Portal is moving to mediawiki.org. Learn more on the project page.
Detailed code updates later this week: MediaWiki
In depth
- WMDE Technical Wishes is considering improvements to automatically generated reference names in VisualEditor. Please check out the proposed solutions and participate in the request for comment.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 16:48, 23 March 2026 (UTC)
- Can someone give a better explanation of the thing about notifications? I don't understand whether this is specific to notifications still on the user talk page or, if not, how it would affect already-archived talk pages. - Jmabel ! talk 20:07, 23 March 2026 (UTC)
- Don't know what you mean. Notifications are the thing that display in the dropdown in the top right. Info on the technical system it uses, Echo, can be found at mw:Extension:Echo. Apparently they want to delete notifications older than 5 years. Prototyperspective (talk) 22:44, 23 March 2026 (UTC)
- Ah, so this is presumably about notifications one has long since dealt with. Got it. I knew those were called notifications, but presumed it had to be something else, because who on earth looks at a notification more than a few days, maybe a month, after the fact? Five years?? (I guess someone cares...). - Jmabel ! talk 00:44, 24 March 2026 (UTC)
- Don't know what you mean. Notifications are the thing that display in the dropdown in the top right. Info on the technical system it uses, Echo, can be found at mw:Extension:Echo. Apparently they want to delete notifications older than 5 years. Prototyperspective (talk) 22:44, 23 March 2026 (UTC)
Annotations invisible for logged out users
Per title - COM:Image annotations are not displayed unless you are logged in. Qbli2mHd (talk) 01:11, 25 March 2026 (UTC)
- Well that makes sense because only logged in users can use gadgets. Nemoralis (talk) 18:39, 25 March 2026 (UTC)
- Hmm, it is actually loaded for all users via Common.js. It works for me in a private window (logged out). Nemoralis (talk) 18:47, 25 March 2026 (UTC)
- I think I understand where this comes from - annotations won't work if page width (determined on load) leads to image being resized. This happens when the window is too narrow to fit an image; annotations will work if you reload the page with a wider window; they won't work again if you make the window even wider, because a sidebar is inserted to the right and image is resized; they will work again if you make window wide enough to fit both the image and the sidebar. Qbli2mHd (talk) 17:47, 26 March 2026 (UTC)
- Hmm, it is actually loaded for all users via Common.js. It works for me in a private window (logged out). Nemoralis (talk) 18:47, 25 March 2026 (UTC)