Commons:Village pump

Shortcut: COM:VP

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓

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 Welcome to the Village pump This page is used for discussions of the operations and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2025/12. Please note: If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias. Have you read our FAQ? For changing the name of a file, see Commons:File renaming. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer). Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam. Purposes which do not meet the scope of this page: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound workshop. For translation requests, please post at Commons:Requests for translation. For media requests, please post at Commons:File requests. For questions about copyright, technical matters, or help that does not relate to the general Commons community as well as proposals, please see the other discussion boards linked in the blue panel at the top. Search archives:     Start a new discussion

#	💭 Title	💬	👥	🙋 Last editor	🕒 (UTC)
1	Community Wishlist – Voting open for Commons-related Wishes!	8	3	Bawolff	2025-12-21 22:36
2	Should we be restoring information that we know is wrong?	14	4	Jmabel	2025-12-20 06:10
3	Writing a bot	14	5	Bawolff	2025-12-18 03:35
4	Category:Burials	18	8	ReneeWrites	2025-12-21 18:01
5	Small question	3	3	Jmabel	2025-12-18 21:21
6	Continuing notifications problem	4	3	Omphalographer	2025-12-18 19:56
7	Epstein Files	10	5	GPSLeo	2025-12-24 11:00
8	Category:Photographs by year	1	1	Rathfelder	2025-12-20 20:55
9	Photo challenge October results	2	2	Prototyperspective	2025-12-21 15:43
10	YouTube moved to CC BY version number 4.0	2	2	Prototyperspective	2025-12-21 15:33
11	Files tagged with both self and PD-US	6	3	Jmabel	2025-12-22 02:44
12	Are we starting to misunderstand the point of license reviewing?	18	7	Nosferattus	2025-12-24 23:12
13	History maps of Europe	1	1	Enyavar	2025-12-22 20:05
14	Category Sorting Question	3	3	ReneeWrites	2025-12-23 01:54
15	Possible 20 year hoax for images relating to 1896 and 1906 Olympic / Intercalated Games	5	3	Nosferattus	2025-12-25 00:05
16	{{PD-USGov}}	4	4	Aplucas0703	2025-12-23 22:58
17	Trouble with API	4	3	Prototyperspective	2025-12-23 13:55
18	Problem using Google Lens en TinEye	4	2	Tvpuppy	2025-12-24 19:32
19	"Photographs of"	1	1	Jmabel	2025-12-24 19:47

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

People of Ngadisan (Java, Indonesia) are filling their cans at the village pump. The old well is defunct and replaced by a water tap. [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Commons:Village pump/Proposals#Temporary account IP viewer policy (6 September 2025) User talk:CommonsDelinker/commands#Replace images with .svg version (5 August 2025) Category talk:Heroes' Cemetery in the Philippines#RfC: Cemetery name (18 July 2025) Discussion on Copyright law of North Korea (16 March 2025) Hosting of free fonts in Commons (18 July 2024) Template: View   ■ Discuss    ■ Edit   ■ Watch

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

December 04

Community Wishlist – Voting open for Commons-related Wishes!

Recently, voting was enabled in the Community Wishlist. It's the successor to the prior Wishlist Surveys and unlike these runs indefinitely. It's a place for the global Wikimedia community/ies to submit feature proposals, ideas for innovations, and requests to get important bugs fixed.

There are many Commons-related wishes in the Wishlist so I'd like to call on you all to browse the wishes, read the ones you find interesting and vote on the ones you find important. Better to not postpone it. Here's some I'd like to highlight after having read all of the 410+ wishes:

• Show categories on mobile – categories on files are very useful but if you use a smartphone to access Commons like around half of users, you can't see them
• Open the Wikimedia Commons file page directly – when opening an image on Wikipedia, it doesn't open a Commons page (the file page) but shows a intermediary Wikipedia page that does not have the categories; this means we get far fewer visits and far fewer people learn about Commons
• A proper audio player – e.g. up-to-date audio versions of Wikipedia articles can be provided now for many articles and could probably double Wikipedia reads but only with a modern player & well-visible audio
• Do something about Google & DuckDuckGo search not indexing media files and categories on Commons – after some work on this videos on Commons are showing in Google's Videos tab but there's more

.

• Add machine translated category titles on WMC – titles are short and by translating them people searching the Web in their own language can also find the Commons cats
• Add a date range filter to Special:MediaSearch
• Suggest media set in Wikidata items for their Wikipedia articles – if you find good media on Commons, just add it once to the WD item and it can trickle down into the Wikipedias
• Video & audio chapters (jump to timestamp)
• When searching Commons, if there is a category with same or very similar title, show a hint/link
• In Commons category deepcategory view mode (wall of images), allow easily filtering offtopic subcats – basically what is needed for a wall-of-images view for categories including subcategory contents
• A way to see why a file is somewhere underneath a specific category (tool to show cat-path)
• Support full colour 3D models on Wikimedia projects – currently it's only STL files without textures
• When searching Commons, under "Categories and Pages" show the category for the search term – basically search results are bad if you look for category/ies, not galleries
• …

• 
  How the audio player could look (bottom panel) after clicking play (desktop)
• 
  audio player for a Spoken Wikipedia audio via audio-chapters (mobile)
• 
  Video on Commons now showing in Google (success)
• 
  Opening an image on Wikipedia in a new tab or with this button does not show the Commons page

If you have questions about any wishes there, ask on the wish talk pages or check if things have already been clarified there. Currently, software development by the WMF is rather low but maybe that changes in the future so voting can still have an impact. You could also name some wishes you find important but weren't mentioned here.

There also is a tag for wishes called 'Multimedia and Commons' by which you can filter the table. Alternatively, you could enable this script and use the category page. However, note that some wishes relevant to Commons don't have the tag because they relate to basically all projects.

The wishlist is based on a new MediaWiki extension. In this Wishlist, there are 'focus areas' which used to be the only things you could vote on until recently. You could additionally vote on these, especially the focus area most related to Commons:

• Focus area 8: Media formats, editing, and display

Prototyperspective (talk) 23:32, 4 December 2025 (UTC)

I think people underestimate how many of these are political wishes not technical ones. Sometimes I feel like people feel they are powerless due to lack of technical know how, but so many of these are stuck on either getting everyone to agree or hammering out ambigious details, which is something anyone can in theory do. e.g. Show category on mobile - would take 10 seconds to change, the real issue is the mobile team came to the unfathomable conclusion that it would be a bad thing. Open image pages on commons. Also pretty easy, i think that one is stuck on most people not caring one way or another, of course the real question is how does this play with media viewer. Machine translation of titles sounds pretty spicy (My personal view is that this is the wrong solution to a real problem). Anyways, 90% of the battle is figuring out what you want and convincing everyone else to agree. Bawolff (talk) 06:53, 5 December 2025 (UTC)

how many of these are political wishes not technical ones. I don't know if you're referring to the wishes in this Wishlist in general or the wishes I linked or a mix – if the second, wishes that aren't about technical changes but about policy-changes get archived there. Some haven't yet been archived but I think by now all of these have comments on the talk page basically asking for it to be archived. It's relatively few that haven't yet been archived. political wishes not technical ones when you say that, you claim they're only "political" – but they rather have political/policy/group-decision-making aspects. Often, these aspects are already elaborated in the wish or on its talk page. If not, I suggest you add the info there. Ultimately, wishes are about getting certain things done / problems solved. If there's also political things that need addressing or be done, then wish creators and supporters are certainly interested in discussing these there and getting them done as well.

• so many of these are stuck on either getting everyone to agree or source? I think they're stuck because there's very little software development and apparently relatively little interest to do any of the many things that could be done to increase it. Only some are stuck on these as well but obviously things like that don't get solved by themselves but need the political aspects to be clarified and then addressed. If 30% of wishes were implemented, one finds another 40% to be infeasible or quite unimportant, then it would be much easier and flow naturally to narrow in on the remaining 30% to find which of these are stuck on political issues and then work on addressing these. This is how I'd imagine the impact of more software development: as WMF would solve more critical bugs, boring but important issues, and more issues in general, people get freed up to and can dive more into suggested innovations and extend Wikimedia. The first step is more development.
• …or hammering out ambigious details That's why I always tried to include potential solution(s) in the wishes and add ideas on how to solve it to the talk pages of wishes that don't have such technical info despite that the wishlist is/was intended to be problem-focused. More details can be hashed out on the talk pages in regards to how things could be done in practice. I also had one user mail me, saying they're developing a script that aims to solve one of the wishes. Details don't get hammered out by themselves, it needs people to think about them and discuss them – this is what the wishes and their talk pages are for too.
• would take 10 seconds to change, the real issue is the mobile team came to the unfathomable conclusion that it would be a bad thing Exactly! So they should do it. It has been asked for many times, the community certainly wants it – it has been the top #1 wish of the Commons Technical survey, is a heavily-followed code issue, and was the top #3 supported wish in the 2023 global Wikimedia Community Wishlist survey. The WMF just ignores it and doesn't even feel the need to give any explanation why they are doing so (they didn't even say that they concluded this). Afaik, they only said Unfortunately, our key partner, the Web team, will not tackle this wish now. The importance of categories to readers must be researched further to prioritize this wish instead of other pending wishes. I strongly disagree with that. Moreover, if they want to do further research before implementing this, then do it.
• Also pretty easy, All the better. So it should rank high on feasibility and ease of implementing. on most people not caring one way or another Hence the wish and the ability to support it. Wikimedia community often shoots itself in the foot. Here we're keeping Commons down for no reason. If you like Commons to be better known and used more + wikilink in file descriptions to not be redlinks + categories to show on file pages at least when on desktop, then I strongly suggest users support this wish. However, most users aren't much aware of this and haven't thought about it. I don't know why you say this as if it was a caveat or downside of the wish: that it may be easy to implement is an advantage and that people in your mind don't care about it, is basically the point of the wish. the real question is how does this play with media viewer No, that's not the real question. Why would it? If you think things like that, I always suggest you (also) raise it on the wish talk page where it potential issues can be addressed. The MediaViewer actually does link to the Commons file page directly – it works how it should. One clicks the "More details" button and it takes you to the Commons file page. It's just that the other file links haven't been adjusted.
• Anyways, 90% of the battle is figuring out what you want and convincing everyone else to agree If this hypothesis was true, then nearly all top 15 wishes of the past years' wishlists would have been implemented. It's far from that. Either way, the wishes – including the voting and the talk page discussions – are one part of that.

Thanks for your feedback; basically maybe the political aspects are underestimated (which imo would suggest that the impact of votes & discussions are also underestimated). Prototyperspective (talk) 13:12, 5 December 2025 (UTC)

Perhaps I'm just sad how it feels like things have devolved to the community begging WMF for tidbits. I guess that is the natural consequence of more and more development happening by WMF instead of being more community oriented. I do think (with the exception of the mobile category one) that the higher you get on the wishlist the more technical and less political things become, because to make it to the top of the vote list, you need more universal agreement to get everyone to vote for it. Bawolff (talk) 17:28, 5 December 2025 (UTC)

@Prototyperspective I do think you underestimate some of the social bits of this. There is not simple 'just doing it'. Just doing things affects hundreds of other people. "if this hypothesis was true, then nearly all top 15 wishes of the past years' wishlists", those people represent just a fragment of the userbase and generally none of the other stakeholders affected by the change. Please vote, please show your interest, all of that is sorely needed, and it DOES influence things. —TheDJ (talk • contribs) 12:55, 8 December 2025 (UTC)

Maybe but many or most of these are welcome by users with no significant objections to having the proposed functionality added. The high number of wishes clearly indicate that users would like to have what's proposed. I've voted on a lot of wishes already. Voting doesn't seem to have much impact so far though as again just a fraction of the highest-voted wishes and a very small fraction of overall wishes got implemented so far. Prototyperspective (talk) 16:24, 15 December 2025 (UTC)

On a related note, I was thinking of mailing the new WMF CEO, Bernadette Meehan, to highlight and support calls for more technical development and maybe briefly explain the need for such after I found this page linked from the latest Signpost with Share your views […] Directly by email at […]. I don't know whether this is something that has any chance of having an impact. Prototyperspective (talk) 19:37, 21 December 2025 (UTC)

I've certainly worked on things in the past where nobody objected and everyone wanted it, until it was actually finished then everyone seemed to suddenly have an opinion. Of course users aren't the only stakeholders here. The wishlist seems to be aimed around getting support, but doesn't exactly encourage dissenting views. Sometimes wishes/features involve extra (often hidden) work for other people even after its "done". Sometimes the reason things don't get done is they create unacknowledged work for other people, who tend not to like that if they aren't on board. Bawolff (talk) 22:36, 21 December 2025 (UTC)

December 17

Should we be restoring information that we know is wrong?

I do not want to get into another edit war, per the complaint "Are images that were taken from Flickr", about restoring speedy deletion tags, that I removed. Should we be restoring information that we know is wrong? See: this edit. We know that the date is incorrect and that the author is incorrect, that is why it is up for deletion. Should we be attempting to fix these obvious errors, or should the errors remain so that the image has to be deleted? RAN (talk) 03:03, 17 December 2025 (UTC)

Both versions (before and after that edit) look problematic to me.

• Edit clearly restores a wrong date and a license we know is invalid. Both bad.
• State prior to edit shows FlickreviewR activity that is unrelated to the PD "license" tag. Also:
  • I would never quote ChatGPT as a source for dating photos. I work with a lot of older materials (mostly for Seattle and Alaska), and I've never found any generative AI to be much better at that than a human who is used to looking at old pictures. It's probably not far off, but as far as I'm concerned, that's on about the level of citing "my cousin Bob". Actual evidence of what year that model of radio or headphones were made would mean something, in that it would give at least an earliest possible date. (Edit removed this.)

    I disagree, ChatGPT has access to billions of dated images that "cousin Bob" does not have access to, not the brain capacity to digest billions of images. ChatGPT does not just give a date, it gives the rationale it used to come up with the date. --RAN (talk) 03:36, 19 December 2025 (UTC)

  • What is the point of linking three sites as "other versions" where two of them explicitly credit the same Flickr user as their source, and the other is dated 2025 so it presumably got the photo either from us or from that Flickr user (it gives no credit). (Edit removed this.)

    I disagree, "other versions" sound like the perfect place to show where the image is in use. --RAN (talk) 03:36, 19 December 2025 (UTC)

- Jmabel ! talk 06:18, 17 December 2025 (UTC)

I will move our disagreements to subsections as separate topics for discussion. If you feel my wording of the questions below is not neutral, please feel free to indicate how you would word the question. - Jmabel ! talk 20:42, 19 December 2025 (UTC)

Is it appropriate to cite ChatGPT for the date of a photo?

Is it appropriate to cite ChatGPT for the date of a photo? Above, Richard Arthur Norton (1958- ) says yes, I say no. - Jmabel ! talk 20:42, 19 December 2025 (UTC)

It is more nuanced than just providing a date, ChatGPT provides a rationale for the date, or range of dates it comes up with, and of course ChatGPT is listed as the source of the information. See for example: File:Arthur Oscar Freudenberg (1891-1968), 1910s, New York City.jpg — Preceding unsigned comment added by Richard Arthur Norton (1958- ) (talk • contribs) 22:54, 19 December 2025 (UTC)

@Richard Arthur Norton (1958- ): I have no problem with that, because specific evidence is provided; ChatGPT here is playing exactly the same role here as any editor could. What I object to is something that just amounts to, "Dating this 1925 because ChatGPT says so." - Jmabel ! talk 01:31, 20 December 2025 (UTC)

• No one has done that, the image in the dispute was "circa", in this case "circa 1925" and the ChatGPT rationale was in place, and clearly marked as coming from ChatGPT. It was removed and the image was restored to the default upload date, which was clearly wrong. And the clearly-wrong date was part of the deletion rationale. I have no objection to people disputing ChatGPT, if they think it should be "circa 1930" for other reasons, but the ChatGPT rationale should be left in place. I also have no objection to people using any other AI, so long as they document the source. AIs are also very good at estimating the age of the subject in the image, and if we know their birth year, it can estimate the year the image was taken within a few years. This is very helpful when looking through the USCO copyright registration database and the USCO copyright renewal database. --RAN (talk) 01:51, 20 December 2025 (UTC)

Disagreement over the use of "other versions"

Is it appropriate to use the "other versions" portion of the Information template to indicate places on the Internet where there is a copy of the image in question? Above, Richard Arthur Norton (1958- ) says yes, I say no. - Jmabel ! talk 20:42, 19 December 2025 (UTC)

• At one time we kept a list of examples where a Commons image was used by a mainstream media outlet, and the data was stored in "other versions=". I am not sure if that list exists anymore. --RAN (talk) 01:56, 20 December 2025 (UTC)
  • At least for images originally published on Commons, that would normally be done with {{Published}} on the talk page and optionally some subcat of Category:Commons as a media source on the page itself (though direct inclusions in Category:Commons as a media source are usually exactly the talk pages with {{Published}}, which adds that category as a side effect). - Jmabel ! talk 06:08, 20 December 2025 (UTC)

I usually put {{Also geograph}} in the "other versions" field, so I think this is a reasonable use of the field. --bjh21 (talk) 02:06, 20 December 2025 (UTC)

The values of 'other versions' are so various and unstructured, that I'm not sure it matters too much, there's not enough of a standard to know that it's always e.g. only a list of derivative files of the current one. So I'd say links to external usages (or other databases it appears in, perhaps) would be okay. I've been using 'other versions' for little galleries of the other pages in a letter, for example, as well as other crops of an image. I'm not sure if that's groovy or not though. Sam Wilson 04:28, 20 December 2025 (UTC)

When we get an image from Flickr (and it's not from an active Commons user who happens to have uploaded first to Flickr as a convenience), I seriously question the value of us tracking other pages that also attribute that same Flickr user. It adds nothing to what we know about the provenance of the photo. - Jmabel ! talk 06:10, 20 December 2025 (UTC)

Writing a bot

Hello, I having an idea of a bot, here how it works:

1. Get a files (SDC) where this match:

creator (P170)	some value edit Wikimedia username (P4174) <value here> 0 references add reference
		add value

Then change the "some value" to a item that have the same value of Wikimedia username (P4174) in the qualifer.

Could it be possible, even this type of statement match around ~40 million files? DinhHuy2010 (talk) 03:21, 17 December 2025 (UTC)

Can you explain what you're specifically trying to accomplish here? Omphalographer (talk) 03:51, 17 December 2025 (UTC)

Replace the "some value" with a item.

That item must have the same value of Wikimedia username (P4174) with the qualifer

Useful I guess for tracking purpose? DinhHuy2010 (talk) 03:58, 17 December 2025 (UTC)

@DinhHuy2010: I don't see what you think would be more useful, but that may be because I don't see what you are actually proposing. creator (P170) cannot take a string for a value; either you are ignoring that, or your wording is unclear. If the latter, could you show with a {{Statement}} what you propose this should end up looking like? - Jmabel ! talk 06:24, 17 December 2025 (UTC)

@Jmabel

For example, for Jimbo Wales

Before:

creator (P170) some value / Wikimedia username (P4174) Jimbo Wales

After:

creator (P170) Jimmy Wales (Q181) / Wikimedia username (P4174) Jimbo Wales

Either overwrite the statements or create a new statement and mark as preffered and the old statement as deprecated. DinhHuy2010 (talk) 06:48, 17 December 2025 (UTC)

So do this only if there is a Wikidata item for that user? I believe this has been proposed before, and there were people who had Wikidata items but did not want their Wikidata item tied that closely to their activity as a user. And, of course, most users do not have Wikidata items, and probably (in my view at least) shouldn't. - Jmabel ! talk 07:17, 17 December 2025 (UTC)

@Jmabel, proposed before? What does that mean?

Also "And, of course, most users do not have Wikidata items, and probably (in my view at least) shouldn't." does this mean?

Should I continuing to do this anyway? DinhHuy2010 (talk) 07:29, 17 December 2025 (UTC)

This is nothing we can decide on Commons. The rules for items for people are defined in the Wikidata notability policy. This does not include even the most active contributors here unless they have an identifier in external databases. It was discussed to have some kind U-items for users but the implementation was never discussed further. GPSLeo (talk) 09:04, 17 December 2025 (UTC)

I think the obvious solution here is to only do it for people with wikimedia username field set on their wikidata item. If someone doesnt want the association known then i guess it is their responsibility to make sure the association isnt set at wikidata. Bawolff (talk) 17:44, 17 December 2025 (UTC)

@DinhHuy2010: I'm not sure what is unclear to you about my meaning, but I'll try being more verbose. (1) This is not the first time that someone has proposed making this substitution; last time I saw it proposed, several users who have Wikidata items indicated that they would not want their Wikimedia account tied to their real-world identity. (2) The majority of people who upload photos here do not have Wikidata items for themselves as individuals and I believe that is entirely appropriate. Your example works only because Jimmy Wales (Q181) exists for Jimbo. To make this work in general, you have to have a Wikimedia item for every user who uploads. Or maybe the answer to your first question is "yes, do this only if there is a Wikidata item for that user and it is already tied to their account," in which case the rest of what I said is largely moot, though it does raise a different question: if there is a Wikidata item about you, is it possible to opt out of having your account tied to that Wikidata item, if someone else has a citation to document that you are the same person? - Jmabel ! talk 21:37, 17 December 2025 (UTC)

If the user has P4174 set they are already effectively connected. I certainly wouldn't advocate adding that to non-notable people against their will, but i feel like once its set the person is connected. Wanting to not be associated after that point is like uploading an image to commons but demanding it not be used on Wikipedia (to be clear, i dont know specificly what DinhHuy2010 is advocating for, but i would only advocate doing this for people who have an existing wikidata item with P4174 set, leaving the rest to use blank nodes (some value) as they currently do.) Bawolff (talk) 00:08, 18 December 2025 (UTC)

once its set the person is connected: so Commons:Harassment#Posting of personal information would not apply here? That seems wrong to me. - Jmabel ! talk 01:12, 18 December 2025 (UTC)

If someone posts personal information on their user page on another projet, and then it gets an interlanguage link from commons, is that a violation of the policy? As written technically maybe, but i think most people would think that is rediculous. I think this is a similar situation. Note that wikidata does have a policy (according to usage instructions at d:Property:P4174) that using the property to out people at wikidata will result in a block, so it shouldn't have personal information against people's wills. I think its important to respect people's privacy, but if they've voluntarily disclosed it on a wikimedia project, i dont see anything wrong with linking to it. Bawolff (talk) 03:35, 18 December 2025 (UTC)

This has been one of my pet peeves of SDC for a long time. Doing this not only makes sense for how commons ontology is set out, it also makes queries (especially aggregating queries) much more performant on blazegraph. So i think this is a really good idea. Bawolff (talk) 17:42, 17 December 2025 (UTC)

Category:Burials

for example Category:Burials at the Congressional Cemetery.

i think it makes sense to categorise graves/tombs of persons under a cemetery, but not the categories of those persons. RoyZuo (talk) 18:41, 17 December 2025 (UTC)

So you're thinking we shouldn't have categories for where people are buried, only categories like Category:Graves at the Congressional Cemetery that show the actual graves? I guess I can see that, because Commons deals with images, not abstract information. Maybe this is something that was carried over from Wikipedia. -- Auntof6 (talk) 20:39, 17 December 2025 (UTC)

 Support - yes, and those photos can be categorized under the person who's buried there, or under a dedicated category for their gravesite if there's many photos of that subject. Abstract relationships like "where is this person buried" don't need to be represented by Commons categories; Wikidata does a better job of that. Omphalographer (talk) 20:58, 17 December 2025 (UTC)

 Support. I think CfD is a better avenue to discuss this though (crossposted to the Village Pump to get more participants), rather than the other way around. --ReneeWrites (talk) 20:04, 18 December 2025 (UTC)

 Oppose - I favor keeping both.

I note that are many "unmarked" burials at most cemeteries. There usually no photos where no markers or gravestone exists, but there lay the person's buried remains. Some people never get a marker, inexpensive wood markers disintegrated over time, stone markers sink under the ground suface and common vandalism breaks markers- the pieces disgarded or even outright theft of the markers themselves.

For example, the Lone Fir Cemetery, "has an estimated 10,000 unmarked graves out of the approximately 25,000 persons."

The former Monument Cemetery of Philadelphia was obliterated and "approximately 28,000 bodies were reinterred to Lawnview Memorial Park but only 300 with their original tombstones." and "most of the reinterments were placed in a mass grave." -- Ooligan (talk) 06:11, 20 December 2025 (UTC)

Is that going to come up at all often for people notable enough to have Commons categories (that we know what cemetery they are buried in, but their grave is not marked)? - Jmabel ! talk 20:05, 20 December 2025 (UTC)

 Oppose Are we going to ensure that the data is already at Wikidata before losing the info? Are we going to create Wikidata entries for those without one? Are we going to create "Category:Grave of ..." for every image of a tombstone that we have? --RAN (talk) 03:29, 19 December 2025 (UTC)

I would say "maybe" to creating the categories. We don't necessarily need a separate category for every grave, especially if we have only one image for it. -- Auntof6 (talk) 03:35, 19 December 2025 (UTC)

If we have a category for the person, a photo of their grave (or a category if there's enough photos) can be placed both in the person's category, and in a "graves at the XYZ cemetery" category. There isn't necessarily any need for a separate category to link the people to the cemetery. Omphalographer (talk) 22:22, 19 December 2025 (UTC)

 Comment mixed feelings on this. We have some large and longstanding categories like Category:Burials at Hollywood Forever Cemetery and the enormous Category:Burials at the Père-Lachaise Cemetery. It would be a very large project to change how this has been done, especially if we wanted to make sure information is not lost. Perhaps the correct question is: how important does a cemetery have to be before it is worth noting in the category for a person that they are buried there. (For the record, as far as I know, in Seattle where I live we haven't done this for any of the cemeteries; instead we have categories like Category:Gravesite of Bruce and Brandon Lee and Category:Lake View Cemetery, Seattle - Leary-Ferry family plot.) - Jmabel ! talk 20:52, 19 December 2025 (UTC)

how important does a cemetery have to be before it is worth noting in the category for a person that they are buried there. There are cemeteries that are designated cultural heritage sites, with many of the graves there being cultural heritage monuments (e.g. Category:Novodevichy cemetery (Moscow)). Now, if a country has no Commons-compatible FoP for sculptures (which includes tombstones) then our only way to point to notable graves on that cemetery is by having a category for "Burials at cemetery X", because any category of the type "Grave of Famous Person X" would get deleted for being an empty category (after its contents would have gotten deleted for copyvio due to lack of FoP). Nakonana (talk) 13:08, 20 December 2025 (UTC)

@Nakonana: but then what does that have to do with Commons? (Not a rhetorical question.) It seems to me not to be Commons' job to track every available fact about a person any more than it is Wikidata's or Wikipedia's job to track every known image of them. - Jmabel ! talk 20:09, 20 December 2025 (UTC)

I'd say that Commons wants photos of those people's graves because they are cultural heritage monuments. So, if I go to that cemetery to take some CC photos it would be handy to have a list of people/graves of interest in form of a category with names. Even if I can't upload those photos to Commons for now, I could still upload them to Wikipedia or Wikivoyage from where they can then be transferred to Commons once the copyright of the sculptures expire. Nakonana (talk) 22:49, 20 December 2025 (UTC)

 Comment - A broad overview, Category:Burials in the United States by cemetery

These sub-categories are heavily populated from Arlington National Cemetery -

• Category:Graves at Arlington National Cemetery
• Category:Burials_at_Arlington_National_Cemetery

I would like to see a broader discussion reaching many more potential participants. --Ooligan (talk) 04:34, 20 December 2025 (UTC)

In response to some comments worrying about information being lost if these categories are deleted, these are mirror categories of the English Wikipedia (e.g. en:Category:Burials at Hollywood Forever Cemetery and en:Category:Burials at the Congressional Cemetery). Wikipedia (and Wikidata) is far more suited to categorizing information in this manner than Commons. --ReneeWrites (talk) 10:51, 21 December 2025 (UTC)

users can also set place of burial (P119), e.g. Honoré de Balzac.

most persons' categories contain mostly files unrelated to the cemetery. that's why i think it's a bad idea to make cat tree based on this relation. setting p119 is good enough and better than making commons cat trees for this. RoyZuo (talk) 12:23, 21 December 2025 (UTC)

I agree. Though another solution worth considering is moving this information to a gallery. If P119 is set appropriately for everyone the page could be maintained by ListeriaBot. ReneeWrites (talk) 15:38, 21 December 2025 (UTC)

I made an example gallery here. ReneeWrites (talk) 18:01, 21 December 2025 (UTC)

December 18

Small question

How can I delete one of my contributions? Benzekre (talk) 10:57, 18 December 2025 (UTC)

It depends on which type of contribution…an edit, or an upload, or an upload of a new or prior file revision, or a recent upload. Prototyperspective (talk) 15:26, 18 December 2025 (UTC)

@Benzekre: if, as I suspect, you are asking how to get a recently uploaded file deleted, you can tag it with {{SD|G7}}, and it will almost certainly be deleted. This is further explained at Template:My bad upload, if you want to understand a little better. If you are asking something else, then you'll have to be more specific. - Jmabel ! talk 21:21, 18 December 2025 (UTC)

Continuing notifications problem

I filed a deletion request just now, and I was subscribed to the whole December 18 deletion request page rather than just my own deletion request. This was posted here a couple weeks ago, but is still a problem. Geoffroi 18:13, 18 December 2025 (UTC)

See Commons:Village pump#Notifications. It's probably not something that can be solved on Commons's end. Nakonana (talk) 18:45, 18 December 2025 (UTC)

Would it help if I added Commons:Deletion requests to muted pages in notification preferences? Geoffroi 19:18, 18 December 2025 (UTC)

Probably not, because that isn't the page which the notifications stem from - it's the daily subpages like Commons:Deletion requests/2025/12/18. Omphalographer (talk) 19:56, 18 December 2025 (UTC)

December 20

Epstein Files

As we know, a lot of his stuff has been dropped since February by the DOJ and the House Oversight Committee but we have only catalogued like 5% of it at the very best and the likely chance of a lot more dropping within the next few weeks, is it possible to have a bot download it all and catalogue it, "Epstein Library" might be the first place to start as a lot of files have dropped under "DOJ Disclosures" in PDF Format, can't trust the current US government, they might delete it all one day and we might become the only resource for it..we have bots that upload US Government stuff from flickr, NASA and DHS, maybe they can do it for DOJ too...--Stemoc 03:04, 20 December 2025 (UTC)

Most of these files are not free as they are from third parties. GPSLeo (talk) 06:22, 20 December 2025 (UTC)

Ugh, a lot of unfree files are already in Category:Epstein Files, and no doubt more will be placed there by well-intentioned people who don't know better. That category needs cleanup and watching. Is there a boilerplate notice we can place on the top of the category that says "Federal agents touching a document created by someone else does not magically turn it free" (but in a nice and friendly way)? --Animalparty (talk) 07:29, 20 December 2025 (UTC)

technically, they are free as they belong to a dead sex offender who has no rights to them anymore and thus falls under the jurisdiction of the DOJ who can choose to release them and they have...sure some images may not be free and can be removed but any involving Epstein not taken by a professional photographer which belongs to him or has been taken by the DOJ/FBI are free and can be released, its a matter for us to figure out which are which, and categorise them accordingly and i know its tricky, but its better than the alternative which is to nominate every image added from the released documents for deletion which will set a bad precedent, thus why its better if we do it ourselves, via a bot or something then weed out those not free cause the amount of images that might get released will be harder to control if everybody decides to upload them here themselves..Food for Thought... Stemoc 08:30, 20 December 2025 (UTC)

These are evidences from court cases. Such content is always still in the copyright of the original copyright holder. I do not think the witnesses made copyright transfer contracts with the government agencies. GPSLeo (talk) 08:34, 20 December 2025 (UTC)

I'm with GPSLeo here. Assuming the "dead sex offender" in question is Epstein, he was never stripped of copyright ownerships, and those would be inherited by his estate; I don't know the terms of settlement of that estate, but I assume it is currently wrapped up in a lot of lawsuits. When the DOJ seizes a copy of a photo, or seizes a document, that has no effect on copyright.

Further, the copyright of ever piece of non-trivial incoming correspondence in that file would belong to the person who wrote it, not to Epstein. - Jmabel ! talk 20:14, 20 December 2025 (UTC)

• Being dead has never been a criterion for automatic loss of copyright; indeed in much of the world copyright extends for several decades beyond the author's death. Nor does being arrested or having property confiscated by law enforcement or federal employees waive copyrights (and for that matter nor does content merely being hosted or posted in a federal institution or government website). It's pretty clear that File:E HOUSE OVERSIGHT 065659 Clean - Copy.jpg for instance was not taken by Epstein and near certain to not have been created by a federal employee during their official duties (seizing, categorizing and posting a photo is not creation). --Animalparty (talk) 01:26, 22 December 2025 (UTC)

• They have been "made public" (copyright term begins, or published), but being made public is not the same as "public domain" (copyright term ended). In the past the US government has seized copyrights and patents during wartimes, but not in this case. --RAN (talk) 22:43, 20 December 2025 (UTC)
• We should really have a large, conspicuous warning template similar to {{NoUploads}} to place at the top of every Epstein category that clearly explains why a snapshot found in Epstein's drawers or phone is not a US government work, to help stem the flow of new uploads after every new batch of releases. There are now at least two batch deletion discussions (Commons:Deletion requests/Files in Category:Epstein Files and Commons:Deletion requests/Files in Category:Jeffrey Epstein, and recent uploads (like this one) that are not currently nominated but should be. --Animalparty (talk) 03:41, 24 December 2025 (UTC)

  I added a warning to the category. GPSLeo (talk) 11:00, 24 December 2025 (UTC)

Category:Photographs by year

Why are photographs by year hidden categories, when Category:Black and white photographs by year are not? Rathfelder (talk) 20:55, 20 December 2025 (UTC)

December 21

Photo challenge October results

Freight cars: Entries • Votes • Scores

Rank	1	2	3
image
Title	Assembly train at the construction site of the new Nuremberg-Ebensfeld line	Freight train near Eltmann	Грузовые поезда в России 2H1A5430WI
Author	Ermell	Ermell	Kora27
Score	13	12	10

Dyeing: Entries • Votes • Scores

Rank	1	2	3
image
Title	Tanneries. Large open-air vats of color dyes with tannery workers amongst them in Fez	Tanneries. Large open-air vats of color dyes with tannery workers amongst them in Fez	mit blauer Tinte gefärbte Rose rose colored with blue ink
Author	Wowan1978	Wowan1978	Pedemann
Score	25	16	10

Congratulations to Ermell, Kora27, Wowan1978 and Pedemann. - Jarekt (talk) 05:31, 21 December 2025 (UTC)

Congrats.

There is an open RfC about the photo challenges – maybe some people here could participate:

RfC: Should deleted images in the results posts be replaced with the next rank?. For an example see Photo challenge: Bark – results.
Prototyperspective (talk) 15:43, 21 December 2025 (UTC)

YouTube moved to CC BY version number 4.0

YouTube changed the CC attribution license to version 4.0 (see: https://support.google.com/youtube/answer/2797468). Anyway, Video2Commons still uses the version 3.0 template (as seen here: File:GgT & kgV mit PFZ & Hasse (Christian Spannagel).webm. It should be updated (for new videos) --PantheraLeo1359531 😺 (talk) 11:32, 21 December 2025 (UTC)

I think the better place to ask about this probably would be Commons talk:Video2commons and https://github.com/toolforge/video2commons/issues/. An issue is correcting the videos that have the wrong license version set retrospectively for prior uploads -> see Commons:Village pump/Technical. Prototyperspective (talk) 15:33, 21 December 2025 (UTC)

Files tagged with both self and PD-US

• {{Self}} and {{PD-US}}

Should we have a filter against this? These licenses are almost always frivolous. --Trade (talk) 23:21, 21 December 2025 (UTC)

I've moved the template links to below the section title as they were breaking the section linking. "Almost always" is not never, so you would need to be careful with how you implement a filter. For example, {{Licensed-PD}} is a legitimate case where you could find both tags on the same page and that template has 31,506 transclusions. From Hill To Shore (talk) 23:35, 21 December 2025 (UTC)

Somehow i doubt there are many editors who upload photos they took before January 1, 1930 Trade (talk) 23:49, 21 December 2025 (UTC)

Your reply suggests that you don't understand the purpose of {{Licensed-PD}}. Here is one example, File:Pieter Boel, Dead Game Guarded by Two Dogs-2.JPG. From Hill To Shore (talk) 00:01, 22 December 2025 (UTC)

Doesnt mean everyone uses it for photographs of paintings Trade (talk) 00:36, 22 December 2025 (UTC)

From Hill To Shore wasn't saying it is always legitimate, just that it is sometimes legitimate. As it happens, my latest upload as of this moment legitimately uses both {{PD-US-expired}} (twice, for different works of art) and {{Self}}. - Jmabel ! talk 02:44, 22 December 2025 (UTC)

December 22

Are we starting to misunderstand the point of license reviewing?

I've been going through the requests for people to become license reviewers and noticed how extremely stringent people are about ensuring that a person understands every nuance of copyright law before they can be a license reviewer. Sometimes presenting massive lists for prospective reviewers to go through and show they understand copyright violations, and then still failing them anyway when they get them all right because people are skeptical that they "really" get copyright law.

The point of being a license reviewer is not supposed to be that you certify that an item is 100% free of copyright violations. It is supposed to be that you have confirmed it was uploaded under another license elsewhere, as a record to prove that it was available in case the item is later deleted or the license is changed.

For more evidenced rationale, consider that we created the FlickrReviewerBot to do this with Flickr uploads. Basically create an instant record of proof in case the item is later modified or deleted. It has no ability to evaluate if the upload is a copyright violation. Similarly, we don't require every upload to be reviewed. Someone could just as easily upload the same copyright violation here under a creative commons license, and it would never need a license review at all.

I think we should really reconsider what we expect of license reviewers. Considering we have such a massive backlog of items needing a review, our current system clearly isn't working. This isn't saying we allow copyright violations, others can still nominate an item for deletion (including the license reviewer themself), but rather that we should expect a license reviewer to do what their name says: just review that it was uploaded under the correct license, not catch every copyvio. Aplucas0703 (talk) 17:25, 22 December 2025 (UTC)

As one of the people who is engaged in inventing test questions for prospective license reviewers: You, Aplucas0703 rightly noticed a huge lack of manpower. But I steadfastly think that moving on to reduce the expectations about LR work is a wrong move, simply shifting the issues downstream.

We must be lucky in that a small amount of files get a human review at all, so, when a reviewer actually touches a file, nobody can think that that file will get looked at again after them. So, this unique check has to be thorough, encompassing observances of COM:FOP, COM:TOO, legitimate derivatives, AI slop and Commons' scope. Especially the first 2 points, being copyright-related, entail the need for sufficiently deep knowledge about the subjects.

Making human reviewers do the same thing as the Flickr review bot, mechanically confirming licenses and disregarding other circumstances, is factually advocating for deliberately neglecting copyvios. Regards, Grand-Duc (talk) 18:37, 22 December 2025 (UTC)

I partly agree that this somewhat advocates for neglecting copyvios, but only in the if we were already reviewing all of the files needing a license review. The fact that they aren't being reviewed right now essentially means that we've decided to both neglect copyvios and neglect license reviews. I think this argument is fine in an ideal situation where the license reviews have a very small backlog and are easily maintained by current reviewers.

If these license reviews are so incredibly valuable for checking for copyvios, then we should deactivate the Flickr reviewer bot by the same logic.

Your argument really only works if we're maintaining our current backlog, which we aren't. We're neglecting copyvios either way, it's just that now we've decided to also neglect license reviewing. I tagged an image I uploaded for a license review almost 2 years ago. No review yet. Aplucas0703 (talk) 20:26, 22 December 2025 (UTC)

There was an incomplete template in File:Kalen Allen in 2017.png, it somehow lacked the video ID. I fixed that while making the review, Special:Diff/1129644856/1135218179; but such incomplete review templates may deter some reviewers.

We're IMO not neglecting copyvios by letting a backlog grow, as the marking of an outstanding review signalises that a check is assumed necessary but not done yet. So, any copyvio hidden in that backlog is not neglected, but simply unknown (that is an important caveat, as any hosting provider privilege or DMCA-style laws usually requires previous knowledge of violations to make someone liable for them). Regards, Grand-Duc (talk) 21:51, 22 December 2025 (UTC)

No wonder that the backlogs grew... I just spend nearly half an hour while reviewing only 3 files from assumed problematic queues (tasks and reasons in parentheses):

• File:1969 - làng tị nạn người Thượng (9680602234).jpg (translating the file name, thinking, wording a DR)
• File:17th Field Ambulance with horse drawn ambulances World War I (48114647937).jpg (trying to identify the unit with Google, thinking about the case, deciding that it's likely a British unit based upon my googling, researching the correct Crown Copyright tag)
• File:(V-2) rocket engines in an assembly workshop at the Mittelwerke underground secret factory in a mountain range near Nordhause 1944. (48479649481).jpg (looking up potentially relevant tags, in that case, the {{PD-US-alien property}} of which I knew the existence but not the exact spelling. In fact, Google was faster than going through the tag categories by myself... Still, sent it to DR for quality assurance)

Then, there's a huge backlog of audio and video files that you just can't review everywhere, as you need to actually hear the audio. And it's time consuming too, you can't make a sound check (pun not intended...) without going to several positions in the multimedia file (to catch possibly protected background or stage decorations or protected audio not perceptible at the file's beginning).

These examples may serve why license reviewers must have a good understanding of these reviewing tasks and copyrights. Regards, Grand-Duc (talk) 23:02, 22 December 2025 (UTC)

I think these are perhaps good reasons to rethink it. The fact that we basically expect license reviewers to sit down and listen to hour long audio clips before doing what they're actually supposed to -- check that it was uploaded under the correct license -- is contributing to this insane backlog that is inhibiting the purpose of license reviews: to verify that it was uploaded under that license as a record for if the file is later deleted or changed at the external site.

So far, there has been nothing to address the main concern, which is that we are neglecting the core purpose of license reviews by creating such an intense process. Aplucas0703 (talk) 23:39, 22 December 2025 (UTC)

So, what is constituting a correct license to you, Aplucas0703? In my opinion, that is one where the licensor did not ignore foreign copyrights, as otherwise, that license would be null and void for (parts of) the uploaded media. And with that, we're back to the expectation of listening to longer audio excerpts while doing reviews... And yes, bots like the one for Flickr or iNaturalist don't do that (and that's both not good and unavoidable), but it's absolutely no reason to make humans, who HAVE the technical ability to do deeper checks, behave like bots. Regards, Grand-Duc (talk) 23:55, 22 December 2025 (UTC)

There is a reason to allow humans to act more like these bots. From my comment you replied to: So far, there has been nothing to address the main concern, which is that we are neglecting the core purpose of license reviews by creating such an intense process. Aplucas0703 (talk) 00:06, 23 December 2025 (UTC)

It would really help if the YouTubereview bot were to be fixed--Trade (talk) 00:51, 23 December 2025 (UTC)

The license review is most often the single moment when a file gets actually seen by a human. It's a totally bad idea to remove mostly every chance at copyvio checks for the sake of reducing backlogs, as the "core purpose" of reviewing licenses is to guarantee valid licensing terms. Reducing backlogs may rather be undertaken by reducing the amount of uploads in need of license reviews, that could be done e.g. by throttling the uploads, either by a fixed amount per day (the site unlocks X token at 00:00 UTC, whenever that amount of token is used up on a first come, first served principle, no new uploads to be reviewed will be possible until next midnight) or by a relationship to the actual backlog (similar to what some torrent sites do with a need of having a positive upload ratio to continue downloading) and/or by restricting the use of automated tools and imports. Don't tackle the symptoms (backlogs) by introducing measures designed to reduce the work quality, tackle the causes (lack of manpower, too large amounts of uploads for the available crew). Regards, Grand-Duc (talk) 01:04, 23 December 2025 (UTC)

For what it's worth, I agree with Aplucas0703. A more in-depth review is always welcome and often necessary, but the license review process should be straightforward and not require more than checking whether a work is actually licensed under the given license at the source. Whether the licensor has actually licensed the work correctly; whether they had the right to do so etc. - that can be a complex question, but shouldn't be part of the basic license review. The license review is a first step, an important step. But if it were meant to encompass a full review of the copyright situation of any given file, we certainly wouldn't have the manpower to prevent an ever-growing backlog. Gestumblindi (talk) 00:56, 23 December 2025 (UTC)

The license reviewed template also doesn't say anything other than "X has checked that file was available at source website under the stated license". Nakonana (talk) 22:09, 23 December 2025 (UTC)

And I think that's really the crux of the issue too! It just seems like we're expecting way too much. I did the math on this, given the large size of our backlog, it would take a collective 43 working years to review all files, if each license review took just 3 minutes. We're making this worse by restricting the license reviewer right and by making the job of current license reviewers more intense. I think maybe we should codify in policy for the user right that it is NOT a "copyright reviewer" and should only be expected to review the actual license, given the following:

• User still shows a basic understanding of copyright law by not showing unreformed uploading of copyright violations (early mistakes considered but not disqualifying if reformed).
• User understands the process of searching for license and that they should ensure the listed license is the exact license which it is available under.
• User understands the deletion process and how to nominate for deletion a file they believe failed a license review.
• User shows trustworthiness and general experience. Aplucas0703 (talk) 22:53, 23 December 2025 (UTC)

@Nakonana: But if any license was fraudulently applied at any source, then a file affixed with such a license was never rightfully available with that license. So checking the availability means always a copyright check. Regards, Grand-Duc (talk) 23:09, 23 December 2025 (UTC)

Of course, but the community can always check that by nominating for deletion. Many licenses are fraudulently applied on Wikimedia Commons all the time, but we have editors patrol random and new files for that purpose. Aplucas0703 (talk) 23:54, 23 December 2025 (UTC)

Might there be a "happy spot" somewhere between? Nakonana and Aplucas0703 certainly have a point, but I'd still like to see human reviewers be people we would trust to do better than a bot here. I would hope they would at least be capable over time of spotting "bad" sources we should not trust and help build up a blacklist of these. (Also: license reviewers have all the rights of patrollers, so unless we are going to change that, they need to be at least qualified as patrollers.) - Jmabel ! talk 02:28, 24 December 2025 (UTC)

I think this is pretty balanced. Maybe just that we don't expect literal perfection in copyright knowledge (like someone being expected to know every Freedom of Panorama law), and ideally knowing also how to spot very obvious copyright violations and add them to the list (like understanding that a random upload of a clip from CNN is not eligible, but not expecting them to know that light shows of the Eiffel Tower filmed at night aren't eligible).

Or maybe we should restrict the rights of license reviewers to be more tailored to this task. Is there a technical reason they need the rights of patrollers rather than just assigning the patroller right individually? In that case we could enroll all current license reviewers in with the patroller right and then restrict the actual license review rights for new requesters. Just some ideas because I'm not the most aware person of how all these things work. Aplucas0703 (talk) 02:38, 24 December 2025 (UTC)

I also agree with Aplucas0703. We have a huge backlog of files needing license review. We should grant this privilege to anyone with half a brain, and kick the harder cases downstream if necessary. Nosferattus (talk) 23:12, 24 December 2025 (UTC)

History maps of Europe

Hi, I would like to discuss the description in all categories of the scheme "Maps of <country> in the <x>th century" (see for example Italy, Belgium, Spain, Poland). There are three different points about the current system I would like to invite comments on:

• the wording of the definition in the first paragraph of the hatnote
• whether or not to include "you may also be looking for similar maps" (second and third paragraph) of the description
• whether or not to re-include a distinction between history maps (in this category group) vs. old maps (not in this category group)

For the first point, there are two proposals, the first is the current "Maps showing all or most of the territory (geographic area) of modern-day <country> - as the lands were in the 8th century (701-800 CE)" which I would prefer to replace with a simple "This category is about maps of the history of <country> in the 8th century (701-800 CE)", given that "modern-day territories" are not always the same as they were in the respective century. Another critism of mine is that "all or most" excludes history maps that only cover smaller parts of the country in question.

For the second point, my argument is that these paragraphs are not necessary, since the links to the Atlas project should be included in the respective parent category (i.e. "Maps of the history of <country>"), which is also linked via template.

For the third point, I find it essential to point out that Commons has always distinguished "current", "history" and "old" maps, formulated in Template:TFOMC: "history" maps include this map of Poland in the 16th century (created recently, depicting the past) but "old" maps include this 16th-century map of Poland (created to depict the present, back then). There are certain grey areas where these categories DO overlap, especially "old history maps", but in quite many cases they don't. The respective category names are quite similar and can be confused, so I would suggest to mention this right in the category description.

I've put my own opinion in italics to explain why I think this requires debate, but I would like for people to check out the scheme examples for themselves, and judge on their own. Peace, --Enyavar (talk) 20:05, 22 December 2025 (UTC)

Category Sorting Question

I'm trying to sort photos of train locomotives and stumbled upon essentially duplicate categories. Category:GMD F40PH-2 locomotives of Via Rail and Category:GMD F40PH-3 locomotives of Via Rail both exist. I looked into this and apparently, the official designation is 'F40PH-2' not 'F40PH-3'. According to official VIA Rail sources, and Wikipedia ([1][2][3]) Since the name appears to be unofficial and more of a 'railfan' thing, ([4][5][6]) should I just go ahead and merge/delete the wrong category? Just need a second opinion. PascalHD (talk) 21:26, 22 December 2025 (UTC)

Things like this are (usually) decided via Commons:Categories for discussion. (A problem is that too few users participate in these so it can take years until things get solved but I see no special urgency in this case and maybe you get it solved within days.) Prototyperspective (talk) 23:15, 22 December 2025 (UTC)

 Agree with Proto that CfD is a better avenue to discuss this. ReneeWrites (talk) 01:54, 23 December 2025 (UTC)

Possible 20 year hoax for images relating to 1896 and 1906 Olympic / Intercalated Games

File:1896 Olympic opening ceremony.jpg uploaded to Commons in 2005 has almost the exact same image composition as File:Aspiotis Olympics 1906 Royal Address.jpg which was uploaded to Commons in 2023. Title and description of the first image claims to be from the 1896 Olympics, but the second image is a postcard claiming to be from the 1906 Olympic / Intercalated games. I attempted to research this image but found additional claims of disputed dates on this YouTube video's title and description. I believe this should be investigated further by someone more involved on Commons than myself. Cards84664 (talk) 23:34, 22 December 2025 (UTC)

Yes, I agree they are the same moment in time. The 1906 explanation is better. The people behind the speaker match the 1906 committee members. Also prince Andrew was only 4 years old in 1896 so I would say this is 1906. I will have a look at what needs to be done. All the best, Taketa (talk) 03:49, 23 December 2025 (UTC)

PS: I found this Youtube video of the 1906 opening [7]. Imho the people standing in line can be found in the video. The people in line all the way on the left, front row with the white clothes a threecolor ribbon and black pants are the same as the video at 4:21. The people in white on the left second line with white hats I believe to be women and they are in the video at 4:04 (note women did not participate in 1896). The man in line first row 5th from the right with the white pants, stick and hat seems to match the man at 3:28. All the best, Taketa (talk) 04:51, 23 December 2025 (UTC)

@Taketa: Two more that might possibly be wrong: File:Le stade olympique en 1896.jpg and File:Le stade panathénaïque en 1896.jpg. Note the Propylaea is present in the first two images, compared to these two: File:Le stade panathénaique d'Athènes en 1896.jpg and File:Games of the I Olympiad, Panathenaic Stadium, Athens, Greece - DPLA - 8c8f5be2734a5c18237a4c2b9a730e69.jpg. I've seen claims that the Propylaea wasn't built until 1906. Cards84664 (talk) 16:04, 23 December 2025 (UTC)

When correcting titles and descriptions, please correct the structured data as well. Nosferattus (talk) 00:05, 25 December 2025 (UTC)

December 23

{{PD-USGov}}

Would anyone mind if i changed the text to "work prepared by an officer or employee of the federal United States Government as part of that person’s official duties". Might help clear up misunderstandings Trade (talk) 01:43, 23 December 2025 (UTC)

Mostly agree, but the normal wording for that would be "United States federal government", not "federal United States Government". You wouldn't say "the state Massachusetts government" or "the city Boston government." - Jmabel ! talk 04:33, 23 December 2025 (UTC)

Sounds good to me (+1 for Jmabel's proposed wording). While we do already have the lengthy note clarifying that it only applies to the federal government, one additional word in the lead sentence won't hurt and will hopefully help anyone who just glances and doesn't read notes. ~Kevin Payravi (talk) 04:42, 23 December 2025 (UTC)

I agree with changing the wording as suggested by Jmabel to "United States federal government" for the added clarification. Seems like a good idea. Aplucas0703 (talk) 22:58, 23 December 2025 (UTC)

Trouble with API

Tracked in Phabricator
Task T413426

Today, it is very difficult to use the MediaWiki API. Error messages like this one appear very often:

3: internal_api_error_DBConnectionError: [3f07a4f7-86eb-4f28-b2d1-62d52c3fe10c] Caught exception of type Wikimedia\Rdbms\DBConnectionError at ...

Are the problems known? XRay 💬 10:56, 23 December 2025 (UTC)

@XRay There's an ongoing technical incident. See https://www.wikimediastatus.net/ It seems to mostly affect Commons and Wikidata. —TheDJ (talk • contribs) 10:58, 23 December 2025 (UTC)

Thanks for pointing that out. I had already guessed as much, but didn't know where to look. -- XRay 💬 11:13, 23 December 2025 (UTC)

(Reminder about Commons:Village pump/Technical) Prototyperspective (talk) 13:55, 23 December 2025 (UTC)

December 24

Problem using Google Lens en TinEye

Lately, I've been having a lot of problems with Google Lens and TinEye. I use them to check for potential copyright issues. An example is the image File:Gambar2-Panda.png. It then gives me a message like, "Oops, something didn't work! TinEye could not read that image URL." It also happens with JPG images, which I know haven't caused any problems in the past. Any idea what the cause might be? Wouter (talk) 11:48, 24 December 2025 (UTC)

@Wouterhagens Are you using the Reverse Image Search gadget, or are you manually inserting the link into TinEye/Google? Tvpuppy (talk) 16:47, 24 December 2025 (UTC)

I use the Image search gadget. Wouter (talk) 17:01, 24 December 2025 (UTC)

I checked and the gadget is not working for me too, it seems the thumbnail URL generated by the gadget doesn't work anymore. For example, for the image you linked above, the gadget generates this URL: /media/wikipedia/commons/thumb/4/43/Gambar2-Panda.png/300px-Gambar2-Panda.png. The image thumbnail is visible for this URL, but this URL doesn't work even when I manually insert it into TinEye/Google. So, the code for generating the URL probably needs to be updated. Thanks. Tvpuppy (talk) 19:32, 24 December 2025 (UTC)

"Photographs of"

A DR I started 9 days ago has gotten no attention, and I think it involves an important decision about category naming. I would ask if some more people can weigh in at Commons:Categories for discussion/2025/12/Category:Photographs of male screenwriters. - Jmabel ! talk 19:47, 24 December 2025 (UTC)