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/03 /Archive/2026/04.

COMMONS DISCUSSION PAGES

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

---

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

---

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

Please note

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

 

Start a new discussion

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

Commons contributors by number of uploaded files (in use)

Commons:Commons contributions achievements/Commons contributors by number of uploads is a relatively new meta page showing a table of Commons users with a column for the number of files upload.

• I just wanted to check which quarry I used to create it but the server times out with error [65d16284-b14b-40ad-aff6-d0fa12d44efb] 2026-02-19 18:17:35: Fatal exception of type "Wikimedia\RequestTimeout\RequestTimeoutException" – the table can still be accessed in the archives here. Maybe somebody knows how this can be fixed (the points below require either that or creating a new page).
• Does somebody know how to add a column for a) rank b) whether or not the user is a bot c) number of files in use in any Wikimedia project d) maybe number of files in use in Wikipedia mainspace separately.
• Maybe people have further ideas for columns – e.g. maybe it's possible to have sortable column to also show number of files by filetype, and/or fraction of files in mainspace use, and/or files that are own work...

I think these would be interesting stats. Prototyperspective (talk) 18:26, 19 February 2026 (UTC)

For the timeout, splitting this across multiple pages might help. Bawolff (talk) 21:04, 22 February 2026 (UTC)

What is interesting is the percentage of files in use. Yann (talk) 21:35, 22 February 2026 (UTC)

Does somebody know how to add a column for … c) number of files in use in any Wikimedia project d) maybe number of files in use in Wikipedia mainspace the percentage could be calculated from that but I'm not sure it's more meaningful than number of files in use; percentage would imply one barely ever uploads other kinds of files. Prototyperspective (talk) 21:42, 22 February 2026 (UTC)

Well, having 1,000 files in use is not the same after uploading 1,000,000 files or after uploading 2,000 files. Yann (talk) 21:49, 22 February 2026 (UTC)

This could however be read by also looking at the other column that has that number. Anyway, I wouldn't have an issue with the percentage which btw is also shown in the Commons app. Prototyperspective (talk) 22:14, 22 February 2026 (UTC)

https://quarry.wmcloud.org/query/102335 (adding in use slowed down the query significantly. Percentage, and in use on main ns on a wikipedia are probably also possible but would slow it down more) Bawolff (talk) 06:22, 23 February 2026 (UTC)

Amazing, thank you! Since this would be run only rarely I don't see much of a problem with it taking long to load (in this case ~13 minutes). Regarding percentage, I think this can be seen in the columns and if one added it, one can't use it for sorting because at the top would be lots of users who uploaded just 1 or so file(s) which is in use. I would have no issue with it being added but don't think it's needed or very useful.

Do you know how one could show the number of files in use on Wikipedias mainspace? This is useful because for example some files are used only in sandboxes, talk pages or are pronunciation audios used in lots of wiktionary and Wikidata pages. Prototyperspective (talk) 14:11, 23 February 2026 (UTC)

Query updated to show that. Note this only includes actual main space, will not include non-main content namespaces like portal. It determines if the site is a wikipedia by if the wiki name ends in "wiki" and os less than 9 letters. I think that should include all wikipedias and exclude other sites, but there could be edge cases possibly. Bawolff (talk) 18:12, 23 February 2026 (UTC)

Aside: while percentage of files that are in use can be interesting, it should not be seen as a metric of who is a great contributor of content to Commons. A very high percentage usually means someone whose uploads have been driven precisely by what is need it in some particular sister project or projects, and who rarely or never uploads more than one image related to a particular subject. Example to the contrary: I just uploaded several dozen photos I took of contributing properties of NRHP-recognized historic districts in Binghamton, New York. Most of these buildings previously had no image on Commons. Few, if any, are likely to end up "used" in the near future because the en-wiki articles on these topics are stubs or near-stubs, the Wikivoyage article has exactly one image of the city's historic center, and I can't think where else they would show up on a sister project. Nonetheless, they are clearly well within Commons scope, and I can't imagine an argument against us actively wanting such images. - Jmabel ! talk 20:50, 23 February 2026 (UTC)

Yeah, sometimes a closer look is needed. I cover the upload of orthophotos. With this, you can link the images to almost any geographical point in Germany or the US in Wikidata. This would mean the usage of maybe more than 100k files, but needless to say I cannot do this by hand :D --PantheraLeo1359531 😺 (talk) 11:11, 3 March 2026 (UTC)

Super interesting, thanks! I find the use in WP-mainspace column the most interesting – since there is no way afaik to enumerate the table based on whatever column is sorted by, could you add a column for the # of number in use on WPmNS? Moreover, maybe a separate list without the bots would be interesting too but it seems like the human/bot boolean is totally false. Many bots, incl the user with most uploads do not have the bot flag but https://commons.wikiscan.org/ does show the correct bot flag – do you know why that is or how to show the correct value in that column? Maybe the accounts' bot flag was removed from somewhere where it shouldn't have been removed or it's not set but sth else is set that could be shown. Minor correction: it should be 'Files uploaded', not 'Images uploaded'. Prototyperspective (talk) 00:54, 24 February 2026 (UTC)

Sorted on the other column https://quarry.wmcloud.org/query/102363 Bawolff (talk) 02:19, 24 February 2026 (UTC)

Thanks! I've now put it on a page where links are clickable and which can be found from within Commons: Commons:Commons contributors by number of uploads and Wikipedia uses thereof (1-5000)

I've put further ideas and remaining issues regarding the list(s) into section "Development". For example, it would be nice if the usernames could be linked to their Uploads page (and I think linking there instead of their userpage also avoids them getting pinged). Prototyperspective (talk) 18:02, 24 February 2026 (UTC)

Those are files uploaded and files in use right, not just images? Because the tables are named as if these were just images so I'm confused whether to rename the column. Prototyperspective (talk) 22:39, 24 February 2026 (UTC)

Yes these are files of all types. The term image is used in the database for historical reasons. Bawolff (talk) 06:21, 25 February 2026 (UTC)

8.8 Mio. files uploaded by one entity is just incredible 😶 --PantheraLeo1359531 😺 (talk) 17:43, 25 February 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)

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)

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)

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)

Help fixing template i18n

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

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

Tech News: 2026-11

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

Weekly highlight

• All wikis will be read-only for a few minutes on Wednesday, 25 March 2026 at 15:00 UTC. This is for the datacenter server switchover backup tests, which happen twice a year. During the switchover, all Wikimedia website traffic is shifted from one primary data center to the backup data center to test availability and prevent service disruption even in emergencies.
• Last week, all wikis had 2 hours of read-only time, and extended unavailability for user-scripts and gadgets. This was due to a security incident which has since been resolved. Work is ongoing to prevent re-occurrences. For current information please see the post on the Stewards' noticeboard (translations).

Updates for editors

• Users facing multiple blocks on mobile will now see the reasons for each block separately, instead of a generic message. This helps them understand why they are blocked and what steps they can take to resolve the issue. For example, users affected for using common VPNs (such as iCloud Private Relay) will receive clearer guidance on what they need to do to start editing again. [1]
• Later this week, Suggestion Mode will become available as a beta feature within the visual editor at all Wikipedias. This feature proactively suggests various types of actions that people can consider taking to improve Wikipedia articles, and learn about related guidelines. The feature is locally configurable, and can also be locally expanded with custom Suggestions. Current settings can be seen at Special:EditChecks and there are instructions for how administrators can customize the links to point to local guidelines. The feature is connected to Edit check which suggests improvements while someone is writing new content. In the future, the Editing team plans to evaluate the feature's impact with newcomers through a controlled experiment. [2]
• View all 23 community-submitted tasks that were resolved last week. For example, the issue where the cursor became misaligned during the use of CodeMirror’s syntax highlighting, which makes wikitext and code easier to read, has now been fixed. This problem specifically affected users who defined a font rule in a custom stylesheet while creating a new topic with DiscussionTools. [3]

Updates for technical contributors

• API rate limiting update: To help ensure fair use of infrastructure, global API rate limits will be applied this week to requests without a compliant User-Agent that originate from outside Toolforge/WMCS and to unauthenticated requests made from web browsers. Higher limits will be applied to identified traffic in April. Bots running in Toolforge/WMCS or with the bot user right on any wiki should not be affected for now. However, all developers are advised to follow updated best practices. For more information, see Wikimedia APIs/Rate limits.
• The new GraphQL API has been released. The API was developed as a flexible alternative to select features of the Wikidata Query Service (WDQS), to improve developer experience and foster adaptability, and efficient data access. Try it out and give feedback. You can also sign up for usability tests.
• The PTAC Unsupported Tools Working Group continued improvements to Video2Commons in February, with fixes addressing authentication errors, large-file handling, task queue visibility, and clearer upload behavior. Work is still ongoing in some areas, including changes related to deprecated server-side uploads. Read this update to learn more.
• Detailed code updates later this week: MediaWiki

In depth

• The Article Guidance team invites experienced Wikipedia editors from selected pilot wikis and interested contributors from other Wikipedias to fill out this questionnaire which is available in English, Arabic, Bengali, Japanese, Portuguese, Persian, and Turkish. Your answers will help the team customize guidance for less experienced editors and help them learn community policies and practices while creating an article. Learn more on the project page.

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

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

Requesting bulk data cleanup - Scheer photos with credit in EXIF

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

I know we have bots that access EXIF data and act accordingly; given that Category:Files from Andrew Scheer's Flickr stream is not a large universe, certainly a bot could run over this data file-by-file and edit accordingly.

I don't think there is any user-facing way to search for particular content in EXIF data. - Jmabel ! talk 04:19, 10 March 2026 (UTC)

At worst, we could make sure the existing bot that extracts author info from EXIF data to SDC runs on all files in this category, after which I believe a Quarry query could find the relevant files. - Jmabel ! talk 04:21, 10 March 2026 (UTC)

Quarry can't access SDC, however it can access exif, so it should be posdible to get it to make a list. Bawolff (talk) 22:00, 10 March 2026 (UTC)

@Bawolff: ah, I thought it was the other way around! (Shows what tools I don't use.) - Jmabel ! talk 05:30, 11 March 2026 (UTC)

I can get a list with Quarry - can VFC perform an update using a manual list? I don't think EXIF shows up in VFC's search query. But looking deeper into VFC at Help:VisualFileChange.js/samples#Inserting variables, there seem to be examples of pulling information EXIF out and duplicating it elsewhere - seems like this might work, will look into it further. I've never worked with bots and would prefer to do this on my own if possible. -Consigned (talk) 10:11, 11 March 2026 (UTC)

In case its helpful: https://quarry.wmcloud.org/query/103004 Bawolff (talk) 18:05, 11 March 2026 (UTC)

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)

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)

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)

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)

Tech News: 2026-12

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

Updates for editors

• The Improved Syntax Highlighting beta feature, also known as CodeMirror 6, has been used for wikitext syntax highlighting since November 2024. It will be promoted out of beta by May 2026 in order to bring improvements and new features to all editors who use the standard syntax highlighter. If you have any questions or concerns about promoting the feature out of beta, please share. [4]
• Some changes to local user groups are performed by stewards on Meta-Wiki and logged there only. Now, interwiki rights changes will be logged both on Meta-Wiki and the wiki of the target user to make it easier to access a full record of user's rights changes on a local wiki. Past log entries for such changes will be backfilled in the coming weeks. [5]
• On wikis using Flagged Revisions, the number of pending changes shown on Special:PendingChanges previously counted pages which were no longer pending review, because they have been removed from the system without being reviewed, e.g. due to being deleted, moved to a different namespace, or due to wiki configuration changes. The count will be correct now. On some wikis the number shown will be much smaller than before. There should be no change to the list of pages itself. [6]
• Wikifunctions composition language has been rewritten, resulting in a new version of the language. This change aims to increase service stability by reducing the orchestrator's memory consumption. This rewrite also enables substantial latency reduction, code simplification, and better abstractions, which will open the door to later feature additions. Read more about the changes.
• Users can now sort search results alphabetically by page title. The update gives an additional option to finding pages more easily and quickly. Previously, results could be sorted by Edit date, Creation date, or Relevance. To use the new option, open 'Advanced Search' on the search results page and select 'Alphabetically' under 'Sorting Order'. [7]
• View all 28 community-submitted tasks that were resolved last week. For example, the bug that prevented UploadWizard on Wikimedia Commons from importing files from Flickr has now been fixed. [8]

Updates for technical contributors

• A new special page, Special:LintTemplateErrors, has been created to list transcluded pages that are flagged as containing lint errors to help users discover them easily. The list is sorted by the number of transclusions with errors. For example: Special:LintTemplateErrors/night-mode-unaware-background-color. [9]
• Users of the Improved Syntax Highlighting beta feature have been using CodeMirror instead of CodeEditor for syntax highlighting when editing JavaScript, CSS, JSON, Vue and Lua content pages, for some time now. Along with promoting CodeMirror 6 out of beta, the plan is to replace CodeEditor as the standard editor for these content models by May 2026. Feedback or concerns are welcome. [10]
• The CodeMirror JavaScript modules will soon be upgraded to CodeMirror 6. Leading up to the upgrade, loading the ext.CodeMirror or ext.CodeMirror.lib modules from gadgets and user scripts was deprecated in July 2025. The use of the ext.CodeMirror.switch hook was also deprecated in March 2025. Contributors can now make their scripts or gadgets compatible with CodeMirror 6. See the migration guide for more information. [11]
• The MediaWiki Interfaces team is expanding coverage of REST API module definitions to include extension APIs. REST API modules are groups of related endpoints that can be independently managed and versioned. Modules now exist for GrowthExperiments and Wikifunctions APIs. As we migrate extension APIs to this structure, documentation will move out of the main MediaWiki OpenAPI spec and REST Sandbox view, and will instead be accessible via module-specific options in the dropdown on the REST Sandbox (i.e., Special:RestSandbox, available on all wiki projects).
• The Scribunto extension provides different pieces of information about the wiki where the module is being used via the mw.site library. Starting last week, the library also provides a way of accessing the wiki ID that can be used to facilitate cross-wiki module maintenance. [12]
• Detailed code updates later this week: MediaWiki

In depth

• The 2026 Coolest Tool Award celebrating outstanding community tools, is now open for nominations! Nominate your favorite tool using the nomination survey form by 23 March 2026. For more information on privacy and data handling, please see the survey privacy statement.

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

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

Opera browser data saver mode

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

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

simpleSVGcheck.js is defect

Tracked in Phabricator
Task T420626

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

— in: User_talk:Chealer/simpleSVGcheck.js#Blocked_by_CSP

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)

Rewriting the RotateLink gadget

So, I'm rewriting the RotateLink gadget.. The current UI is pretty old - no dark theme, image preview sometimes doesn't load, and the interface isn't very user-friendly. I'm thinking about putting a slider at the bottom of the file preview while keeping the preview centered. Here's what I'm designing now: imgur (direct video: [13]). 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)

Tech News: 2026-13

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

Weekly highlight

• Wikimedia site users can now log in without a password using passkeys. This is a secure method supported by fingerprint, facial recognition, or PIN. With this change, all users who opt for passwordless login will find it easier, faster, and more secure to log in to their accounts using any device. The new passkey login option currently appears as an autofill suggestion in the username field. An additional "Log in with passkey" button will soon be available for users who have already registered a passkey. This update will improve security and user experience. The screen recording demonstrates the passwordless login process step by step.
• All wikis will be read-only for a few minutes on Wednesday, 25 March 2026 at 15:00 UTC. This is for the datacenter server switchover backup tests, which happen twice a year. During the switchover, all Wikimedia website traffic is shifted from one primary data center to the backup data center to test availability and prevent service disruption even in emergencies.

Updates for editors

• Wikimedia site users can now export their notifications older than 5 years using a new Toolforge tool. This will ensure that users retain their important notifications and avoid them being lost based on the planned change to delete notifications older than 5 years, as previously announced. [14]
• Wikipedia editors in Indonesian, Thai, Turkish, and Simple English now have access to Special:PersonalDashboard. This is an early version of an experience that introduces newer editors to patrolling workflows, making it easier for them to move from making edits to participating in more advanced moderation work on their project. [15]
• The Special:Block now has two minor interface changes. Administrators can now easily perform indefinite blocks through a dedicated radio button in the expiry section. Also, choosing an indefinite expiry provides a different set of common reasons to select from, which can be changed at: MediaWiki:Ipbreason-indef-dropdown. [16]
• Mobile editors at several wikis can now see an improved logged-out edit warning, thanks to the recent updates from the Growth team. These changes released last week are part of ongoing efforts and tests to enhance account creation experience on mobile and then increase participation. [17]
• View all 36 community-submitted tasks that were resolved last week. For example, the bug that prevented mobile web users from seeing the block information when affected by multiple blocks has been fixed. They can now see messages of all the blocks currently affecting them when they access Wikipedia.

Updates for technical contributors

• Images built using Toolforge will soon get the upgraded buildpacks version, bringing support for newer language versions and other upstream improvements and fixes. If you use Toolforge Build Service, review the recent cloud-announce email and update your build configuration as necessary to ensure your tools are compatible. [18][19]

• The API Portal documentation wiki will shut down in June 2026. API keys created on the API Portal will continue to work normally. api.wikimedia.org endpoints will be deprecated gradually starting in July 2026. Documentation on the API Portal is moving to mediawiki.org. Learn more on the project page.
• Detailed code updates later this week: MediaWiki

In depth

• WMDE Technical Wishes is considering improvements to automatically generated reference names in VisualEditor. Please check out the proposed solutions and participate in the request for comment.

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

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

• Can someone give a better explanation of the thing about notifications? I don't understand whether this is specific to notifications still on the user talk page or, if not, how it would affect already-archived talk pages. - Jmabel ! talk 20:07, 23 March 2026 (UTC)

  Don't know what you mean. Notifications are the thing that display in the dropdown in the top right. Info on the technical system it uses, Echo, can be found at mw:Extension:Echo. Apparently they want to delete notifications older than 5 years. Prototyperspective (talk) 22:44, 23 March 2026 (UTC)

  • Ah, so this is presumably about notifications one has long since dealt with. Got it. I knew those were called notifications, but presumed it had to be something else, because who on earth looks at a notification more than a few days, maybe a month, after the fact? Five years?? (I guess someone cares...). - Jmabel ! talk 00:44, 24 March 2026 (UTC)

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)

Placeholder images

MOVED from COM:Help desk - Jmabel ! talk 05:37, 25 March 2026 (UTC)
On some image pages this placeholder image : https://commons.wikimedia.org/w/resources/assets/file-type-icons/fileicon-ogg.png is being incorrectly inserted into the html under the "use this file" link. example here: https://commons.wikimedia.org/wiki/File:Ravenscar_-_geograph.org.uk_-_401270.jpg Ndurgom (talk) 09:46, 24 March 2026 (UTC)
END MOVED - Jmabel ! talk 05:37, 25 March 2026 (UTC)

@Ndurgom: I've moved your question to this page where it is more likely to be addressed. - Jmabel ! talk 05:37, 25 March 2026 (UTC)

I don't see a "Use this file" link. Is it the one included by Help:Gadget-Stockphoto? I don't have that enabled. MKFI (talk) 18:35, 25 March 2026 (UTC)

@MKFI: It is.

ANOTHERWlKlPEDlAN _{wɑit thɑt’s ɑ typo} 23:24, 25 March 2026 (UTC)

Its probably because the resolution is so low there are no "view in other resolution" links. User:Krinkle recently made a bunch of fixes to the gadget and i think one of them was to use those other resolution links to pick the download size. [Im guessing here, have not really looked into it]. Bawolff (talk) 09:08, 27 March 2026 (UTC)

Tracked in Phabricator
Task T421557

@Ndurgom @Bawolff I filed T421557 and am implementing a workaround in the gadget. Krinkle (talk) 23:01, 27 March 2026 (UTC)

State of Flickr2Commons?

Flickr2Commons is not working for me right now. I can work around it, but does anyone know what is going on? - Jmabel ! talk 20:02, 27 March 2026 (UTC)

More precisely: everything seems normal along the way, but the actual upload never completes. - Jmabel ! talk 06:21, 28 March 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)

Misfunction of "license reviewed failed, all right reserveds" on several pages.

Hello, MediaWiki:Gadget-LicenseReview.js cannot function properly when using license review failed, then select "All rights reserved" as the rational. For example, on this page, File:Angelica Bove Funweek.it 2024.jpg
This is a screenshot of a copyrighted video from youtube. Lemonaka (talk) 00:59, 30 March 2026 (UTC)

Tech News: 2026-14

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 Beta version of Abstract Wikipedia a new Wikimedia project which is language-independent, was launched last week. The project allows communities to build Wikipedia articles in their native language, which can be readily accessed by other users in their own languages. The wiki is powered by instructions from Wikifunctions and also based on structured content from Wikidata. Read more.

Updates for editors

• The Growth team is running an A/B test to evaluate a clearer, more user-friendly message that promotes account creation on wikis. Currently when logged-out mobile users begin editing, they see a jarring warning message that can feel abrupt and discouraging. This also presents temporary account editing as the default rather than encouraging account creation. The test is running on ten Wikipedias, including Arabic, French, Spanish and German. Read more.
• The Wikimedia Apps team is inviting feedback on how editing should work on the Wikipedia mobile apps. The discussion focuses on improving how users access editing tools when they tap "Edit". This is part of a broader effort to convert readers who develop an interest in editing, to access a more user-friendly pathway to start contributing.
• View all 45 community-submitted tasks that were resolved last week. For example, an issue where citation fetching from the large newspaper archive Newspapers.com was no longer working, due to a block in Citoid requests, has now been fixed. [20]

Updates for technical contributors

• 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 19:22, 30 March 2026 (UTC)

Did anyone else see this?

I went to Category:Tavares, Florida and on the {{Wikidata Infobox}} instance there I saw that the "official website" link read "Official Website of [somebody's name that started with I, think the second name started with H]". The link was correct and refreshing the page made it return to just "official website". Did anyone else see this or am I just losing my mind (small loss)? - The Bushranger (talk) 19:34, 1 April 2026 (UTC)

Bug with Notices

Noticed (heh) this evening that the 'Notices' tab on Commons is not allowing you to clear notices from other Wikimedia projects unless you clear it from that project. - The Bushranger (talk) 01:36, 2 April 2026 (UTC)