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/2026/09 /Archive/2026/10.

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).
• Requests relating to templates can be filed at Commons:Template requests
• Have you read the FAQ?
  
  

 

Start a new discussion

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

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

Flickr2Commons

Not all OK with Flickr2Сommons, sadly. I've uploaded File:Sunset in Vernazza 2018.jpg and File:Sunset in Hehuanshan, Taroko National Park.jpg, they have been transferred without date and {{Flickreview}} tag. I've added them manually. It is possible to use an old version? Юрий Д.К. 09:34, 8 July 2026 (UTC)

@1Veertje. RoyZuo (talk) 13:45, 8 July 2026 (UTC)

sorry, should have tested more. Submitted a patch that should fix this Vera ^(talk) 19:25, 8 July 2026 (UTC)

• Currently F2C adding Flickreview tag but date field is still empty. Юрий Д.К. 15:13, 13 July 2026 (UTC)

  @Юрий Д.К. looking at latest uploads, this seems resolved? although it seems if the flickr file has no exif or date taken then f2c leaves it empty. RoyZuo (talk) 10:49, 25 July 2026 (UTC)

  @RoyZuo: Sadly, no. I've uploaded File:Monistrol de Montserrat (55416587297).jpg. EXIF with date, but F2C leaves the file without it. I've added it manually. Юрий Д.К. 12:06, 26 July 2026 (UTC)

  @Юрий Д.К. i see how i got confused. i clicked your 1st version and saw the date in sdc.

  it seems technically ok if f2c doesnt fill in the data for a short while, coz @FlickrResourcesBot adds sdc. RoyZuo (talk) 13:54, 26 July 2026 (UTC)

  @RoyZuo: Hello. I hope that the F2C will add the date during import. It will be convenient for me to add "Taken on" template. Besides, I've noticed another problem. I've uploaded File:Storm cloud at sunset - Paraná, Entre Ríos (34769035286).jpg and the F2C left a digital Flickr ID of an author instead of a nickname. It isn't good indeed. Юрий Д.К. 00:36, 1 August 2026 (UTC)

  @1Veertje.

  @Юрий Д.К., indeed problematic. please report problems to https://codeberg.org/magnusmanske/flickr2commons/issues or m:Talk:Flickr2Commons. RoyZuo (talk) 17:01, 2 August 2026 (UTC)

  Thank you for allerting me. I've submitted a patch Vera ^(talk) 14:38, 3 August 2026 (UTC)

• Also F2C removing coords from Flickr images. Юрий Д.К. 21:39, 10 August 2026 (UTC)
• It appears that it working fine now. Thank for fixing! Юрий Д.К. 19:01, 3 September 2026 (UTC)

Uploads do not appear permanently on my Watchlist

My uploads do not appear permanently on my Watchlist (only for "1 year") though my Global Preferences are indicating they should. What do I do wrong or is this a hiccup in the system? JopkeB (talk) 09:13, 23 August 2026 (UTC)

For me it seems to work fine. I've clicked the "edit your watchlist" button and it shows all files as "never", and some o the ones I've found are several years old. Pere prlpz (talk) 14:20, 2 September 2026 (UTC)

@Pere prlpz: Did you do that in your Global Preferences? JopkeB (talk) 02:37, 6 September 2026 (UTC)

Last month in technical changes (August)

Overview of development and technical activity since July 26th. These changes might not have made the bigger news bulletins as they are more specific to Commons and have smaller usecases and/or audiences.

• Already covered in Tech News, but native lazy-loading has landed everywhere on desktop T148047. This means that now all images only load when they are close to being in view of the browser viewport, which should help with bandwidth usage for both clients and the wikimedia servers. This is a browser feature that was launched some 10 6 years ago, that we can now use natively (without Javascript). This took several of the Wikimedia developer teams (mobile, content platform, multimedia etc).
• UploadWizard's Flickr import works again after Content-Security-Policy had broken it T419263 T278472.
• Special:Upload pages can now test larger than 100MB uploads by making use of the chunked parameter phab:T74768. Another very old wishlist item getting closer to resolution. By Amdrel (wishlist contractor) and myself.
• A new version of thumbor (the thumbnailing service) was released. Now running Debian Trixie, with newer versions of Imagemagick, libsvg etc. T419815. Thanks to Wikimedia's MediaWiki-Media-Platform Team.
  • More of the rarer EXIF orientations are handled correctly now T424495. By myself and MediaWiki-Media-Platform team.
  • Transparent WebP images no longer lose their transparency when resized T283646. By myself and MediaWiki-Media-Platform team
  • Multilingual SVG rendering is now better supported, with fixes for language fallback T261192 and T154237.
  • librsvg update fixed T246003, T270836, T370044, T431758.
  • a bug where thumbnails of HDR images would sometimes turn black has been fixed T393331.
• PDF handling should be more resilient now: metadata-extraction failures are classified as transient or permanent instead of getting permanently cached as "no metadata", a likely cause or contributing factor to PDFs showing as having 0×0 dimensions T433059 T420341 T299521. PDFs are also now fetched by storage URL for metadata extraction. Thanks to Chuiimuii_ofc, Sam Wilson, Bawolff and myself.
• TIFF lossy/lossless parameters would sometime break loading TIFF files in MultimediaViewer T434333. By myself
• VTT captions now render natively in the browser instead of with a software renderer, T116154. This briefly broke SRT-only subtitles and audio captions, both now fixed T434172. By myself with support of James Forrester.
• Video transcoding was updated to a newer ffmpeg version. This enabled making use of the ffmpeg's fpsmax flag. This helps with transcoding 60fps original content T318419. Thanks to @Ladsgroup of MediaWiki-Media-Platform team.
• Thumbnail serving is being moved off the upload cluster onto a new thumb.wikimedia.org domain, for better caching and resilience against scraper traffic T427465. This is rolling out wiki by wiki; test wikis, mediawiki.org, cs/fawiki and dewiki so far. By MediaWiki-Media-Platform team
• And the usual set of changes related translations, dependency updates and newer PHP/MediaWiki versions (~90 this period, excl. translations).

Apologies if i forgot to name a few people. —TheDJ (talk • contribs) 10:16, 26 August 2026 (UTC)

Sounds good! --PantheraLeo1359531 😺 (talk) 13:12, 26 August 2026 (UTC)

Great updates, thank you! I'm especially looking forward to the new thumb.wikimedia.org in hopes that it helps resolve issues for tools whose display of thumbnails have been impacted by rate limiting. ~Kevin Payravi (talk) 16:32, 26 August 2026 (UTC)

Indeed, that is part of the reason we're doing this. The other being it allows us to move thumbnails to the same CDN cache as text, which is much larger and means that thumbnails won't be ejected from the cache due to automated access to the much larger original files. Once this is all in place, we will look to introduce separate rate limits for thumbnails and originals. We're also considering if this can be tiered like the API rate limiting. JTweed-WMF (talk) 12:58, 27 August 2026 (UTC)

Thanks for putting all this together in one place, it's a great summary of what's going on. Happy that the new Media Platform team is starting to make a difference. JTweed-WMF (talk) 12:54, 27 August 2026 (UTC)

Attention! This update of librsvg in August 2026 has almost certainly caused broken rendering of Media Viewer at various types of images and vector files rendering errors in hundreds of known files. I request a fix or tentative rollback of changes before August 2026. (Most recent reports connected: PNG caching bug? and Image not loading the SVG) ThecentreCZ (talk) 08:03, 2 September 2026 (UTC)

I see no evidence in either report. There are a lot of things changing atm for various reasons about images (OS upgrades, improved caching, new urls etc etc). You are going to have to be very specific if you think there is something wrong that you want people to look into. —TheDJ (talk • contribs) 08:11, 2 September 2026 (UTC)

subcategory sortkey display

Mostly, the 'Subcategories' section of a category is divided by letter or number, more rarely other glyphs (there are informal standards); for this post I wish to bring up the 'regional indicator symbols'. For the Unicode characters in the range U+1F1E6 to U+1F1FF, which have the property that when put next to each other (example: 🇧 followed by 🇷) then browsers and font vendors can decide which flag should go with pairs of symbols (🇧🇷). In theory, this makes for a good sortkey. As these characters are encoded in alphabetical order from A to Z, they naturally sort by this two-letter code. However, in the category view only the first character is displayed, which breaks the flag. Could an exception be made for this use case? — Arlo James Barnes 03:13, 27 August 2026 (UTC)

What is the chance of any large number of users being able to work with this successfully through the existing UI? - Jmabel ! talk 20:27, 27 August 2026 (UTC)

I guess that depends on what you mean by large. Plenty of people have access to emoji keyboards that can paste flag icon pairs, but if something breaks (like the two halves get separated) it may not be immediately obvious what went wrong. Arlo James Barnes 20:53, 27 August 2026 (UTC)

Hmm, its an interesting idea. Make the sortkeys of the uppercase collation be first grapheme cluster instead of first character. It might make sense in general, although might be weird if there are keys where the first grapheme cluster is a prefix of some other grapheme cluster and sort both before and after that grapheme cluster.

Of course this might already be fixed if commons switched to the UCA collation, which quite frankly would make sense as a multilingual project. Bawolff (talk) 21:14, 6 September 2026 (UTC)

FWIW, i filed a phab task - phab:T438247. My biggest concern is if we do this fully generically this might have unintended consequences for some languages (Maybe good maybe bad) especially east asian languages. Alternatively i guess its a lot safer to do this just for regional indicators and maybe emoiji. Even emoiji its a bit unclear what the correct behaviour is. Is it a good thing or a bad thing that man with a computer 👨‍💻 sorts under 👨 along with other modified men emoiji instead of being its own category, or that all the skin tone variants sort under the same base emoiji? Bawolff (talk) 21:00, 16 September 2026 (UTC)

Thank you, the list of examples looks thorough. That's a good question about modified emoji, I could see it being argued either way along the usual lumping/splitting lines. Arlo James Barnes 21:36, 20 September 2026 (UTC)

PNG caching bug?

I've been trying to upload a new version of File:Strait of Malacca highlighted.png, but the image preview is refusing to update (even after reverting back and forth). Is there a currently known bug affecting PNGs or something? — Paul_012 (talk) 00:30, 31 August 2026 (UTC)

Hmm, seems like linking to the file caused it to resolve itself? — Paul_012 (talk) 00:59, 31 August 2026 (UTC)

It's not just PNG, I've noticed various files take awhile to regenerate thumbnails. Maybe a new anti-DOS precaution? #Last month in technical changes (August) mentions some relevant updates. — Arlo James Barnes 16:54, 31 August 2026 (UTC)

@Paul 012 This is most likely a known cache invalidation problem phab:T425216. —TheDJ (talk • contribs) 08:17, 2 September 2026 (UTC)

"Add a note"

The "Add a note" (ImageNote) feature seems to have gone away for me today on all file pages. Is this a bug, or is there some UI change that requires me to change how I get this? I believe Image-Annotator is turned on by default, and I certainly have not done anything deliberate to disable it.

I'm getting the following in my browser console; maybe something else is firing an error and it never reaches the JavaScript to load this button?

uncaught exception: Object
can't access property "currentWindowGlobal", bc is null ext-tabs-base.js:813:19
uncaught exception: Object 2
IndexedDB UnknownErr in ClampResultCode: ..\..\..\..\checkouts\gecko\dom\indexedDB\IndexedDBCommon.cpp:47
uncaught exception: Object

- Jmabel ! talk 23:21, 31 August 2026 (UTC)

same for me. --Herzi Pinki (talk) 08:55, 1 September 2026 (UTC)

Even worse now: "Open in Media Viewer" no longer appears on a line of its own (no line break before it). - Jmabel ! talk 18:24, 1 September 2026 (UTC)

There is an open thread reporting the same bug in MediaWiki_talk:Gadget-ImageAnnotator.js#annotations_with_problems, but I wonder if there is a better place to report it in order to be fixed. Pere prlpz (talk) 13:52, 2 September 2026 (UTC)

Is there a phabricator ticket on this? - Jmabel ! talk 20:40, 3 September 2026 (UTC)

As far as I know there is none, and the help page says bugs and problems should be reported in the talk page. However, we could try opening a ticket. Pere prlpz (talk) 21:03, 3 September 2026 (UTC)

Seems to work again. --Herzi Pinki (talk) 20:55, 4 September 2026 (UTC)

works in rare cases e.g. File:Kreuzspitze-Grossvenediger.jpg --Herzi Pinki (talk) 21:01, 4 September 2026 (UTC)

That one works for me, too; File:Arthur Avenue 07 - Clinton Hall.jpg does not. - Jmabel ! talk 02:32, 5 September 2026 (UTC)

We have on german forum Commons:Forum#Annotation_weg since pretty long a discussion. I tried to contact the developeres more than once, but aint got a reaction. It has to to with the new skins because with the old skins it works fine.--Sanandros (talk) 15:21, 5 September 2026 (UTC)

I am having this problem on Vector (2022). Is that considered a "new" skin (after 4 years)? - Jmabel ! talk 21:40, 5 September 2026 (UTC)

Yes Vector 2022 is the new one, Vector 2010 used to function with me. But some users said also that the browser has a infuence. Some us Firefox and got problems and with Safari it worked fine.--Sanandros (talk) 22:47, 5 September 2026 (UTC)

I tried vector 2010 and Anotation doesn't seem to work there. Example: https://commons.wikimedia.org/w/index.php?title=File:Diada_castellera_de_la_Festa_Major_de_la_Salut_2026_-_Muixeranga_de_Barcelona_-_20260906_134240.jpg&useskin=vector Pere prlpz (talk) 16:38, 6 September 2026 (UTC)

If u use your link it works for me, using FF 155.0.1 (64-Bit).--Sanandros (talk) 19:37, 6 September 2026 (UTC)

I found and fixed one issue, which was a regex for the thumbnail URL that didn't include the new thumb.wikimedia.org (phab:T427465). File:Diada castellera de la Festa Major de la Salut 2026 - Muixeranga de Barcelona - 20260906 134240.jpg and File:Arthur Avenue 07 - Clinton Hall.jpg are working for me now, if there are other pages that are still not working, please include a link and what skin you are using. --AntiCompositeNumber (they/them) (talk) 19:54, 6 September 2026 (UTC)

Those two now work for me as well. Thank you, AntiCompositeNumber. - Jmabel ! talk 21:51, 6 September 2026 (UTC)

Yes it worked also for me.--Sanandros (talk) 22:31, 6 September 2026 (UTC)

I need wikidata-to-commonscat help

I need help untangling some Wikidata connections for horse-drawn vehicle categories. Could someone help me establish correct one-to-one Wikidata connections for:

• Category:Coaches (carriage)
• Category:Horse-drawn carriages
• Category:Carriages

I discovered that the Wikidata item d:Q4655519 (coach) was linked to both Category:Horse-drawn carriages and Category:Coaches (carriage). Since d:Q4655519 is specifically about coaches, I removed the carriage-related sitelink. However, Category:Horse-drawn carriages continued to display d:Q4655519 in its Wikidata infobox, and I am not sure why.

While trying to fix this, I started creating a new item (d:Q141245384) before realizing that d:Q235356 (carriage) already exists and is linked to Category:Carriages. But Category:Carriages includes both horse-drawn and non-horse-drawn material, so I am unsure how to correctly align the Wikidata items with the Commons categories.

At this point I am confused and do not want to make things worse. Any guidance would be greatly appreciated.   ▶ I am Grorp ◀ 06:32, 1 September 2026 (UTC)

Update: This morning, Category:Horse-drawn carriages is no longer displaying d:Q4655519 (coach), which is correct, so maybe that problem was a caching issue.   ▶ I am Grorp ◀ 15:35, 1 September 2026 (UTC)

Update #2: I think I've figured it out (courtesy of 2 separate AIs, neither of which gave me the exact right instructions, but which helped me figure it out). At least now there is a 1-to-1 correlation between each of the three Commons categories and a singular wikidata record.   ▶ I am Grorp ◀ 09:36, 2 September 2026 (UTC)

Image not loading the SVG

When I go to Category:Wikipedians interested in East Asia, I seen the SVG is not display on Commons. I seen the image is missing so it not loading SVG?

Ranch9613 💬 17:44, 1 September 2026 (UTC)

Hello, I think someone or something broke the SVG Media Viewer and rendering of vector files at Commons in about August 2026. I have seen some files and i have a vector file that was rendered perfectly from 2025 to Summer 2026 and since last month it shows weird wrong line drawing and tweaks. ThecentreCZ (talk) 07:13, 2 September 2026 (UTC)

It seems that a new recursion/depth limit has been put in place in newer versions of librsvg. This will require some investigation. —TheDJ (talk • contribs) 08:13, 2 September 2026 (UTC)

Yeah, it's the limit. test:File:East Asia orthographic projection flattened - 2.svg works fine no issues. Re-upload might still show broken because of memcached protection in place (which is based on the image name, not hash) but that should fix it :/ Amir (talk) 10:34, 2 September 2026 (UTC)

The file there is File:East Asia (orthographic projection).svg. This error sounds similar to T436505: 400 Bad Request on File:Warsaw Pact in 1990 (orthographic projection).svg. Sam Wilson 08:01, 2 September 2026 (UTC)

This is now fixed —TheDJ (talk • contribs) 15:28, 2 September 2026 (UTC)

Błąd wewnętrzny

[e7abf4b6-7e7a-487d-bc5c-a4eeb7f22944] 2026-09-02 18:25:08: Krytyczny wyjątek typu „InvalidArgumentException”.

-> Błąd Magen (talk) 18:28, 2 September 2026 (UTC)

I have the same, for the last 10 minutes. Ymblanter (talk) 18:30, 2 September 2026 (UTC)

So did I. Obviously the upload is not working at all. -- Clemens 18:48, 2 September 2026 (UTC)

The old form still works. Ymblanter (talk) 18:52, 2 September 2026 (UTC)

Ah, Thank you. Still a severe issue, because the old form cannot be accessed via WP (e. g. Wiki loves monuments pages(!)). -- Clemens 18:55, 2 September 2026 (UTC)

It's now working again. Many thanks to whoever fixed this. -- Clemens 19:10, 2 September 2026 (UTC)

Page formatting problem

File:QR code for mobile English Wikipedia.svg#filehistory. Have a look at the last column ("Comment"). For me, at least, it is cut off. I'm at 1920 x 1080 on a PC, using Firefox, for what it's worth. - Jmabel ! talk 03:32, 5 September 2026 (UTC)

This isn't a formatting issue; the upload comment itself is truncated at 255 characters, probably either by the wiki at the time of upload or by the bot which was responsible for the upload. Omphalographer (talk) 00:43, 6 September 2026 (UTC)

@Omphalographer: yes, I know about the truncation, but for me the right-hand half of the column is cut off, even the header. Does it not look that way for you? I can do a screenshot if it is not something you can see on your system. - Jmabel ! talk 00:59, 6 September 2026 (UTC)

Interesting - I do not see that on my system. What web browser are you using, and what is your skin set to in MediaWiki preferences? Omphalographer (talk) 01:01, 6 September 2026 (UTC)

@Omphalographer: Vector 2022 skin, Firefox 154.0.01 running on a Windows PC. Screenshot now added above, you'll need to click through to the file page to read it intelligibly. - Jmabel ! talk 03:23, 6 September 2026 (UTC)

Ah - yes, I see the same issue if I switch to Vector 2022. Probably worth reporting at mw:Talk:Reading/Web/Desktop Improvements. Omphalographer (talk) 03:44, 6 September 2026 (UTC)

 Done - Jmabel ! talk 07:06, 6 September 2026 (UTC)

Yes, older versions of mediawiki limited edit summaries and image upload comments to 255 bytes (due to being stored in mysql as VARBINARY(255)). The limit is not quite as strict in newer mediawiki, but there is still a similar limit i believe. Bawolff (talk) 01:01, 6 September 2026 (UTC)

Again, I know that, and it has nothing to do with the problem I am reporting. - Jmabel ! talk 03:23, 6 September 2026 (UTC)

Yep, sorry, i replied before i saw Omphalographer"s comment and your response to it Bawolff (talk) 20:59, 6 September 2026 (UTC)

.ogg videos don't have thumbnails on Wikipedia?

On one of my uploads (I usually do webm but I use ogg sometimes) the thumbnail wouldn't show up on the Wikipedia article, I thought it was a fluke, but today I ran across another article using someone else's ogg video and the thumbnail for it wont render on Wikipedia either. Is this a known issue? Is there a fix? Just curious, Nesnad (talk) 12:10, 5 September 2026 (UTC) EDIT: If today's example is useful to see, this is the video that didn't have a thumbnail on Wikipedia: File:Schwebebahn timelapse.ogg Nesnad (talk) 12:12, 5 September 2026 (UTC) FINAL EDIT: Weird. Just noticed on another language Wiki it loads a thumbnail but not on English Wiki? Anyway, just looking for some thoughts. Nesnad (talk) 12:14, 5 September 2026 (UTC)

Broken import function?

I just tried to import the file Gem1.jpg from enwiki (and, in the process, rename it to "The Gem, second series, Number 1, 1908.jpg"). The error message I got was:

"Import failed

Internal error: MediaWiki\Status\StatusFormatter::getMessage: Invalid result object: no error text but not OK"

This broken import/upload process created File:The Gem, second series, Number 1, 1908.jpg, which has metadata and edit history from enwiki, but no associated file. I immediately tried again (with an extra period so as to avoid filename clashes), and got File:The Gem, second series, Number 1, 1908..jpg — which, again, has metadata and enwiki edit history, but no associated file.

I assume this has been a problem for a while; is there a quick way to check all recent imports to see if they're corrupt? DS (talk) 15:07, 7 September 2026 (UTC)

(Also, I think I was using the wrong heuristic to assess whether the image's copyright has expired; better to not put it on Commons just yet. The technical issue still applies, though.) DS (talk) 15:29, 7 September 2026 (UTC)

Tech News: 2026-37

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

• Add a Link has been upgraded for English Wikipedia users with improved detection of links that have different capitalization. This will help reduce ambiguous suggestions caused by differences in capitalization in article titles, including articles about cultural goods. A second phase of improvements is planned, which will also prepare the feature for release in other languages. [1] [2]
• The Article guidance feature will be enabled by default for junior editors on Simple English and Turkish Wikipedia starting 10 September 2026 following an experiment. Junior editors with 0 to 99 edits will automatically see the feature when they click a red link or use the "Madde oluşturto" option on Turkish Wikipedia to create a new article. The change is intended to help junior editors create higher-quality articles that meet each Wikipedia’s standards. Additional improvements will continue based on the experiment results and community feedback.
• The Pageviews Analysis tool which allows users to compare pageviews across multiple pages, turns 10 years old this year and several new features have been added. They include WikiNav which provides insights into how readers of Wikipedia explore the content, editing stats in Siteviews, the ability to lookup articles belonging to a WikiProject, and support for dark mode. [3]
• A visually simplified Minerva navigation bar is being tested for logged-out readers using mobile web on the Bengali, Czech, English, Farsi, and Polish Wikipedias. The experiment aims to determine whether simplifying the navigation improves reader retention. The test will run from August 31 to September 28, and no action is required from users.
• WMDE Technical Wishes is working on improving auto-generated reference names in VisualEditor. Editors will only notice a slight change starting this week. When adding automatic reference names the numbering will start at :1 instead of :0. Read more on the project page. [4]
• All wikis will be read-only for a few minutes on September 23. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [5]
• View all 25 community-submitted tasks that were resolved last week. For example, an issue where Parsoid could mishandle nested nowiki tags, causing content to be lost and displaying unwanted text has now been fixed. [6]

Updates for technical contributors

• Interface administrators can configure gadgets from MediaWiki:Gadgets-definition. The definition format has been updated and no longer requires the ResourceLoader option, as gadgets are always loaded through ResourceLoader. This simplifies gadget configuration by removing an option that is no longer necessary, making gadget definitions easier for administrators. [7]
• 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 18:41, 7 September 2026 (UTC)

"the numbering will start at :1 instead of :0" Arlo James Barnes 19:01, 7 September 2026 (UTC)

"We will only be adding arsenic to the well, not cyanide." DS (talk) 02:33, 8 September 2026 (UTC)

42 would be so much better! ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:45, 8 September 2026 (UTC)

All the better lest i confuse it with my xwindows display. Bawolff (talk) 20:07, 8 September 2026 (UTC)

I fixed links in this message that didn't show up because of missing colons. But because this is a mass message delivery, other wikis might have the same typos too that have yet to be fixed :v. HyperAnd [talk] 04:25, 8 September 2026 (UTC)

Who's is the issue?

Can someone explain what happened to me. There 2 (still visible for me) redirects (1 2) nominated for deletion using "nominate for deletion" gadget, where creator of both is @Túrelio (1, 2), however looks like gadget "missed" him and notified initial (from previous page iterations when it was a file - 1, 2) creator instead. Is that some kind of gadget's bug or as intended to miss page creators up to initial to notice them? ~2026-48708-14 (talk) 14:43, 8 September 2026 (UTC)

Advice on function

In File List, [8], it currently does not have a convenient function to search by title, date, format, colour et al., the characteristics of a file. And I would like a statistic on this page which shows how many uploads one has. Kaap bij Sneeuw (talk) 13:47, 9 September 2026 (UTC)

Rendering of new uploads is broken (or, at the very least, seriously delayed)

I've uploaded new versions of a couple images recently, and their old versions don't get refreshed/replaced by the newly uploaded ones. Please take a look.

More detailed info:

• The expectation after a new version is uploaded:
  • The PNG render on top of the page should update to the newly uploaded version
  • "Original file" link should allow the newest (freshly uploaded) version to be accessed
  • Thumbnails in the "File history" section should be updated immediately
• What actually happens:
  • The PNG render eventually updates - but with a significant delay of at least a few hours
  • "Original file" link still points to the older version
  • The most recent version's thumbnail is the same as the penultimate version's thumbnail

Examples:

• 17 hours delay (as of right now) and still counting - only PNG render has been updated (i.e. 1 out of 3 elements): File:F1 progress of record for most poles.svg
• Another upload (fresh) - also all 3 elements are delayed: File:Madring (2026).svg

Cherkash (talk) 18:00, 13 September 2026 (UTC)

another case study: file:Fu King Chinese Restaurant, Lake City, FL.jpg First the image and thumbnail were both upside-down, then Steinsplitter bot did its thing and the image was in theory right side up, but actually only the thumbnails were. Then the image was the right way up but the thumbnails had returned to inverted position, where they remain. Arlo James Barnes 19:31, 13 September 2026 (UTC)

UPD: Tried purging both of my examples just now. It didn't do a thing. Still broken. Cherkash (talk) 20:56, 13 September 2026 (UTC)

I'm facing the same issue with File:Airbus Industrie F-WULR Airbus A350-1041 Melbourne International Airport (MEL YMML) (55483824952).jpg. I originally made a request at the enwiki Graphics Lab to remove the watermark in the image, which was done by @Liandrei, but the new file version still had the watermark. Liandrei then did a bit of back and forth with the file and it shows that the intermediate versions had the watermark removed, but the newest version (which was a revert to one of the non-watermarked versions) always retained the watermark for some reason. S5A-0043🚎 09:22, 14 September 2026 (UTC)

phab:T425216 Bawolff (talk) 21:46, 14 September 2026 (UTC)

•  Comment I have problems with File:Samling af love og anordninger m. v. af mere almindelig interesse, udgiven efter Indenrigsministeriets Foranstaltning 1875-1880.pdf. the 250px looks right but the the 500px is wrong. I purged many times. --MGA73 (talk) 15:21, 25 September 2026 (UTC)

Stale thumbnail cache on File:James Nachtwey, Moscow, 24.03.2011.jpg

I overwrote this file to remove an unintended watermark (file history confirms the current version is correct/clean). However, the small thumbnail used on en:James Nachtwey still briefly shows the old watermarked version before swapping to the correct one on click-through. Tested on two separate devices and networks (desktop + phone), so it doesn't appear to be local browser caching.

Thumbnail URL: https://thumb.wikimedia.org/wikipedia/commons/thumb/7/7e/James_Nachtwey%2C_Moscow%2C_24.03.2011.jpg/500px-James_Nachtwey%2C_Moscow%2C_24.03.2011.jpg?utm_source=en.wikipedia.org&utm_campaign=parser&utm_content=thumbnail

Multiple ?action=purge attempts on both the file page and the article, plus a null edit on the article, haven't resolved it after several hours. Would appreciate immensely a server-side thumbnail regeneration if possible to preserve pristine imagery on the page. Oleg Cheremin (talk) 12:02, 14 September 2026 (UTC)

Tech News: 2026-38

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

• The Future Audiences team has started a about a proposed new experiment to show a temporary notice about the new Google Preferred Sources feature to Wikipedia readers coming from Google. The experiment is to test whether this notice makes visitors come back to Wikipedia more often. Preferred Sources feature lets users choose websites they trust so Google can highlight content from those sources more prominently in Search and AI experiences. We are interested in testing this on other languages that Google supports and would welcome assistance with starting conversations on other wikis. If interested, please reach out to Future Audiences on the talk page.

Updates for editors

• The chat platform Discord is releasing a new self-service framework that websites can use to specify how their links should look when shared on Discord. The Future Audiences team is planning to start using this new framework to improve how Wikipedia links look when shared on Discord, giving better attribution and credit to contributors. The link appearance and behavior won't change in the first phase of this project as we want to first collect some baseline data to assess the impact of future changes. However, if community members who are active on Discord spot any issues, they can reach out on Phabricator or Metawiki.
• The Reader Growth team will be running an experiment to test whether compacting article lead sections on mobiles with the addition of a "read more" button improves reader retention. The test will begin on September 17 on Arabic, Spanish, French, Indonesian, Italian, Japanese, Portuguese, Vietnamese, and Chinese Wikipedias and will run for four weeks.
• All wikis will be read-only for a few minutes on September 23. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming week. [9]
• View all 28 community-submitted tasks that were resolved last week. For example, an issue where Wikistats for Wikipedias was returning an HTTP 500 error and could not be reached, has now been fixed. [10]

Updates for technical contributors

• Developers who maintain a tool that queries the Wikimedia Commons links tables need to update their code to connect to the new x4 database cluster. The links tables have been moved from the s4 cluster to x4, and will no longer receive updates on s4. The page and redirect tables remain available on both clusters. A wiki replica for the x4 cluster will be set up afterwards. The change is being made because the s4 cluster has grown too large to operate efficiently. You can read more.
• 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:28, 14 September 2026 (UTC)

Date field vs embedded EXIF: one caught mismatch; P571 still stale; how are these handled?

While auditing capture dates of El Chaltén photos I caught this one: File:El Chaltén, Argentina (Unsplash).jpg had 2016-06-20 in its date field, while the embedded EXIF (DateTimeOriginal and GPSDateStamp) reads 2016-02-18. I corrected the field to match the file (diff).

Still stale: the file's structured data statement (P571) reads 2016-06-20. A bot added it from the file information before the correction. My attempt to update it from an unregistered session was stopped by the "SDC file metadata change" filter.

Two questions:

1. Is there an existing maintenance report or query that flags files whose date field disagrees with the embedded EXIF DateTimeOriginal? If not, is one wanted? I can spot-check a small sample and post a short list as a trial.
2. After a date correction like this, what is the usual path for the structured data? Ask someone to update the P571, or is there a bot/task that reconciles it?

~2026-50160-67 (talk) 18:46, 16 September 2026 (UTC)

1. I don't think so, you can't read the content of {{Information}} in SQL query, it is not stored in database. It is possible to read it via imageinfo API: Extension:CommonsMetadata#Returned data
2. You can update it yourself, you need to be autoconfirmed. I updated it for this file.

Nemoralis (talk) 10:35, 19 September 2026 (UTC)

PDF upload broken

I just tried to upload a PDF file of a court opinion, but the Upload Wizard and Upload forms both didn’t recognize it as a PDF. I had to upload the PDF to a PDF editing Web-site, download it, and then upload it again here for it to work. This needs to be fixed. TE(æ)A,ea. (talk) 23:32, 16 September 2026 (UTC)

Can you link to the source of the original PDF, or upload that file somewhere else? I have some theories about what might have happened, but no way to confirm without the original.

PDF is a weird format. A lot of readers will accept badly malformed files and try to fix them up - MediaWiki is a little stricter. (Most notably, many readers will accept files with leading junk before the %PDF header.) Omphalographer (talk) 01:24, 17 September 2026 (UTC)

• Omphalographer: It was File:United States v. Anderegg (7th Cir. 2026).pdf, which I had just uploaded. TE(æ)A,ea. (talk) 23:03, 29 September 2026 (UTC)

  Thanks! And sure enough, there was some leading junk in the original file reading as the text:

  Cas:25-1354:Typ:cr:Dat:08/25/2026:Jud:Lee:Doc:FinalOpinion:Now:Tue,_25_Aug_2026_15:21:13_CDT:Cap:USA v Steven Anderegg

  I've removed that header and reuploaded what remained to the same filename. (There should be no change to the visible contents of the PDF - either from the previous version or from the uscourts.gov original.) Omphalographer (talk) 02:41, 30 September 2026 (UTC)

Deletion nomination

Something went wrong with this deletion nomination. Can someone help fix it? Thanks, --~2026-50255-17 (talk) 22:32, 17 September 2026 (UTC)

What's the issue? Nemoralis (talk) 10:20, 19 September 2026 (UTC)

Broken SVG Media Viewer

Hello, since update of librsvg and media visual render of vector files in August 2026, Media Viewer created error that renders SVG in wrong way. This SVG image doesn't show white strip at the bottom in the Commons viewer, while normal original file in browsers shows it in correct way: File in Browser. From July 2025 to August 2026 such valid file did show exactly same in Commons as in all other normalized viewers and internet browsers like Chrome, Edge, Inkscape etc. ThecentreCZ (talk) 00:10, 18 September 2026 (UTC)

The white stripe in that SVG was defined in an incredibly strange way. (It was described as an absolutely enormous shape, tens of millions of pixels across, then scaled down to fit.) I've replaced it with a much more straightforward rectangle which should render correctly in all contexts.

For what it's worth, this didn't render correctly in Firefox either. Omphalographer (talk) 03:47, 18 September 2026 (UTC)

Edition problem

As I edit pages manually often the following error occurs: "Sorry! We could not process your edit due to a loss of session data. You might have been logged out. Please verify that you're still logged in and try again. If it still does not work, try logging out and logging back in, and check that your browser allows cookies from this site." Repeating attempt to edit will result to saving changes (not always, however) but it delays editing. Has someone a such problem? Юрий Д.К. 08:51, 20 September 2026 (UTC)

@Юрий Д.К. Yes, many: w:Wikipedia:Village_pump_(technical)#c-GiantSnowman-20260919184200-Loss_of_session_data Ponor (talk) 09:37, 20 September 2026 (UTC)

@Юрий Д.К.: Yes, a few times recently. It's happened before, though its relatively rare. Seems to happen in spurts when it happens. Just persist and retry when it happens; I'm pretty sure the relevant people are aware. - Jmabel ! talk 09:46, 20 September 2026 (UTC)

It seems also to affect uploads. https://phabricator.wikimedia.org/T438781 PantheraLeo1359531 😺 (talk) 18:37, 21 September 2026 (UTC)

Yes, I've had it happen mainly on uploads. I can't say much about the Upload Wizard, because I don't use it, but for Special:Upload, I've occasionally needed one or two retries, but nothing worse. - Jmabel ! talk 22:08, 21 September 2026 (UTC)

• @Ponor, Jmabel, and PantheraLeo1359531: Hello! Thank all for answers. By the time of this topic it was a really annoying thing (about 50% manual edits I forced to re-save); currently much better but it still occurs. UploadWizard works unstable also. Best, Юрий Д.К. 18:39, 22 September 2026 (UTC)

"add link"/"link with page" tool broken

Hi, I don't even know if this the good place to post this, as I don't know if the problem is on the Commons or the Wikidata side, but the tool (gadget?) to link a commons page to Wikipedia page via Wikidata (the "add link" option in the "in wikipedia" section that allow to create interproject links to Wikipedia via Wikidata) has been (again) broken, for weeks now. It has no problem to find the Wikipedia page(s) to link to Commons, but when trying to press the "link with page" button, it always fails, giving the error message "An error has occured. Invalid CSRF token." Rhadamante (talk) 13:13, 20 September 2026 (UTC)

How to update multiple SVG files at once

While working on Commons:Graphic_Lab/Illustration_workshop#Twisted_pair_cable_schematics_text, I could not find a way to upload new versions of eight SVG files which I had previously created at once instead of e.g. https://commons.wikimedia.org/w/index.php?title=Special:Upload&wpDestFile=Twisted_pair_sfftp.svg&wpForReUpload=1 for each. It seems the Upload Wizard allows only new files to be uploaded, not new versions of existing files.

Does anyone know of a quick way to update multiple files at once?

Thanks, cmɢʟee ⋅τaʟκ 08:58, 21 September 2026 (UTC)

Offhand, no, and I'm not sure it would be a great idea to have the Upload Wizard do this, I think it would be prone to accidental overwrites. - Jmabel ! talk 22:10, 21 September 2026 (UTC)

Thanks, @Jmabel: I see your point. The current way makes it even more likely the wrong file is uploaded on top of a file when done manually, if the filenames vary by just one character as in the set above. At least the wizard can pick up the filename from the uploaded file and overwrite the correct one.

Nevertheless, is there an existing tool that would allow this to be automated? Thanks, cmɢʟee ⋅τaʟκ 19:06, 22 September 2026 (UTC)

@Cmglee: I'm not aware of one, but I suspect you would do best to contact some of the people who do mass uploads. - Jmabel ! talk 19:19, 22 September 2026 (UTC)

Images displayed rotated by 90° in mobile view but correctly on desktop

I have encountered a reproducible problem with several portrait images uploaded to Wikimedia Commons.

The images are displayed correctly in vertical orientation on desktop, but in the mobile version of Wikipedia they are rotated by 90 degrees.

Example:

File:Сергей Ауслендер (2026)+.png

File:Елена Якович (2026).png

File:Зеев Ханин (2026).png

The PNG file is physically stored in portrait orientation (1503 × 2003 pixels) and contains no EXIF Orientation tag. The image is displayed correctly on desktop.

The same problem has occurred with other recently uploaded portrait images. Explicitly specifying the Commons filename in the Wikipedia infobox instead of obtaining the image through Wikidata did not solve the problem.

Could this be a thumbnail-generation or mobile rendering issue? I would appreciate help determining whether this is related to the current thumbnail-cache problems or whether a Phabricator task should be filed. TheKnowledgeEngineer (talk) 20:21, 24 September 2026 (UTC)

I checked File:Зеев Ханин (2026).png and its EXIF does contain a "Orientation" tag with "Rotate 90 CW". So, this is most likely the cause. Thanks. Tvpuppy (talk) 22:47, 24 September 2026 (UTC)

Regarding irregular implementation of Flickr Files ID and Too Much Errors

Hey, I want to report that during batch uploading of images from Flickr using Upload Wizard i had noticed two prominent problems first is the Flickr File Id are very irregular like in the first batch sometimes one of the file has the id and the other three don't when technically all of them should have there Flickr Id from start and should be in brackets () instead of dashes --. Other is that the error of too many requests is occurring quite often nowadays like on the second batch they are showing. I hope both of the problems should be solved as quick as possible. My other request is that the general image count should be increased to have atleast 8 Flickr files from the current 4 images per batch. Abdullah1099 (talk) 13:19, 25 September 2026 (UTC)

Also why the software removes every when the title on Flickr is like Large Sagittarius Star Cloud | 2020/08/10 instead it can convert them into Large Sagittarius Star Cloud – 2020-08-10. Please also solve this issue. Abdullah1099 (talk) 14:21, 25 September 2026 (UTC)

Hello @Abdullah1099

1. In my experience, the UploadWizard only adds the Flickr ID if there are duplicate image names. This means if all the image names are all different, the UploadWizard will not add the Flickr ID to the end.
2. As you have noticed, UploadWizard uses a dash for the Flickr ID. You may have notice other Flickr files uses brackets, those were maybe uploaded using Flickr2Commons instead.
3. Recently, there is ongoing problem with Flickr uploads limit, see discussion at Commons:Upload Wizard feedback#There was a problem during the HTTP request: 429 Too Many Requests.
4. I have no idea what you are referring to when you mentioned "general image count" should be "8 Flickr files per batch". As far as I know, there isn't such arbitrary image count or limit. The only limit that is related to this topic is UploadWizard only allowing uploads of 500 Flickr files at a time, or normal users are limited to 380 uploads per 72 minutes.
5. These characters # < > [ ] | : { } / are not allowed to be in filenames. This is why those characters are converted.

Thanks. Tvpuppy (talk) 15:14, 25 September 2026 (UTC)

@Tvpuppy, My view of your points are

1. I think the ID should be added for Every File from Flickr, If they catalog there file why not use it.

2. Dashes and Brackets are not very serious issue but i think the signs should be same.

3. Thanks for informing about the same issue is discussed on commons and i hope it's should be resolved quickly. This issue makes uploading images tedious as i am not in my hometown now and here the internet is not very great.

4. I am talking about during uploading Flickr images using Upload Wizard there is from start a limit of 4 images per batch then you can add another four images you want. I think the limit should be changed to atleast 8 images per batch. Thanks for informing me about there is an actual limit of 500 images.

5. My problem is that the software doesn't convert the symbols but directly remove the sentences and that should be solved. Abdullah1099 (talk) 02:50, 26 September 2026 (UTC)

There is no reason to have the Flickr ID number in the filename. The purpose of a filename is to identify a file (in searches and categories) for users. Source information belongs in the information template. Please spend your time writing useful descriptions for files you upload (versus the descriptions on Flickr, which are rarely ideal for Commons) rather than worrying about this. Pi.1415926535 (talk) 03:05, 26 September 2026 (UTC)

Ok, No problem. I mean it will be better if every Flickr file made available with ID rather than not. Yeah, It's on user to have the id in the title or not. Abdullah1099 (talk) 03:06, 26 September 2026 (UTC)

Tech News: 2026-39

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

Weekly highlight

• All wikis will be read-only for a few minutes on Wednesday, 23 September 2026 at 14:00 UTC. This is for the datacenter server switchover backup tests, which happen twice a year. During the switchover, all Wikimedia website traffic is shifted from one primary data center to the backup data center to test availability and prevent service disruption even in emergencies. [11]

Updates for editors

• The Growth team tested a new post-edit notice designed to encourage Temporary Account holders to register for a permanent account. The new notice replaced multiple dialogs and a simultaneous welcome notification with a single message highlighting the benefits of creating an account. The experiment increased permanent account creation from 1.94% to 3.66%, an 87% relative increase. The change will now be released to all wikis. [12]
• For Wikipedia editors using the "Suggestion mode" Beta Feature, there is a new opt-in user preference for showing "experimental" edit checks and suggestions. These types are listed at Special:EditChecks, and are intended for early developer-testing and for gathering feedback from experienced users. Administrators can change the configuration details for each suggestion as usual. Administrators can also use this feature to help test their community's ideas for locally created checks and suggestions. Experimental types will have a more distinct visual style later this week. Feedback is welcome.
• The CEE Technical Village Pump has been launched as a space for technical discussions and collaboration among Wikimedia communities in Central and Eastern Europe.
• A new tool, Starter Kit, is now available for new and small language Wikipedia communities. It brings together guided tasks, tools, and resources to help communities get started, monitor their progress, and collaborate with the broader Wikimedia community. Starter Kit is hosted on Wikimedia Toolforge and is designed for Wikipedias with fewer than 50,000 articles. Learn more about how Starter Kit works and how communities have been using it in this Diff blog post.
• The Reader Growth team is launching a retest of the image carousel experiment. The retest will use three new versions of the design, updated based on community feedback. The team will assess results and determine with communities whether or not to proceed with the feature. The experiment will begin the week of September 28 and will run on Arabic, Bengali, Chinese, Czech, English, Farsi, French, German, Indonesian, Japanese, Polish, Portuguese, Spanish, Swedish, and Vietnamese Wikipedias.
• After successful rollouts to Arabic, Bengali, Chinese, Czech, English, French, Indonesian, and Vietnamese Wikipedias, the Reading Lists feature from the Reader Experience team will be available to all logged-in users on all Wikipedia wikis starting September 28.
• View all 28 community-submitted tasks that were resolved last week. For example, an issue where the mentor status script repeatedly updated mentors’ status even when nothing had changed, creating unnecessary Recent Changes entries, has now been fixed. [13]

Updates for technical contributors

• The abusefilters list query API, used to retrieve specific details about active or historical abuse filters configured on a wiki, has been updated to support the formatversion=2 configuration parameter, thereby leading to breaking changes to the API response. All users who maintain user-scripts or other code need to check if they use the abusefilters list query API, and respond to any breaking changes. [14]
• 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 11:53, 27 September 2026 (UTC)

"Enable syntax highlighting for wikitext"

Any idea why "Enable syntax highlighting for wikitext" would have turned itself on in my preferences with no action from me? If I hadn't recognized the feature, I would have had a heck of a time working out how to turn it back off. - Jmabel ! talk 06:56, 28 September 2026 (UTC)

Maybe an accidental click on the "Syntax" item while editing? Glrx (talk) 17:52, 28 September 2026 (UTC)

I don't even know what 'the "Syntax" item' is. - Jmabel ! talk 20:05, 28 September 2026 (UTC)

See MW:Help:Extension:CodeMirror#CodeMirror_preferences.

I am currently editing my reply. I see the Syntax item to the right of the Bold, Italic, signature, link, etc buttons and just to the immediate left of the Advanced dropdown. Glrx (talk) 20:41, 28 September 2026 (UTC)

I certainly didn't deliberately click that, though I guess I could have done so accidentally. But I don't readily see how: for example, right now while I'm editing this, I don't see any of those controls, and that is more than fine with me. - Jmabel ! talk 21:24, 28 September 2026 (UTC)

Tech News: 2026-40

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

• Users of default skins on desktop and mobile web (Vector 2022 and Minerva respectively) will now be informed if the search suggestions displayed as they type into Search come from page redirects. Previously, users could get confused when the top search suggestions did not match exactly what they had typed. The new redirect notice clarifies that these suggestions are not random, but related to the search. The suggested pages may be redirects to the most relevant destination articles being searched for. [15]
• Logged-out Wikipedia users on mobile web will begin to see a bookmark button for saving articles to their reading lists instead of the current Watchstar button. When clicked, the bookmark button prompts users to log in or create an account to save an article for later. An earlier experiment found that the bookmark icon was four times more likely than the Watchstar button to encourage logged-out users to create an account. This change is part of efforts to encourage more readers to become account holders and use features that help them save and return to content. [16]
• An experiment will begin on September 29 on Spanish, Arabic, English, and French Wikipedias to simplify the experience users encounter immediately after account creation. The test will explore whether removing friction from the current Welcome Survey helps new users understand what to do next more easily. The experiment will run through the end of October. [17]

• The Product and Technology Advisory Council has put out a call for the community to suggest topics that it should consider and discuss with the Wikimedia Foundation. Editors and technical contributors are invited to add topics to the council's talk page.
• Later this week, it will be possible for communities to configure Edit Checks and Suggestions so that they are shown within additional namespaces, such as a Draft: namespace. Feedback is welcome.
• A bug in the Global Watchlist is causing the page to fail to load for users that have unseen changes on Wikimedia Commons. Developers are working on a fix. Until then, affected users can follow the workarounds described in the relevant help section.
• New magic words {{CATEGORYSORT:TIMESTAMP}} and {{CATEGORYSORT:RTIMESTAMP}} are now available for use. They are able to change the default sorting of categories to be based on timestamp of categorization. [18]
• View all 20 community-submitted tasks that were resolved last week. For example, the issue where Wikistats for Wikipedias was not reachable has now been fixed. [19]

Updates for technical contributors

• The datacenter switchover, scheduled on September 23, has been postponed. The equinox exercise revealed capacity issues, preventing the switch of all services to the other datacenter. The process has been paused, prioritizing investigating that issue, to ensure that we continue to be able to serve our users reliably. A new exercise will be scheduled. Meanwhile, all traffic and edits continue to work as usual.
• On September 23, a power loss briefly affected all wikis, creating intermittent issues on both reading and editing modes. This also affected Gerrit. This is unrelated to the datacenter switchover postponement. [20]
• Produnto has been deployed to mediawiki.org and some Indic language wikis. We want to hear your feedback on this experimental product. Produnto allows users to use Lua modules hosted in Wikimedia's GitLab. It simplifies the sharing of Lua code between wikis. Instead of copying each individual Lua module from one wiki to another, users will be able to easily share packages across all wikis.
• Detailed code updates later this week: MediaWiki

Meetings and events

• A Cross-wiki code collaboration workshop will be held online on October 2 at 12:30 UTC, bringing together South Asian technical contributors to learn about Produnto and begin piloting it on Hindi, Punjabi, Odia, Telugu, and Malayalam Wikipedias. Produnto is a package manager for deploying Lua modules hosted on GitLab to Wikimedia wikis, and was recently deployed on some pilot wikis.

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

MediaWiki message delivery 10:46, 28 September 2026 (UTC)

The sorting of entries by when they were categorized could help sort out large backlogs. Also, I found that you can sort a category by timestamp by adding ?cldsort=timestamp to the URL (?cldsort=timestamp&cldorder=desc for descending order), which doesn't edit the page itself unlike adding the magic words. HyperAnd [talk] 13:26, 28 September 2026 (UTC)

Wanted categories

Is it possible to revive the updates to Wanted Categories perhaps on a daily or even rarer (but predictable) schedule. I understand that it takes time to build the list, but when the list is 25 days old it is pretty much useless. Most of the categories there have been resolved, and I think it would be resonable to "kick" some script to redo it. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:44, 29 September 2026 (UTC)

Last month in technical changes (September)

An overview of activity since August 26th. These changes might not have made the bigger news bulletins as they're more specific to Commons and have smaller usecases and/or audiences.

• Fixed Varnish serving a stale cached version at a file's original (non-thumb) URL after the file was overwritten with a new upload. By @Krinkle. T425216
• UploadWizard now honours AbuseFilter's "show CAPTCHA" consequence on publish, with matching support landing in ConfirmEdit. By Product Safety and Integrity-team. T429321
• Animated WebP files can now be uploaded and get animated thumbnails, instead of a static frame. By @Kizule. T290345
• Hitting the thumbnail failure-limit now correctly returns a 429 (too many requests) instead of a misleading 500 error. By Media Platform Team. T439110
• Special:UploadStash hardening by Tim Starling: thumbnail names are now validated before serving (rejecting URLs with trailing garbage) T436201, omitting a thumbnail width no longer throws an exception T436202, and it now sends a CSP header like thumb.php already did T436203.
• Fixed a chunked-upload bug where retrying the last chunk after a request timeout could hit a database timeout instead of completing. By Umherirrender. T212101

And a small repeat of a few of the more important Commons changes that were published before.

• Commons' link tables (categorylinks, pagelinks, templatelinks, imagelinks, etc.) have been split off into their own dedicated database cluster ("x4"), separate from the rest of Commons' data ("s4"). The Commons database had grown too large and this was causing problems. Tool maintainers querying these tables directly need to switch to the new cluster. See the wikitech writeup for details. By the Data Persistence team. T398709
• The move of thumbnail URLs from upload.wikimedia.org to thumb.wikimedia.org (announced in Tech News) has now been rolled out to all wikis. Old upload.wikimedia.org thumbnail links keep working for now. The switch broke a few Commons gadgets that hard-coded the old domain, like ImageAnnotator and the "direct link to Commons" gadget. Both have since been fixed. By Media Platform Team. T427465

Apologies if I forgot to name a few people. —TheDJ (talk • contribs) 15:32, 29 September 2026 (UTC)

Question: if I have (as I have had for years) some deeplinks like https://upload.wikimedia.org/wikipedia/commons/0/05/Bundesarchiv_Bild_146-2005-0119%2C_Kurt_Weill.jpg on my own site, does this mean that these are now deprecated and at some point they will break? If so, what is the preferred way for me to change that? - Jmabel ! talk 18:45, 29 September 2026 (UTC)

@Jmabel well that link doesnt have /thumb/ in the path, so it's an original and it will remain the same. But if they were a thumbnail, then you should probably update them to the new servername, to prevent them from breaking some time in the future. How far in the future, I cannot say. —TheDJ (talk • contribs) 19:50, 29 September 2026 (UTC)

Would be sad if we just break them instead of returning a redirect. Bawolff (talk) 22:06, 30 September 2026 (UTC)

Flickr upload now return "There was a problem during the HTTP request: 403 Forbidden" instead "There was a problem during the HTTP request: 429 Too Many Requests"

No matter the Upload Wizard and Flickr2Commons, it just will return the same "There was a problem during the HTTP request: 403 Forbidden" instead "There was a problem during the HTTP request: 429 Too Many Requests" message when Uploading from Flickr. KMB1933 (talk) 01:59, 30 September 2026 (UTC)

Upload Wizard - The server responded with an invalid JSON document.

The last few days I tried to upload a few files to Commons using Special:UploadWizard

After I click the upload button, a red stop sign with an exclaimation point appears with this text:

• "The server responded with an invalid JSON document. This could be a problem with the API, or you could be using a proxy server that prevents you from uploading files."

I have never seen this error, nor do I have a "proxy."

How can I resolve this issue or is it a tool issue? Thank you, -- Ooligan (talk) 17:44, 30 September 2026 (UTC)

If you know how to do this, it would be helpful if you could look in the browser developer console network tab to see what the api returned when you get this error (i appreciate this might be technically difficult for most people) Bawolff (talk) 22:08, 30 September 2026 (UTC)

Hello @Bawolff, I will try. If you have any link that shows how to do it, that would be helpful. Thanks, -- Ooligan (talk) 22:44, 30 September 2026 (UTC)

Thumbnails for File:Suntur Paucar.svg persistently return 429

Thumbnail requests for File:Suntur Paucar.svg have returned HTTP 429 for several days, through multiple caching datacentres. The request body is Too many thumbnail requests for failing image

After running ?action=purge, I now see HTTP 400 Bad request errors instead. I see the same result for different sizes e.g. 250px and 330px, on both upload.wikimedia.org and thumb.wikimedia.org.

• The original SVG downloads fine (HTTP 200).
• This isn't client rate limiting: x-ratelimit-remaining is near the maximum, and there's no Retry-After.

It looks like the SVG fails to render, and Thumbor's failure throttle never resets. Possibly this is to do with markup errors in the original SVG? How might I resolve this? Matthew at catfishing (talk) 13:55, 1 October 2026 (UTC)

Appears fixed, thanks to @Snævar for editing the SVG. Matthew at catfishing (talk) 07:35, 2 October 2026 (UTC)

Category gallery count shows negative number

In the last few days I have seen some categories which claim to have negative number of galleries when seen from the parent category. For example in Category:Korvenkylä, Lappeenranta the subcategory Category:Tiuru Hospital shows as

Tiuru Hospital (-1 P, 20 F)

While this is easy to fix with a null edit on the category it becomes tiresome to do it by hand. Does anyone know what causes this? MKFI (talk) 16:36, 2 October 2026 (UTC)