Commons:Village pump/Technical/Archive/2025/11

Category field missing on upload form

All of a sudden today, the thing to add categories in the upload form (it may be a HotCat functionality?), Special:Upload, is...well, not there. Destination filename, Summary, and Licensening all are, but the category-addition bar below them is gone. I tried deactivating and reactivating HotCat without any change. What gives? - The Bushranger (talk) 22:05, 5 November 2025 (UTC)

Tracked in Phabricator
Task T409400

The problem is reported. GPSLeo (talk) 08:57, 6 November 2025 (UTC)

I can see category section at Special:Upload. Check whether you disabled ImprovedUploadForm gadget. (it's enabled by default) – Ammarpad (talk) 10:27, 6 November 2025 (UTC)

The error vanished in some way. I had ImprovedUploadForm and HotCat enabled, I also enabled and disabled HotCat multiple times when testing the bug. If I disable both the section is missing, with one of them enabled the section is present. GPSLeo (talk) 11:12, 6 November 2025 (UTC)

OK, it seems you were affected by phab:T409367, which has been fixed now. – Ammarpad (talk) 11:36, 6 November 2025 (UTC)

It has returned for me as well. Thank you! - The Bushranger (talk) 23:49, 6 November 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:51, 6 November 2025 (UTC)

Wikidata item update

Can someone please update Creator:Benjamin Disraeli to the new category Category:Benjamin Disraeli (it's currently in Category:Benjamin Disraeli, 1st Earl of Beaconsfield)? I'm on an 8 inch tablet, and the Wikidata item for Disraeli is too big for me to find the creator category statement. Thank you for your time. Geoffroi 22:08, 20 November 2025 (UTC)

@Geoffroi Done, I have updated it. Thanks. Tvpuppy (talk) 00:32, 21 November 2025 (UTC)

Thank you. Geoffroi 00:34, 21 November 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 14:57, 21 November 2025 (UTC)

Wikitable bug

I've been having this issue on my user page User:MrAureliusR on the wikitable holding my babelboxes - note (at least on my Firefox browser) one of the double bars || which is supposed to separate cells in the table is being displayed literally, and this has broken the table. It is somehow also displaying a third column, which makes even less sense if one of the separators isn't being parsed. I've tried to fix this before by swapping some of the Babelboxes around but no luck. Wondering if anyone else has seen this issue before and can give me a pointer! MrAureliusR (talk) 21:22, 24 November 2025 (UTC)

I think I have fixed it, pls have a look. Ymblanter (talk) 21:32, 24 November 2025 (UTC)

Oh, strange, why did I have it in my head that the separators were double bars? Very odd! Thanks for the help. MrAureliusR (talk) 22:04, 24 November 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 00:20, 25 November 2025 (UTC)

Tech News: 2025-45

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

• Administrators will now find that Special:MergeHistory is now significantly more flexible about what it can merge. It can now merge sections taken from the middle of the history of the source (rather than only the start) and insert revisions anywhere in the history of the destination page (rather than only the start). [1]
• For users with "Automatically subscribe to topics" enabled in their preferences, starting a new topic or adding a reply to an existing topic will now subscribe them to replies to that topic. Previously, this would only happen if the DiscussionTools "Add topic" or "Reply" widgets were used. When DiscussionTools was originally launched existing accounts were not opted in to automatic topic subscriptions, so this change should primarily affect newer accounts and users who have deliberately changed their preferences since that time. [2]
• Scribunto modules can now be used to generate SVG images. This can be used to build charts, graphics and other visualizations dynamically through Lua, reducing the need to compose them externally and upload them as files. [3]
• Wikimedia sites now provide all anonymous users with the option to enable a dark mode color scheme, featuring light-colored text on a dark background. This enhancement aims to deliver a more enjoyable reading experience, especially in dimly lit environments. [4]
• Users with large watchlists have long faced timeouts when editing Special:EditWatchlist. The page now loads entries in smaller sections instead of all at once due to a paging update, allowing everyone to edit their watchlists smoothly. As part of the database update, sorting by expiry has been removed because it was over 100× slower than sorting by title. A community wish has been created to explore alternative ways to restore sort-by-expiry. If this feature is important to you, please support the wish! [5]
• View all 31 community-submitted tasks that were resolved last week. For example, the fixing of the persisting highlighting when using VisualEditor find and replace during a query. [6]

Updates for technical contributors

• Since 2019 the Wikimedia URL Shortener at https://w.wiki is available for all Wikimedia wikis to create short links to articles, permalinks, diffs, etc. It is available in the sidebar as "Get shortened URL". There are 30 wikis that also install an older "ShortUrl" extension. The old extension will soon be removed. This means /s/ URLs will not be advertised under article titles via HTML class="title-shortlink". The /s/ URLs will keep working. [7]
• On Thursday, October 30, the MediaWiki Interfaces and SRE Service Operations teams began rerouting Action API traffic through a common API gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to the Service Ops team board.
• MediaWiki Train deployments will pause for the final two weeks of 2025: 22 December and 29 December. Backport windows will also pause between Monday, 22 December 2025 and Thursday, 2 January 2026. A backport window is a scheduled time to add things like bug fixes and configuration changes. There are seven deployment trains remaining for 2025. [8]
• Detailed code updates later this week: MediaWiki

In depth

• In 2025, the Wikimedia Foundation reported that AI systems and search engines increasingly use Wikipedia content without driving users to the site, contributing to an 8% drop in human pageviews compared to 2024. After detecting bots disguised as humans, Wikimedia updated its traffic data to reflect this shift. Read more about current user trends on Wikipedia in a Diff blog post.

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

MediaWiki message delivery 19:30, 3 November 2025 (UTC)

Commons:Copyright rules by territory/Belgium

Could someone take a look at Commons:Copyright rules by territory/Belgium? It looks like there's a level-2 section heading (==Copyright tags==) in Commons:Copyright rules by territory/Belgium#General rules that's not displaying properly. -- Marchjuly (talk) 07:30, 7 November 2025 (UTC)

@Marchjuly, I think I fixed it, just need to wait for a TA to mark this for translation, so it updates the other language versions as well. Thanks. Tvpuppy (talk) 12:58, 7 November 2025 (UTC)

Thank you for doing that Tvpuppy. I didn't catch it was an added line break causing the problem. -- Marchjuly (talk) 20:33, 7 November 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 11:05, 3 December 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". [9]
• 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. [10]
• 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. [11][12][13]
• 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. [14]
• 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. [15]
• 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. [16]
• View all 27 community-submitted tasks that were resolved last week. For example the inability to lock accounts on mobile sites has been fixed. [17]

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. [18]
• 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. [19]
• 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. [20]
• 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. [21]
• 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. [22][23]
• 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)

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-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:) [24]
• 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)

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)

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

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)

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)

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. [26]
• 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. [27]
• 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. [28]

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. [29]
• 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). [30]
• 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)

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)

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)

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

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)

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)

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)

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)

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)