Commons:Village pump/Archive/2026/09

I need help with uploading a png file to Wikimedia

On Special:UploadWizard, I always get

[fbf7d8d9-9f85-4fba-ad04-1c2f6b43de49] 2026-09-02 19:00:33: Fatal exception of type "InvalidArgumentException"

I cleaned my cookies, cash, you name it. Relaunched browser. The error is still there. — Preceding unsigned comment added by LokThimiKhwamSukh (talk • contribs) 19:03, 2 September 2026 (UTC)

The upload wizard is currently down, for all types of files. Hopefully it will be fixed soon. Ymblanter (talk) 19:08, 2 September 2026 (UTC)

Seems to be working fine now (from EU/ESAMS). Nux (talk··dyskusja) 19:52, 2 September 2026 (UTC)

Severe bug in the frontend file cache servers (not serving the effective last version of any original file)

Tracked in Phabricator
Task T425216

There's a severe scheduling bug in the Wikimedia file server cache (for the "original source" files), which does NOT reflect the LAST version of ANY updated file, but ALWAYS serves some previous version BEFORE the last update.

• I think that when a file is updated, the file server cache incorrectly receives an update event much too early, and then updates itself before the file has been actually stored and made available on the file storage server.
• This bug does NOT affect the thumbnail generator which correctly uses the last version and updates the PNG thumbnail correctly, because it receives the update event correctly after the file was actually stored on the file server.
• You can wait for hours or days, there's no way to have the "original source" file made available via its standard (undated) link (e.g. https://upload.wikimedia.org/wikipedia/commons/f/ff/U1CC43.svg, instead of https://upload.wikimedia.org/wikipedia/commons/archive/f/ff/20260902082205%21U1CC43.svg which is supposed to be the link for the version dated 2026-09-02 08:22:05 in the history, but is in fact a link to the version immediately before it!)
• This is NOT specific to this file, in fact I've seen this bug in many other files whose updates were NEVER reflected in their original versions (i.e. not the generated thumbnail which are correct), many days (or months!) after their updates.
• Attempts to fix this by uploading the exact same content has no effect (the frontend considers this is a duplicate upload, and discards the upload). If you upload again the "original file" that you've downloaded from the top of the file history, you are in fact uploading an older version!
• Attempts to fix this by editing the file description page has no effect on this bug. Always, the history shows links to the incorrect (non-thumbnail) dated versions.

This means that we can NEVER correctly update the original files (with the exception of their thumbnails), as we are always serving original files one (or several) versions before!

• The only workaround for now is to upload an additional "nulledit" file (with some "invisible" change, e.g. a non-significant space in SVG files, or in some internal file metadata): this works sometimes, but not always as in the previous example where a nulledit upload was made in an attempt but still used the 2nd version, then a revert which is still served with the 2nd version (but the dated version with the nulledit is correct...). In summary the content of the Wikimedia file cache is completely inconsistant with the effective file versions.
• I found no way to force the frontend file cache servers to download again the effective file version from the backend storage servers (e.g. by appending some dummy query string such as "?action=purge" to the "upload.wikimedia.org" link); the frontend continues to maintain its own old local version (for extremely long time which is constantly extended as long as the file is demanded because the frontend is never informed that there was an update was available, even days, weeks, or months before).
• The bug also affects the "file preview" (e.g. when you click any file in Commons to display the file in "full screen" mode, it also shows an old version).

I consider this synchronization bug (between the inconstant frontend file cache servers, and the backend storage servers which superficially seem correct, as these latter servers are used by thumbnail generators) being severe everywhere in Wikimedia for three major reasons:

• It affects countless files that need to be legitimately updated on Wikimedia Commons, but also files stored in other Wikimedia wikis (e.g. in any localized edition of Wikipedia when these files are not accepted in Commons due to licencing exceptions). The displayed file histories are completely inconsistant! The bug is independant of the file content type (not specific to SVG): this same bug occurs as well for PNG, GIF, JPEG images, as well as PDF or DejaVu documents, or audio and video files!
• Reverting any file to a previous version does not work (except for their generated PNG thumbnails), and files that must be reverted, because of an unexpected error (e.g. from any user that used the wrong filename and unepectedly overwrote the incorrect file), or because of some users voluntarily damaging file contents with abusive uploads (the revert from the file history also does not work, except for the served thumbnails). This creates severe maintenance problems against user abuses or errors, or for any legitimate fixes that may be desirable and needed.
• Transfering any file from Wikipedia to Commons may in fact transfer an old version that was updated on Wikipedia, where the correct last version will be permanently deleted just after the transfer (an no more history available in Commons or in Wikipedia to find the correct last version).

This bug is reproducible everywhere (you can try with your own file, upload it, make a correct file description page with the required licences, date, your author name, and relevant categories, then update the file content several times with successive visible edits, look at the file description page and find a logic to the displayed file history, but don't look just at the displayed list of thumbnails: click each version thumbnail to see the full version and you'll see that they don't match...). -- verdy_p (talk) 08:39, 2 September 2026 (UTC)

Have you opened a Phabricator ticket? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:33, 2 September 2026 (UTC)

I should but before I want to make sure that Wikimedia Commons users are aware of the problem, or if they know a way to workaround the problem. Or if they also experiment the problem (or not), and explain why. For now I don't know what to do. And how much this impacts those using Commons (including those that assume that what Commons displays is correct, and that use bots, or local admins that may perform unexpected admin actions because they trust what is displayed in file histories, and all those that want to perform any kind of maintenance. The ticket on Commons would not be visible so much to many users. This message is an alert to more people (this does not exclude opening a ticket if the problem is serious, or if there are more problems than those I tried to list above with my experiences and attempts; I have experience the problem since months, but could not explain it correctly and did not investigate to find a possible cause and a workaround; this is really a quite old problems and it is in fact architectural within Wikimedia servers and how they are synchronized; this genrally does not affect thumbnails only because thumbnails are generated on request, long after the file upload has been completed: the file description page is regenerated, which contains a link to request a thumbnail, then the user's web browser refreshed the page and starts asking for the thumbnail and the thumbnail generator is instructed to download the new version directly from the backend storage servers, without using any frontend file caches which are already corrupted; then the browser gets the expected thumbnail version, but no one is able to get the original non-thumbnail file.... except if someone else with a different ISP in a different region wants to download the original file from a different front cache server which has still not seen any request for this updated original file; but if the updated file is "popular", requested frequently enough from many parts of the world, there's no chance anyone will ever see the updated version as no Wikimedia frontend cache will ever update itself to reflect the update). verdy_p (talk) 11:37, 2 September 2026 (UTC)

Note that I posted a copy of this message in the Phabricator tracker link T425216 you posted above. This was a separate bug, less critical, but investigations went in the wrong way (thinking that people had problems with their browser cache, or that it was related to some regional CDNs, but visibily the bug is effectively within Wikimedia's domain, on the frontend servers and compeltely independent of users, their location, their browser, or file contents, it is much more serious). verdy_p (talk) 11:45, 2 September 2026 (UTC)

Note also that there has been many source code updates in MediaWiki and in Wikimedia server tools and policies to dramatically limit the work performed by thumbnail generator, and on how original (non-thumbnails) files are served. These were limitations on how often caches can update themselves (to avoid stressing too much the servers). This must have forgotten a frequent case: file contents must remain updatable, and now they cannot be updated reliably. This bug will be probably very tricky to fix (and may cause downtime or severe degradation of performance if not tested properly): these tests for normal operations (forgotten since many months, possibly years) must be developed as well as stress tests (this should be performed first on test servers to limit the damages on Wikimedia) and should become part of the development and deployment process. This could also require the involvment of some internal administrators, and possibly update the usage policies.

But for now, users should be aware that this problem exists. If they want to test it, please don't do that on files updated and maintained by others, or on "popular" files: do that on your own test files or files you uploaded recently and you are actively maintaining. If you have ideas about how to workaround the issue (like those that I tentatively posted above), please post them, this can help others. Don't harness the servers for your own "stress tests", unless you are directly involved in the development and tests for this issue, and you are ready to discuss what you do and document all what you found, and where you tested the behavior (so that all bugs can be tracked exactly in a predicatable way; I suggest you upload these test files not directly on Commons, but on a test wiki, or in a dedicated section of Commons meant for test files with explicit "test" filenames and categories) verdy_p (talk) 13:06, 2 September 2026 (UTC)

Also I wonder why users cannot have their own "sandbox" file for their own tests or their inctremental edits, or even before any upload: a single file (or one per file type if the file extension is needed to correctly set the content type), visible only by them in their own user space. This would be useful before having the possibility to transfer it as a new or updated version of any common file, using a dedicated upload form where they can select the target and submit a commit comment. It would save lot of storage resources and would avoid multiple successive uploads. Users that want to work on their own small collection of files to test trogether could ask for a larger set of personal files. These files would be accessible only in their own user wikipages (i.e. "File:User:(username)/(filename).(ext)", possibly abbreviatable as "File:~~/(filename).(ext)" or just "~~/(filename).(ext)" in galeries accessible only from "User:(username)/(subpage)"; and users should be able to manage their private temporary collection of personal test files, within an acceptable storage policy, in terms of volume or maximum storage time, after which these files could be erased automatically; these files would not necessarily keep a long history of versions, each version counting within the personal storage limit). This could even completely replace the current upload system. This personal storage would be useful notably to see if a file renders correctly, has the correct metrics or internal metadata and fits well with other files within personal test wikipages; a personal test wikipage however would not be necessary as the system would provide automatically some gallery page for the personal collection of files they are working on (if they need to test and work on these files with other users, they could offer them a sharable link, usable by them on the same wiki server: they would just add the offered shared file into their own work collection. In each personal collection, these files could have different local filenames; the server would manage the list of users cooeprating on this workfile so that the list is automatically integrated into the lsit of authors once the file will be really uploaded to the public space; those personal files could also have a file description page, and a local list of categories (displayed only to the user viewing the test file, but still not added to the target category): these categories would be proposed in the public upload form, as well as the description, but if the file is intended for an existing public file, it would be necessary to manually edit and merge these descriptions within the public upload wizzard. Once the file is published by the wizzard, it is removed from the private user's collection (unless the user asks to keep it for more time within his work collection) and user wikipages referencing these private work files could be updated automatically to use the new public file... verdy_p (talk) 13:22, 2 September 2026 (UTC)

Its a known issue, Krinkle is already working on it. The tl;dr: When people added the ?utm parameters to image urls, it confused mediawiki. It correctly handles thumbnails but not original files. Bawolff (talk) 16:49, 3 September 2026 (UTC)

Copyright status about currency of Bulgaria

When Bulgaria replaced to euro, it is still protected by copyright after replaced to euro? However, what is the current situation about Bulgaria and the euro. like Ireland, the currency is copyrighted; But it not mentioned in the section mentioned here, any questions that currency has copyright that should not allowed to upload here due to restrictions from Bulgarian National Bank? TentingZones1 (talk) 12:21, 3 September 2026 (UTC)

National sides of Euro coins are copyrighted, so that would also apply to Bulgaria. Abzeronow (talk) 01:53, 4 September 2026 (UTC)

Server side error

Some of my recent edits on Wikimedia Commons did not register due to "Server returned error: HTTP 503." In one instance of using VisualFileChange, I had to manually add the request I made because of Error: -- NO TASK DESCR. FOR mdUploaderNotified PLEASE ADD IT -- ##### Server status: 503 - Error:. This server-side problem also extends to editing some pages using source editing, needing a few "TRY AGAIN" clicks. I suspect much of the issues concern uploading of edits, because it seems fine whenever I "download" data like loading any of the pages here (file pages, Commons policy pages, categories, watchlist, galleries etc.). (Very likely, I experienced another "Server returned error: HTTP 503." while saving this topic.) JWilz12345 (Talk|Contributions) 03:06, 4 September 2026 (UTC)

503s are generally transient errors that go away after a few minutes. Bawolff (talk) 16:54, 4 September 2026 (UTC)

1970 Yugoslav film poster with locally redrawn Disney characters

I would appreciate opinions on the copyright status of a 1970 Yugoslav theatrical poster before uploading it.

The poster was issued by Kinema Sarajevo for Remek djela Volt Diznija ("Walt Disney Masterpieces"), a theatrical compilation of eleven Academy Award-winning Disney shorts. Contemporary Yugoslav newspaper listings document the compilation's theatrical release in December 1970.

The poster appears to be a locally produced Yugoslav design rather than a reproduction of a French, American or other Disney campaign poster. Its composition and lettering are original, and the characters appear to have been independently redrawn by a local illustrator in a noticeably simplified, non-professional style rather than reproduced from film frames, model sheets, or existing Disney promotional artwork.

Under the former Yugoslav copyright rules applicable in Bosnia and Herzegovina, works of applied art published before 1 January 1977 had a 25-year term. For works published before 1 January 1971, Commons' Bosnia and Herzegovina copyright guidance indicates that the copyright had already expired before the URAA restoration date.

The issue I am uncertain about is the treatment of the characters depicted in the poster. It includes locally redrawn representations of Mickey Mouse, Pluto, the Three Little Pigs / Big Bad Wolf, Ferdinand the Bull and other characters associated with the films in the compilation.

I am not arguing that the underlying Disney films are public domain. The narrower question is whether an independently drawn 1970 Yugoslav poster, whose own copyright has expired, remains non-free merely because its local illustrator depicted recognizable characters from the advertised films.

In particular:

• the drawings do not appear to reproduce identifiable film frames;
• I have not found evidence that they reproduce Disney model sheets or existing poster artwork;
• the Yugoslav poster has a different composition from the known French/Belgian campaign material for the same compilation;
• the characters appear to have been redrawn locally rather than mechanically copied.

Would Commons treat the surviving character copyrights as preventing upload of the entire poster, or can the poster be considered a public-domain work of applied art where the particular drawings themselves are independently created?

If useful, I can provide a high-resolution scan and side-by-side comparisons with the known foreign campaign posters and film imagery.

Relevant copyright guidance:

• Commons:Copyright rules by territory/Bosnia and Herzegovina
• Commons:Derivative works
• Commons:Character copyrights
• Commons:Fan art

Thank you.
User:Baronmilone, 18:41, 4 September 2026 (UTC)

Streetcar image

I found an image I want to use of a streetcar here (full image here) and I did some research and I found it in a magazine article from 1964 stating the image was from a former resident of Martinsburg. This was the earliest mention of it. The street railway operated form 1891 to 1893. I don't know if this is copyrighted, it is on Flickr, but I doubt he is the original owner. Wobs100 (talk) 02:41, 5 September 2026 (UTC)

If that U.S. magazine wasn't properly copyrighted, then it is in the public domain. Otherwise, The 1964 magazine is properly copyrighted, see page 3. You'd need to have reasonable evidence of how this photo passed into the public domain (publication before 1931; publication without formalities in the era when that was required in the U.S.; etc.). 1964 first publication with proper authorization by the heirs and a proper copyright notice would mean this will not be in the public domain until 2060, even if the photo is much older. - Jmabel ! talk 04:19, 5 September 2026 (UTC)

And showing that the 1964 publication was not authorized by the heirs would border on impossible; we have no way of knowing whether "Charles Hess" was the photographer's heir or not. - Jmabel ! talk 04:22, 5 September 2026 (UTC)

Ok! Wobs100 (talk) 12:44, 5 September 2026 (UTC)

Photo challenge July 2026 results

Disaster rephotography: Entries • Votes • Scores

Rank	image	Title	Author	Score
#1		Tenement House Rynek 42, Wroclaw, Poland - after World War II Tenement House Rynek 42, Wroclaw, Poland - current state	Krigore	16
#2		Town Hall in Wroclaw - after World War II Town Hall in Wroclaw - current state	Krigore	12
#3		St. John the Baptist Archcathedral, Wrocław, Poland - after World War II St. John the Baptist Archcathedral, Wrocław, Poland - current state	Krigore	11

Puddles: Entries • Votes • Scores

Rank	image	Title	Author	Score
#1		Peafowl mirror image on a puddle	Sindugab	18
#2		A puddle in Warsaw, Poland	Krigore	17
#3		Reflection in a puddle	Gorillo.Chimpo	13

Congratulations to @Krigore, @Sindugab and @Gorillo.Chimpo. Sekidoki (aka Taiwania Justo) is speaking (Reception Room) 06:35, 5 September 2026 (UTC)

A rephotography contest is a clever idea! Congratulations to those who participated. -- Arlo James Barnes 21:21, 5 September 2026 (UTC)

Template:Countries of Asia

Hello everyone,

In the template {{Countries of Asia}}, the entry for Israel has been removed and replaced with Palestine. I wasn’t able to find the edit that caused this change. Could someone help locate the source of this edit? -- Geagea (talk) 07:06, 3 September 2026 (UTC)

@Geagea: I can't see or understand what you mean or what the issue of {{Countries of Asia}} would be. The template contain these lines: Countries of Asia: Afghanistan ·[...]Indonesia^‡ · Iran · Iraq · Israel · Japan · Jordan [...] - Israel is clearly present in the display I have. There's also Limited recognition: Abkhazia^‡ · Taiwan · Northern Cyprus^‡ · Palestine · South Ossetia^‡ – Other territories:[...], where Palestine is evidently also present. Regards, Grand-Duc (talk) 10:46, 3 September 2026 (UTC)

Well, now it's ok. it was:

Countries of Asia: Afghanistan ·[...]Indonesia‡ · Iran · Iraq · Palestine · Japan · Jordan [...] - Israel is clearly present in the display I have. There's also Limited recognition: Abkhazia‡ · Taiwan · Northern Cyprus‡ · Palestine · South Ossetia‡.

Anyway, we're all good now. Thanks for taking a look. -- Geagea (talk) 10:55, 3 September 2026 (UTC)

I think the template uses the country name from Wikidata, and the problem was the Wikidata item for Israel (d:Q801) was vadanlized yesterday, and the edit had just reverted today. Not sure why the Wikidata item is not protected. Thanks. Tvpuppy (talk) 11:00, 3 September 2026 (UTC)

Thanks, i'be checked WD and it was ok. I didn't thought about checking the history. Thanks. -- Geagea (talk) 13:21, 3 September 2026 (UTC)

The item is protected, the vandal waited to get the confirmed status (and is now globally locked). Ymblanter (talk) 18:04, 7 September 2026 (UTC)

The recognition of Israel is limited too. I certainly do not want to open the can of worms of defining what is limited and what not, but if someone says the template "Countries of Asia" is taking a political stance they may have a point. See:

Palestine recognition

Israel recognition

Regards. Strakhov (talk) 16:40, 7 September 2026 (UTC)

@Strakhov: I think in these cases we have always considered full UN membership as a clincher. - Jmabel ! talk 01:06, 8 September 2026 (UTC)

@Jmabel it is a flawed reasoning. Both Vatican City (Holy See) and Palestine are not full members. They are merely observer states. Vatican City, nevertheless, remains part of {{Countries of Europe}} as a regular country as opposed to state with limited recognition. JWilz12345 (Talk|Contributions) 02:05, 8 September 2026 (UTC)

I "don't have a dog in this fight" with reference to which UN observer states are listed; just that we don't exclude any UNmember states. - Jmabel ! talk 02:23, 8 September 2026 (UTC)

Wikimedia Commons turned 22

Some ice-cream for the Occasion! EugeneZelenko (talk) 12:35, 7 September 2026 (UTC)

AH thank you for the reminder. Time flies by (so fast D: ) --PantheraLeo1359531 😺 (talk) 16:06, 7 September 2026 (UTC)

Good news! Hope that Commons will live and thrive! Юрий Д.К. 17:10, 7 September 2026 (UTC)

commons-nominator, nominations without leaving the page you are in

I comment here a script I maintain since some time, commons-nominator, because I just added a thing that maybe is useful for more people. In a file page it puts a row of links that nominate the file to FP, QI and VI, each one with its dialog and one single edit per click, and next to them it also schedules a featured picture as Picture of the day in the next free date, sets the picture as the image of its Wikidata item when that item still has none, and searches which English Wikipedia articles the picture could illustrate, which is what a Commons FP needs before it can be a featured picture over there. What I added now is that all this arrives to the category pages too, written over the thumbnails themselves, so you can go through a whole category deciding while you look at the pictures instead of opening them one by one. Every picture that is still not a Quality Image gets a small QI button, in green when the file is already a Featured Picture, because a FP without QI is almost always an oversight and not a decision, on my own files 84 of my 212 featured pictures were missing it. Pressing it opens the normal dialog with the short description already filled from the file, and when you finish you stay in the category. In the FP nomination pages it also adds rename buttons and it warns you about the two open nominations rule before you edit instead of after. It only offers what each process could accept, so it stays quiet on videos, on small images or when your five QI nominations of the day are already used, and it never writes anything without a click. Documentation and installation in User:Wilfredor/commons-nominator, and I read everything that you tell me is wrong with it. Wilfredor (talk) 17:58, 7 September 2026 (UTC)

POTD

The photographer of the POTD of 20260917 and 20261127 and some other dates removed his pictures because he wants to give the honours to other photographers. Is someone busy to choose other pictures? Hobbema (talk) 08:13, 11 September 2026 (UTC)

It appears that this has been solved. Hobbema (talk) 17:40, 11 September 2026 (UTC)

This section was archived on a request by: Jmabel ! talk 19:54, 13 September 2026 (UTC)

Images and files not loading properly on Commons

Hi, I have noticed that when I am uploading pictures and PDFs to Commons recently, they are sometimes not rendering properly when I open the file page. Examples: https://commons.wikimedia.org/wiki/File:Phylloscopus_forresti_-_James_Eaton_-_338161400.jpeg https://commons.wikimedia.org/wiki/File:Pelargopsis_melanorhyncha_-_James_Eaton_-_435252346.jpeg https://commons.wikimedia.org/wiki/File:Photo_Guide_to_the_Lycaenidae_of_Bolivia.pdf Mitsingh (talk) 08:28, 8 September 2026 (UTC)

Can you be more specific ? They look fine to me. I cant know what you think ‘properly’ means. —TheDJ (talk • contribs) 10:37, 8 September 2026 (UTC)

I am sharing some screenshots of what it looks like to me-

https://postimg.cc/MMBfDtyw

https://postimg.cc/BXpLMj1Q

https://postimg.cc/4nbQRNhF Mitsingh (talk) 11:39, 8 September 2026 (UTC)

A script for the wikitext and structured data coordinates that disagree

A file can carry its position twice, as {{Location}} in the wikitext and as P1259 in structured data, and nothing keeps the two honest. Category:Pages with local camera coordinates and mismatching SDC coordinates has about 19,000 files where they do not match.

User:Wilfredor/commons-sdc-coords shows both sides on a file page with the distance between them and a button to fix whichever one is wrong. On a category page it reads the whole category and lists only the files where the camera EXIF settles which side is right, and then writes them in one run with pause and stop. It carries on from where the last run stopped, or you can ask it for a random sample instead, because a category that size never gets read in one sitting.

In a batch it only ever writes structured data, never wikitext, because the structured data was often copied from the EXIF by a bot and rewriting somebody's corrected wikitext on that evidence would undo human work at scale. And it will not touch a file where the camera is as far from one side as from the other.

I ran it over 670 files and 654 were written. It also purges the pages it corrects so they leave the tracking category, which does not happen on its own because the statement lives in a different slot from the wikitext.

Source and documentation at User:Wilfredor/commons-sdc-coords. Reports and complaints welcome. Wilfredor (talk) 13:01, 8 September 2026 (UTC)

@Wilfredor: Did your script also make this change? It is wrong! The EXIF coordinate in this image are false. So I correct it with my knowledge about this location. Had visit this museum. Please don't change coordinates if a local wikipedian correct this in first step. --sk (talk) 14:29, 8 September 2026 (UTC)

This one was wrong too. Strakhov (talk) 14:32, 8 September 2026 (UTC)

Idem, also wrong. 2/2 in my watchlist so far. Several more to check. Maybe not a great idea changing this automatically.Strakhov (talk) 14:37, 8 September 2026 (UTC)

@Stefan Kühn and Strakhov: Yes, it was my script and the two of you have reason, I have switched off the category run and I am reverting what it did. The error is in the rule and not in the code, I supposed that the two sides were not symmetric, that bots copy the EXIF into the structured data but not into the wikitext, so I took the EXIF agrees with the wikitext, as a proof that the statement had drifted, and that is false because the bots write also the wikitext from the EXIF, and the summary of Rkieferbot says it with those words, "Bot: Inserted location tag from EXIF", so my test was comparing one number with itself and passed always. In the Venice file the history Strakhov removed the EXIF claim in September 2020, put the correct one and marked the file page as "bad location", a bot returned the EXIF value into the wikitext in August 2025, and my script then saw the wikitext and the EXIF agreeing and wrote over that correction a point at 474 m, on the Rialto bridge instead of Piazza San Marco, from a Nikon D750 that does not have GPS receiver, so that coordinate never came from the camera. Stefan, if your file has the same shape then it is the same cause. The numbers for now, the run wrote 900 files and 392 of them, the 44%, carry {{Location}} with source:exif, which means the wikitext was the EXIF again and there was no independent evidence for any of the two sides, and I am checking the 900 one by one to find the ones where a person had put the statement by hand before me, which is the subset that really undid the work of somebody, and in the first 100 there are 7, with the names of Ermell, Strakhov and MIGORMCZ. Please, you should not clean this yourselves, I will revert every one that I find and I post the list in this thread when the check finishes, and if you already fixed some please tell me which ones and I leave those alone. Two things changed already, a location template that says source:exif is not treated anymore as a second witness, and the category run stays off until I rebuild the rule over the page history, where a person set the statement and a bot inserted the location template after, is a signal that can be read instead of a guess, the panel on the file page continues, because there a person is looking at one file and deciding. Sorry for the mess and thanks for detect it. Wilfredor (talk) 14:42, 8 September 2026 (UTC)

Everything is reverted, so nobody has to check their watchlist. The run wrote 1319 files and touched a hand set P1259 in 110 of them, but 13 of those were people who had removed a bad value, where my edit was the good one and reverting would put the rubbish back. In File:2018-10-19 Buenos Aires by Sandro Halank–111.jpg there was a coordinate in Turkmenistan, HenkvD removed it in 2022 and a remnant stayed. The other 97 were people who had set the value I wrote over. @Strakhov: had already put 2 back, so I restored the other 95 from the revision before mine, same guid, same rank, same qualifiers, and purged them so they return to the category. The list is at User:Wilfredor/commons-sdc-coords/overwritten. The cause is that I took the EXIF agreeing with the wikitext as evidence, when a bot had put the EXIF into the wikitext in first place. Rkieferbot says it in its own summary, how I told in the previous message. And I trusted the EXIF without looking at it. One file had latitude and longitude changed of order and a building of Berlin went to the Arabian Sea, another had the sign wrong and Budapest moved 2835 km, another said 90, 0, which is the North Pole. @Strakhov: you have reason about doing this automatically. The category mode stays off and it does not come back with that comparison, because the wikitext is almost always the EXIF again. Any new rule I test against these 95 files before it writes nothing. Sorry for the work and thanks again The file page panel continues, there a person looks at one file and decides. Wilfredor (talk) 15:36, 8 September 2026 (UTC)

Thank you. Strakhov (talk) 15:38, 8 September 2026 (UTC)

Commons:Categories for discussion/2025/05/Category:Threshold of originality-related deletion requests in Albania

This discussion which I started needs attention. Kindly go to this discussion page. JWilz12345 (Talk|Contributions) 07:56, 11 September 2026 (UTC)

PIP removal requests on "embarrassment"

Recently, I have seen several instances of individuals nominating photos of themselves (no explicit evidence they actually are the person in question) for deletion on the allegation that it causes embarrassment. Commons:Photographs_of_identifiable_people#Removal_requests does state that embarrassment may be a reason for deletion, but does not guarantee this. Now, the claim that a photo causes embarrassment is difficult to assess when looking at these photos, as it is somewhat subjective. However, many such requests concern photos in which there is basically no element of degrading or insulting content. This includes many neutral portrait photos or screenshots taken from videos. We should obviously not cave to every allegation that a photo is embarrassing, as this could quickly become a tool of censorship for individuals wishing to promote a particular image of themselves.

Since COM:PIP does not elaborate on what constitutes embarrassment, can we come up with some guidelines for future deletion discussions? – Howardcorn33 (💬) 09:57, 3 September 2026 (UTC)

I don't know if the nominator being the uploader counts as 'explicit evidence' but it seems appropriate that if someone adds an image to Commons they should be able to subtract it unless that would disrupt reuses on WMF wikis. Outside of that, it sounds more like a matter for the email addresses at meta:Safety Resource Center/Digital Safety. Arlo James Barnes 14:38, 3 September 2026 (UTC)

I am also including cases where the photo was uploaded by a different user from the person depicted on the image. – Howardcorn33 (💬) 15:33, 3 September 2026 (UTC)

The process for the deletion of a picture based on the request of the depicted person always requires the identification of the person. Deleting the photo based on false claim of someone being the subject of the photo would be a massive personality rights violation. GPSLeo (talk) 16:40, 3 September 2026 (UTC)

Should we always require VRT verification for users claiming to be particular individuals in deletion discussions? – Howardcorn33 (💬) 17:09, 3 September 2026 (UTC)

No, VRTS should not be automatic. There are plenty of cases where an unused and unremarkable photo can be quietly deleted in good faith. Requests like "I was the child in this photo and I prefer it to not be online anymore" can be treated respectfully and it benefits the project goals to have a courteous way of handling such requests. If it's in use beyond user pages or just within Commons, especially on a Wikipedia article about a person, or has some objective historical value, then asking a user to go via email (and avoid drawing attention in public) is at that point justifiable and easy to explain if challenged. Fæ (talk) 07:50, 4 September 2026 (UTC)

We should generally default to deleting photos of people on the subject's request unless there is a compelling reason to keep it - e.g. if the subject is clearly notable, or the photo is in use and no good alternative is available. These sorts of photos typically have negligible educational value, and/or are easily replaceable; hosting these photos against the subject's wishes does not advance the purposes of Commons. Omphalographer (talk) 02:33, 12 September 2026 (UTC)

Ah I should have specified I was referring to notable people (eg. those with Wikipedia articles). – Howardcorn33 (💬) 09:29, 12 September 2026 (UTC)

• Just a few recent ones:

• Commons:Deletion requests/File:Silvia Leal.jpg
• Commons:Deletion requests/File:Shana Pearson dehors Casa Del Popolo.png (BullDoser !)
• Commons:Deletion requests/File:Fa-مجتبی عیسی پور.ogg
• Commons:Deletion requests/File:Anne C, Agungsn, Aesthetic of Me 5-5-2026.png
• Commons:Deletion requests/File:Abendrot Rittersgrün.jpg

I too would welcome a guideline on this. Andy Dingley (talk) 16:53, 3 September 2026 (UTC)

Announcing Wiki Loves Peace!

Hello everyone,

I would like to invite the Commons community to participate in Wiki Loves Peace 2026, an international photography campaign organized in collaboration with the United Nations Office for Disarmament Affairs (UNODA) under the Wiki4Disarmament project.

The campaign runs from 21 September 2026 (International Day of Peace) until 30 October 2026 (conclusion of United Nations Disarmament Week) and aims to document peace-related heritage, memorials, museums, educational institutions, public art, and peacebuilding initiatives through freely licensed media on Wikimedia Commons.

The winning photographs will be featured on UNODA's official social media platforms with appropriate attribution to the author(s).

Examples of eligible subjects include:

• Peace memorials and monuments
• Peace museums and exhibitions
• Anti-war memorials
• Sites associated with reconciliation and coexistence
• Public art promoting peace
• Peace education and disarmament initiatives
• Hiroshima and Nagasaki heritage sites
• Remembrance and commemorative sites

The project page, participation guidelines, jury process, and campaign details can be found here:

Meta page: Wiki Loves Peace, Commons: Campaign:Wiki Loves Peace

Feedback, endorsements, questions, and participation are all welcome. We would also be grateful for help with outreach, translations, and community engagement.

Best,
❯❯❯ Raydann^(Talk)

Wikimedian-in-Residence
United Nations Office for Disarmament Affairs (UNODA)
09:37, 12 September 2026 (UTC)

Listed building

In my family archive I found this 1951 picture. On the back was written 'Priory court Hold'. I found a link to File:Antique Exports at Pevensey - geograph.org.uk - 5196866.jpg and it seems to build a listed building. However the template (Geograph from structured data) does not allow me to link back to the 1951 picture.

Smiley.toerist (talk) 13:35, 13 September 2026 (UTC)

They should be linked by SDC "depicts" (appears to be Ye Olde Mint House (Q26573236) and/ or a category.

They are not "Other versions" of the same work. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:18, 13 September 2026 (UTC)

There's no 'should' for SDC fields. They are safely ignored by most volunteers, in fact the opposite is true, I'm just now trying to filter by SDC inception dates, only to find it's impossible and the same data has been deleted from the wikitext so can't be searched in normal ways.

For example there's a set of files related to File:(1862) Annual report of the board of directors and officers of Longview Asylum, to the governor of the state of Ohio, for the year ending... - DPLA - d843c318b58f83086da3aaf4a3f118e9.jpg and because some but not all wikitext has been deleted from these just 2 months ago, they are impossible to filter out if the date does not happen to be in the title. Thanks SDC obsessives, not helpful when trying to mass determine copyright issues amongst hundreds of thousands of related files (see DR).

In the case of the 1951 photo, it seems easier to recommend adding an info template just with the other_versions field to cross-link related images. The obsession with blanking all wikitext has made Commons invisible to users when searching. Fæ (talk) 19:18, 13 September 2026 (UTC)

BTW, with the above DPLA example, the image page shows a Subject line of "Longview Asylum (Cincinnati, Ohio), Hospitals, Psychiatric--Ohio--periodicals" but looking at the SDC, there's no subject field, nor anything that looks like that line. Where is it? Does Commons really have to be made so cryptic a software engineer with decades of experience can't do basic searching? Fæ (talk) 19:29, 13 September 2026 (UTC)

What I wrote was "should be linked by SDC "depicts" ... and/ or a category." (as indeed they now are) That is indisputably true.

If you wish to learn how to use SDC properly, this subsection is not the venue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:42, 13 September 2026 (UTC)

Using Commons properly is our joint concern. That does not mean mandatory use of the WCQS just to search for images by date. Fæ (talk) 19:56, 13 September 2026 (UTC)

Then make that case in the appropriate venue, rather than sniping at your fellow contributors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:09, 13 September 2026 (UTC)

In this case, for a listed building, I completely agree with Andy on SDC and/or gallery. See File:Residence at 2004 34th Avenue S., Seattle, WA, after road put in, probably about 1900 (PORTRAITS 2309).jpg for an example of a reasonable way to handle this for a building that is not notable in its own right, by placing a gallery in the description. - Jmabel ! talk 20:01, 13 September 2026 (UTC)

I didn't mention a gallery. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:08, 13 September 2026 (UTC)

@Pigsonthewing: I know you didn't. As I said, for a listed building I agree with you completely. I then added how I would do it for a non-notable building, where we are not likely to have a Wikidata item, and where it would not merit a category. - Jmabel ! talk 21:23, 13 September 2026 (UTC)

I love it when people share their family archive imagery :) --PantheraLeo1359531 😺 (talk) 19:58, 13 September 2026 (UTC)

Thanks, I enjoy doing it. As I am the last of the family line and I dont have any family menbers where I can pas on the family archives, I find it a moral duty to preserve the images for prosperity. Unfortunatly a lot of family albums get dumped, when nobody within the family is interested in keeping them, when someones dies. For the pictures that are out of scope for the Commons (portrets etc) I upload them on to genealogical websites (Geni), so even these pictures dont get lost. I appreciate the inclusion of the inheritors option in the uploadwizard. I had to set license data manualy before, and I suspect that a lot of uploaders uploaded the pictures as 'own' work.Smiley.toerist (talk) 11:38, 15 September 2026 (UTC)

PS Does this body of water File:Hove 1951.jpg stil exists? Smiley.toerist (talk) 11:43, 15 September 2026 (UTC)

It certainly does:

• StreetView
• OSM
• Category:Hove Lagoon

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:27, 15 September 2026 (UTC)

And there is the Big Beach Cafe, Hove. Smiley.toerist (talk) 21:41, 15 September 2026 (UTC)

Editor's identification marks on images

As per Commons:Advert, is it appropriate for a Wikimedia COmmons editor/photographer to add their own personal/trade mark (trade mark,name etc) to an image that they both created and uploaded onto Commons. User:KaasterMDK has been marking all of the files that he has uploaded with his own insignia for example, in this file, his mark appears at the bottom of the info box in the top left corner. Martinvl (talk) 16:14, 14 September 2026 (UTC)

File:Guerra entre Buenos Aires y la Confederación.png is fine. RoyZuo (talk) 16:30, 14 September 2026 (UTC)

Although not an approved policy, Commons:Watermarks may be helpful. Pere prlpz (talk) 16:52, 14 September 2026 (UTC)

FWIW, for maps that is quite traditional, though somewhat less common recently. See https://gis.stackexchange.com/questions/18187/put-the-authors-name-on-maps where cartographers weigh in on both sides of this. I myself don't think it is at all objectionable when the creativity in a map is basically one person's work. - Jmabel ! talk 04:08, 15 September 2026 (UTC)

What is encouraged is that attribution is put in the attribution copyright statement. This can include any detail the creator/author wishes including websites or pseudonyms. If a CCBYSA license is used, this is binding on reusers. Credit bars and watermarks are haphazard and discouraged. In addition it's weaker as a way to ensure credit, because there's nothing to stop a later user removing them and in the age of AI supported tools, even novices can find ways to do that. In fact I've uploaded several tens of thousands of copyright free files that had credit bars added by websites, and stripped them off before even uploading...

Artworks that are signed, initialed or marked as part of the work are different, those should be retained as part of the work, as a courtesy, and for potential historical use. This may include relatively technical artwork, like plant illustrations. --Fæ (talk) 11:40, 15 September 2026 (UTC)

Location of art vs. origin of art

This came up because of a recent edit at File:Iranian wall tile with seated figure - San Diego Museum of Art 01.jpg. Pinging @Pataliputra!, who made the edit.

It seems to me that categories for the origin of artworks and artifacts are being conflated with categories for their location. In my view, this Persian piece in San Diego should not be in Category:1204 works in Iran because it is now in San Diego, California. Besides the general principle of distinguishing origin and location, in this case much of the Khwarazmian Empire is not present-day Iran, so I'm not at all sure even its origin is really what we normally mean by "Iran" (and I'm not sure whether that is important or not).

But I started following up some of the category tree and discovered it isn't just one case of a misapplied category, which is why I'm not just taking it up with the person you made this particular edit. We do have (and the file page already uses) Category:13th-century ceramics from Iran, but that does not break things down to individual years, so I see why an editor would be tempted to add an "in Iran" category for the work. And Category:13th-century ceramics from Iran is, in turn, in Category:13th-century art in Iran, which I see mixes "in" and "from" subcats.

Is this something that someone should sort out? Or should we just tolerate this ontological mess and say, "Probably people will find what they are looking for, anyway"? - Jmabel ! talk 04:20, 15 September 2026 (UTC)

I hope you're not implying that it should instead have a '1204 works in California' or in 'the United States', that'd be equally counterfactual. And while '1204 works in the Khwarazmian Empire', or 'from', is straightforward to add, I doubt the category tree could expand to include historic locations across the board. It's your upload so I don't think anyone would begrudge you to revert the addition of the category, but it seems fairly logical to me. Arlo James Barnes 05:21, 15 September 2026 (UTC)

I'm not so concerned with the one photo as with the categorization scheme. We have categories like Category:13th-century ceramics from Iran (note "from", not "in") and we could refine that down to categories for individual years. I do not think we should conflate where an artwork was created with where it is located. And we also do have Category:13th-century art in the United States, little if any of which refers to indigenous work by Native Americans. - Jmabel ! talk 19:49, 15 September 2026 (UTC)

There are similar discussions in the VP archives about location marking, including using wikidata, as well as categorizing for ancient art and finds. There are practices but no hard policy. Keep in mind that for ancient artworks there's the findspot, the place it was created (or minted), the place it might have been first identified, locations it may have been sold or granted or stolen from, the locations it might be on display, location it was destroyed, etc. All this data might be available in reliable sources and all might be relevant and any might be subject to debate or uncertainty. --Fæ (talk) 20:29, 15 September 2026 (UTC)

Server switch - Your wiki will be read-only for a short time soon

Read this message in another language • Please help translate to your language

The Wikimedia Foundation will switch the traffic between its data centers. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster.

All traffic will switch on 23 September. The switch will start at 14:00 UTC.

Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.

A banner will be displayed on all wikis 30 minutes before this operation happens. This banner will remain visible until the end of the operation. You can contribute to the translation or proofreading of this banner text.

You will be able to read, but not edit, all wikis for a short period of time.

• You will not be able to edit for up to an hour on Wednesday 23 September 2026.
• If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.

Other effects:

• Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
• We expect the code deployments to happen as any other week. However, some case-by-case code freezes could punctually happen if the operation require them afterwards.
• GitLab will be unavailable for about 90 minutes.

This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule.

Please share this information with your community.

Trizek (WMF) 12:58, 15 September 2026 (UTC)

Nice transparency, especially the detailed write up on wikitech, thank you. It's reassuring to see regular emergency system testing in action. Fæ (talk) 07:27, 16 September 2026 (UTC)

DLPA Duplicates

Who is responsible for DLPA project? I have with File:Presidential Trips - Letters (Miscellaneous Map Room correspondence) - January 2, 1944-April 4, 1945 - DPLA - d3c545b339b5725179374453cae7a1de (page 198).jpg a duplicate which is also in the source a duplicate. So i think there is something wrong at the National Archives and a need somebody who can fix this. thx for helping.--Sanandros (talk) 14:44, 15 September 2026 (UTC)

There is well over a thousand of them, see quarry:query/109312. I do not know which of the naming conventions are preferred, which one of each pair should be deleted? Snævar (talk) 17:42, 15 September 2026 (UTC)

It's Dominic, to answer your question🙃 --PantheraLeo1359531 😺 (talk) 20:07, 16 September 2026 (UTC)

There was something like 40,000 duplicated files a couple of months ago depending on whether you counted 100 files with the same SHA1 value as one duplicate or not. Thanks to hard work of volunteers this has reduced to a current ~1,400. Faebot is automatically topping up Category:Duplicate to gradually get through the remainder. As a reminder, the DPLA mass uploads are a funded project, the recent volunteer housekeeping is not.

As well as duplicates, if anyone is interested in both copyright problems found when looking at the 11 million DPLA uploads, and the uploading of what is probably at least a million jpg images of single pages of text from books, where we have, or could have, the book in a searchable PDF format instead, please have a read through some of the deletion case book at Category:DPLA deletion cases. Comments welcome in the deletion requests, the most recent being an interesting copyright restriction on local government magazines published 20 years ago, which were presumed to be copyright free, but, are not (DR). --Fæ (talk) 19:55, 15 September 2026 (UTC)

A lot of the dupes with multiple matches have differentiating page numbers. They seem to be empty pages and invalid as dupes as such, as in nothing should be done with them.--Snævar (talk) 12:07, 16 September 2026 (UTC)

What I stirred up a hornet's nest? And nobody has a solution?--Sanandros (talk) 13:02, 16 September 2026 (UTC)

TL;DR: yes, the duplicate images are a known issue occurring "upstream" in the DPLA project. Omphalographer (talk) 16:36, 16 September 2026 (UTC)

WRT the page number problem, this does seem to be a DPLA bot design flaw that affects, probably, hundreds of thousands of mass uploaded individual scans of pages from documents and books rather than just uploading the document or book. This was due to the page numbering being made up on the fly by the bot, not because page numbers were used at the source. This messy issue seems to be behind the sample of files at Category:DPLA duplicate names but not the same image, a category created due to some duplicate analysis we were doing a few weeks back. Fæ (talk) 10:34, 17 September 2026 (UTC)

Commons as the host of Global Gadgets

Have been using Commons to host this code: MediaWiki:Gadget-owidslider.js

Followed by using this code on EN Wikipedia among other wikis.

Are folks here good with being a central code repository for gadgets? Or should we push for another wiki to be the central repository for this sort of material? Also thinking ahead to a central repository for templates, as hopefully global templates eventually roll out. May need a separate wiki for these... Doc James (talk · contribs · email) 01:46, 12 September 2026 (UTC)

Technically I think Meta might some day become a host for global gadgets if that is ever handled by MediaWiki. At the moment personal global.js is already on Meta. But without having any extra mechanism for global gadgets I think Commons is fine for hosting code. Nux (talk··dyskusja) 10:11, 12 September 2026 (UTC)

The main thing about global gadgets and templates is having a subpage for configs and translations, like en:MediaWiki:RefToolbarConfig.js for example. Mw:Extension:Chart modules are allready global and they are on commons. Snævar (talk) 10:15, 12 September 2026 (UTC)

User:Snævar is this what you are refering to as a subpage for translations? [1] Doc James (talk · contribs · email) 16:10, 12 September 2026 (UTC)

Sure. mw:Multilingual_Templates_and_Modules has a sentance explaining my main point. "Hard-coding the text of these strings forces other wikis to modify the code in order to localize them, preventing globalization." That applies to gadgets too. Imagine trying to add translations of over 300 languages to a script that has strings in the code. It is going to be a mess. Yet, if we go over the gadgets on the top 10 wikipedias, a sizeable chunk of them have strings in the code. That is the real blocker for global gadgets. Snævar (talk) 16:42, 15 September 2026 (UTC)

User:Snævar MediaWiki:Gadget-owidslider.js has the i18n at the top for various languages of the interface. Is this what you mean or something different? Doc James (talk · contribs · email) 17:00, 15 September 2026 (UTC)

That is i18n, but in some cases there is also l10n. So i18n is transaltions, which in some cases you might want to have for any wiki (based on user language). The other part is adjusting to local community needs. For refToolbar that would be local names of templates and parameters to use when citing something.

So I think i18n inside code might be fine (especially when not too big), l10n is something specific wiki should download and should adjust (so more tricky to do right). Nux (talk··dyskusja) 18:09, 15 September 2026 (UTC)

Thanks. Looks like we may be adopting the refToolbar so will keep this in mind. Doc James (talk · contribs · email) 18:37, 15 September 2026 (UTC)

@Doc James, in case you didn't know: mw:Extension:Produnto. Nemoralis (talk) 11:14, 19 September 2026 (UTC)

Thanks, yes have spoken with Tim Starling and this will bring us global modules. He has also published a MVP for global templates for which it would be useful to have a new central wiki.[2] Doc James (talk · contribs · email) 18:18, 19 September 2026 (UTC)

Tokyo Game Show

I will be at Tokyo Game Show in a few hours.

Anything you want me to take pictures of?

Syced (talk) 12:13, 18 September 2026 (UTC)

The battery rental dispensers seem unusual, perhaps those? Arlo James Barnes 17:11, 18 September 2026 (UTC)

For that link, I get 404.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:35, 18 September 2026 (UTC)

Should work now, sorry. It's the website of the convention center. Arlo James Barnes 18:42, 18 September 2026 (UTC)

Ananta, Silver Palace, any indie game. Ahri Boy (talk) 09:11, 19 September 2026 (UTC)

@Syced: to avoid making uploads that end up getting deleted later, please give COM:Japan a read before you'll embark upon a photo tour. It's a tall order to avoid running afoul of COM:DM Japan in exhibition scenarios. For instance, everything that is game art and centrepiece of your photo won't be clear to upload. Same for mascots or sculptures of game characters - the latter is perhaps a grey area where guidances of the Japanese Agency for Cultural Affairs are contradictory in themselves; further material on ANU. Utilitarian objects should be fine, though. Regards, Grand-Duc (talk) 11:06, 19 September 2026 (UTC)

Mediaviews count

A little question: how are media views counted? For example, here, is what we see the number of users who viewed the image at its full resolution, or does it also include those who viewed it as a miniature inside a Wikipedia article or a Commons gallery or category? I don't know if it's feasible to have both types of data accessible. Some time ago, "Page views in the past 30 days" (for example, here) was added, allowing us to know how many visitors each file description page has, so maybe it could be useful to also have the statistics for both types of media visualizations available. MGeog2022 (talk) 20:12, 18 September 2026 (UTC)

@MGeog2022 mediaviews are the sum of all views (and downloads) of thumbnails and originals. Are you asking to show the pageview data in the same graph as the mediaview data ? —TheDJ (talk • contribs) 20:59, 18 September 2026 (UTC)

@TheDJ, no, I was asking about the views (or downloads) of originals, the full-resolution versions. I think this would be an interesting statistic, that, currently, we don't have available: an image being rendered when a user scrolls a Wikipedia article (the user could even have completely ignored the image), is not the same as a user noticing an image and then viewing it at its full resolution (again, viewing an image at its full resolution is not the same as viewing its file description page). MGeog2022 (talk) 21:13, 18 September 2026 (UTC)

@MGeog2022 right.. I don't think this is tracked at the moment. Additionally, there are times when the original is used as the thumb (when the displayed size is equal to or larger than the original), which would effect that metric. —TheDJ (talk • contribs) 11:24, 19 September 2026 (UTC)

@TheDJ, well, for images that are so small, there would be no problem in both statistics having the same value (in such a case, when seeing the thumbnail while scrolling a page, the user is seeing everything that can be seen in the image, anyway). MGeog2022 (talk) 08:44, 20 September 2026 (UTC)

Same admin closing deletion request and undeletion request

I'm not sure if we have an explicit policy, but since undeletion requests are the only appeal way when a deletion request has been closed wrongly, it seems reasonable for them to be closed by a different admin - at least if they are closed in the same sense. In fact, I would expect the original closing admin to argument their rationale when closing if they want, but not to close the undeletion request themselves.

Recently, this undeletion request was closed by the same admin that closed the original deletion request.

Is this allowed or normal in Commons? Pere prlpz (talk) 17:02, 20 September 2026 (UTC)

Given that there are few admins here on Commons (170 per COM:ADMIN, perhaps around half or less have COM:UNDEL as part of their regular watchlist), I agree for flexibility of adminship rules on non-controversial undeletion requests, like undeleting eligible images in a certain country in the event of that country introducing a Commons-suitable Freedom of Panorama rule. For example, Fitindia closed Commons:Deletion requests/Files in Category:Abraj Al Bait Towers as "delete," and courtesy of flexible rules Fitindia could undelete the images they decided as "delete" due to the introduction of exterior architecture-only COM:FOP Saudi Arabia. It is certainly non-controversial, given that the FoP introduction was first discussed on COM:VPC before acceptance. In the case of more complicated requests, like about the topic referenced by the deletion request you shared here (AI-generated media), it is prudent that a different admin would close it. JWilz12345 (Talk|Contributions) 17:30, 20 September 2026 (UTC)

So you mean [3]. Since it was stalled from 16 June until today, there was amply enough time to get support for undeletion, which it didn't. Yann (talk) 21:49, 20 September 2026 (UTC)

Well, one administrator (Theklan) did show support for undeletion. I assume he didn't close the deletion request because he had been part of the previous discussion, but the closing admin didn't exercise the same level of caution. Pere prlpz (talk) 21:59, 20 September 2026 (UTC)

Help in Category:Falcon 9 by flight

I want to kindly request everyone interested to help in categorising the images present on Category:Falcon 9 Starlink by flights and Category:Launches of Falcon 9. Abdullah1099 (talk) 02:23, 22 September 2026 (UTC)

Caption and description mismatch

When I upload my photos, I select to use the same text for caption and description. Sometimes afterwards I will correct the text but don't always remember to do so for the caption as well. I don't understand why the caption is somewhere else that cannot be edited at the same time as the description. Is there any way to easily find cases where the two originally matched, and one was edited but the other was not? NE2 (talk) 20:20, 17 September 2026 (UTC)

"Easily", no. Because this uses the SDC, tools that look at the wikitext on Commons fail to work. It can be done using https://commons-query.wikimedia.org/ but you need to know how to write SPARQL, effectively locking out the vast majority of volunteers who are never going to learn SPARQL just to use Commons, and thanks to the way the databases work, I understand that the lags across these systems can be days, and to my personal cost that systems like commons-query will consistently fail for large collections, so queries are highly unreliable.

There has never been a consensus for using SDC captions, nor a common understanding of the relationship to descriptions (wikitext). For these reasons my own uploads never touch captions and leave them blank to avoid conflicts and confusion for later mass use or searches. The descriptions are sufficient and far more useful across systems. Fæ (talk) 05:44, 18 September 2026 (UTC)

@NE2: Like Fæ, I mostly skip creating captions as well. However, FWIW, I think the distinction is pretty clear. While short descriptions often make perfectly good captions, a caption is strictly text and should almost never be longer than a sentence or two, whereas descriptions are much more flexible. A caption shouldn't usually go into things like (for example) what references were used for a map, or issues about a basis for dating a historic image, or any history about a depicted building, or other things like that which may be a useful part of a description. - Jmabel ! talk 21:50, 21 September 2026 (UTC)

Problems with re-upload of edited pics

Several times recently I've found that uploading new versions of files don't upload properly. Example this evening I edited out the watermark from File:Common tailorbird, Sri Lanka 2020-04-14.jpg and uploaded the new version, but the watermark is still showing in both the photo, and the thumbnail in the File History. Purging the cache (even repeatedly) does not help. Anyone know what the problem is? - MPF (talk) 23:27, 20 September 2026 (UTC)

@MPF yes, this is know problem. Assuming that is the same problem as phab:T425216, it is only about cache. Latest version should eventually show up in all sizes. Nux (talk··dyskusja) 21:49, 21 September 2026 (UTC)

@Nux thanks! Certainly similar, though if it is the same, it's a recurrence rather than continuing, as that was several months ago, and my cases have just been in the last couple of weeks. It wasn't happening e.g. last month. - MPF (talk) 00:18, 22 September 2026 (UTC)

Request for Main Page Announcement for Wiki Loves Peace 2026

Hello everyone,

I would like to request a Main Page announcement for Wiki Loves Peace 2026, an international photography campaign running from 21 September to 30 October 2026.

The campaign aims to document peace-related heritage, memorials, museums, educational institutions, public art, and peacebuilding initiatives around the world through freely licensed photographs on Wikimedia Commons.

The campaign is organized under the Wiki4Disarmament project and is supported by the United Nations Office for Disarmament Affairs (UNODA).

If there is community support, I would like to request that the campaign be featured in the Meta-Wiki Main Page announcement section.

For context, the campaign has also been featured by the Wikimedia Foundation: Instagram, LinkedIn, Facebook, YouTube, Bluesky, Threads

Feedback is welcome.

 Support - as proposer

Raydann (talk) 12:37, 21 September 2026 (UTC)

 Support. MGeog2022 (talk) 12:46, 21 September 2026 (UTC)

 Support. Nux (talk··dyskusja) 21:53, 21 September 2026 (UTC)

 Support. Tvpuppy (talk) 15:04, 22 September 2026 (UTC)

•  Done, given the urgency of the action and no opposition expressed in more than 24h.--Ymblanter (talk) 17:32, 22 September 2026 (UTC)

eduse essay

I started a draft essay at commons:educational use if anyone would like to edit it or give feedback at the talk page. Arlo James Barnes 19:30, 22 September 2026 (UTC)

Can we emulate playable public domain video games?

Would it be possible for a technically adept editor (i.e., not me) to upload to Commons a public domain video game, for example, Spacewar! or Ballerburg, in a way that it was actually playable on Commons, and on other projects where it was transcluded in the same way that images are transcluded? BD2412 T 01:44, 21 September 2026 (UTC)

At this juncture, no. The only thing even like that would maybe be embedding SMIL into SVG to make the game playable, which would be quite a hack. ―Justin (koavf)❤T☮C☺M☯ 02:21, 21 September 2026 (UTC)

SMIL isn't interactive, as far as I know. And even if it were, it wouldn't carry through to thumbnails embedded in wiki pages. Omphalographer (talk) 02:47, 21 September 2026 (UTC)

You can with scripts, of course, which I think would not be uploadable here. ―Justin (koavf)❤T☮C☺M☯ 03:16, 21 September 2026 (UTC)

Is it something worth working on? Or are there security/privacy concerns that would make it unworkable for this project? BD2412 T 04:18, 21 September 2026 (UTC)

I would recommend against it until/unless we allow actually uploading code itself and have an executable file. Or maybe a progress web application? But I certainly wouldn't want to discourage anyone from this: it would be an intriguing challenge. ―Justin (koavf)❤T☮C☺M☯ 04:40, 21 September 2026 (UTC)

SMIL can be interactive (e.g. media:SMIL missile demo.svg), but is ultimately very limited in what you can do. Additionally it only works if you directly view the page. I wouldn't particularly reccomend it for this purpose. Bawolff (talk) 18:50, 21 September 2026 (UTC)

SMIL can be interactive, entertaining and educational. At Media:Mapquiz USA states SMIL.svg, I just scored 50/50 with no errors. --Redrose64 (talk; at English Wikipedia) 13:40, 22 September 2026 (UTC)

This would be a big change. If we decided to do this broadly, the proper approach would be to copy what InternetArchive did with porting emulators/dosbox to web assembly. However given the very small number of public domain games, that doesn't seem worth it. The other approach is to create gadgets for one-off example. Consider for example w:Template:Tic-tac-toe or w:Template:Conway's Game of Life gadget as very simple examples in that direction. However there is a lot of red tape and discussion required to get a new gadget off the ground, in addition to technical expertise required. Bawolff (talk) 18:44, 21 September 2026 (UTC)

I'd think it more important to get standard images for them, as neither of those have any images on the page. If this were a project for one system with very notable games, then it would be one thing, but we're talking about a limited number of games, each on virtually its own system, with its own hairiness.--Prosfilaes (talk) 23:07, 21 September 2026 (UTC)

The best way to understand gameplay is to play the game. I grant that short videos of play can come close, though. BD2412 T 00:11, 23 September 2026 (UTC)

The best way to experience a game is on the original hardware. A bad emulation can be worse than a video, and lack of proper input or output support can doom many games. With the limited number of notable games we can work with, and the fact that they virtually each run on their own systems, I just don't see this as feasible for Commons.--Prosfilaes (talk) 02:25, 23 September 2026 (UTC)

I mean, theoretically there's probably some hack. But this isn't the purpose of commons. Maybe in the future, when there's a wider array of public domain software and video games. PARAKANYAA (talk) 15:28, 23 September 2026 (UTC)

What kind of tennis is this?

Smiley.toerist (talk) 14:21, 23 September 2026 (UTC)

I would say non formal, street tennis perhaps? Nux (talk··dyskusja) 15:03, 23 September 2026 (UTC)

The official website describes this activity as "mini-tennis". Thanks. Tvpuppy (talk) 16:13, 23 September 2026 (UTC)

I created Category:Mini tennis.Smiley.toerist (talk) 20:49, 24 September 2026 (UTC)

Ethics of Medical Photography Network

The "Ethics of Medical Photography Network" may be of interest; they are shortly to launch an "Ethics of Medical Photography Toolkit", "for everyone who encounters historical medical photographs in any capacity, including any researcher or visitor to archives and museums, as well as the wide range of GLAM (Galleries, Libraries, Museums and Archives) professionals who care for and provide access to medical photography collections". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:31, 24 September 2026 (UTC)

@Doc James may find this interesting. JayCubby (talk) 20:37, 24 September 2026 (UTC)

Thanks. As someone who has taken 100s to 1000s of medical images, many are exciting to help other people who have the same condition as them. But of course the question needs to be asked and consent acquired. Doc James (talk · contribs · email) 23:41, 24 September 2026 (UTC)