Commons:Village pump/Technical

Shortcuts: COM:VP/T • COM:VPT

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

Welcome to the Village pump technical section

Technical discussion

Village pump/Technical

Bug reports

Code review

Tools

Tools/Directory

Idea Lab

This page is used for technical questions relating to the tools, gadgets, or other technical issues about Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; recent archives: /Archive/2025/11 /Archive/2025/12.

COMMONS DISCUSSION PAGES

• Commons Help desk
• Village pump (general discussion)
  • Copyright
  • Proposals
  • Technical
• Graphics and photography discussion
  • Photography critiques
  • Image improvement
    • Illustration workshop
    • Map workshop
    • Photography workshop
    • Video and sound workshop
• Categories for discussion
• Undeletion requests
• Deletion requests
• Volunteer Response Team/Noticeboard
• Translators' noticeboard
• Work requests for bots

---

• Contact administrators
  • Vandalism
  • User problems (Dispute resolution)
  • Blocks and protections
• Bureaucrats' noticeboard
• CheckUser requests
• Oversight requests

---

• Telegram
• IRC ^webchat
• Commons mailing list (archive)
• Commons' bugs on Phabricator

Please note

• Feature or bug reports should be filed on Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).
• Have you read the FAQ?
  
  

 

Start a new discussion

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

How to move (rename) many categories?

How can one rename many categories at once? This would be similar to VisualFileChange or massrename but for categories, not files. For example, all categories starting with something / that are in the search results of some search query. Prototyperspective (talk) 16:40, 13 October 2025 (UTC)

This really isn't possible?

Is it possible to edit the content of many categories at once similar to how VisualFileChange can be used to edit many file pages?
See MediaWiki talk:Gadget-VisualFileChange.js#VisualFileChange for category text content changes?.
Prototyperspective (talk) 23:51, 3 November 2025 (UTC)

I am also curious if you find out something here. I'm less interested in mass-renaming of categories, but if there is a better way to mass-categorize many categories (like Cat-a-lot?), I am still unaware of possibilities. The only way I know is HotCat and Edit. --Enyavar (talk) 09:54, 4 November 2025 (UTC)

but if there is a better way to mass-categorize many categories (like Cat-a-lot?) you can use cat-a-lot for that. Prototyperspective (talk) 12:57, 4 November 2025 (UTC)

So it doesn't seem to be possible and I'll create a wish for it. Please correct if I'm wrong and there is a bot one could readily use for this or a tool. Prototyperspective (talk) 16:41, 2 December 2025 (UTC)

I'm not familiar with Commons:AutoWikiBrowser, but maybe it is possible to do using AWB? Tvpuppy (talk) 15:40, 4 December 2025 (UTC)

Thanks! Maybe it's possible with AWB – but for whatever reason it's developed for proprietary Microsoft Windows and I'm using Linux (looking for something cross-platform or Web). Prototyperspective (talk) 16:27, 4 December 2025 (UTC)

Flickr2commons “The file you submitted was empty.”

I have this issue “The file you submitted was empty.”, How to fix? 6D (talk) 07:15, 15 October 2025 (UTC)

Does Anyone else have this issue? 6D (talk) 09:13, 16 October 2025 (UTC)

Not recently, no. I don’t know the cause of it, but I remember when I had this issue, I just kept resubmitting the files until they went through. Tvpuppy (talk) 02:28, 17 October 2025 (UTC)

And the Flickr2Commons are struck at Running....., may be the F2C API key got ratelimited. 6D (talk) 15:21, 22 October 2025 (UTC)

And it now working again!!!’ 6D (talk) 23:53, 22 October 2025 (UTC)

So are your two issues both solved now? Prototyperspective (talk) 10:23, 29 October 2025 (UTC)

The Flickr2Commons are struck at Running..... is fixed, but Flickr2commons “The file you submitted was empty.” is not fixed, when I moved about ~600-800 images, this issue pop up for 30 Minutes-1 Hour. 6D (talk) 02:50, 30 October 2025 (UTC)

I'm also still experiencing the same “The file you submitted was empty.” with the tool. Also checked, and I am able to manually transfer these files, so it is a tool related issue. Respublik (talk) 23:09, 28 November 2025 (UTC)

Path to merging multi-part audiobooks?

Commons contains a sizable fraction of free-licensed audiobooks. However, many are split into multiple parts. This makes it cumbersome to download them and to listen to them conveniently and without interruptions.

It's also not well-suited for adding the file to Wikidata items or Wikipedia articles or Wikisource pages if it's split up into many parts. There also are further issues.

Is there any way that many or all of the multi-part audiobooks could be feasibly bundled up into one file each?

For example, there's many in Category:LibriVox recordings and I just merged one of them with 8 parts (just 45 min; 83 MB) using one ffmpeg command. But it can't be done manually for all the audios there. Prototyperspective (talk) 00:01, 17 October 2025 (UTC)

Created Commons:Bots/Work requests#Merging audio files of audiobooks. Prototyperspective (talk) 14:42, 6 November 2025 (UTC)

One reason is that only one part audio files can be featured as Media of the Day and that instead of cluttering a Wikipedia page with lots of audio parts, it should be just one file (and some templates may only allow for one or a few audios). It also makes it easier to correct/update/improve the description, metadata and categories and to add it to Wikidata items. Prototyperspective (talk) 16:42, 2 December 2025 (UTC)

NASA videos imported at low quality

I noted Kesäperuna recently reuploaded this old video that was recently featured on the frontpage where I remember I was a bit surprised about the sometimes blurry resolution: File:Measuring Elevation Changes on the Greenland Ice Sheet.webm (thanks for that!)

When going to the video source (the sourced linked in the first link is 404 by now so the source of the webm reupload) and clicking on the Download button, the only webm available there is 62 MB, not 110 MB like in the new file uploaded to Commons.

So it seems like sometimes or often NASA doesn't make videos available in full resolution as webms and it's been these videos that have been imported here. Kesäperuna probably downloaded another file and then converted it.

I then also noticed the new video File:At Land's Edge - Tracking Coastal Ecosystem with Landsat (SVS14903).webm imported by OptimusPrimeBot operated by Don-vip looks quite blurry and tested whether I'd get a better version if I download the mp4 file and convert it to webm locally on my machine using ffmpeg. As you can see in the File history of that file, the new video is of much better resolution and about 5 times the size (click on the prior version to see the difference). Thus, I think many NASA or even PD-US-gov videos may have been imported at submax resolution.

I think many of these videos are some of the most educational, most useful and partly most-used videos we have on Commons, so I think they should probably be on Commons at full resolution where if necessary and as adequate only the default playback quality is changed but not the max-resolution kept low. At the very least the fraction of NASA videos that are featured in MOTD or in use on any other Wikimedia project like Wikidata or Wikipedia (but probably all of them).

How do you think would be the best way to fix the low-resolution of these videos? That would be a two-step process of 1. identifying which videos have been imported at submax resolution and 2. importing a higher-resolution video (directly if available or via downloading the maxres video and converting it to webm locally. Could somebody implement this?

I don't know if the max-resolution video is by now usually available as mp4 but if so it may also make sense to wait until mp4 files get accepted on Commons if that's just a few more years(?) If somebody could import highres versions of these files, that would be great either way! Prototyperspective (talk) 17:55, 17 October 2025 (UTC)

Yes, this is a problem. The original WebM file is remarkably small. Then there is a standard quality version in an unfree codec, and a MOV (ProRes 444 or so) file with astronomical file size. If it is a managable amount of files, I can help converting and reuploading, as my machine can roar like a lion :) (works very fast). As we don't have videos beyond 8192 pixels wide or tall, this is no problem :) --19:05, 17 October 2025 (UTC) PantheraLeo1359531 😺 (talk) 19:05, 17 October 2025 (UTC)

For the encoding from other formats, video2commons should now (since yesterday) be able to upload videos with a good size/quality ratio (thanks to Amdrel contribution). To identify the videos that need a reupload however, I have no idea. vip (talk) 22:42, 17 October 2025 (UTC)

Does anybody have an idea how to identify videos with lower or much lower quality than available at source?

Prototyperspective (talk) 18:46, 3 December 2025 (UTC)

Good that you noticed and started this thread, better to have more eyes on this issue.

Firstly, NASA svs website changed url format from https://svs.gsfc.nasa.gov/goto?4022 to https://svs.gsfc.nasa.gov/4022.

I did couple more videos that were used in articles with most views in category Videos from NASA, that were in poor quality and had better versions available.

Highest quality "master" format in NASA website is very varied, sometimes it's mp4 file, mpeg2 file, or prores mov, I used best version available and encoded to AV1/Opus format with reasonable settings(depending on video in question, as most videos have visible mpeg2 artifacts in prores master files for some reason) to keep file sizes smallish.

What should be done to videos uploaded in different format such as ogv that are promoted to MOTD or have other "awards" associated with them, can they be just redirected to better webm version? Kesäperuna (talk) 00:01, 18 October 2025 (UTC)

I think, yes. OGV is outdated, probably not the most suitable codec for UHD content, and WebM (with AV1) is state-of-the-art. I can imagine there is a "replace" voting system for featured media, too. --PantheraLeo1359531 😺 (talk) 16:36, 18 October 2025 (UTC)

Thanks for the info. It may be useful if somebody replaced all those links with the new format using VisualFileChange. Good idea to replace the ones with most views first and right away. I think the old file can simply be deleted and redirect to the new webm file per F8. Twinkle has something about the file format but the actual policy doesn't require it to be it of the same file format. However, I'm not sure if it can technically be done currently – maybe it's only possible for files of the same file format. I'll tag the low-res file at a later point – would like to have it stay as is for a while so people can still see the file in the context of this issue/thread. I think many files are affected by this so I think it was best if this wasn't done manually but via some script or so. One of the difficulties with that though is that it doesn't seem like one can download the highest quality file with some standardized url like e.g. appending ?dl=hd https://svs.gsfc.nasa.gov/4022?dl=hd. Prototyperspective (talk) 22:11, 20 October 2025 (UTC)

F8 says “exact or scaled-down duplicate of an older existing file”. If the scaled-down duplicate is the older one, it does not apply; the OGVs should not be deleted in order not to break external usage (which we cannot track down and fix). Please add {{Superseded}} to the description pages of the OGVs instead of getting them deleted. —Tacsipacsi (talk) 16:08, 7 November 2025 (UTC)

Thanks; maybe that phrase should be changed then: the old file could be turned into a redirect to the higher-quality file so the uses would not break. Prototyperspective (talk) 16:40, 7 November 2025 (UTC)

Some of them do break: hotlinking to the https://upload.wikimedia.org files doesn’t follow redirects, so it’s the external, non-wiki usage (i.e. usage that doesn’t come from first- or third-party MediaWiki installs) that suffers the most. —Tacsipacsi (talk) 22:15, 7 November 2025 (UTC)

Template:Shortcut not showing

The {{Shortcut}} box isn't showing on any of the pages it's being used. Could somebody please fix this? Prototyperspective (talk) 13:52, 29 October 2025 (UTC)

Moved to this new page for template requests: Commons:Template requests#Make template Shortcut show again. Prototyperspective (talk) 14:34, 2 November 2025 (UTC)

I don't see what the use of that template even is if it's not showing. Note that many of the policy pages using this don't have an additional {{Shortcut2}} template that is showing so the shortcuts aren't visible to the readers. Prototyperspective (talk) 16:43, 2 December 2025 (UTC)

Empty files in Flicker2Commons

I successfully uploaded some hundreds of files by F2C today, but then the infamous empty file error started to appear (The file you submitted was empty.) [ 1, 2, 3, 4, 5, 6, 7 ] I know that {{Magnus is not here}}, but Magnus Manske isn't anywhere, not at his talkpage, not at bitbucket... Does anyone know, what can I do to make F2C to upload photos. (Logging off/clearing the cache didn't help.) Otherwise I think, that in these case someone (?some WM branch/WMF) should intervene, as the maintainer isn't willing to maintain his own tools (same for U2C, WikiShootMe...). — Draceane ^talk_contrib. 14:30, 3 November 2025 (UTC)

@Οἶδα, 6D, Karl Gruber, and Thyj: FYI. — Draceane ^talk_contrib. 14:31, 3 November 2025 (UTC)

Here, it also affect the FlickreviewR 2 bot. 6D (talk) 15:21, 3 November 2025 (UTC)

So, some API problem at Flickr side? (Commons_talk:Flickypedia#Cannot_login) — Draceane ^talk_contrib. 17:22, 3 November 2025 (UTC)

I wish I knew the workaround to this recurring issue. The only solution that has ever worked for me is to wait it out, and occasionally wait much longer I would like. Οἶδα (talk) 23:16, 3 November 2025 (UTC)

That sounds to me as if flickr is blocking the api request to deal with an influx of data at their end (aka rate limiting) —TheDJ (talk • contribs) 19:01, 18 November 2025 (UTC)

It is not only affect you, it is everyone who use Flickr2commons bot. 6D (talk) 06:27, 9 November 2025 (UTC)

Any way to interlink other versions for many files?

At Special:ListFiles/Distribution Wissen SRF you can see that the same 15 useful explainer videos were uploaded in German, French, and Italian. However, they don't link to each other in file description in the other_versions field of {{Information}}. Is there a way to add this to many files at once or have it somehow be automatically added?

See also {{Otherversion}} and this idea for UploadWizard. Is the only way to add it by manually going through each file to add the interlinking? This is of course not the only case of files in multiple languages not linking to each other. If a person not understanding language X well or at all doesn't see it linked at the file but would understand language Y well, they likely won't notice/learn that this video also exists. Prototyperspective (talk) 17:34, 6 November 2025 (UTC)

The same problem also exists for files Special:ListFiles/RTS Radio Télévision_Suisse.

Moreover, most of these would probably be good to add to the Wikidata item about the subject – can this be done in bulk somehow? (I mean at least the 3 language version files at once per item.) Prototyperspective (talk) 15:37, 17 November 2025 (UTC)

I am not sure that it is exactly what you are looking for because there is not so much automation but there are galleries. Example DustDFG (talk) 05:54, 3 December 2025 (UTC)

@Prototyperspective and do not overlook Template:Edit_other_versions in the example DustDFG (talk) 06:02, 3 December 2025 (UTC)

I've also just found that gallery syntax maybe is not only possible... There is also Template:Other_versions and now I am confused... DustDFG (talk) 06:06, 3 December 2025 (UTC)

Way to mark files that got a new revision but still have same date?

Many data graphics like charts or choropleth map get updated via new revisions. However, the value in the date field usually stays the same.

This is problematic to users who look at the file information template and then see another date than the year the data graphic was released. This is confusing and especially so if the date there is not before the latest data point (which would make that date impossible). Apps and tools could also use this false information and display (or otherwise use) it, for example the Commons app, scrapers, or Web search engines. The structured data would also still have the false data.

Is there a way to display for example a warning next to the value in the date field when the file has multiple revisions and that date wasn't changed?

Maybe one could also prompt the user whether the date changed after a new revision was uploaded to reduce the number of these cases in the future? Another way would be to identify the files with a likely false date due to new revision uploads and correct these. But even if that was done, having a small warning display next to the date would be good: for example, a warning icon that when hovered over says "A new revision of the file was uploaded, this date may be outdated" (and it would be best if users could make the warning go away if the date is still correct or was updated).

Many and ultimately most of the files affected by this may be in Category:Charts by year of latest data and Category:Maps by year (the corresponding subcat is changed when a new revision has newer data).

It may be best and easiest to understand this with some examples:

• File:Mean-seawater-ph.png was updated in 2023 with data for 2021 but it still has the date of the release of the chart of the first revision, 2019
• File:Chick culling laws world map.svg has 2020 in the date field but the latest revision is from 2025, including probably legal changes made after 2020
• File:World laws pertaining to homosexual relationships and expression.svg gets frequently updated via new revisions and has it solved by appending (upload date) to the date in the date field. Similar for this.

Prototyperspective (talk) 00:19, 7 November 2025 (UTC)

It's not just datagraphics but sometimes also other images – I think most often screenshots. Example:

• File:Abe lincoln on app.jpg (comment for the new revision upload: Updated, interface of app changed a lot since 2017/2019 and so has the article.) – it has 2017 in the date field but is a 2025 screenshot.

Prototyperspective (talk) 16:39, 2 December 2025 (UTC)

Lots of Wikipedia articles using low-quality superseded files …but glamorgan & glamorous fail

For many files, a new version has been uploaded as a separate file. It usually is of substantially higher resolution, more translatable / editable, and of the better filetype SVG. However, often the Wikipedia articles that use the old file have not been edited. In addition, some users may still use of the now legacy file because a note about it was missing earlier or they didn't/couldn't read it.

Here's an example:

• 
  New SVG version with high resolution and very translatable
• 
  Old version still used in 9(!) mainspace Wikipedia articles

Usually, one could do a scan of uses of files in a category with the glamorgan or glamorous tools. It would be very useful for Category:Superseded or Category:Vector version available which are added to files like the second one above via a template.

However, for these two categories where either tool would be most useful, they don't work.

Does somebody know why or how to get either or both to work for a report of file uses of superseded files?

--Prototyperspective (talk) 23:39, 7 November 2025 (UTC)

It says Results Category "Category:Superseded " has 0 files. at glamorous. When clicking on the link "Git" in the upper right, it's difficult to find the issue tracker and it is not on github or gitlab but bitbucket. It doesn't look like the developer is interested in people helping with the development. I've created an issue for this but I already had created 3 issues there earlier about glamorous v2 and they don't show up because it seems like it needs the issue status to be changed and the tool developer is not even doing that.

Issue: https://bitbucket.org/magnusmanske/glamtools/issues/293/glamorous-category-has-0-files-but-it-has
Prototyperspective (talk) 20:55, 4 December 2025 (UTC)

Deepcat search

Tracked in Phabricator
Task T410440

What's going on with deepcat search recently? It stops showing the results when scrolling with "Deep category search SPARQL query failed" message under the search box. Qbli2mHd (talk) 10:36, 8 November 2025 (UTC)

Could you give some example category/ies? See also phab:T395348. Prototyperspective (talk) 11:42, 8 November 2025 (UTC)

It's any scrollable search really, like [1]. The behaviour is unpredictable, you could manage to have the results loaded several times or get an error on the next screen. Qbli2mHd (talk) 02:19, 9 November 2025 (UTC)

Could you create an issue on phabricator? I could scroll down and it did load more images and I could click on the Load more button but eventually after scrolling just a bit it shows "No more results found" at the bottom and the error message you wrote at the top (it didn't show when only the first set of images showed) before the 1,842 files of that example deepcat search were shown. Thanks for reporting this problem here. Prototyperspective (talk) 20:58, 9 November 2025 (UTC)

phab:T410440 Qbli2mHd (talk) 18:38, 18 November 2025 (UTC)

Flickr2Commons sometimes struck

For some reason, the Flickr2Commons have been struck for few hours now. 6D (talk) 10:57, 10 November 2025 (UTC)

Resumed, and then got stuck again. Zhuyifei1999, who runs this bot, has not been heard from in months. Is there anyone who can restart the bot? - Jmabel ! talk 06:06, 12 November 2025 (UTC)

And now it is running again. - Jmabel ! talk 06:32, 12 November 2025 (UTC)

And it is struck again!!!!!!!! 6D (talk) 06:30, 13 November 2025 (UTC)

Do you mean stuck or struck? If the latter, what do you mean. Misspelling makes it difficult for others to quickly understand what you mean and this is also in the title. In any case this seems like something to report at Commons talk:Flickr2Commons. The recent threads that could be about this there describe the problem as it showing The file you submitted was empty. – is this a new separate problem or the same problem? The issue tracker seems to be https://bitbucket.org/magnusmanske/flickr2commons If nothing helps, a wish in the m:Community Wishlist could be created if this is deemed important to fix and nothing much is happening already to solve this. Prototyperspective (talk) 10:41, 13 November 2025 (UTC)

Tech News: 2025-46

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

Example of a talk page with the new design, in French.

• Starting November 12, users will see a change in the appearance of talk pages on some Wikipedias. Almost all wikis have received this design change; English Wikipedia will get these changes later. You can read more on Diff. Users can opt out of these changes in their user preferences in "Show discussion activity". [2]
• MediaWiki can now display a page indicator automatically while a page is protected. This feature is disabled by default. It can be enabled by community request. [3]
• Using the "Show preview" or "Show changes" buttons in the wikitext editor will now carry over certain URL parameters like 'useskin', 'uselang' and 'section'. This update also fixes an issue where, if the browser crashed while previewing an edit to a single section, saving this edit could overwrite the entire page with just that section’s content. [4][5][6]
• Wikivoyage wikis can use colored map markers in the article text. The text of these markers will now be shown in contrasting black or white color, instead of always being white. Local workarounds for the problem can be removed. [7]
• The Activity tab in the Wikipedia Android app is now available for all users. The new tab offers personalized insights into reading, editing, and donation activity, while simplifying navigation and making app use more engaging. [8]
• The Reader Growth team is launching an experiment called "Image browsing" to test how to make it easier for readers to browse and discover images on Wikipedia articles. This experiment, a mobile-only A/B test, will go live on English Wikipedia in the week of November 17 and will run for four weeks, affecting 0.05% of users on English wiki. The test launched on November 3 on Arabic, Chinese, French, Indonesian, and Vietnamese wikis, affecting up to 10% of users on those wikis. [9]
• View all 27 community-submitted tasks that were resolved last week. For example the inability to lock accounts on mobile sites has been fixed. [10]

Updates for technical contributors

• Nominations are open on Wikitech for new Toolforge standards committee members. The committee oversees the Toolforge Right to fork policy and Abandoned tool policy among other duties. Nominations will remain open through 2025-11-28.
• The JWT issuer field in OAuth 2 access tokens for SUL wikis has been changed to https://meta.wikimedia.org. Old access tokens will still work. [11]
• The JWT subject field in OAuth 2 access tokens will soon change from <user id> to mw:<identity type>:<user id>, where <identity type> is typically CentralAuth: (for SUL wikis) or local:<wiki id> (for other wikis). This is to avoid conflicts between different user ID types, and to make OAuth 2 access tokens and the sessionJwt cookie more similar. Old access tokens will still work. [12]
• MediaWiki's block messages (blockedtext, blockedtext-partial, autoblockedtext, systemblockedtext, blockedtext-tempuser, autoblockedtext-tempuser) now support additional parameters indicating whether the user is blocked from editing their own user talk page $9 or emailing other users $10. [13]
• A REL1_45 branch for MediaWiki core and each of the extensions and skins in Wikimedia git has been created. This is the first step in the release process for MediaWiki 1.45.0, scheduled for late November 2025. If you are working on a critical bug fix or working on a new feature, you may need to take note of this change. [14]
• The process for generating CirrusSearch dumps has been updated due to slowing performance. If you encounter any issues migrating to the replacement dumps, please contact the Search Platform Team for support. [15][16]
• 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 20:35, 10 November 2025 (UTC)

I think the automatic protection icon feature can be useful here in Commons. This means we don't have to manually place {{Protected}} in protected pages anymore. Tvpuppy (talk) 22:46, 10 November 2025 (UTC)

Palacios en la Comunidad de Madrid

Palacios en la Comunidad de Madrid has no images - what's wrong? --~2025-33091-77 (talk) 15:56, 12 November 2025 (UTC)

I think I fixed the first image but I do not have time to fix all of them now. Ymblanter (talk) 16:22, 12 November 2025 (UTC)

As the page says This list is periodically updated by a bot. Manual changes to the list will be removed on the next update! so please don't manually edit the contents. Prototyperspective (talk) 12:11, 13 November 2025 (UTC)

My edits were indeed overwritten by a bot, so that I am not going to edit it again.--Ymblanter (talk) 15:42, 13 November 2025 (UTC)

Tracked in GitHub
magnusmanske/listeria_rs/issues/82

This is the problem described at /Archive/2025/03#Can the Listeriabot be fixed? which was just archived without being solved.

The outcome of that discussion so far mostly is that this is caused by bug https://github.com/magnusmanske/listeria_rs/issues/82 […] reported in 2021. ListeriaBot does not produce correct wikitext when row_template is used. Since this depends on somebody fixing this in the listeria code, the route to get it solved may be devs here doing so or asking Manske about it and/or supporting wish m:Community Wishlist/Wishes/Continue development of the Listeria bot that creates dynamic tables using Wikidata (0 supporters so far, thanks).

Looks like 45 galleries are affected by this in the same way. Prototyperspective (talk) 12:21, 13 November 2025 (UTC)

I added this issue on Commons to the examples of flaws that need fixing in the wish at produces galleries like this with no images on Commons (#82), etc. If you want this bug to be fixed, I recommend voting on that wish which can also be picked up by any volunteer. Prototyperspective (talk) 21:06, 4 December 2025 (UTC)

Special name space redirect

Tracked in Phabricator
Task T410518

There used to be a page in the special name space called OAuthConsumerRegistration/propose. It no longer exists, as OAuth Consumer Registration proposals are now dealt with on Media Wiki for all Wikimedia projects. The current version of Open Refine isn't up-to-date, and it points to https://commons.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose. That's not helpful, as you get told that "you have requested an invalid special page". What would be more useful is for there to be a redirect that points to the relevant page on Media Wiki instead, which is here. I wonder whether admins, or whoever else has the right privileges, could edit the Special:OAuthConsumerRegistration/propose page and set up a redirect that points to the right spot on Media Wiki. Schwede66 00:39, 16 November 2025 (UTC)

No, pages (including redirects) cannot be created in the Special: namespace at all, regardless of permissions. You could request that a redirect be added at meta:Phabricator; however, given that this link only appears in one place, having it corrected there may be more productive. Omphalographer (talk) 21:12, 16 November 2025 (UTC)

I've never provided feedback to OpenRefine before. I've done so now. No idea how often they update their software. Schwede66 22:39, 16 November 2025 (UTC)

Not sure but I think this might be caused by gerrit:1191860. Nemoralis (talk) 04:31, 17 November 2025 (UTC)

Filed as T410518. Tgr (WMF) (talk) 15:27, 19 November 2025 (UTC)

Category missing in all of a cat's subcats

I noticed at Category:Electricity production trends in the United Kingdom that the category is missing the category Category:Charts of the United Kingdom.

The Electricity production trends categories don't have a template so all their categories are set not via template but separately on all the categories.

Is there a way to add [[:Category:Charts of ''name of country'']] (where name of country is simply whatever comes after "Electricity production trends in" in the category title)) to all of these categories without having to go through all the categories and adding it manually?

If not, is there a tool to which this functionality could possibly be added? Prototyperspective (talk) 11:41, 17 November 2025 (UTC)

Another example is that I'd like to add the navbar that's included in Category:Videos of short films from 2024 to all subcats of Category:Videos of short films by year. The only thing that varies there for every 10 cats is |decade=202 and it would already suffice if one could add this for 10 cats at a time from the parent category page with an interface like Cat-a-lot. Prototyperspective (talk) 21:58, 7 December 2025 (UTC)

Tech News: 2025-47

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 Reader Experience team is experimenting with reading lists on mobile web, allowing logged-in readers with no edits to save private lists of articles for later. The experiment is running on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias since the week of 10 November, and will begin on English Wikipedia the week of 17 November.
• Users who can’t receive their email verification code during login can now get help by submitting a form on a new special page. This update is part of the Account Security initiative. If your account has an email address, please make sure you still have access to it. When logging in from a new device or location without 2FA, you may be asked to enter a 6-digit code sent by email to finish logging in. Learn more.
• One new wiki has been created: a Wikisource in Minangkabau (s:min:) [17]
• View all 23 community-submitted tasks that were resolved last week.

Updates for technical contributors

• As part of the Parser Unification project, the Content Transform Team rolled out Parsoid as the default parser to many low-traffic Wikipedias and is preparing the next step to high traffic ones. This message is an invitation for you to opt-in to Parsoid, as described in the Extension:ParserMigration documentation, and identify any issues you might encounter with your own workflow using bots, gadgets, or user scripts. Please, let us know through the "Report Visual Bug" link in the Tools sidebar or create a phab ticket and tag the Content Transform Team in Phabricator.
• Unsupported Tools: Several issues with Video2Commons have been fixed, including filename-related upload failures, black-video imports, and retry handling. AV1 support has also been added. Ongoing work focuses on backend stability, ffmpeg errors, subtitle imports, metadata handling, and playlist uploads. To track specific tasks, check the Phabricator board.
• Detailed code updates later this week: MediaWiki

Meetings and events

• Save the date for the next Wikimedia Hackathon happening in Milan, Italy from May 1–3, 2026. Registration will open in January 2026. Scholarship applications are currently open, and will close on November 28, 2025. If you have any questions, please email hackathon@wikimedia.org.

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

MediaWiki message delivery 17:23, 17 November 2025 (UTC)

Unsupported Tools: Several issues with Video2Commons have been fixed That's great news! Thanks to everyone involved. However, I think this belongs into section "Updates for editors", not "Updates for technical contributors". To track specific tasks, check the Phabricator board. As explained on the talk page of the meta page about this ongoing effort, the phabricator board doesn't contain most v2c tasks – those are on GitHub here. So if that issue tracker isn't linked, its issues I think need to be imported to phabricator. Prototyperspective (talk) 18:45, 17 November 2025 (UTC)

File uses at Wikiradio not showing

m:Wikiradio (tool) is for playlists of audio-files. It only links to files via wikilinks instead of embedding the audios.

Is there a way for the used tracks to show the use at Wikiradio in the File use sections of the audios here? This would enable way more people to learn about this tool and to find wikiradio stations of similar audios as the one they're interested in. Audios on Commons are usually short and stop after you played them, with wikiradio you can listen to playlists that continue to play. Prototyperspective (talk) 23:19, 17 November 2025 (UTC)

No this is not possible. That tool essentially works the same way as downloading to your desktop works and we cant show that either. —TheDJ (talk • contribs) 18:56, 18 November 2025 (UTC)

The only thing we can know about, is the linking to its description page, which is registered via WhatLinksHere as is standard. Example: Special:WhatLinksHere/File:Pachelbel's Canon.ogg —TheDJ (talk • contribs) 18:58, 18 November 2025 (UTC)

Yes so I think it's technically possible but maybe not with how things currently are. There could be some relevant change to Wikiradio (e.g. embed files instead of linking to them on the page or specify the files on Commons instead of on meta) or to MediaWiki.

WhatLinksHere doesn't show the places where it's wikilinked from other projects, only those wikilinks on Commons. Prototyperspective (talk) 19:10, 18 November 2025 (UTC)

@Prototyperspective: I think one approach might be to change the playlist pages to use <gallery> to list the files. That would cause them to show up through the usual mechanism for showing pages that are in use on other wikis. This might need some changes to Wikiradio itself so that it can read galleries. --bjh21 (talk) 20:09, 21 November 2025 (UTC)

That would be an idea but I think it would make the playlist page less readable than plain hyperlinks to the files which e.g. for music are usually artist name - song name. On the other hand, one could still see these by clicking the edit button and looking at the wikitext and having these playlists very readable isn't quite important. Navigating to the file would become more difficult. I'll create an issue in the repository for WikiRadio. However, it doesn't seem like there's any developer actively looking into these and developing it further. The bigger problem is that it can't play mp3 files (anymore?) and that didn't get fixed so far despite this being the most common audio format nowadays. This is probably the larger reason why I was looking for an alternative solution if one is possible. Prototyperspective (talk) 20:21, 21 November 2025 (UTC)

"Geograph from structured data" template doesn't work for derivative files via CropTool

I've run into this problem before. I used CropTool on an image originally imported from the Geograph project- File:Crompton Parkinson Factory Clock - Netherfield Road - geograph.org.uk - 3207039.jpg- but the cropped/derivative version- File:Crompton Parkinson Factory Clock - Netherfield Road - geograph.org.uk - 3207039 (cropped).jpg- doesn't copy and display the file information correctly.

The original doesn't use a regular {{Information}} template and instead relies on {{Geograph from structured data}}. This is then copied to the derivative/cropped version, but doesn't work there, the problem presumably because the structured data it relies upon isn't automatically transferred?

Cutting and pasting the information manually would be enough of a nuisance in itself, but even figuring out how to do so in the first place is far from straightforward since {{Geograph from structured data}} gives no indication of that. The onus should *not* be on the end user to do so, at least not without prior warning.

At the risk of stating the obvious, this situation clearly isn't satisfactory. Ubcule (talk) 12:49, 18 November 2025 (UTC)

@Ubcule I agree with you that some SDC data should be copied when cropped, but unfortunately CropTool currently doesn't have this feature.

In the meantime, you can use Commons:MoveClaim Tool to copy SDC data from one file to another, which should save a lot of time by not having to manually do it. Note that the tool doesn't appear to work if there is no SDC data, so you may have to begin by adding at least one SDC claim (e.g. caption). Thanks. Tvpuppy (talk) 19:50, 18 November 2025 (UTC)

@Tvpuppy: - That seems to mostly work, so thank you for your help!

While the implied criticism below certainly isn't aimed at you (you were helpful and did your best with the current setup and the onus isn't on you to provide a proper solution to someone else's problem), this is still a clunky semi-manual workaround that, while a helpful improvement and usable for more technical users like ourselves, still isn't really a proper, acceptable solution for general use.

I'm not sure whose responsibility this problem is; CropTool's for not copying over the structured data (is it required or expected to?) or the {{Geograph from structured data}} template's, and those who forced the use of that template for Geograph imports rather than the standard infobox.

Given the Geograph template also has the problem that- as far as I can tell- it's not editable directly (only via the structured data) and thus doesn't- and can't- integrate properly with things that *would* normally go in the infobox (e.g. {{Image extracted}} has been simply plastered below), I'm not inclined favourably towards it or its use, as it seems to be the primary cause of the problem.

Ubcule (talk) 13:20, 19 November 2025 (UTC)

I don't have experience with this tool but isn't it the case that not always the SD should be copied as the crop could display something else (say just a pencil in a photo of a building where location is set)? So it would have to prompt the user whether (or which?) SD should be copied. If it's still adequate to set this in CropTool, please create a code issue for CropTool in its issue tracker, thanks. Prototyperspective (talk) 11:14, 3 December 2025 (UTC)

Technical issue

Tracked in Phabricator
Task T393287

On the Special:ListFiles pages, can we add selection buttons for choosing a specific date range? such as from 12 December 2012 to 11 November 2013, which makes it easier to view the photos the uploader uploaded. Huangdan2060 (talk) 02:16, 20 November 2025 (UTC)

phab:T393287. Nemoralis (talk) 11:03, 21 November 2025 (UTC)

Some recent improvements to Video2Commons

As some of you may know, the WMF allocated a small budget for a contractor to address some Commons tool issues. This is less than a lot of us would have hoped for, but it is definitely more than nothing. I was among the small group who were consulted as to where this should be allocated. We and they chose Video2Commons was chosen because, as against the other likely possibilities, there seemed to be a fair chance of a contractor making progress without needing a deep, broad understanding of Commons in general. Status is at meta:Product and Technology Advisory Council/Unsupported Tools Working Group. - Jmabel ! talk 16:18, 21 November 2025 (UTC)

Truly great to see the progress there. And that's solid reasoning regarding the decision-making. I hope more improvements to Commons-related tech will be made also in similar ways. Prototyperspective (talk) 20:24, 21 November 2025 (UTC)

Potential changes to MediaWiki:Protectedpagewarning

I'd like to propose that we replace the contents of that interface message with User:JJPMaster/MediaWiki:Protectedpagewarning. The current version describes any non-semi-protection--template, autopatroller, or full protection--as "only administrators can edit." My version accounts for the multiple protection levels. I also added wikilinks for all the relevant user groups, which were absent in the original. JJP_Master (she/they) 05:40, 24 November 2025 (UTC)

@JJPMaster: Your version doesn't seem to handle semi-protection and cascading protection. Is that intentional? NguoiDungKhongDinhDanh 06:12, 24 November 2025 (UTC)

@NguoiDungKhongDinhDanh: Yes. Semi- and cascading protection are handled by MediaWiki:Semiprotectedpagewarning and MediaWiki:Cascadeprotectedwarning respectively. JJP_Master (she/they) 06:16, 24 November 2025 (UTC)

Tech News: 2025-48

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

• Last week, the Wikimedia Search Team recreated the "DWIM" (Do What I Mean) gadget functionality server-side, for Russian and Hebrew Wikipedias. This feature adds cross-keyboard suggestions to the standard search-box suggestions. For example, searching for cxfcnmt on Russian Wikipedia will now add suggestions for счастье ("happiness") that the user probably intended. They plan to enable this feature for other Russian and Hebrew wikis this week. [18]
• Later this week, users of the "Improved Syntax Highlighting" beta feature will have syntax highlighting available in DiscussionTools. This requires that the "Enable editing tools in source mode" preference be set. [19]
• Campaign events extension – the set of tools for coordinating events and other on-wiki collaborations has now been deployed to all Wikimedia wikis. A new feature known as Collaborative contribution to help organizers and participants see the impact of activities has also been added. Join the upcoming learning session to see the new feature in action and share your feedback.
• View all 24 community-submitted tasks that were resolved last week. For example, the bug which stopped CodeReviewBot from working, has now been fixed. [20]

Updates for technical contributors

• Users of Wikimedia API can join a usability study to help validate the new design of Wikimedia REST API sandboxes. Interested participants should fill the recruitment survey. [21]
• The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support for format=xml&xlst={stylesheet} will be removed from Wikimedia projects by the end of November, 2025. In addition, it will soon be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44, and v1.45. Support for XSLT stylesheets will be fully removed from MediaWiki v1.46 (expected to release between April and May 2026). [22]
• The WDQS legacy endpoint (query-legacy-full.wikidata.org) will be decommissioned at the end of December 2025, and finally closed down on 7th January 2026. After this date, users should expect requests to query.wikidata.org that require the full graph to fail or return invalid results if they are not rewritten to use SPARQL federation. The team encourages users to ensure that tools and workflows use the supported WDQS endpoints (https://query.wikidata.org/ - Main graph or https://query-scholarly.wikidata.org/ - Scholarly graph). For support with migrating use cases, please review the Data Access and Request a Query pages for details and assistance on alternative access methods.
• 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 15:53, 24 November 2025 (UTC)

Template bug on crops of deleted copyvios

There appears to be a bug in the {{Extracted from}} template that's causing cropped images to wrongly describe their source image as having been "deleted for reasons that do not affect this image", when that source file has been deleted. The cropped image is presented to the user as if it has no problems at all, and can still be used.

For example, File:Prince Hamzah.jpg, a photo taken from social media, was deleted for lacking permission a few days ago. But File:Prince Hamzah (cropped).jpg, a crop of it that links back to the original, still exists and now confidently says:

This image has been extracted from another file: Prince Hamzah.jpg. The source file was deleted for reasons that do not affect this image, like a derivative work which is not a part of this cropped image.

(I've now manually flagged this crop as also lacking permission.)

This appears to be a mistake in the {{Extracted from}} template that was introduced in 2021, flagged on the template talk page in 2022 and is still unfixed. It seems to be assuming that all missing source files were deleted "for reasons that do not affect this image", when the template can't actually know that: the only information the template has is that the source no longer exists.

Can somebody with a better understanding of templating and the deletion process take a look at this? Belbury (talk) 12:42, 25 November 2025 (UTC)

It's not always the case that a crop is a copyvio if the parent image is; it may be that one half was a copyvio and the crop removed that.

The presumption is that cropped images that are still copyvios will be deleted when the parent image is deleted; and thus that the template only applies to crops without copyvios. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:18, 25 November 2025 (UTC)

I suppose the question is how often admins delete images without checking if any cropped versions also need to be deleted.

Is it safe to assume it's rare enough that we're saving admins a significant amount of work by having this template automatically mark all surviving crops as source file was deleted for reasons that do not affect this image, even if that's giving us some false positives? Belbury (talk) 16:04, 25 November 2025 (UTC)

It seems to be assuming that all missing source files were deleted "for reasons that do not affect this image" Why should it not. If the extracted images is still there and hasn't also been deleted, then one can assume this. I think it would be better to ask about / work on / raise awareness about copyvio file deletions also checking for extracted files. Prototyperspective (talk) 17:10, 25 November 2025 (UTC)

It's not lining up if we're assuring users that the stated licence is valid because the source was deleted for reasons that do not affect this image, but we're also categorising them into the backlogged Category:Extracted images with broken file links and asking experienced editors to check them all.

If we're confident that admins check for linked crops every time and best practice is to let the template handle the switch from {{Extracted from}} to {{Extracted from deleted}} automatically, we shouldn't be filing these into a heavily backlogged "priority to check" category, should we? Belbury (talk) 09:16, 26 November 2025 (UTC)

One could also have a parameter in the template that can get changed when the image got checked. However then I think it needs some change to a gadget that allows reviewing files with the click of a button. The template edit request could be made at Commons:Template requests. Prototyperspective (talk) 13:53, 26 November 2025 (UTC)

Rename

Can you rename File:Wohnhaus_Kirchplatz_1.jpg please to File:Tauchritz Kretscham mit Hauptbau, Saalbau und Nebengebäude Kirchplatz 20.jpg. Regards, Sanisconokow (talk) 14:38, 29 November 2025 (UTC)

@Sanisconokow: Done. In future you can mark your own uploads for renaming using the "Move" link. See COM:FR for details. --bjh21 (talk) 15:41, 29 November 2025 (UTC)

Ah ok, it is missing at mobile page... Thank you Sanisconokow (talk) 18:48, 29 November 2025 (UTC)

Is it really missing in the mobile Web version of Commons? If so, please create a code issue on phabricator to show the hyperlink also on mobile (and then link it here using {{Tracked}}). Prototyperspective (talk) 11:25, 3 December 2025 (UTC)

Can do this, but I have to wait till February. Maybe you are more fast in this. Regards, Sanisconokow (talk) 16:03, 3 December 2025 (UTC)

Display bug for usernames in "File history" section of file pages

Tracked in Phabricator
Task T411304

I just noticed in the "File history" section of file pages (example: File:Hungry Howie's on Pensacola Street, Tallahassee, Florida.jpg, but it's doing it on all pages that I can see), that it's now doing this with my username. I'm pretty sure it didn't used to break like this, and it looks like there should be plenty of room for it in the box without breaking. I'm guessing something got changed in the backend somewhere? - The Bushranger (talk) 23:26, 29 November 2025 (UTC)

I have the same problem for my uploaded files. Also a break before the last letter. It looks like there is same sort of nbsp in the space --PantheraLeo1359531 😺 (talk) 09:51, 30 November 2025 (UTC)

• This now appears to be fixed, thank you! - The Bushranger (talk) 02:39, 4 December 2025 (UTC)

Image thumbnail problem

Could take anyone a look at File:Vittore Carpaccio - Young Knight in a Landscape - Google Art ProjectFXD.jpg. For some reason the image doesn't show up in any page, where it's used. Armbrust (talk) 17:07, 30 November 2025 (UTC)

All i see in the logs i have access to is a bunch of "first byte timed out" errors. Would probably need to file a bug on phabricator to get it more investigated. If the file is a progressive jpeg, try uploading as a baseline jpeg. Bawolff (talk) 20:03, 30 November 2025 (UTC)

Fixed by Yann (thanks!) with the following comment/explanation: c:User:Rillke/bigChunkedUpload.js: baseline instead of progressive. How to see more files affected by this issue so they can be fixed as well or alternatively is there a code issue about making also such progressive files show up properly? Prototyperspective (talk) 11:28, 3 December 2025 (UTC)

Essentially the issue is that progressive jpeg take much more memory to resize, so large files are much more likely to time out. Bawolff (talk) 16:31, 3 December 2025 (UTC)

Here is a list of some files with rendering failures according to the logs (Note that this is only a sample based on files that someone tried to look at at a specific point in time, so consider this list to be rather incomplete. Its also possible other unrelated errors could make a file show up on the list. For many of them, the failures are only at very large sizes, e.g. an 8000px thumbnail):

Bawolff (talk) 18:52, 3 December 2025 (UTC)

Thanks! I put the list into a collapsed template (mainly for those users who scroll through this page) – hope that's okay (if not just remove it).

Is there an issue on phabricator about this already? Especially when considering how many files are affected. And do you know of a way to bulk correct the files or to change the thumbnail code to make also those display? Maybe rerunning the code to resize them (not sure if you mean resizing the thumbnail or sth else) if it timed-out earlier? Prototyperspective (talk) 22:20, 3 December 2025 (UTC)

Its somewhat expected that edge cases happen with thumbnail rendering. Some of these cases are only for creating 16000px wide thumbnails, in which case the response on phabricator would probably be - don't do that. In other cases it seems like a server overload happened. e.g. for the NBC logo that has been deleted for years. Someone requested that file like 500 times in a 1 minute interval, which seemed to trigger some sort of short term overload which got it on this list, but for our purposes that is a false positive. Anyways I don't think you'll get much response from phabricator unless there is a specific pattern that has been identified. Bawolff (talk) 22:32, 3 December 2025 (UTC)

Its somewhat expected that edge cases happen with thumbnail rendering That it's expected doesn't mean it can't or shouldn't be fixed. I'm not saying it should necessarily be prioritized by whoever does it (and maybe a volunteer fixes this). Some of these cases are only for creating 16000px wide thumbnails That's something I don't understand based on the info so far: aren't thumbnails sized down to a size of an average around 300px? e.g. for the NBC logo that has been deleted for years It doesn't matter for deleted files. Anyways I don't think you'll get much response from phabricator That doesn't mean bugs shouldn't be filed there...e.g. when it's not normal anymore for bugs there to stay unfixed for 1+ decade but more development going on in a more positive future.

.

I don't know how you created this list of broken files. The main question basically remains of how to proceed to get these files fixed. For example, if you can create a list like that, couldn't that be fed into a script that corrects these? unless there is a specific pattern that has been identified another approach would be to retry failed thumbnail renderings every once in a while and with larger timeouts. Prototyperspective (talk) 22:42, 3 December 2025 (UTC)

The list is generated by looking at the "varnishslow" log (in logstash) for entries that have a 503 status code and are for a thumbnail from commons [logstash is not available to the public, you have to ask to get access]. This is basically a list of every web request that took so long that a timeout occured. There is a lot of things that can cause a failure here. It could be a transient issue, it could be a broken file, it could be that the file is simply too big and a timeout is reached, it could be some other sort of bug. I haven't particularly investigated individual cases, to do something about them would require determining the cause, and its likely different files have different causes. Re That's something I don't understand based on the info so far: aren't thumbnails sized down to a size of an average around 300px - users can request bigger thumbnail sizes. I think there is some max where we refuse to serve them. If a user asks for a huge thumbnail and it doesn't work, that is arguably a non-issue. Users who need a file that large should just download the whole thing. Re That doesn't mean bugs shouldn't be filed there...e.g. when it's not normal anymore for bugs there to stay unfixed for 1+ decade but more development going on in a more positive future - I don't think anyone really has the goal of 0 thumbnail rendering failures. Some of these may be legitimately broken files where failure is the correct thing to do. I'm not saying don't file bugs at all, but some narrowing things down is probably a good idea. If the bug report is simply: something sometimes breaks for unclear reasons, its not a useful bug report. A future dev could just pull the same list I did if they are interested, by which time the files in question on the list would probably be entirely different. Bawolff (talk) 23:12, 3 December 2025 (UTC)

Thanks! This helps the eventual solution – e.g. if somebody later gets back to this problem and would like to find out how the failing files were identified. to do something about them would require determining the cause I think that applies to just one of the two approaches of what could be done here: the solving of the cause problems. But the other approach would be to just fix the individual files, e.g. by retrying them with a larger timeout or something and/or by running some script to regenerate the thumbnails. I think the first approach or also doing the first approach would generally be preferred but one could also just fix those files like the individual file that Armbrust asked about was fixed but at scale for many files at once. If a user asks for a huge thumbnail and it doesn't work, that is arguably a non-issue Yes but not that the thumbnail is then broken also for users who request a smaller thumbnail in the category or search results views as is the case with the files in the list. Some of these may be legitimately broken files I didn't name 0 files as a goal or a near-term goal. The thing is that the preview on the file page often loads just fine, just not the thumbnail in the category view. If the bug report is simply: something sometimes breaks for unclear reasons, its not a useful bug report. Not as useful as it should be ideally but again: one could do what has been done with the single specific one file File:Vittore Carpaccio - Young Knight in a Landscape - Google Art ProjectFXD.jpg but for all or many files in that list. For things that change many files, usually scripts are used so it's a technical task and it would solve the bug of thumbnails missing. Prototyperspective (talk) 23:42, 3 December 2025 (UTC)

Just to clarify, thumbnails (unless they already exist) are generated live. So there is no script to run to regenerate them. They are generated anytime someone views the image thumb's url. By the same token, this is where 8000px thumbnails can come from, the user just has to modify the url to change the size. Some files that are near the edge could in theory be fixed if the limits were higher, but limits are also there for a reason, to make sure no individual file hogs all the resources and prevent other files from rendering. Bawolff (talk) 23:48, 3 December 2025 (UTC)

Ahh that's the key part I didn't know, thanks. I thought they were already generated at the upload and then sit on the server.
Wouldn't it make sense and improve performance and reduce server-load if thumbnails weren't re-regenerated every time one opens a Commons page at least for one or a few standard sizes?
(Nevertheless, while it would be done differently and may be more difficult, one could maybe have a scrip edit the files and upload new versions in a batch to fix a fraction of the affected files in the list.) Prototyperspective (talk) 23:53, 3 December 2025 (UTC)

I think a couple common sizes are auto-generated. And recently they've become bucketed (i.e. If you're off from the common size by a little bit, it returns the common size instead of a brand new file). To be clear, this is only the first time its viewed. Once a thumbnail of a specific size is generated, its saved for later. Bawolff (talk) 23:57, 3 December 2025 (UTC)

Some of these things just don't belong here. We are a pretty generic file host. There is no way we can account for anything and everything in the world. It's fine that a museum wants to host a 33000 x 66000 pixel progressive png in a pipeline they specifically designed for that to work and to facilitate archival quality. But we haven't done that extra work, so it will fail. This is expected. There are limits to everything. Just because someone can build the burj khalifa, doesn't mean you can place it on a lot designed for townhouses. —TheDJ (talk • contribs) 18:37, 4 December 2025 (UTC)

I think we're talking past each other a bit. I was saying one should probably just generate and store a thumbnail of max 300 px size and then serve that. If there's some issues within the file, then the file can be edited. For example, exactly like it was done for File:Vittore Carpaccio - Young Knight in a Landscape - Google Art ProjectFXD.jpg except by some script for all the problematic files. I doubt not filing any code issue and just letting this info sit here and collect dust in the archives is a good approach even when this is not an important problem. Prototyperspective (talk) 18:54, 4 December 2025 (UTC)

Is this even possible? AFAIK the PNG limit is at 65535 pixels. TIF may server larger pixel dimensions --PantheraLeo1359531 😺 (talk) 18:12, 8 December 2025 (UTC)

serve* --PantheraLeo1359531 😺 (talk) 18:13, 8 December 2025 (UTC)

I think you are mixing up jpg and png. Max dimensions of a png are 4294967295 x 4294967295 afaik. 65535 is the jpg limit. ("progressive" usually refers to jpgs, although pngs have a similar feature called adam7. I dont know if adam7 affects memory usage patterns when scaling in pngs the way progressive does in jpg. I think it doesn't but i dont know). Regardless, i think TheDJ's point is that we are optimizing for the average case. There are always going to be cases outside of that. The exact number so to speak is besides the point. Bawolff (talk) 19:05, 8 December 2025 (UTC)

Tech News: 2025-49

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 Wikipedia Year in Review 2025 will be available on December 2 for users of iOS and Android Wikipedia apps, featuring new personalized insights, updated reading highlights, and refreshed designs. Learn more on the review's project page.
• The Growth team is working on improving the text and presentation of the Verification Email sent to new users to make them more welcoming, useful and informative. Some new text have been drafted for A/B testing and you can help by translating them. See Phabricator.
• Add a link will now be deployed at Japanese, Urdu and Chinese Wikipedias on December 2. Add a link is based on a prediction model that suggests links to be added to articles. While this feature has already been available on most Wikipedias, the prediction model could not support certain languages. A new model has now been developed to handle these languages, and it will be gradually rolled out to other Wikipedias over time. If you would like to know more, please contact Trizek (WMF).
• View all 34 community-submitted tasks that were resolved last week. For example, the issue where search boxes on some Commons pages showed no results due to switch from SpecialSearch to MediaSearch, has now been fixed. [23]
• Two new wikis have been created:
  • a Wikipedia in Toki Pona (w:tok:) [24]
  • a Wikiquote in Nigerian Pidgin (q:pcm:) [25]

Updates for technical contributors

• Detailed code updates later this week: MediaWiki

In depth

• The Wikimedia Foundation is in the early stages of exploring approaches to Article guidance. The initiative aims to identify interventions that could help new editors easily understand and apply existing Wikipedia practices and policies when creating an article. The project is in the exploration and early experimental design phase. All community members are encouraged to learn more about the project, and share their thoughts on the talk 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:54, 1 December 2025 (UTC)

Sorting files in a category by the number of categories the files have?

Is this possible somehow?

It would also be useful for Wikipedia articles.

Here, in the case of Category:NIH BioArt, I'd like to either filter for files with only the (currently) 2-3 meta-categories set or sort the files by number of categories to add categories to those files that miss them.

Most of these files don't have categories set and currently one can't filter away the ones that already got some. Categorization request here. Prototyperspective (talk) 00:47, 3 December 2025 (UTC)

Does https://quarry.wmcloud.org/query/99622 work? Bawolff (talk) 02:48, 3 December 2025 (UTC)

Very cool. I imagine this could be useful in many cases. Maybe a script/gadget could be built using this that enables seeing the results (1) from the click of the button on the category page (e.g. under Tools "List files by number of cats") and (2) in wikitext so you can click the file links. Currently, a main problem here is that the file links are not clickable.

Moreover, it would be better if not needed if the files had a preview/thumbnail. Do you think it would be possible to make this a native sorting feature? Because with native MediaSearch sorting one could search e.g. use deepcategory:Category:NIH BioArt and then just sort by number-of-categories.

A hacky way would be, if I'm not mistaken, to export it as wikitable and then using VsCodium or a text-editor like it to search and replace prepend [[File: and append |thumb]] and then paste it manually into some page on Commons. Prototyperspective (talk) 21:20, 4 December 2025 (UTC)

Some sort of gadget or toolforge tool would be possible (To be clear, I'm not necessarily volunteering to make one). Its unlikely this would be built into mediawiki, as this category sorting method becomes slow for very large categories, which is a no-no for anything built into mediawiki. Bawolff (talk) 21:53, 4 December 2025 (UTC)

For your hacky way - we can do that with quarry. Try this link https://quarry.wmcloud.org/run/1046668/output/0/wikitable which outputs a table you can paste into commons. Bawolff (talk) 22:16, 4 December 2025 (UTC)

Thanks! I think it his can be quite useful in many occasions for dynamically improving categorization of some cat by users (works best with flat cats and is especially useful for categories with new files such as after batch uploads). Maybe it could also be useful for some report, e.g. for files uploaded as part of challenges like the Commons:Wiki Science Competition 2025 where good files often don't have categories other than the hidden meta categories set.

A problem is that one needs to put this on a Commons page and click preview to be able to use the results (being able to click the file links and see thumbnails if that's enabled). Also, currently one needs to fork the query and run it on Quarry which is impractical and inaccessible to most users.

If nobody here is interested in creating a tool for this, I'll probably make a wish in the m:Community Wishlist. It could be a gadget that adds an entry to the Tools menu like "List files by number of cats".

Query for the output https://quarry.wmcloud.org/query/99690

@Don-vip: By the way, you may be interested in that query – the example category is for a batch import you recently implemented (thanks again). Prototyperspective (talk) 19:20, 10 December 2025 (UTC)

Nice! vip (talk) 19:42, 10 December 2025 (UTC)

Proposal about changing VisualFileChange.js

Not sure that I need to put it here but don't know where else but there was warning make post in village pump too...

Pressing enter inside input field should be equal to pressing compare button

https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-VisualFileChange.js#Pressing_enter_inside_input_field_should_be_equal_to_pressing_compare_button DustDFG (talk) 05:48, 3 December 2025 (UTC)

Any way to mass-remove captions?

Ozzie10aaaa (talk · contribs) uploads lots of very useful images (thanks for that) but at the same time he 1) doesn't add the useful file description from the source, 2) chooses either undescriptive or bad file titles (recently improved but not by much), and 3) sets horribly bad undescriptive file captions.

Is there a way the captions could be bulk-removed from the files?

Examples:

• At File:Hiv-death-rates china.png (file name should e.g. be "Death rate from HIV/AIDS in China and surrounding countries, OWID"), the caption is china 2021
• At File:Burden-of-disease-from-injuries.png (file name should e.g. be "DALY rates from injuries in countries of the Americas, OWID"), the caption is north/south america
• At File:Region-share-tropical-deforestation.png (file name should e.g. be "Share of tropical deforestation from commodity production, OWID"), the caption is deforestation/africa
• At File:Annual-research-development-funding-for-neglected-tropical-diseases.png (file name should e.g. be "Annual research & development funding for infectious diseases, 2023, OWID"), the caption is covid-19 funding/research
• This list could go on for very long

Also as a related note: the Commons app currently only shows the file caption instead of the file title and caption or only file title if a caption is set.
So if you were to browse for example subcategories of Category:Our World in Data or other categories with the files in the app, it would just show things like "china 2021" as the title.
I think fixing this is one of the top code issues in the Commons app.
However, the code issue was closed without any explanation: https://github.com/commons-app/apps-android-commons/issues/6023 I hope it will be reopened and if not hope somebody forks the app and adds this functionality along with other key missing features like playing videos and audio so that this app will be abandoned and a better version of it continue to be developed and eventually linked from the Commons frontpage.
Note that this is not a problem just because of uploads from the user and neither because of also uploads with similar captions by other users but also because lots of users, me included, use the caption as a kind of subheader to add complementary titles such as subheadings instead of just repeating what's already in the file title anyway already. It's important to choose and change titles that are descriptive per COM:File naming and then display these in the app. If users for strange reasons only want to see the caption and not see the file-title too or instead, then there could be a setting like "Show only caption" in the app's preferences.

Anyway, is there any way to remove these captions? Maybe one could have a tool list all uploads of the user along with their captions, then one could unselect the ones where users already fixed the caption, and then bulk-remove these using something like QuickStatement. Prototyperspective (talk) 19:06, 3 December 2025 (UTC)

Yes seems useful, I'm in agreement with Prototyperspective--Ozzie10aaaa (talk) 19:38, 3 December 2025 (UTC)

Filemover issue

Several times per day the filemover tool renames a file but doesn't remove the rename request template afterwards. File:Niederehe 2024-08-12 - 26.jpg is an example (see history). I've seen this several times per day for a few weeks at least. Thanks for your time. Geoffroi 21:16, 4 December 2025 (UTC)

Need SQL query for geolocated images before date X

Hello! I would like to create a current chart showing the number of geolocated images up to date X. I tried this at https://quarry.wmcloud.org/query/99798, but "WHERE img_timestamp < 20101206235959" is not recognized. How can this be fixed? Thanks --PantheraLeo1359531 😺 (talk) 13:05, 7 December 2025 (UTC)

https://quarry.wmcloud.org/query/99805# is the basic way of how to do that, but i think a smarter method is needed as that query is very slow. Bawolff (talk) 19:02, 7 December 2025 (UTC)

p.s. If an image has multiple sets of coordinates, its possible it might get counted twice. I'm not sure if its even possible to have multiple coordinates or how common that is. Bawolff (talk) 03:39, 8 December 2025 (UTC)

@Bawolff: an image may easily have both {{Location}} and {{Object location}} templates with different coordinates. MKFI (talk) 09:48, 8 December 2025 (UTC)

So we need a parameter that counts a single file as 1, not more? --PantheraLeo1359531 😺 (talk) 17:45, 8 December 2025 (UTC)

I changed the query to do that, but that might make it slower so it might timeout. It might all be a moot point if no files have multiple coordinates. Bawolff (talk) 18:55, 8 December 2025 (UTC)

Looks like it worked and did change the answer by quite a bit. Bawolff (talk) 19:15, 8 December 2025 (UTC)

Thank you a lot :) --PantheraLeo1359531 😺 (talk) 19:28, 9 December 2025 (UTC)

@Bawolff Following queries are faster during execution :) --PantheraLeo1359531 😺 (talk) 16:47, 10 December 2025 (UTC)

Tech News: 2025-50

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

• Anybody who wishes to secure their user account can now use two-factor authentication (2FA). This is available to all registered users of all Wikimedia projects. This is part of the Account Security initiative. Later, 2FA will be required for all users who can take security- or privacy-sensitive actions.

Updates for editors

• Following last week's deployments, the Add a link feature, which allows editors to add suggested links during editing, will be available to an additional 33 Wikipedias starting on 9 December. This expansion is possible thanks to the new prediction model that now supports all languages, including those that were previously not covered. While the feature has been available on most Wikipedias for some time, this rollout brings us closer to using the improved model everywhere. If you have any questions or would like more details please contact Trizek (WMF).
• Last week, the Search Platform team added transliterated as-you-type search suggestions to Georgian wikis. If there are only a few regular search suggestions, then queries in Latin or Cyrillic script are now rewritten into Georgian script to look for more matches. For example, searching for either bedniereba or бедниереба will now suggest the existing article about ბედნიერება ("happiness"). You can recommend other languages where transliterated suggestions would be useful on Phabricator for future development.
• Later this week, a controlled experiment will begin for editors on the 100 largest Wikipedias who are editing a section in the mobile web visual editor. 50% of these editors will notice a new "Edit full page" button that will enable them to expand their editing session to the whole page. This feature is intended to make it easier for people on mobile web to edit any article section, regardless of which section-edit icon they tapped to begin. The experiment will last ~4 weeks. You can find more details about the project.
• Later this week, the Reader Growth team will launch a mobile web experiment to expand all article sections by default (currently they are collapsed by default) and pin the section header the user is currently reading to the top of the page. The experiment will affect 10% of users on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias. [26]
• The Wikipedia Year in Review 2025, a feature in the Wikipedia mobile apps (iOS and Android) that provides users with a personalised summary of their engagement with Wikipedia over the year, is now available on the iOS and Android apps. This edition includes expanded personalised insights, improved reading highlights, new donor messaging, and updated designs. Open the app to view your Year in Review and explore your reading journey from 2025.
• A recent software bug caused edits made with VisualEditor to make unintended changes to wikitext, including removing whitespace and replacing spaces with underscores in wikilinks inside citations. This was partially fixed last week, and further fixes are in progress. Editors who used VisualEditor between November 28 and December 2 should review their edits for unexpected modifications. [27]
• View all 23 community-submitted tasks that were resolved last week. For example, the incorrect handling of URLs copied from the address bar of Microsoft Edge users, has been resolved. [28]

Updates for technical contributors

• Starting this week, users of the "Improved Syntax Highlighting" beta feature will have CodeMirror as the editor for Lua, JavaScript, CSS, JSON and Vue content models, instead of CodeEditor. With this, the linters will be upgraded. This is part of a larger effort to eventually replace CodeEditor and provide a consistent code editing experience. [29]
• Developers are encouraged to take the 2025 Developer Satisfaction Survey, which remains open until 5 January 2026. If you build software for the Wikimedia ecosystem and would like to share your experiences or feedback, your participation is greatly appreciated. [30]
• There is no new MediaWiki version this week.

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

MediaWiki message delivery 17:41, 8 December 2025 (UTC)

File:1575 tercer escudo manuscrito.svg

• 
  broken SVG
• 
  PNG

This "SVG file" is actually a perfectly valid PNG file. I'm not sure a move to the correct file extension would fix this, since MediaWiki stores file types in the database (see mw:Manual:file table) Phillipedison1891 (talk) 01:15, 9 December 2025 (UTC)

@Phillipedison1891: I don't know how this SVG file was created, but it contains only a PNG image. If I were to recreate the SVG file, it would just be a fake SVG, which makes no sense, especially since the original PNG already exists on Commons. --Mrmw (talk) 06:38, 10 December 2025 (UTC)

You can't move across file extensions, you have to reupload. This sort of situation shoulf not be possible as file extensions are checked during upload. Bawolff (talk) 16:27, 10 December 2025 (UTC)

Any way to identify files with closed captions missing the ClosedCaptions template?

There are many files with TimedText subtitles but missing the {{Closed captions}} template (example: Special:Diff/1128180107).

The template is useful because it allows people to easily see that and which subtitles are available on thje file page and because it sets categories like Category:Files with closed captioning in English which can e.g. be used for filtering, searching, and glamorous usage scans etc.

Is there a way to identify these files and if possible also to add that template to these automatically? Prototyperspective (talk) 11:47, 9 December 2025 (UTC)

Hello @Prototyperspective, I made this SQL query to look for files with TimeText pages, but without the {{Closed captions}} template. The query shows there are 7824 files with this case. Thanks. Tvpuppy (talk) 14:24, 10 December 2025 (UTC)

Amazing, thank you very much! Do you know of a way to add the template to these files automatically? I think VisualFileChange could be used for that but it only works on categories, searches, etc and not Quarry outputs afaik. If not, it may be best to make a new thread at Bot work request so that a bot adds it based on the query export. Prototyperspective (talk) 14:53, 10 December 2025 (UTC)

No, I don't. I would like to know if there's a way to do it automatically as well. Tvpuppy (talk) 15:26, 10 December 2025 (UTC)

Enhance NoFoP-category with year the item becomes PD

There's a suggestion at Template talk:NoFoP-category#Year that the images become free suggesting that {{NoFoP-category}} include a field to store the year that the subject becomes Public Domain, after which the category can be removed or replaced, and any deleted items undeleted. Posting here for visibility, input is appreciated. -Consigned (talk) 10:22, 10 December 2025 (UTC)

File rename tool broken?

I renamed the file now located here with replace usage checked in the Move & Replace tool but it did not edit en:Yarrabubba impact structure which still has | photo = 41467 2019 13985 Fig1 HTML.webp and that ENWP usage is additionally not showing up in the File uses on the file description page. Prototyperspective (talk) 16:38, 10 December 2025 (UTC)

Abuse filter makes it impossible to start a DR for timed text

Apparently an abuse filter makes it impossible to start a DR for timed text, because it won't allow anything but timed text on the page. I am trying to start a DR for TimedText:WIKITONGUES-_Aminah_Abba_speaking_Wolof.webm.en.srt; here is what would go on that page:
{{delete|reason={{U|Jumbo T}} says (at [https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&oldid=1128926632#Delete_incorrect_captions?] that the captions here are wrong and this should be deleted, but that for some reason they could not start the DR themself. I have no Wolof, so I have no independent opinion of whether that is correct. Jumbo T, would you please explain in more detail what is wrong here (entirely wrong? needs editing? etc.)|subpage=TimedText:WIKITONGUES- Aminah Abba speaking Wolof.webm.en.srt|year=2025|month=December|day=10}}
Jmabel ! talk 22:04, 10 December 2025 (UTC)