Commons:Village pump/Technical/Archive/2026/03

Category:Commons talk archives#Village%20pump/Technical/Archive/2026

Puzzling category placement of a video file

Does, other than me, somebody see why this video file is placed into category Pages using duplicate arguments in template calls (with an according error message)? If there is no valid reason, how to fix this? — Speravir – 03:16, 1 March 2026 (UTC)

Looks like a problem with {{Media of the day}} Bawolff (talk) 03:23, 1 March 2026 (UTC)
Aah, yes, this was the last added template, and afterwards the error message appeared. I forgot to mention this. — Speravir – 03:27, 1 March 2026 (UTC)
Fixed https://commons.wikimedia.org/w/index.php?title=Template:Motd/2026-04-28_(de)&diff=prev&oldid=1173830105 Bawolff (talk) 03:33, 1 March 2026 (UTC)
Aaargh! ●°.°● Thank you. — Speravir – 03:38, 1 March 2026 (UTC)
This section was archived on a request by: --Speravir 03:38, 1 March 2026 (UTC)

Quarry querry for total size in bytes for specific file names

Hi, I have this query. How do I modify this so that the query only counts files within a category that have the string “ABCD” in their name? Thank you :) --PantheraLeo1359531 😺 (talk) 13:48, 3 March 2026 (UTC)

AND p.page_title LIKE '%ABCD%' should do the trick. — Alien 3
3 3
17:47, 3 March 2026 (UTC)
Perfect, thank you, that's it :D --PantheraLeo1359531 😺 (talk) 10:46, 4 March 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:25, 4 March 2026 (UTC)

Massrename & Global replace glitch

I have User:Perhelion/massrename.js in my common.js. I'm no longer seeing the choice when I'm in a category. Pretty sure I've used it within the last week, so this is new. Using Vector (2022) on a PC with Firefox, if that matters. Any clues would be appreciated. - Jmabel ! talk 18:33, 5 March 2026 (UTC)

@Jmabel, due to an earlier incident affecting multiple wikis, all site and user javascripts are temporarily disabled. Thanks. Tvpuppy (talk) 18:36, 5 March 2026 (UTC)
@Tvpuppy: Thank you! And I wondered why "Global replace" was no longer in my list. This must be the reason. Best regards, זיו「Ziv」For love letters and other notes 22:04, 5 March 2026 (UTC)
You can follow phab:T419154 for the scripts in particular. —Justin (koavf)TCM 23:34, 5 March 2026 (UTC)
 Info, see announcement by WMF, it appears all site and user javascripts have now been re-enabled. Thanks. Tvpuppy (talk) 01:17, 6 March 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:58, 6 March 2026 (UTC)

Upload from Flickr not working

I am unable to upload my Flickr photos using the Upload Wizard. No errors, just does nothing upon entering link and clicking the button. I am guessing this has to do with the incident from earlier today? Hope it works again soon, Flickr2Commons also doesn't work, as usual. PascalHD (talk) 05:12, 6 March 2026 (UTC)

 Comment, see related discussion at Commons:Help desk#Commons Upload Wizard is broken. Thanks. Tvpuppy (talk) 15:38, 6 March 2026 (UTC)
(I noted this there as well; but for the record, but I've filed phab:T419263 about this.) a smart kitten[meow] 16:40, 6 March 2026 (UTC)
This should work now. Nemoralis (talk) 10:49, 7 March 2026 (UTC)
Mostly I believe it now does, yeah — as far as I'm aware, there's now just an issue with some image thumbnails not being displayed when UploadWizard is given the link to a Flickr album (as opposed to a single file). Best, a smart kitten[meow] 19:45, 7 March 2026 (UTC)
The album thumbnail issue now appears to be fixed, I can see them displaying properly now. Thanks. Tvpuppy (talk) 22:24, 9 March 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --Tvpuppy (talk) 00:50, 10 March 2026 (UTC)

Can't update map data

I'm trying to update Data:Wikivoyage/Hyderabad.map to improve the coverage of the Wikivoyage article on voy:Hyderabad. However, when I try to update it, it says, "The text you have submitted is 2,238.514 kilobytes long, which is more than the maximum of 2,048 kilobytes." The main changes I wanted to do are:

  • To merge Southern Suburbs with South, and
  • To expand North, West, and East to cover the entire metropolitan region.

And it's strange to find that there's a 2048 kB limit on updates. So, how to divide my update into chunks? Sbb1413 (he) (talkcontribsuploads) 06:08, 17 March 2026 (UTC)

Well, I overcome this by uploading South Hyderabad separately as Data:Wikivoyage/Hyderabad/South.map, which is the biggest of the geoshapes in my original GeoJSON file. Sbb1413 (he) (talkcontribsuploads) 06:34, 17 March 2026 (UTC)
@Sbb1413 in general, the solution is: use fewer nodes (fewer corners) for your shape. geojson should not be super detailed generally. it's not like street map, it will carry all detail to the top level, causing very high data sizes. —TheDJ (talkcontribs) 11:21, 17 March 2026 (UTC)
Thanks. Sbb1413 (he) (talkcontribsuploads) 11:50, 17 March 2026 (UTC)
This section was archived on a request by: Sbb1413 (he) (talkcontribsuploads) 06:34, 17 March 2026 (UTC)

librsvg does not support fallback font set (more than one font family)

Later note: This has been resolved. Font fallback is working now. Tests below show current situation.

See Phab:T64986: "librsvg does not support fallback font set (more than one font family)"

"I believe after purging SVGs are now obeying the font list. Not closing until this is confirmed"

That was from June 6, 2024! Has anybody confirmed this yet?

I guess you would need to upload an SVG file with sections using different fonts for the same line of text.

1st section:

font-family="Verdana"

2nd section:

font-family="Verdana,Liberation Sans"

3rd section:

font-family="Liberation Sans"

See Help:SVG#Font substitution and fallback fonts: For the user agent librsvg, the default font is Liberation Serif.

According to this Google search Verdana does not have a substitution font provided by Wikimedia. I don't know if this is true. So the top section should show the default serif font (Liberation Serif) instead of the sans-serif font Verdana.

If font fallback is working the 2nd section should be using Liberation Sans. If it is not working then it should show Liberation Serif, and should look exactly the same as the first section.

The 3rd section will show Liberation Sans, which Wikimedia definitely has.

So if font fallback is working, then sections 2 and 3 should look exactly the same.

If font fallback is not working, then sections 1 and 2 should look exactly the same.

I don't know how to create SVG files, and so somebody else will have to do this. --Timeshifter (talk) 01:00, 18 March 2026 (UTC)

Pinging people from the Phab thread, and more: Pppery. HNowlan (WMF). cmglee. Glrx. I also asked for people to come here from Commons:Graphic Lab/Illustration workshop. Between all of us someone should be able to create a test SVG file. --Timeshifter (talk) 02:05, 18 March 2026 (UTC)
Does this work?

ᛅᛒᛁᛘᚢᛋ (talk) 09:58, 18 March 2026 (UTC)

Thanks Abemos! It looks like I can increase the text size via the image wikitext:

[[File:SVG_font_fallback_test.svg|800px|none]]

I added 2 recently created sans-serif fonts (according to a Google search): NeuSans and Salsiccia.

It looks like Wikimedia is using the same default sans-serif font to replace Verdana, NeuSans, and Salsiccia if they are the only font listed in the font-family. I think it is DejaVu Sans. Look at f and r and a. See the font characters listed here:

File:SVG Text Font Test.svg

If Liberation Sans is also listed, then Wikimedia uses it. That means font fallback is working. You can recognize Liberation Sans by looking at f and r and a. See it listed in the above-linked file. --Timeshifter (talk) 01:03, 19 March 2026 (UTC)

I just want to mention that I choose the fonts directly through the font-family property. It might display differently if done through the style property. If the original theory is correct. That could be the reason. I'll try testing this too. ᛅᛒᛁᛘᚢᛋ (talk) 21:36, 19 March 2026 (UTC)

This graphic uses the style property instead:

This looks correct too. ᛅᛒᛁᛘᚢᛋ (talk) 21:48, 19 March 2026 (UTC)

Thanks Abemos. I uploaded them both to Shoutwiki too: . I use Vector 2010 or Vector 2022 skin on the wiki I edit on there. The files look exactly the same there as here. I did not have to purge or do anything special. They looked the same before and after using ctrl-F5 with my Firefox browser.
I left a note at the Phabricator task linking to here, and pointing out that I think font fallback is working. --Timeshifter (talk) 04:08, 20 March 2026 (UTC)
Phab:T64986 has been closed as resolved. --Timeshifter (talk) 13:52, 20 March 2026 (UTC)
Is this thread issue solved then? Prototyperspective (talk) 14:35, 20 March 2026 (UTC)
Prototyperspective. Yes. --Timeshifter (talk) 15:00, 20 March 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 15:18, 20 March 2026 (UTC)

COM:LRR archiving

It looks like SpBot has stopped archiving closed discussion at COM:LRR after the changes implemented at and after Revision #1181980614. (Existing level 2 header was replaced with level 3 header and a seperate level 2 header was introduced) Maybe some config needs to be changed or anything else so that the bot re-starts archiving. @The user who changed it at LRR has already implemented level 3 headings at Revision #1181981624 in the archives for 2026. Shaan SenguptaTalk 10:44, 18 March 2026 (UTC)

✓ Taken care of Thanks to Armbrust. Shaan SenguptaTalk 10:40, 20 March 2026 (UTC)
This section was archived on a request by: Shaan SenguptaTalk 10:40, 20 March 2026 (UTC)

User:YiFeiBot seems to have stopped working

Hi all,

It seems that User:YiFeiBot has stopped working. It hasn't made an update (Special:Contributions/YiFeiBot) since March 12 when normally it would scour changes one a day. At a minimum it was adding and removing entries from Category:Pages using Information template with parsing errors and Category:Media missing infobox template.

As far as I could tell the bot wasn't blocked for misbehaving or anything of the sort. It also looks like User:Zhuyifei1999, who I assume was its owner has retired and not made any edits for almost a year. I was pointed in this direction from Commons:Administrators' noticeboard (the only other authoritative link on User:YiFeiBot.)

Any assistance in this matter would be greatly appreciated.

Thanks, --Stux (talk) 18:23, 19 March 2026 (UTC)

Broken by phab:T299951. Should be fixed now, I think --Zhuyifei1999 (talk) 21:31, 19 March 2026 (UTC)
Thank you @Zhuyifei1999! And you're alive! Next time if something happens I'll ping you directly as well. But I can confirm that the bot is now working again! --Stux (talk) 10:27, 20 March 2026 (UTC)
I would prefer email. The only reason I saw this thread was because someone emailed me about something regarding Commons. I'm likely to not see pings --Zhuyifei1999 (talk) 10:33, 20 March 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 14:34, 20 March 2026 (UTC)

Lua error

File:Relief depicting Ptolemy XII offering wine to Geb 01.jpg, which I'm pretty certain was fine when I created it on 4 January 2026 and until very recently, was recently tagged by YiFeiBot with Category:Pages using Information template with parsing errors. There is no overt {{Information}} template on that page, but I assume that was invoked by {{Art Photo}}. The page does, indeed, now give an error "Lua error in Module:Size at line 235: attempt to index field 'P518' (a nil value)." That's presumably applies to part (P518). FWIW, Relief depicting Ptolemy XII offering wine to Geb (Q137685825) has no changes since I created it on 4 January 2026 and does not overtly use applies to part (P518), so I'm pretty sure the error must be a recent change in the Lua module, not in my content on either Commons or Wikidata.

Following that up, I would guess that Special:Diff/1179794875 (about a week ago) by Marsupium is at fault, but honestly I've never worked with LUA and it's about midnight here as I write this, so I'm not going to investigate further myself right now. - Jmabel ! talk 07:00, 20 March 2026 (UTC)

@Mike Peel reverted the change, so everything should be back to normal. --HyperGaruda (talk) 08:25, 20 March 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 14:34, 20 March 2026 (UTC)

Tech News: 2026-10

MediaWiki message delivery 17:48, 2 March 2026 (UTC)

Exploratory: Handling the uploading of images better

This is nowhere near any form of proposal. If it were I would have formulated it as such. This is separate from the question "Should this be done?" which is when a proposal might be made in order to determine that greater decision.

Background / problem

A strong example of the issues Commons faces, especially with bulk uploads, is discussed with respect to a particular uploader at Commons:Administrators' noticeboard/User problems § Uploads by Fabe56. I do not anticipate that we shoudl discuss uploader specific issues here. I use ut purely as an example. Distilling the key points from the tl;dr discussion for those without the inclination to take a deep dive, it is all too easy, and with good faith, to Upload great swathes of files which are correctly licenced for onward use, without:

  • using sensible file names. "DSC, IMG etc are useless for descriptive and retrieval purposes
  • entering the uploaded files into a meaningful category scheme which is part of a full Commons hierarchy
  • using critical judgement and uploading many files of high'y similar nature

This results in the use of Commons as what may appear to be a personal file store by some uploaders, perhaps even a kind of vanity of the "I have uploaded more than you" sort

Solving the existing issues

Nothing obvious springs to mind to solve the existing problem. We are not speaking of a small number of files. The example has over two hundred thousand files of varying quality and variable retrievability. It might be that Commons has to bite the bullet on legacy uploads and work towards a future which seeks to promote good housekeeping at upload time.

Working for the future

I assume there is some form of Edit Filter which is, or can be implemented on Commons which would seek to control this at upload time. This is the reason I have posted this at the technical Village Pump, not the one for proposals. I hope that those who understand filtering tools and enjoy technical puzzles can look at the issues form above, and consider how uploads might be better handled to seek to ensure the ability to catalogue them for retrieval and, where desirable, use.

I'm posting this exploratory post because I do not have the skill to formulate even in plain language, how a technical solution might be created. But we have experts in all fields here who have that skill. 🇵🇸🇺🇦 Timtrent 🇺🇦 talk to me 🇺🇦🇵🇸 12:59, 2 March 2026 (UTC)

Please see Commons:File naming and Commons talk:WMF support for Commons/Upload Wizard Improvements#Guidance/facilitation of categorization. Further comments there as well as specific ideas what else could be done (how) would be welcome. Prototyperspective (talk) 14:01, 2 March 2026 (UTC)
@Timtrent: Sorry, I seemingly fail to understand what you wanted to express in your section heading. The sequence of an adjective and two -ING words is puzzling for me, who's not a native English speaker, so I can't correct that in my head. Did you use some kind of autocompletion tool while writing who bungled the wording? Going by the main body of text, did you perhaps mean something along the lines of "Exploration of possible new ways to better handle file uploads"? Please confirm or fix the wording according to your actual idea. Regards, Grand-Duc (talk) 16:06, 2 March 2026 (UTC)
I amended the title. 🇵🇸🇺🇦 Timtrent 🇺🇦 talk to me 🇺🇦🇵🇸 18:26, 2 March 2026 (UTC)
Since Commons:File naming already says that images should not have generic names such as DSC123456.jpg it does seem appropriate that an Abuse filter would at least log such uploads if not outright block them. For Fabe56 to have uploads 18000+ DSC... images without challenge is odd, I'm sure there are other automatic meaningless names they used.
Since the filter is just on an per edit basis, a bot would presumably be required to spot a pattern of possible bad upload behaviour. It would also be useful if a bot made regular lists of batch uploads with a common factor, such as all from a Flickr account; all named in a format {prefix} {number}.{extension}; etc. This would make it easier to review mass uploads to flag as problematic, raise a deletion discussion or if useful to better name/categorise/etc as a group. It would also be easier to go back and review past batches for an uploader if a problem is identified. KylieTastic (talk) 19:27, 3 March 2026 (UTC)
Looking into that, Flickr transfers of DSC filenames aren't caught by the MediaWiki:Titleblacklist. A Fabe56 upload like File:DSC 8266 (13991064494).jpg wouldn't have triggered the File:DSC.[\d\s]+\.JPG blacklist entry because of the Flickr ID in parentheses. It's only looking for a plain File:DSC 8266.jpg. We might want to add a few more possibilities for Flickr in the "Other common patterns" section of the blacklist. Belbury (talk) 19:46, 3 March 2026 (UTC)

Just a finding.

Whenever I nominate a file for deletion, I start to receive notifications about unrelated deletion requests, and I have to turn off notifications manually. Can someone fix this? Candidyeoman55 (talk) 10:01, 5 March 2026 (UTC)

See the prior discussions about this at Receiving reply notification when subsequent DRs are added to daily page. Looks like by now phab:T412462 is solved but in practice one still needs to manually unsubscribe from the DR page to stop getting these notifications. Prototyperspective (talk) 15:13, 5 March 2026 (UTC)

The Challenge Speedy Delete button worked but there was an unfortunate anomaly

Please examine Commons:Deletion requests/File:Baswanthrao Patil TRS.jpg

Salient points:

  • I challenged an SD on the file using the big grey button
  • There had been a prior DR
  • The SD challenge grabbed the prior DR rationale instead of the SD nominator's rationale
  • This caused confusion between me and Shaan Sengupta who was the SD nominator.

While the circumstances are unusual they are unlikely to be unique. Please will someone who understands this record it as an issue to be investigated? 🇵🇸🇺🇦 Timtrent 🇺🇦 talk to me 🇺🇦🇵🇸 15:23, 5 March 2026 (UTC)

I went to the old revision, and clicked the "Challenge speedy deletion" button to check, and I got the same incorrect DR message as you did. I have no idea what is the reason for this, since for me the gadget is working fine for the other files in similar situations. Thanks. Tvpuppy (talk) 03:27, 6 March 2026 (UTC)
  • I just tested with other files, I found out that if you clicked the "Challenge speedy deletion" button, it will always get the delete reason of the earliest instance of that specific SD template, not the current instance.
  • So, for the case of File:Baswanthrao Patil TRS.jpg, if other users nominated the file for speedy using {{Copyvio}} again, and then you challenge it, it will always incorrectly get the earliest delete reason made by User:আফতাবুজ্জামান in 2024, not the latest one made by other users (the correct one).
  • The problem is most likely in MediaWiki:Gadget-AjaxQuickDelete.js, probably somewhere between line 735 and 811. However, I have still no idea what the cause of the problem. Perhaps someone more knowledgeable can help fix this.
Thanks. Tvpuppy (talk) 04:01, 6 March 2026 (UTC)

Critical error with ‘use this file on web’ functions

The integration of images from Commons no longer works to a large extent. I described the problem here: https://commons.wikimedia.org/wiki/Commons:Help_desk#Warum_funktioniert_das_Einbinden_eines_Bildes_in_eine_externe_Website_nicht_ (see example). The cause (according to my tests) is that ‘use this file on web’ (or ‘embed’) works with image sizes such as ‘256’ or ‘512’, while technically it has obviously been changed to “250” and ‘500’! If I manually change the 256 or 512 to 250 or 500 in the ‘Embeds’ in the ‘Thumbnail Link’, it works again. With my extremely large number of affected pages from the last 10 years (which I cannot automatically adjust myself), this is extremely annoying. But even the current ‘use this file on web’ template (on German Wikimedia Commons) still offers the old values (which no longer work) – so it is currently inoperable (no longer works). However, it would make sense for the ‘previous solutions’ in the existing world, such as my many pages, to continue to work, e.g. by redirecting the “256” link versions to the new ‘250’ versions. (This applies to the other sizes as well, of course: 512=>500, etc.) Or is there already an elegant solution for automatically changing the format in ‘externally hosted’ websites (in my case, Strato)? It would also be very unfavourable for the ‘use this file on web’ function as a whole if there were no guarantee that the integrations would continue to work in the long term and could not suddenly fail at any time (as is currently the case). Is anyone already working on a solution? Unfortunately, I am unable to do so. What does the solution will look like? Dirk Liesch (talk) 10:54, 5 March 2026 (UTC)

Seems like the stockphoto gadget needs an update to suggest the recommended file sizes. Johannnes89 (talk) 12:44, 5 March 2026 (UTC)
I have a proposed fix on the stockphoto gadget talk page. Bawolff (talk) 10:20, 9 March 2026 (UTC)
@Bawolff: Where? I see nothing at File talk:Wikimedia Commons - Stockphoto gadget.png. - Jmabel ! talk 19:16, 9 March 2026 (UTC)
@Jmabel at mediawiki talk:Gadget-Stockphoto.js Bawolff (talk) 20:13, 9 March 2026 (UTC)
@Bawolff: Thanks!
Question: wouldn't it make sense that when we get a request for a thumbnail size that is no longer supported, we round up to the next higher supported thumbnail size? - Jmabel ! talk 22:40, 9 March 2026 (UTC)
Yes it would, and it would have made everyone's life easier if they did that. Unfortunately they did not and its a giant pain (this script is not the only thing that broke, there has been breakage all over the place). Honestly i find the whole situation annoying and frustrating. Note that special:filepath will round up, if you use it. Bawolff (talk) 01:03, 10 March 2026 (UTC)

Help fixing template i18n

Since no one else would do it, I finally created an {{AI modified}} template, so that we can track media altered by AI software (as required by the new Commons:AI images of identifiable people guidelines). However, I'm sure I fucked up the i18n set-up (which is quite confusing). If anyone could fix it and get it to use the translate extension for i18n, that would be awesome! Nosferattus (talk) 23:53, 8 March 2026 (UTC)

Perhaps it's better to post this at Commons:Translators' noticeboard, since this issue may require a translation admin to fix. Thanks. Tvpuppy (talk) 22:21, 9 March 2026 (UTC)

Tech News: 2026-11

MediaWiki message delivery 18:50, 9 March 2026 (UTC)

Requesting bulk data cleanup - Scheer photos with credit in EXIF

Andrew Scheer, formerly leader of the opposition in Canada's parliament, has a Flickr stream that releases photos as CC-0, resulting in 1,901 files in Category:Files from Andrew Scheer's Flickr stream. When these files were uploaded from Flickr, since the account's under his name, Scheer was listed as the 'Author'. Poking around some of the files, I see many whose EXIF credits Andre Forget (e.g. File:088A0780 (41365002220).jpg with "Photos Andre Forget / OLO", where I assume OLO refers to Office of the Leader of the Opposition; another with slightly different credit is File:Andrew Scheer (40839023063).jpg).
Request: Is it possible to, in bulk, identify all of those which credit Andre Forget in the EXIF, and update him as the Author/Photographer of those images? Even though we don't need to credit the photographer as the files are CC-0, I think it's still worthwhile to credit the right person. -Consigned (talk) 01:32, 10 March 2026 (UTC)

I know we have bots that access EXIF data and act accordingly; given that Category:Files from Andrew Scheer's Flickr stream is not a large universe, certainly a bot could run over this data file-by-file and edit accordingly.
I don't think there is any user-facing way to search for particular content in EXIF data. - Jmabel ! talk 04:19, 10 March 2026 (UTC)
At worst, we could make sure the existing bot that extracts author info from EXIF data to SDC runs on all files in this category, after which I believe a Quarry query could find the relevant files. - Jmabel ! talk 04:21, 10 March 2026 (UTC)
Quarry can't access SDC, however it can access exif, so it should be posdible to get it to make a list. Bawolff (talk) 22:00, 10 March 2026 (UTC)
@Bawolff: ah, I thought it was the other way around! (Shows what tools I don't use.) - Jmabel ! talk 05:30, 11 March 2026 (UTC)
I can get a list with Quarry - can VFC perform an update using a manual list? I don't think EXIF shows up in VFC's search query. But looking deeper into VFC at Help:VisualFileChange.js/samples#Inserting variables, there seem to be examples of pulling information EXIF out and duplicating it elsewhere - seems like this might work, will look into it further. I've never worked with bots and would prefer to do this on my own if possible. -Consigned (talk) 10:11, 11 March 2026 (UTC)
In case its helpful: https://quarry.wmcloud.org/query/103004 Bawolff (talk) 18:05, 11 March 2026 (UTC)
Thanks, this is indeed helpful. I'm still stuck with VFC not being able to use a custom list of files and its criteria not able to access EXIF, but am going to look into AWB. -Consigned (talk) 10:21, 17 March 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --廣九直通車 (talk) 05:47, 9 April 2026 (UTC)

Croptool won't let me overwrite

Hello, I was trying to crop this image, and I decided to overwrite instead of uploading new (which I haven't tried before), but I got this text: "Upload failed! [api] Received error: abusefilter-disallowed : ⧼abusefilter-warning-file-overwriting⧽". I would have assumed it would let me, considering I'm Autoconfirmed, so I'm allowed to do most other actions. Does this require a higher level of permission? LetmeEditit (talk) 19:15, 10 March 2026 (UTC)

@LetmeEditit Yes, you need autopatrol to overwrite files. Please see COM:OVERWRITE. You may request an exception for that specific file, or you can request the autopatrol permission. Thanks. Tvpuppy (talk) 19:45, 10 March 2026 (UTC)
You would need "Autopatrol" for that, see Commons:Overwriting existing files. Please request that right on COM:RFR#Autopatrol, with your 4k edits, it should be a no-brainer to get it. If you don't want to wait for it, ping me, I'll add {{Allow Overwriting}} for a short time. Regards, Grand-Duc (talk) 19:46, 10 March 2026 (UTC)
Thank you both for informing me. I've put in a request for autopatrol now. I probably won't use it much, since most of the time I think uploading a separate file is better, but it seems like a nice thing to have the option. Side note — I think the error message should be changed to be more clear, it's very vague. LetmeEditit (talk) 20:02, 10 March 2026 (UTC)
@LetmeEditit: but how could it be appropriate to crop in place a file that is used in articles in multiple Wikipedias, rather than upload your own version? You are forcing a change on every one of those Wikipedias. Have you properly read COM:OVERWRITE? - Jmabel ! talk 05:32, 11 March 2026 (UTC)
COM:OVERWRITE is kind of confusing, and it seems like a lot of the policy on here should really be re-written for more clarity. I personally feel like a crop to the image fits the example provided at Commons:Overwriting existing files#Substantial crop or un-crop, since the grass is a fairly repetitive negative space, which IMO doesn't add any value to the image. The image's use case in each article is to illustrate the unique colour of the fox, and I think the large section of grass detracts from that, as it makes the fox hard to see.
I think the best solution would be to re-write this section of policy, as a new user it's confusing and seems contradictory in places. LetmeEditit (talk) 12:13, 11 March 2026 (UTC)
Pinging @Tvpuppy, Grand-Duc, since you both apparently see no problem here. What am I missing? - Jmabel ! talk 05:34, 11 March 2026 (UTC)
You're right, in this case, a new file should be created instead of overwriting. Admittedly, I didn't pay much attention to the file, as I was focused on answering the part about permission to overwrite. Thanks for your additional comment above. Tvpuppy (talk) 10:28, 11 March 2026 (UTC)
I feel a comradeship in spirit with Tvpuppy here... I also only thought about the technological prerequisites of overwriting, not so much about whether the actual act would be sensible here. When I looked at the fox image, I thought, "Yeah, there's lot of background, a crop to the main motif is not a bad idea", but failed to notice the pages where it's used. Regards, Grand-Duc (talk) 11:00, 11 March 2026 (UTC)

Creating a WD item from Artwork information

Hi, Please see Template talk:Artwork#Creating a WD item from Artwork information. Yann (talk) 18:15, 11 March 2026 (UTC)

Overwrite files per OpenRefine

Hi!

Deutsch: Ich habe mehrere Dateien über OpenRefine hochgeladen. Mir ist aufgefallen, dass ein URL-Parameter TIFF-Dateien hochgeladen hochgeladen hat, die keine eingebetteten Koordinaten hatten. Die Lösung besteht darin, die neuen URLs zu nutzen und auf die Dateinamen zu überschreiben. Dies funktioniert auch soweit (OpenRefine gibt den Hinweis aus, dass die Datei überschrieben wird), aber die eigentliche Überschreibung erfolgt nicht. Der Mimetype ist derselbe, und ein manuelles Überschreiben via URL funktioniert ohne Meckern. Die Dateien unter neuem Namen hochzuladen und die alten zu löschen, möchte ich vermeiden. Für Ratschläge bin ich dankbar :3.
English: I uploaded several files via OpenRefine. I noticed that a URL parameter uploaded TIFF files that did not have embedded coordinates. The solution is to use the new URLs and overwrite the files to their respective file names. This works so far (OpenRefine displays a message that the file is being overwritten), but the actual overwrite does not take place. The MIME type is the same, and manual overwriting via URL works without any problems. I would like to avoid uploading the files under new names and deleting the old ones. I am grateful for any advice :3.

--PantheraLeo1359531 😺 (talk) 09:01, 13 March 2026 (UTC)

Might help if you would indicate at least one of the files in question, and if the file page does not name the relevant URL(s), please be explicit about that too. - Jmabel ! talk 18:41, 13 March 2026 (UTC)
Of course, sorry! We have File:DOP20 RGB Berlin Sommer 2025 - 373000 5808000 (Senatskanzlei Berlin).tif from TIF source. I would overwrite this file per OpenRefine from the URL GeoTIFF source. --PantheraLeo1359531 😺 (talk) 13:35, 14 March 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --廣九直通車 (talk) 05:47, 9 April 2026 (UTC)

So, I'm rewriting the RotateLink gadget.. The current UI is pretty old - no dark theme, image preview sometimes doesn't load, and the interface isn't very user-friendly. I'm thinking about putting a slider at the bottom of the file preview while keeping the preview centered. Here's what I'm designing now: imgur (direct video: ). Open to suggestions; I've been reading some comments on MediaWiki talk:Gadget-RotateLink.js. Nemoralis (talk) 23:43, 21 March 2026 (UTC)

 Comment, the new UI looks very nice, thanks for creating it. Just a minor suggestion, can you specify in the gadget text that the rotation is "clockwise"? I know it is quite obvious, but I think it's better to be clear. Thanks. Tvpuppy (talk) 11:36, 22 March 2026 (UTC)
@Tvpuppy, thanks, I added it. New UI is now live: MediaWiki talk:Gadget-RotateLink.js#Rewrite. Nemoralis (talk) 18:27, 22 March 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --廣九直通車 (talk) 05:47, 9 April 2026 (UTC)

Need help for MassRename

Deutsch: Nachdem ich mehrere Dateien hochgeladen hatte, habe ich gemerkt, dass ich durch einen Vorlagenfehler falsche Koordinaten in den Dateinamen gelegt habe. Glücklicherweise konnte ich die eigentlich korrekten Dateinamen rekonstruieren, und habe sie in eine CSV-Datei gelegt Link zur Cloud auf Filen. Kann jemand mit einem Bot die Dateien umbenennen, sodass die Dateinamen passen? Das wäre echt klasse. Herzlichen Dank!
English: After uploading several files, I realized that due to a template error, I had included incorrect coordinates in the filenames. Fortunately, I was able to reconstruct the correct filenames and saved them in a CSV file Link to Filen cloud. Can someone use a bot to rename the files so that the filenames match? That would be really great! Thank you a lot!

--PantheraLeo1359531 😺 (talk) 20:30, 28 March 2026 (UTC)

In der Datei liegen Datensätze in der folgenden Form vor: „https://gdi.berlin.de/services/wms/truedop_2020_sommer?service=WMS&version=1.3.0&REQUEST=GetMap&LAYERS=truedop_2020_sommer_rgb&CRS=EPSG:25833&WIDTH=5000&HEIGHT=5000&FORMAT=image/geotiff&STYLES=&BBOX=396000,5816000,397000,5817000;DOP20 RGB Berlin 2020 - 397000 5828000 (Senatskanzlei Berlin).tif;DOP20 RGB Berlin 2020 - 396000 5816000 (Senatskanzlei Berlin).tif;DOP20RGB Berlin 2020 (Senatskanzlei Berlin)“ . Für einen Bot wäre folgende Angabe besser geeignet: „ 'DOP20 RGB Berlin 2020 - 397000 5828000 (Senatskanzlei Berlin).tif';'DOP20 RGB Berlin 2020 - 396000 5816000 (Senatskanzlei Berlin).tif' “ . Nur der alte und der gewünschte Dateiname in einer Zeile. GeorgDerReisende (talk) 20:56, 28 March 2026 (UTC)
✓ Done So, jetzt sind nur noch die Namen vorhanden :) --PantheraLeo1359531 😺 (talk) 21:05, 28 March 2026 (UTC)
Es braucht einen neuen öffentliche Link. GeorgDerReisende (talk) 21:25, 28 March 2026 (UTC)
Ah entschuldige, ich dachte, der alte Link bleibt aktiv. Damit sollte es klappen. --PantheraLeo1359531 😺 (talk) 21:51, 28 March 2026 (UTC)
In der vorliegenden Reihenfolge dürfen die Dateien nicht verschoben werden! Sonst würden verschiedene Dateien mehrfach überschrieben werden und damit viele Dateien verloren gehen. Nur als Beispiel: in einmal soll „370000 5808000“ auf „370000 5810000“ verschoben werden, dann soll „370000 5810000“ auf „370000 5814000“ verschoben werden, dann „370000 5814000“ auf „371000 5812000“! Usw. Außerdem heißt es auf der Dateibeschreibung, dass es sich um Quadrate von 2x2 km handeln soll, die Koordinaten verweisen aber auf 1x1 km-Quadrate. Ich würde das gerne überprüfen, kann das aber erst am Dienstag machen. GeorgDerReisende (talk) 22:18, 29 March 2026 (UTC)
Du hast Recht! Ich kann das aufklären :). Die erwähnten 2×2km sind der Blattschnitt, die die Senatskanzlei vorgibt. Da die Bilder über den Web Map Service bezogen wurden (und nicht bereits gekachelt), habe ich den Zuschnitt aller Kacheln auf 1km×1km begrenzt, um die Konsistenz über alle Jahre hinweg zu gewährleisten (wenn ich also ein Koordinatenpaar in der Suche eingebe, bekomme ich für jedes Jahr denselben Ausschnitt) (leider gibt es einige Inkonsistenzen über die Jahre, die ich versucht habe, zu überwinden). Es ist richtig, dass einige Namen bereits "belegt" sind. Kann man da vielleicht die betreffenden Dateien zu Namen verschieben, die einen "temporären Platzhalter" im Namen haben, sodass dann die richtigen Namen frei werden? Danke und liebe Grüße! --PantheraLeo1359531 😺 (talk) 16:15, 30 March 2026 (UTC)
@GeorgDerReisende (Ping) --PantheraLeo1359531 😺 (talk) 16:15, 30 March 2026 (UTC)
(Die Originalbeschreibungen wurden pro Forma übernommen. Es kann bei einigen Fällen gekachelte Downloads geben, die allerdings im JP2-Format vorliegen und verlustfrei komprimiert sein können) --PantheraLeo1359531 😺 (talk) 16:17, 30 March 2026 (UTC)
1. In der Dateiverschiebungsliste sind die Dateien der Serie „RGB Berlin 2021“ doppelt vorhanden, wenn noch auf Basis dieser Liste gearbeitet werden soll, muss die zweite Erwähnung der Serie (ab Zeile 6001) gelöscht werden.
2. Die Dateien mit den Koordinaten 368000/5808000, 368000/5809000, 369000/5808000, 369000/5809000, 370000/5806000, 370000/5807000, 371000/5814000, 371000/5815000, 372000/5804000, 372000/5805000, 373000/5828000, 373000/5829000, 374000/5806000, 374000/5807000, 375000/5828000, 375000/5829000, 376000/5806000, 376000/5807000, 377000/5830000, 377000/5831000, 378000/5806000, 378000/5807000, 379000/5832000, 379000/5833000, 380000/5806000, 380000/5807000, 381000/5832000, 381000/5833000, 382000/5806000, 382000/5807000, 383000/5836000, 383000/5837000, 384000/5806000, 384000/5807000, 385000/5836000, 385000/5837000, 386000/5806000, 386000/5807000, 387000/5834000, 387000/5835000, 388000/5804000, 388000/5805000, 390000/5806000, 390000/5807000, 392000/5810000, 392000/5811000, 394000/5826000 und 394000/5827000 brauchen nicht bearbeitet zu werden, da sie laut Liste nicht verschoben werden sollen.
3. Ich finde den Fehler nicht, der zu dieser Situation geführt hat.
3a. Lösung 1 — die dreckige Methode: du lädst einfach alle Dateien mit dem richtigen Namen nochmal über die Dateien mit dem falschen Namen hoch. Ergebnis: für jede Datei werden 37 MB Speicherplatz zusätzlich benötigt und in der Versionsgeschichte taucht die falsche Dateiversion mit auf, was in der Zukunft Probleme mit sich bringen könnte.
3b. Lösung 2 — die saubere Methode: du beantragst die Löschung dieser 7200 Dateien und sie wird so durchgeführt und dann lädst du die Dateien mit den richtigen Namen erneut hoch. Ergebnis: für jede Datei werden nur die 37 MB einmalig benötigt und es gibt eine saubere Versionsgeschichte. Nachteil: ein Dateilöscher-Admin muss die 7200 Dateien einzeln händisch löschen, offenbar gibt es für solche Massenlöschungen keinen Bot.
3c. Lösung 3 — die extrem arbeitsintensive Lösung: wie von mir schon anfangs beschrieben, gibt es Ketten von notwendigen Dateiverschiebungen. Diese Ketten musst du alle identifizieren. Dann kann mit einem Bot so gearbeitet werden: move( Datei987 nach DateiTemp ), move( Datei765 nach Datei987 ), move( Datei444 nach Datei765 ), move( DateiTemp nach Datei444 ). Usf.
Ich für mich würde die Lösung 2 vorschlagen und dem Dateilöscher-Admin eine Palette Gummibären oder so zukommen lassen. GeorgDerReisende (talk) 13:46, 31 March 2026 (UTC)
Alles klar, ich würde dann die Tage ggf. die Löschung der betroffenen Dateien beantragen und die Dateien mit korrektem Namen neu hochladen. Danke Dir für Deinen Einsatz! --PantheraLeo1359531 😺 (talk) 08:43, 2 April 2026 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --廣九直通車 (talk) 05:48, 9 April 2026 (UTC)

Request for privacy: Change Author field to "Unknown" on my uploads

Hello,

For privacy and safety reasons, I would like to request a batch update for all files uploaded by my account (formerly Risantana or "Cheposo", now Stratos 499).

I need the |Author= field in the {{Information}} template of all my previous uploads to be changed from "Risantana" to "Unknown" or "Anonymous". My goal is to ensure that my current or former username is no longer linked to these files' metadata or description fields.

Could a bot operator or an administrator assist me with this mass edit?

Thank you for your understanding and help regarding this privacy matter.

Regards, --Stratos 449 (talk) 13:36, 11 March 2026 (UTC)

@Stratos 449: Hi, Works created by you, and uploaded under a free license, cannot be credited to "Unknown". However you can choose whatever pseudonym you want. Yann (talk) 17:07, 11 March 2026 (UTC)
They could relicense it to a different license that does not require attribution. Bawolff (talk) 20:41, 14 March 2026 (UTC)
Including you can use your current account name, if that will do. - Jmabel ! talk 21:18, 11 March 2026 (UTC)

Thumbnails not generating for external wikis

In the past several days, thumbnails are not being properly generated acrsso multiple wiki farms that use the wikimedia commons. Clicking through on the thumbnail returns a " Error Use thumbnail steps listed on https://w.wiki/GHai. Please contact noc@wikimedia.org for further information (a765913)"

Has something changed which has broken the standard functionality used by literally thousands of mediawiki wikis that rely on the wikimedia commons shard libraries? - 17:08, 7 March 2026 (UTC) Lestatdelc (talk) 17:08, 7 March 2026 (UTC)

@Lestatdelc, as stated in mw:Common thumbnail sizes#FAQ, the error is probably due to the wikis not using one of the "standard" thumbnail sizes. Previously, the thumbnail will generate for any specified size via URL, but now MediaWiki requires one of the "standard" size to be specified when requesting via URL.
However, this change was made in January 2026, so the problem might be something else if it only occurred in the past several days. Thanks. Tvpuppy (talk) 19:40, 7 March 2026 (UTC)
If you are using mw:Extension:QuickInstantCommons, please update to the latest version. I just recently (like last week) fixed a bug in it to make it compatible with these changes. Bawolff (talk) 10:19, 9 March 2026 (UTC)
And what if I don't want to use a "standard" thumbnail sizes? Then what? You used to be able to change the size of an SVG converted to PNG in the URL. Now you can't
Can't you stop fucking up the site holy shit??!!! First you ban 90% of the users from editing images and now this, what are you going to break next? Yilku1 (talk) 19:49, 14 March 2026 (UTC)
Please be civil and remember to be respectful to others. The change was implemented by MediaWiki and not by users here in Commons, but I certainly believe the change was made to improve the site rather than worsening it. Regarding your second point, I have no idea what you are referring to as I'm pretty sure "90% of the users" are not "banned from editing images". Thanks. Tvpuppy (talk) 20:04, 14 March 2026 (UTC)
I'm fucking tired of EVERYTHING enshittifing, and now it's happening to wikipedia. Who asked for this?
90% of the users can't edit images. You have to ask like a pleb to the admins so you can edit, but only one for the image you asked. Another stupid change nobody asked. Yilku1 (talk) 20:15, 14 March 2026 (UTC)
Explain me how breaking most thumbnails is improving the site? Yilku1 (talk) 03:08, 15 March 2026 (UTC)
If you are using instant commons (not quickinstantcommons) there is a setting you can set where it downloads the original and then resizes locally (to any size you want). Bawolff (talk) 20:40, 14 March 2026 (UTC)

Tech News: 2026-12

MediaWiki message delivery 19:33, 16 March 2026 (UTC)

Opera browser data saver mode

this probably niche problem happened to me today. writing here in case anyone might have it too.

i couldnt edit using opera browser on my android phone. after some testing i realised that my ip is different (according to whatismyipaddress.com) when i use chrome and opera. turning off data saver finally makes ip the same and lets me be no longer affected by ip blocks. RoyZuo (talk) 20:22, 17 March 2026 (UTC)

simpleSVGcheck.js is defect

The script User talk:Chealer/simpleSVGcheck.js doesn't work anymore. @Flexagoon wrote:

The script no longer works for me, because requests to the validator API are blocked by Content-Security-Policy

What can we do to fix this? Kind regards, --Sebastian Wallroth (talk) 12:38, 19 March 2026 (UTC)

@Sebastian Wallroth (and others): Please do file a subtask of phab:T419265 for any CSP issues in userscripts/gadgets that have started happening -- my comment here (on metawiki) has links to some partially-prefilled task templates I put together in case they're helpful, though it's not required to use them! Best, a smart kitten[meow] 14:09, 19 March 2026 (UTC)
Thanks! I created a report and added @Sebastian Wallroth as a subscriber. Flexagoon (talk) 18:22, 19 March 2026 (UTC)

Images seem to be broken

I'm into computer programming, and I've heard that wikimedia commons recently archived most of their images, but now none of them show up on my webpages. I don't know how to input images into my HTML code anymore.

here is a link that doesn't work.

https://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Snowy_Mountain_Valley.jpg/1599px-Snowy_Mountain_Valley.jpg

pretty much all of the old images are broken like this, and they simply don't show up on my webpages. Dragonstudios36 (talk) 14:52, 20 March 2026 (UTC)

Use https://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Snowy_Mountain_Valley.jpg/1920px-Snowy_Mountain_Valley.jpg instead. Try using one of the sizes from this list: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px [Personally I find it really silly we are just breaking everything instead of just using redirects]. Near the top of the image page there should be a button labelled "use this file" which will give you html code to include the file. Bawolff (talk) 19:24, 20 March 2026 (UTC)

Tech News: 2026-13

MediaWiki message delivery 16:48, 23 March 2026 (UTC)

  • Can someone give a better explanation of the thing about notifications? I don't understand whether this is specific to notifications still on the user talk page or, if not, how it would affect already-archived talk pages. - Jmabel ! talk 20:07, 23 March 2026 (UTC)
    Don't know what you mean. Notifications are the thing that display in the dropdown in the top right. Info on the technical system it uses, Echo, can be found at mw:Extension:Echo. Apparently they want to delete notifications older than 5 years. Prototyperspective (talk) 22:44, 23 March 2026 (UTC)
    • Ah, so this is presumably about notifications one has long since dealt with. Got it. I knew those were called notifications, but presumed it had to be something else, because who on earth looks at a notification more than a few days, maybe a month, after the fact? Five years?? (I guess someone cares...). - Jmabel ! talk 00:44, 24 March 2026 (UTC)

Annotations invisible for logged out users

Per title - COM:Image annotations are not displayed unless you are logged in. Qbli2mHd (talk) 01:11, 25 March 2026 (UTC)

Well that makes sense because only logged in users can use gadgets. Nemoralis (talk) 18:39, 25 March 2026 (UTC)
Hmm, it is actually loaded for all users via Common.js. It works for me in a private window (logged out). Nemoralis (talk) 18:47, 25 March 2026 (UTC)
I think I understand where this comes from - annotations won't work if page width (determined on load) leads to image being resized. This happens when the window is too narrow to fit an image; annotations will work if you reload the page with a wider window; they won't work again if you make the window even wider, because a sidebar is inserted to the right and image is resized; they will work again if you make window wide enough to fit both the image and the sidebar. Qbli2mHd (talk) 17:47, 26 March 2026 (UTC)
Category:Commons talk archives