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

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.

Village pump in Sabah, Malaysia. [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 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)

  Ultimately unless files in the category actually starts getting deleted the warning is largely toothless Trade (talk) 22:10, 26 December 2025 (UTC)

  Closed the December 20th DR. Abzeronow (talk) 04:09, 28 December 2025 (UTC)

  Other DR closed too. Abzeronow (talk) 01:21, 4 January 2026 (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)

Wondering if we can try to establish some consensus on this proposal in some way or reach some mid-way agreement, probably by fully splitting patroller/image-reviewer rights (and then adding current members into both automatically). It's worth noting that admins, who also have this permission, aren't even expected to have a perfect understanding of copyright either, per our advice pages to them. Aplucas0703 (talk) 03:27, 31 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)

The other issue is that by the time a license reviewer finally gets to a file that needs license review the source link may be dead without an archive link being available. In such a case we are forced to delete a file just because the potentially valid license has not been reviewed in time. Nakonana (talk) 19:58, 25 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)

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)

For TinEye I found a workaround. When the page of TinEye comes with the “Oops”message replace the link after "https://tineye.com/search?url=" with the url of the fullsize of the image. For example /media/wikipedia/commons/6/62/2019-09-20_aardbeien.jpg. This results in https://tineye.com/search?url=/media/wikipedia/commons/6/62/2019-09-20_aardbeien.jpg and TinEye makes it into https://tineye.com/search/3e596fd0049887ea46404c6df8dd2c0fa4b94817?tags=&sort=size&order=desc&page=1. Wouter (talk) 09:52, 26 December 2025 (UTC)

I've been having the same issue now for several days in a row from the Reverse Image Search gadget. Looks like it needs a fix. Aplucas0703 (talk) 17:56, 26 December 2025 (UTC)

The image server no longer generates arbitrary widths of images like before. It only supports: 20, 40, 60, 120, 250, 330, 500, 960. So an interfaceadmin can probably replace the value of 300px with 330px and that should make the gadget work again. Technically it should use the api to generate the url, but, this will do for now. —TheDJ (talk • contribs) 20:32, 26 December 2025 (UTC)

I'm having the same problem right now with Google Lens and Tineye. How do I patrol for copyright violations? Geoffroi 20:26, 29 December 2025 (UTC)

Should still work with copy-paste into Google Lens. - Jmabel ! talk 22:41, 29 December 2025 (UTC)

Tried it. It didn't work. Geoffroi 22:48, 29 December 2025 (UTC)

December 26

How do I see structured data?

I often see updates to structured data, but I am confused by what it actually is and how to see it. How do I see it? Immanuelle ❤️💚💙 (please tag me) 19:27, 26 December 2025 (UTC)

@Immanuelle: Right below the image itself there are two tabs: "File information" which contains the caption, summary, license etc. and "Structured data" where metadata (usually but not always tied to Wikidata) is added to the image. This is a bit of an oversimplification, but the "File information" tab is designed to be readable for humans while "Structured data" is designed to be machine-readable. --ReneeWrites (talk) 21:03, 26 December 2025 (UTC)

Also, if you have JavaScript disabled, structured data will show up at the very bottom of the page instead. HyperAnd [talk] 08:59, 29 December 2025 (UTC)

Epstein files 2

You might or might now know but news shows that it's possible to remove the redactions used in many of the documents that have been released as part of the Epstein files

Question is, are we allowed to host these "unredacted" files on Commons or does that run afoul of Commons:PIP Trade (talk) 22:19, 26 December 2025 (UTC)

https://www.theguardian.com/us-news/2025/dec/23/epstein-unredacted-files-social-media Trade (talk) 00:35, 27 December 2025 (UTC)

If they are entirely authored by U.S. government employees in their professional capacity, then they are free of copyright. - Jmabel ! talk 00:51, 27 December 2025 (UTC)

As Jmabel says, if said files was created by an U.S. employee in the course of their duties, we can host it redacted or unredacted. But most of the Epstein files are not created by a government employee so for copyright reasons, we cannot host them on Commons. Abzeronow (talk) 01:37, 27 December 2025 (UTC)

What exactly does the Guardian article have to do with the photographs in the Epstein files? Trade (talk) 01:58, 27 December 2025 (UTC)

Either {{PD-US-GovEdict}} or {{PD-USGov}} will work. Images that will be out of copyright from the Epstein files will be extremely rare, redacted or unredacted. (Also, images are more likely to properly redacted than Word files, and I think the FBI redactions, unlike that of the Virgin Islands court, are more likely not easily removed.) In any case, first do no harm. If the redaction was protecting a victim, then it's not ethical to remove it and post it here.--Prosfilaes (talk) 07:54, 27 December 2025 (UTC)

So if it's not a victim then you will fully support hosting the file on Commons then? Trade (talk) 02:26, 4 January 2026 (UTC)

Only if the material was created by a U.S. federal employee acting within the scope of their official duties. Creation here means authorship, for example being the photographer, the writer, or otherwise the original creator of the work. The reason most photographs of victims are not acceptable is that they were generally not taken by U.S. federal government employees (as part of their duty). That does not imply that photographs of non-victims are automatically acceptable, only that, as a general matter, photographs of victims are unlikely to qualify as U.S. government works. --Jonatan Svensson Glad (talk) 02:40, 4 January 2026 (UTC)

...why do you keep changing the subject to photos when the article is about documents Trade (talk) 03:07, 4 January 2026 (UTC)

Sorry, I was following up on the earlier comments. The key issue is authorship. You need to determine which federal employee or agency created the document, regardless of whether it is text or images, and whether it was created as part of their official duties. Not everything authored by a federal employee qualifies. (For example, even if Trump had been a federal employee at the time, a personal birthday letter would not be a U.S. government work.) Some/most unredacted text documents may be acceptable on Commons, but any privacy question would need to be evaluated individually based on its value and scope. So no, nobody should ”fully support” anything without knowing the actual file/content in question. --Jonatan Svensson Glad (talk) 03:37, 4 January 2026 (UTC)

So you want each and every unredacted file someone wants to upload to be discussed before upload? Trade (talk) 04:28, 4 January 2026 (UTC)

You don't necessarily need to discuss everything before upload. But for any media you want to upload, be it images or documents or whatever, you yourself need to check that it is free of copyright and does not in any other way violate the law or the rights of other people. If you are sure, go ahead and upload it. If not, discuss or refrain from uploading. Kritzolina (talk) 07:48, 4 January 2026 (UTC)

December 28

Group portraits

I'm a little surprised to see that we rarely seem to have Category:Group portraits, Category:Group photographs, and Category:Group portrait photographs (and other analogous group portrait categories by medium) broken down into categories by the nature of the group (which would be orthogonal to most existing subcategories). The following is how I'd want to organize it (incorporating some existing categories). For simplicity's sake, I'm just expressing this in terms of subcats of Category:Group portraits; the others would be analogous (with Category:Group portrait photographs inheriting from both Category:Group portraits and Category:Group photographs). I'm posting here in case anyone either would want to help or sees something wrong with this scheme. The following is intended to be illustrative rather than exhaustive:

Category:Group portraits

Category:Group portraits by nature type of group (renamed per discussion below)

Category:Class portraits See discussion below; there was enough in place that was decent enough that I just reworked it minimally instead of doing it the way I would have done from scratch - Jmabel ! talk 22:39, 31 December 2025 (UTC). Using existing Category:Class photographs.

Category:Group portraits of clubs

Category:Group portraits of co-workers

We currently have Category:Group portraits of forestry workers in Europe, which appears to be implicitly group portrait photographs, and should be renamed accordingly. moved to Category:Group portrait photographs of forestry workers in Europe - Jmabel ! talk 06:51, 3 January 2026 (UTC)

Category:Family portraits (currently directly under Category:Group portrait photographs)

Category:Group portraits of royal families (currently directly under Category:Group portrait photographs)

Category:Group portraits of military units

Category:Portraits of musical groups (currently have Category:Portrait photographs of musical groups, but lack this level)

Category:Group portraits of politicians (currently have Category:Group portrait photographs of politicians but lack this level)

Category:Group portraits of governing bodies

Category:Regents group portraits (currently directly under Category:Group portrait photographs)

(somewhere under the photo side of this should be Category:Photos of the entire Seattle City Council currently not under Category:Group portraits at all)

• this might still be desired if there are enough such portraits, but I ended up handling these two categories differently for now. - Jmabel ! talk 22:13, 4 January 2026 (UTC)

Category:Group portraits of sports teams

Category:Wedding party formal portraits (currently directly under Category:Group portrait photographs)

For what it's worth, what started me thinking of this was not finding anything like Category:Group portraits of co-workers. We have a lot of group portrait photos that would belong under that. - Jmabel ! talk 02:55, 28 December 2025 (UTC)

I think Category:Group portraits by type is more in line with how we name categories (and sounds better), other than that I think this is a good idea. ReneeWrites (talk) 12:01, 28 December 2025 (UTC)

@ReneeWrites: maybe "…by type of group"? Because just "Group portraits by type" sounds like it might mean paintings vs. photographs, etc. - Jmabel ! talk 21:51, 28 December 2025 (UTC)

Good point, "by type of group" works too! ReneeWrites (talk) 23:46, 28 December 2025 (UTC)

How would Category:Class portraits be different from Category:Group portraits of students and/or Category:Class photographs? Nakonana (talk) 19:09, 29 December 2025 (UTC)

@Nakonana: It would be a subcategory of Category:Class photographs (thanks for finding that), excluding things like File:Milady in Brown 1909 (1909) (14758164426).jpg which are not group portraits. Category:Class photographs is currenty a subcat of Category:Group portraits of students; that is a bit of a mess because (as in the example I just gave) not everything in the former is a group portrait. So probably Category:Class photographs should be moved up the hierarchy, and Category:Class portraits should be the intersection of the two. - Jmabel ! talk 22:54, 29 December 2025 (UTC)

Actually, better Category:Class group portraits than Category:Class portraits. - Jmabel ! talk 06:44, 31 December 2025 (UTC)

Hmm. I just went through all the (categorized) class photographs. There are few enough montages that I think it is OK to treat Category:Class photographs in the hierarchy of group portraits, and just allow for the fact that a few are actually montages. Anyway, all the ones I found that are montages are now (also) in Category:Montages of classes and its one subclass. - Jmabel ! talk 07:58, 31 December 2025 (UTC)

It seems pretty clear that there is agreement on the general idea here. I'll make this one of my work areas. If some details change later, that won't be unusual. - Jmabel ! talk 06:37, 31 December 2025 (UTC)

"Location estimated"

What, actually, is the point of {{Location estimated}}? It sounds like it should be some sort of warning, but I would guess that locations estimated by an at all experienced Commons contributor using a map would be, on average, more accurate than the locations that we pull in from third-party sources or even the ones from most cell phone GPSs. And why don't we just handle this through a "source:" value in {{Location}} and its sibling templates? - Jmabel ! talk 07:05, 28 December 2025 (UTC)

The |prec= parameter of {{Location}} would probably be more useful and give better information (although I must admit that having a default value of 300mm feels a bit optimistic!). That a location may "be somewhat imprecise" (as {{Location estimated}} puts it) is not very informative. But perhaps it's good to have more of a call-out of the fact that someone's guessed at a location? Sam Wilson 07:51, 28 December 2025 (UTC)

Not having GPS in my camera, any of these that I do for my own photos are estimates, and while 300mm is a little ambitious, plenty of them are certain within 1.5m, and almost all within 10m unless it is something like going down a river in a boat. Whereas I've seen things supposedly done with GPS that were off by 100m or more, especially outside of cities, but even within (for example) Downtown Seattle: 100+ images all geotagged to the the same hotel: maybe where the person was when they uploaded? Who knows. - Jmabel ! talk 21:57, 28 December 2025 (UTC)

@Jmabel: Do you have perhaps 2 or 3 examples of such images tagged "to the same hotel"? Chances are that the photographer used a device that had its last GPS fix on that hotel; maybe there's a hint in the EXIF how the coordinates were calculated. Some geotaggers that can work with cameras may have a low processing power and no en:A-GPS, so that they take quite the time to produce a solid and accurate fix, getting confused by multiple signal reflections between buildings, for example. This is not so much an issue with smartphones due to their much higher powered CPU and their ability to also use WLAN and other positional references; in build-up areas, a precision in the order of magnitude of 10m is attainable, as those phones can often cope with GPS signal distortions. The thing with GPS being "off by 100m or more" most likely dates back to the time when the Pentagon deliberately downgraded the signal quality. It was either Clinton or Bush junior who made the decision to provide unaltered signals to the broader public. Scrambling the signal again would cause losses in the billions for logisticians and farmers among others, as they rely on differential GPS being precise down to 1,5cm (to guide combine harvesters and other heavy machinery on field tracks for instance), airlines and shipping companies would also suffer damages due to higher fuel costs if GPS would get downgraded. So, if a GPS-based position is off by more than 100m, then the device providing the location was either of computational low-power, lost the signal and reverted to a guestimation or the data was corrupted. Otherwise, you'd be better by a magnitude of 10 at least. Regards, Grand-Duc (talk) 22:36, 28 December 2025 (UTC)

It's still pretty common for geotags from modern devices to be 100m or more off, especially around hills or buildings. I suspect it occurs when the picture is taken quickly, before the device gets an accurate fix. For example, File:Air Line State Park Trail 12, Lebanon CT.jpg was taken with a late-model smartphone, yet had coords more than 1 km away from the actual location. Pi.1415926535 (talk) 23:00, 28 December 2025 (UTC)

@Grand-Duc: usually when I notice them, I do my best to fix them, so no handy examples. I see this mostly in photos batch-imported from other sites. I'm not sure why you need examples: if you are doubting this happens, I will do the work to find some; if you are just curious to see examples, that's pretty tangential to the issue I was raising here. - Jmabel ! talk 01:56, 29 December 2025 (UTC)

I asked for examples to have material to make a conjecture :

1. If coordinates are off and the camera does not have a GPS built in, it's worth checking the EXIF for an entry in a fitting field (software, makernotes or the like).
2. I imagine that some geotaggers write themselves somewhere into the non-standardised EXIF, beside providing coordinates.
3. If the camera does have an in-built GPS, then it's likely that the locating component was too slow in getting a fix.
4. If that is not given, but there's an actual batch from the same author with the same error ("street photography tagged to a hotel"), then it could maybe be possible to ask the author to fix them by himself.

-> So, yes, curiosity, but with some background thoughts. And I forgot that it's possible to switch off the background location tracking in any phone OS, so that modern phones too will have a delay in getting a good fix... Regards, Grand-Duc (talk) 02:12, 29 December 2025 (UTC)

As to the original question about the goal of the template: I think it has its best application in cases related to Grand-Duc's point #4, but more specifically where a batch is uploaded from a third-party source who does not have the experience of a Commons user. Like Flickr photographers geotagging all their vacation photos manually to the middle of their holiday destination, which then get imported like that. In such a case, the template can function as a maintenance warning that someone should double-check the coordinates. --HyperGaruda (talk) 07:15, 29 December 2025 (UTC)

As I said in my 01:56, 29 December 2025 (UTC) remark, I mostly see this in batch uploads (usually from Flickr), so we can't routinely ask the author. I've occasionally contacted someone on Flickr about a particular, confusing photo; about half the time they help out. - Jmabel ! talk 22:57, 29 December 2025 (UTC)

December 29

Wat license is needed for digitalisation of text?

I uploaded a pdf File:Lettre posthume de Bernard à Estelle.pdf. The content is PD-old-100-expired and PD-US-unpublished, but using OCR (of the typed out version of my father) and carefully editing the results, looks to me as own work. This is much more than a scan and a lot of work. Do I just use an own work license? Smiley.toerist (talk) 15:02, 29 December 2025 (UTC)

• You can use Template:Licensed-PD or similar to mark your license on your rework. This typographical right has varying protections in different countries, but in France where you are is a full PMA+70, requiring a separate license. You may want to consider the license {{PD-heirs}} for the main work, to avoid any need to put a US tag on it. Is the unedited original also uploaded? -Nard (Hablemonos) (Let's talk) 15:16, 29 December 2025 (UTC)
  • Yes, everything is in Category:Lettre posthume de Bernard à Estelle. I used {{PD-heirs}} for the typed out version my father did. The content is PD in the US, also under unpublished license. Smiley.toerist (talk) 18:31, 29 December 2025 (UTC)
  • {{Licensed-PD |1=PD-old-100-expired |2=cc-by-sa-4.0}}. I tried this template, but it mentions photograph instead of something more specific and accurate. A PDF is more than a picture, it has digitalized content. In most cases the problem is avoided when the text is digitalized in French Wikisource. However an entry in Wikisource is out of scope. The 'literature' has not only to be PD, but also published by an independent publisher. Just any old PD text is not sufficient. Smiley.toerist (talk) 18:59, 29 December 2025 (UTC)

    Go look now, you'll find the licensing is all there now. -Nard (Hablemonos) (Let's talk) 22:34, 29 December 2025 (UTC)

Interface administrators please go thru edit requests

a new year is coming. can users please go through all Category:Commons protected edit requests for interface administrators once? thanks. RoyZuo (talk) 15:10, 29 December 2025 (UTC)

December 30

How many files uploaded

I'm interested in knowing how many files I have uploaded to commons. How would I find this out? - Chris.sherlock2 (talk) 04:47, 30 December 2025 (UTC)

You could go to https://commons.wikimedia.org/w/index.php?title=Special:Log&excludetempacct=1&page=&tagfilter=&type=upload&user=Chris.sherlock2&wpFormIdentifier=logeventslist&wpdate=&wpfilters%5B0%5D=newusers&offset=&limit=500 and see how many times you can press next 500. Bawolff (talk) 06:29, 30 December 2025 (UTC)

I found it... https://ptools.toolforge.org/uploadsum.php?user=Chris.sherlock2

41320! - Chris.sherlock2 (talk) 07:35, 30 December 2025 (UTC)

@Chris.sherlock2: Another place to get the count is XTools, which says 41,387 — I guess the difference is that some have been deleted? Sam Wilson 08:13, 30 December 2025 (UTC)

Yeah, that would track. Thanks! - Chris.sherlock2 (talk) 09:08, 30 December 2025 (UTC)

Another method: https://glamtools.toolforge.org/glamorous.php?doit=1&username=Chris.sherlock2. Nakonana (talk) 12:57, 30 December 2025 (UTC)

Yeah, I like Glamorous, however it has two flaws: first, I can't exclude Wikidata, and second I can't exclude junk wikis like ceb.wikipedia.org which are just bot driven and, frankly, utterly useless to pretty much anyone. - Chris.sherlock2 (talk) 02:34, 31 December 2025 (UTC)

Do you want to help, to categorise 34,000 media needing categories as of 2020, please?

We are currently categorizing all media needing categories as of 2020. Progress is good so far, as shown on Category talk:All media needing categories as of 2020, but the task is getting increasingly more difficult, because the 'low hanging fruit' have been harvested by now. Do you want to help us? If so, please leave a comment about your approach or your achievement either here or on the discussion page.--NearEMPTiness (talk) 08:21, 30 December 2025 (UTC)

One way is to categorize the trees in the pictures. Example File:954I8789 نمایی از زن و مرد گردشگر در درکه - تهران.jpg and File:954I8790 زن و مرد گردشگر در درکه - تهران.jpg. However I cannot read Arabic, so I dare not place it in a country category.Smiley.toerist (talk) 12:44, 30 December 2025 (UTC)

But, please, if all you can do with an image that is clearly supposed to depict a place is to categorize a tree, don't remove it from Category:All media needing categories as of 2020! - Jmabel ! talk 19:22, 30 December 2025 (UTC)

A few months ago I went there, categorized a few images (spent quite some time geolocating them), provided some ideas at the talk page which were fully, totally ignored by that community as if I do not exist. Not going to do it again. Ymblanter (talk) 19:33, 30 December 2025 (UTC)

I don't think that you should feel ignored, keeping in mind that "no criticism is praise enough." Implementing procedures to fight the backlog will take some time. It's a task for unsung heroes, who are sufficiently self-motivated to categorise files or to motivate uploaders to to it themselves. --NearEMPTiness (talk) 20:15, 30 December 2025 (UTC)

@Jmabel: I completely agree with the comment “don't remove it from Category:All media needing categories as of 2020!“, but the problem is that when using Cat-a-lot it automatically removes it. Wouter (talk) 07:54, 31 December 2025 (UTC)

Cat-a-lot makes it easy to add the category Unidentified people to all photos of people, for example. The user can be proud because now so many images have a category added. Another user has then to solve the problem with "Unidentified people" with over 31,000 images. I've personally noticed that there are images with the person's full name in the description and that also have a Wikipedia article. Wouter (talk) 10:10, 31 December 2025 (UTC)

acte d'association en nom collectif

Do we have any categories for compagny establishments? In this case a limited compagny with 3 associates.Smiley.toerist (talk) 12:17, 30 December 2025 (UTC)

see also File:Factuur B Vankersschaver 1904.jpg Smiley.toerist (talk) 12:19, 30 December 2025 (UTC)

There is a problem in structured data to connecting with d:Q137599156. Smiley.toerist (talk) 12:32, 30 December 2025 (UTC)

Some suggestions:

• Category:Documents of Belgium (and there's also Category:Documents by year and Category:Documents by type)
• Category:Documents related to economy
• Category:Corporate law
• Category:Private limited company
• Category:Privately held companies
• and maybe some subcategory of Category:Certificates

Nakonana (talk) 13:15, 30 December 2025 (UTC)

And

• Category:Registration
• Category:Business documents
• Category:Business ownership
• Category:Business administration
• Category:Bureaucracy

Nakonana (talk) 13:26, 30 December 2025 (UTC)

Why upload only one page? You attribute authorship to a notary. Isn't the name in the document? -- Asclepias (talk) 20:30, 30 December 2025 (UTC)

I will upload the 3 other pages. This is a legal document, but I cant see any signature or mention of a notary. So I suspect it would be the work of a lawyer. There is a stamp of registration and signature of a receiver of the Ghent. There is change of the contract on the 6th of april 1904, specifying what happens when one of the associates dies. If there is interest I wil upload it. This is al part of an old estate dossier. I have put the file in the Category:Private limited company. There are forms of associations, but this looks to be the closest one. Their is a defined capital amount each puts in. Smiley.toerist (talk) 10:34, 31 December 2025 (UTC)

If there's no mention of a notary, why do you attribute to author=notaris? -- Asclepias (talk) 11:18, 31 December 2025 (UTC)

I have changed it. I had assumed it was drawn up by a notary. Today such a document would certainly have been written by a notary.Smiley.toerist (talk) 12:01, 31 December 2025 (UTC)

I have added the 3 missing pages.Smiley.toerist (talk) 12:33, 31 December 2025 (UTC)

• 
• 
• 

December 31

Duplicate of Category:Candy stores

Is Category:Sweet shops the same as Category:Candy stores? Sam Wilson 13:09, 31 December 2025 (UTC)

Clearly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:02, 31 December 2025 (UTC)

Sweet Shops are subcategory of Category:Sugar confectionery stores while candy stores are a subcategory of Category:Confectionery stores and Category:Sugar confectionery (not sure why). Might be a matter of American vs British English and is probably best handled via redirects if so. Nakonana (talk) 15:06, 31 December 2025 (UTC)

Okay, I'll move the contents of Sweet shops to Candy stores and redirect it. Thanks! Sam Wilson 08:30, 1 January 2026 (UTC)

Categorization by date

Is this edit (and hundreds like it) by Gzen92 correct? I think not. It removes a visible/topical category and substitutes a hidden category that even at best is redundant because it was already implicitly there (created by {{Taken on}}). - Jmabel ! talk 19:20, 31 December 2025 (UTC)

I would say no (and I initiated a similar thread two weeks ago ago about edits of a different user) but the community consistently showed its inability to deal with the question of categorization by date. None of the discussions I am aware of was formally closed, and if they were it would be a no consensus closure. In the meanwhile, people do what they think is best, and edit-war if reverted. Ymblanter (talk) 00:54, 1 January 2026 (UTC)

This is the thread I mentioned Ymblanter (talk) 00:56, 1 January 2026 (UTC)

It seems to me that either we need to un-hide those daily categories, or edits like this shouldn't happen. I don't care which of those two ways we go.

@Gzen92: I'm trying to understand your intent here. Did you understand that you were removing a visible/topical category without adding another to replace it? And did you intend to explicitly add a category that was already there because of a template, and if so, why? - Jmabel ! talk 03:12, 1 January 2026 (UTC)

Probably unhiding everything involved is the easiest solution. Ymblanter (talk) 08:10, 1 January 2026 (UTC)

The main difference between these two topics is that we do diffuse categories down on a photographs-by-day level for countries, and photographs-by-day are a subcategory of photographs-by-month. So I don't think Gzen92 did anything wrong here. In the other topic linked photographs were diffused from a by-country to a by-city level, and that's a more contentious topic. ReneeWrites (talk) 14:15, 1 January 2026 (UTC)

Given that the previous category Category:March 2024 France photographs is a parent to the new category Category:France photographs taken on 2024-03-12, this seems like it should be correct - it's diffusing the file to a more specific category. (And given that the by-day category was already present, the file was previously overcategorized.) Omphalographer (talk) 07:48, 1 January 2026 (UTC)

I modified it to a more specific category. I didn't check the category's visibility. Gzen92 (talk) 09:28, 1 January 2026 (UTC)

Repeating/clarifying my take (and after this I will drop it): (1) I'd be fine with making the by-day categories visible. Without that, from the point of view of everyone but contributors, this hides information. (2) I think that 'by month' categories for something as large as France are overly broad, and we should be down to some more specific region. I do not know France well, and would not have known in this case what more specific region to use. (3) There is absolutely no value in having a category explicitly added that is already added by a template. - Jmabel ! talk 20:39, 1 January 2026 (UTC)

Unhiding would be a good idea. I'm not entirely sure why the photographs-by-day categories are hidden in the first place, and why the parent category or some sibling categories aren't. ReneeWrites (talk) 13:36, 2 January 2026 (UTC)

Anyone think unhiding these is not a good idea, or needs to go through a formal proposal? It would affect tens (maybe hundreds) of thousands of categories, but it's not terribly hard to do with a bot: just switch these all to use {{World photo}} and modify that template accordingly. - Jmabel ! talk 18:32, 2 January 2026 (UTC)

I think this is a good idea, but for an action which would affect hundreds of thousands of categories I think we need a bit more visibility. Probably going through a formal proposal is safer. (Note that there are two, in principle, separate proposals: (i) switching to {{World photos}} and (ii) unhiding them by modifying the template). Ymblanter (talk) 19:17, 2 January 2026 (UTC)

Nobody seems to care however, may be we can just implement this. Ymblanter (talk) 16:43, 3 January 2026 (UTC)

January 01

Happy New Year

Happy New Year 2026 to everyone!

This is the year of Wikipedia/Wikimedia's 25th anniversary, and, so, a good moment to think about what can be done to help keeping, in addition to carry on building, this wonderful work that we are creating together.

In the year that has just ended, I wrote 3 essays related to this topic (1 in Commons and 2 in English Wikipedia), that you can read if you are interested:

• Digital preservation
• Past and future of Wikipedia
• The hidden encyclopedia that resides in the article histories

In the year we have just left behind, there was also very good news in this regard: for the first time (as far as I know), Internet Archive publicly confirmed that, unlike 10 years ago, it has copies around the world, so the many contents preserved there (including many Wikipedia articles and many Commons files, among many other WMF pages) are not exposed to the natural risks that a single location like San Francisco may face, so now there are far better preservation guarantees for legitimate files or wiki pages that, for one reason or another, may be removed from public view in WMF sites in the future (I think it's a good practice to also save in Wayback Machine those Commons files that are worth of special value). MGeog2022 (talk) 20:01, 1 January 2026 (UTC)

Wouldn't it be a much better policy to establish data centers for Wikimedia projects in additional and safe countries? That would also mitigate the risk. --Enyavar (talk) 08:06, 2 January 2026 (UTC)

I think that WMF backups in countries other than the USA would be fine, but probably they could only host offline backups, since US copyright law is always considered for Commons media, and US-only fair use law is considered for many media files hosted in Wikipedia itself. I'd like to see fair use and fixed-term (since publication) copyright expiration in the European Union and other countries, but, sadly, it isn't the case for now (the current interest in promoting AI in the EU could be a good reason to change the laws, but I fear they won't change, since it seems that, sadly, AI companies are given permission to ignore copyright laws where others wouldn't be allowed to do the same).

Here, I wasn't thinking about possible censorship or political issues. Fortunately, it doesn't happen often, and administrators make a great work, but, for one reason or another, a Wikipedia article or a Commons file (there are more than 130 million files in Commons, we need to be understanding) may be mistakenly deleted (false copyvio claim, controversial out of scope discussion, etc). I'm not saying it's something that usually happens, only that it is something that could happen with some files, and, if they are of special value, it's good to include them also in Wayback Machine, where, to ask for deletion of content, very strong evidence of the copyvio is needed. MGeog2022 (talk) 14:15, 2 January 2026 (UTC)

I think there is some confusion above:

• Besides three sets of servers in the U.S., Wikimedia already has servers in Amsterdam, Singapore, Marseille, and São Paulo.
• Not all WMF projects follow U.S. copyright law. For example, de-wiki as far as I know completely ignores U.S. copyright law, but follows the copyright laws of Germany, Austria, and Switzerland, which are almost completely harmonized with one another.

Jmabel ! talk 18:37, 2 January 2026 (UTC)

Thanks for the info in the second point, I wasn't aware of it.

WMF does have datacenters out of the USA, but they are caching ones only (source). As far as I know, only 2 of the 3 US datacenters store the full contents permanently. But good point also to talk about the non-US WMF datacenters: if there can be caching datacenters out of the USA, perhaps there would be no problem in having application datacenters also (I don't know enough about it, but I always thought that the reason for both application datacenters being US-based was WMF following USA copyright law). MGeog2022 (talk) 19:51, 2 January 2026 (UTC)

Having whole datasets outside the US (preferably in stable, democratic countries), would be good. We have to be prepared --PantheraLeo1359531 😺 (talk) 20:33, 4 January 2026 (UTC)

January 02

What to do with audio file with wrong pronunciation?

Hi,

File:zh-zhī.ogg contains audio that's actually a pronunciation of "zhǐ", not "zhī" as the file name suggests (this is already confusing people: see wikt:Talk:之#Mandarin_audio). The file was nominated for deletion before, but was kept (Commons:Deletion_requests/File:Zh-zhī.ogg). There's already a perfectly valid file File:zh-zhǐ.ogg containing a correct pronunciation of "zhǐ". What do we do now?

• If we can't delete File:zh-zhī.ogg, can we upload a new version of it? I recorded a pronunciation of "zhī" and tried to upload it as a new version, but got hit with Commons:Overwriting existing files.
• If we can't upload a new version, can we at least rename File:zh-zhī.ogg (so that we can upload a correct file)? The problem is that File:zh-zhǐ.ogg is already taken (and it's a good file). Do we rename it to File:zh-zhǐ2.ogg?
• I *could* upload my recording as File:zh-zhī2.ogg and edit all the pages that use File:zh-zhī.ogg to use my version... But that seems like a waste of everyone's time (as it's so much more work than just fixing the wrong file), *and* File:zh-zhī.ogg would still remain erroneous and confusing.

Can an admin step in here? Wyverald (talk) 03:44, 2 January 2026 (UTC)

Stepping in, partly as admin. Unless someone else objects in the next 24 hours, here's what I propose.

• I will temporarily mark File:zh-zhī.ogg with {{Allow overwriting}} so you can overwrite it.
• When you overwrite it, please edit the file page to accurately reflect your replacement file.
• @Wyverald: may I presume that once I allow overwriting, you will get to it promptly and report back here so an admin can quickly lock it back down? Is there a time of day that works well for you (in UTC, please) to start this?

- Jmabel ! talk 06:14, 2 January 2026 (UTC)

Thanks. I can do it any time this weekend (from now until 8am Sunday UTC, or 8pm Sunday to 8am Monday). Wyverald (talk) 18:51, 3 January 2026 (UTC)

@Wyverald: have at it! Let us know here when you are done, so I can remove that tag. - Jmabel ! talk 23:01, 3 January 2026 (UTC)

Done. I took the liberty to remove the tag myself when editing metadata -- hopefully that's not illegal :) Thanks for the help! Wyverald (talk) 02:15, 4 January 2026 (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) 08:11, 2 January 2026 (UTC)

@Enyavar: I'm trying to understand the first point. A couple of questions that may help me understand:

• Would there be no such thing as "maps of Germany" for any date before 1866? Or would we take "Germany" before that date to mean the German-speaking world (and, if so, would that include areas where the rulers spoke German, but most of their subject did not)? or what? (Similarly for Italy.)
• Similarly: would there be no such thing as maps of Poland or Lithuania between 1795 and 1918? If so, what would we call maps of that area in that period?

I could easily provide a dozen similar examples, but answers to those two will at least give me a clue where this proposes to head. - Jmabel ! talk 18:49, 2 January 2026 (UTC)

Thanks for that question, our categories about "history of" do not really care for nation states existing. Germany's history begins quite some time before it became a nation in the 19th century, and Polish history did not stop during the times of division: Poland in the 19th century is unquestionably a valid category. Our history categories generally imply that people know the limits of a subject without exact definitions.

Your question is getting to the reason why I am uncomfortable with the current hatnote/definition of these categories. I have not checked for all countries in Europe, but I'm quite confident: We do not define the subject of "Maps of the history of Poland" with a hatnote. We do not define "Poland in the 16th century" either. So why would we define the combination subcategory of the two so narrowly and rigidly, that only 6 out of 26 files currently in the category even match that (unreasonable) definition? (And of course, Poland/16th is just a stand-in here, I would argue the same for Spain/12th and Italy/8th and all others)

I would even be okay with no definition at all, besides a template notice (my third point) that "maps of <country> in Xth century" is about history maps, and old maps have to be found in "Xth-century maps of <country>". --Enyavar (talk) 04:53, 3 January 2026 (UTC)

Surnames

We have a longstanding and slightly stale Commons:Categories for discussion/2024/07/Category:Surnames, mostly about the fact that we currently supposedly have two flat-list categories for surnames. It impacts probably 10,000+ categories in terms of their parent categories, and hasn't gotten a lot of attention, so I'd like to see more voices there before considering the matter resolved.

Please, unless you find my wording here non-neutral (which you should certainly address here), let's keep the discussion on the CfD, not here. - Jmabel ! talk 19:10, 2 January 2026 (UTC)

January 03

Can anyone work out the name of the photographer, and if they have a Wikidata entry

See: File:Pamela Colman Smith, "In Private life" (1904).jpg RAN (talk) 11:48, 3 January 2026 (UTC)

R.D. Macpherson? (Robert Macpherson) Nakonana (talk) 11:59, 3 January 2026 (UTC)

The "D." is written like the Greek letter Delta or Cyrillic cursive "d". Nakonana (talk) 12:00, 3 January 2026 (UTC)

Or maybe not "Robert" but some other name because this Robert died before 1904. Nakonana (talk) 12:03, 3 January 2026 (UTC)

Maybe it's not a "D" after all but a "J" instead? R.J. Macpherson [1]? According to Google search there may also be something about R.J. Macpherson at [2] but the page doesn't load for me to confirm. Going by Flickr, R.J. was active around 1895, so the time would fit. Nakonana (talk) 17:26, 3 January 2026 (UTC)

And it looks like he was based in Jamaica. The woman in the photo is half Jamaican and lived in Jamaica for some time, right? Nakonana (talk) 17:28, 3 January 2026 (UTC)

• Excellent detective work, "Macpherson", now I see it. I will see if I can find more images from him. --RAN (talk) 14:13, 3 January 2026 (UTC)

en:Duncan Macpherson (photographer)? Nevermind, he was likely too young in 1904. -Nard (Hablemonos) (Let's talk) 14:43, 3 January 2026 (UTC)

User:Yug@commonswiki_(importer) - extension

Hello everyone and happy new year 2026,

Following Stewart Xaosflux's guidance and request, allow me to inform the Commons community that I requested a one month extension for my temporary importer rights to finish Lingualibre.org/wiki/'s selected imports toward Commons:Lingua Libre. See the previous discussion and votes there :

• meta:Steward_requests/Permissions/2025-11#User:Yug@commonswiki_(importer)
• Commons:Village_pump/Archive/2025/10#Migration_of_Lingua_Libre_project_pages_to_Commons
• Commons:Lingua Libre#Current status

Best regards. Yug (talk) 19:14, 3 January 2026 (UTC)

I'm adding 10 days temporarily while this is open. @Yug: when this closes please drop a new request at SRP. If 2 months is what you need, please express that here. — xaosflux ^Talk 20:06, 3 January 2026 (UTC)

Hello User:Xaosflux,

As discussed here, I'm depending on other users collaboration for Translations pages, we will see if 10 days will be enough. Yug (talk) 20:57, 3 January 2026 (UTC)

What I meant was that it would be at least long enough for this discussion to come up with a consensus. — xaosflux ^Talk 00:44, 4 January 2026 (UTC)

January 04

Category:2026 protests against the capture of Nicolás Maduro in New York City

I noticed this is a subcategory of Category:Demonstrations and protests in support of the Venezuelan government of Nicolás Maduro. Is it fair for Commons to call the demonstration a pro-Maduro demonstration? Trade (talk) 02:42, 4 January 2026 (UTC)

I understand what you are getting at, but from a navigation point it may be for the best. We might want a separate parent category at the same level as Category:Demonstrations and protests in support of the Venezuelan government of Nicolás Maduro, but if we do that the two should be linked with a {{Cat see also}}. - Jmabel ! talk 08:29, 4 January 2026 (UTC)

School class pictures

I find very few group pictures of school classes. Most schools had end of the schoolyear pictures of the whole class. Nowadays this is very limited because of of privacy concerns, but in the past this was not a problem. Are there any specific categories for this? In this case the children where born around 1932. I find it very dificult to recognize any childern at this age even if you have a picture of the child at the same age to compare. I cannot recognize my mother with any certainty (two good posibilities) Smiley.toerist (talk) 11:38, 4 January 2026 (UTC)

Category:Class photographs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:51, 4 January 2026 (UTC)

First published in the United States before 1930

The upload wizard is still offering "First published in the United States before 1930" as a reason why a work might not be covered by copyright; that should now be "First published in the United States before 1931".

Is there a reason why the annual update cannot be automated? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:49, 4 January 2026 (UTC)

Possibly better asked at Commons:Upload Wizard feedback. - Jmabel ! talk 21:12, 4 January 2026 (UTC)

Adding a specific category for the art style in File:Fem_myror_är_fler_än_fyra_elefanter_papperskalender_02.jpg

I came across File:Fem_myror_är_fler_än_fyra_elefanter_papperskalender_02.jpg and I noticed that its art style looks intriguing. I'd put that file in the same category with others (that contain the same art style) but I don't know what category would be appropriate.

Edit: by "art style", I specifically meant different colored patterns, each containing colors almost always of high saturation, put together in the same art piece. Toarin (talk) 20:06, 4 January 2026 (UTC)