This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I suspect most images in Category:Butchers in Ireland are AI-generated, because I just felt that they are somehow odd-looking, but I couldn't be sure. Can someone just help take a look at these before I mass nominated them for DR? Thanks. Tvpuppy (talk) 16:36, 2 March 2026 (UTC)
Yes and also a violation of COM:WEBHOST -Nard (Hablemonos) (Let's talk) 16:42, 2 March 2026 (UTC)
Thank you Nard for your help, and also thank you to Grand-Duc for creating the mass DR and identifying the errors. Tvpuppy (talk) 17:38, 2 March 2026 (UTC)
Now all deleted. I don't think it matters whether we delete this as AI slop or as copyvio. It's one or the other, or possibly (given Irish law) both. Deleting. - Jmabel! talk 19:53, 2 March 2026 (UTC)
This section was archived on a request by: Jmabel! talk 19:53, 2 March 2026 (UTC)
Mass rename/edit request
Hi. I just uploaded many audio files via Lingua Libre. I thought I had sorted out the settings so that this would not happen, but it included my old username alongside my current one in both the file names and in the "Recorder" field in the description. I would prefer that my old username was not visible like this. Please could someone with permissions rename the files and change the recorder field to Pink Bee? (If the latter cannot be done automatically, I will do it manually.)
I am sorry to have to request this again – like I say, I thought I had sorted the naming issue. I will make sure it does not happen again. Thank you. Pink Bee (talk) 02:02, 3 March 2026 (UTC)
Mass rename started. - Jmabel! talk 06:58, 3 March 2026 (UTC)
@PinkBee: should all be done, let me know if some admin-specific task remains. - Jmabel! talk 07:36, 3 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:36, 3 March 2026 (UTC)
Wikipedia linking back to Commons
When I used Chrome I used to get a backlink from Wikipedia to Commons in a column on the right side of the article. It would also have the link to Wikidata. What setting in Chrome/Wikimedia did I accidently change to have it gone. RAN (talk) 00:45, 4 March 2026 (UTC)
Richard Arthur Norton, only works on articles with a Wikidata item and sitelinks for other projects on Wikidata. - Alexis Jazzping plz 02:00, 4 March 2026 (UTC)
Yes, but I am not getting any links when they exist. I can go from Commons to Wikipedia through the infobox, but the links back disappeared about a week ago. I must have changed a setting or updated Chrome or Wikimedia settings, but cannot work out what changed. --RAN (talk) 02:09, 4 March 2026 (UTC)
@Richard Arthur Norton (1958- ): Is there any "In other projects" section at all? (Search for that string within the page.) - Jmabel! talk 03:20, 4 March 2026 (UTC)
No, let me delete Chrome and re-install it. --RAN (talk) 05:23, 4 March 2026 (UTC)
Perhaps it collapsed into a single Tools button at the top right (next to Edit and History)? The Tools dropdown menu gives me the option to "move to sidebar". --HyperGaruda (talk) 05:32, 4 March 2026 (UTC)
Thanks!!!! That was it, most likely an errant click that collapsed the sidebar. Simple error, but drastic changes, and not obvious before you figured it out. Thank you again. --RAN (talk) 18:34, 4 March 2026 (UTC)
It might have been a change on Wikipedia end. I use different language wikis (with Firefox browser) and some language wikis have the side bar while others haven't, so I'm guessing that this is not a Chrome issue. Nakonana (talk) 17:32, 4 March 2026 (UTC)
When you hide the sidebar there's just a Tools dropdown. It stays like this unless you clear cookies or open it with another browser where you haven't hidden the panel yet. Prototyperspective (talk) 11:40, 5 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 11:20, 6 March 2026 (UTC)
Wikidata Infobox
I've always had this set to 'Collapsed', as it's a nuisance. Just today, it's suddenly started being expanded each time I go to a new category, and it's getting tiresome having to click on 'Collapse' on every new link. How can I get it to stay collapsed, please? I can't find it in the Preferences. Thanks! - MPF (talk) 19:00, 5 March 2026 (UTC)
Maybe you had them collapsed via some gadget. These scripts apparently got disabled since that problem today where wikis were changed to read-only. Prototyperspective (talk) 19:03, 5 March 2026 (UTC)
@Prototyperspective Could be; no idea, I don't remember! But I want whatever it was back again, ASAP . . . MPF (talk) 20:40, 5 March 2026 (UTC)
@MPF, the collapsed Wikidata Infobox setting is at line 8 of your user JavaScript (User:MPF/common.js), but as mentioned by Prototyperspective, all user JavaScripts have been temporarily disabled. Thanks. Tvpuppy (talk) 20:50, 5 March 2026 (UTC)
@Tvpuppy thanks! Is there any info on when they might get restored? - MPF (talk) 20:56, 5 March 2026 (UTC)
@MPF, you can monitor phab:T419154 for updates. The site JavaScripts were re-enabled an hour ago, but currently there is no clear info on user JavaScripts, other than they will be "back online soon, with a few restrictions". Thanks. Tvpuppy (talk) 21:01, 5 March 2026 (UTC)
@Tvpuppy Thanks! "due to an issue being worked on" . . . remarkably secretive! Wonder what it is??? - MPF (talk) 21:10, 5 March 2026 (UTC)
Maybe they now prevent loading of JavaScript from other namespaces or even external servers in MediaWiki namespace. I thought this was already the case, but it seems that it was not. GPSLeo (talk) 21:25, 5 March 2026 (UTC)
@MPF, since the issue is related to the security of the site, I would assume it is better for them to be secretive about it until the issue is fixed. Thanks. Tvpuppy (talk) 22:00, 5 March 2026 (UTC)
Info, see announcement by WMF, it appears user javascripts have now been re-enabled. Thanks. Tvpuppy (talk) 01:15, 6 March 2026 (UTC)
@Tvpuppy Excellent! Thanks for the updates - MPF (talk) 01:27, 6 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 11:19, 6 March 2026 (UTC)
I think they can be categorized under Category:Launch (boat), or perhaps you can create a new subcat under it. Thanks. Tvpuppy (talk) 02:53, 6 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 11:20, 6 March 2026 (UTC)
All of these are important enough photographers to have en-wiki articles. Do we have any criteria of how significant a photographer has to be in order to have a topical (vs. hidden) category? - Jmabel! talk 08:58, 1 March 2026 (UTC)
I thought the "hidden" criterium is more for user categories (photographs by Wikimedians who upload their images by themselves), and "topical" cats for photographers that are non-Wikimedians? --PantheraLeo1359531 😺 (talk) 10:00, 1 March 2026 (UTC)
That's how I understood the split to be as well. Most "Photographs by photographer" categories are hidden because they're userspace categories. There are a few notable photographers who are also Wikimedians, who can have photographs both in main- and userspace. For the photographers mentioned by Jmabel (and others this would apply to) it doesn't seem fitting to have these categories be hidden. ReneeWrites (talk) 15:28, 1 March 2026 (UTC)
Same, although there have been a couple incidents where Commons users demanded to be unhidden, and I don't recall there being consensus that it was absolutely required. User categories can get pretty expansive, though, since many of us have hidden category systems we use to organize our own stuff (doesn't make much sense to unhide "Quality images of birds by Rhododendrites" or "Photographs taken by Rhododendrites - Poland"). There's another use case that's often hidden: files from [some particular flickr account]. But in general, yeah I think photographers other than Wikimedians should be unhidden by default. —Rhododendritestalk| 16:08, 1 March 2026 (UTC)
Imo category-hiding is slightly overused. Usually it's useful to be able to go to images made by the same person – these often have certain similarities such as subjects the reader/visitor may be interested in. For Commons contributors, people can go to the user-page. For photographers, a category is useful. If I'm not mistaken, hidden categories are not displayed to people who are not logged in and have enabled the display of hidden cats. So it would be best to unhide most if not all of these categories. Categories where there's just very few files in them probably aren't useful. Categories about who made a photo are not topical as they are not about the topic of the image but they're nevertheless useful and not just for maintenance purposes or useful only at the category pages instead of also at the file pages that most people would not benefit from seeing. Prototyperspective (talk) 12:02, 1 March 2026 (UTC)
Btw, it may also be a good idea to link to the category page in the Author field of the information template which currently links to the Wikipedia article. One could add sth via template like (see more photos of this creator/photographer). Then there would be less need for the category to be unhidden but even that would not mean the cat is better hidden. Prototyperspective (talk) 12:07, 1 March 2026 (UTC)
Typically, the Wikipedia article links (at least by the normal interwiki links via Wikidata) to the main Commons category for the person, and the "Photographs by" category is a subcat. Exactly as for any other creator and their works, if their works (or representations of their works) are on Commons. Not sure why photographers would be different from, say, painters, for this. - Jmabel! talk 06:37, 2 March 2026 (UTC)
Not sure how this is meant to relate to my comment – if one was looking for further photos a direct link to the page with more photos of the photographer that's easily visible to all in the Information template would be useful and the same applies also to painters. Even if that was widely done I think it would be better to unhide these categories. Prototyperspective (talk) 11:12, 2 March 2026 (UTC)
It sounds like we aren't certain exactly where to draw the line, but that the people I'm asking about are certainly on the "should not be hidden" side of the line. I will unhide these and similar ones I come across. - Jmabel! talk 06:37, 2 March 2026 (UTC)
Today, 2,700 poorly categorized files have been added to the Category:Images with file name and description in Greek language. All of these need at least one more category, please. Can you help, to categorize them, please, or even use them in an article? Do you have any recommendations, how to achieve this more effectively? NearEMPTiness (talk) 12:26, 2 March 2026 (UTC)
What's the criteria for a new license template?
So there's one user on a site, and on their profile they say all of their uploads are released under a CC BY 4.0 license. There's no license laundering apparent and it appears to be their own work. This user has uploaded thousands of images. Would that warrant creating a separate template and license review category for it? HurricaneZetaC 15:02, 2 March 2026 (UTC)
Why would this entail a new license template? What different license is claimed?
Yes, this would be an appropriate maintenance category, probably one added by an appropriate, purpose-specific maintenance template. Compare {{UWash-Check-Needed}}, though that one is about needing a cat check, not a license check. - Jmabel! talk 19:47, 2 March 2026 (UTC)
{{Official Prime Video AU & NZ YouTube channel}} exists because it is a special case that is valid but has some date dependencies. Yes, I a special-case variant of {{YouTubeReview}} (possibly a wrapper around that) adding a category specific to this task would be a good solution. - Jmabel! talk 20:04, 2 March 2026 (UTC)
commons was mentioned too. worth a watch and lets us think about how we can better engage newcomers. RoyZuo (talk) 19:17, 2 March 2026 (UTC)
Not specifically a Commons topic but as a person with degrees in both Math (including graduate-level work in topology) and Computer Science, almost every time I tried to edit a math-related article on Wikipedia to make it more comprehensible to lay readers, I was reverted on the basis of insufficient rigor. (I had not removed any existing, rigorous, content, just added paraphrases in lay terms.) Of course I stopped trying. - Jmabel! talk 19:58, 2 March 2026 (UTC)
Questionable flags
There are quite a lot of purported flags from history on Commons, where their actual historical status is unsourced or otherwise uncertain. Most of the time these have been uploaded in good faith and they're not "fictitious", but they often reflect misconceptions that have gained popularity online. I wasn't sure which template to use, have started a thread at Template talk:Fictitious flag#Disputed flags but I was thinking perhaps to start something more specific like a flag version pf {{Lacking insignia source}}.--Pharos (talk) 19:33, 2 March 2026 (UTC)
A new Mapillary importer: Curator
Hi!
I would like to introduce Curator. It is a tool that allows the import of image sequences from Mapillary. The tool was rolled out and tested and has reached a stable state. Before you try it out, check out COM:Curator and remember issues like Freedom of Panorama. Mapillary covers many areas, which have a Wikipedia article, but no image in it. Or Mapillary maybe shows areas and structures that don't exist anymore. Happy testing! --PantheraLeo1359531 😺 (talk) 13:31, 3 March 2026 (UTC)
Congrats. The Brutalist architecture has a large number of very high-quality files – the entries/scores gallery is very much worth a visit. I found most files in the Peace challenge didn't have much to do with the subject – it seems difficult to capture this subject in photos. Prototyperspective (talk) 23:40, 3 March 2026 (UTC)
Flickr upload with Upload Wizard
Is uploading free licensed files from Flickr via Upload Wizard currently down? I've repeatedly tried uploading files by long time good Flickr users with 2 different browsers on 2 different machines and can't get anything to upload. (Uploading files directly from my machine works fine.) Wondering, -- Infrogmation of New Orleans (talk) 19:18, 6 March 2026 (UTC)
seems to work again and this is a technical issue where it would be best to centralize further discussion at the thread in Village_pump/Technical. Prototyperspective (talk) 12:32, 9 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:32, 9 March 2026 (UTC)
this is not how to file a deletion request Prototyperspective (talk) 12:33, 9 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:33, 9 March 2026 (UTC)
While trying to georeference a bunch of aerial photographs from Staatsarchiv Sigmaringen Findbuch Wü 160 T 5, I've found that some (but not all) of those photos are facing south (in german: "gesüdet"; example for photo facing south), not north as usual ("genordet"). Aerial images facing south are hard to work with, since nowadays all modern maps (and modern Orthophotos) are facing north. Currently, there's no category for aerial photographs / orthophotos with such a cardinal direction, as it's the case for maps. Is it OK to rotate the images currently facing south by 180° or should they keep their current orientation? What's your opinion? --Fl.schmitt (talk) 10:12, 4 March 2026 (UTC)
@Fl.schmitt: I think we can rotate this images. There now loss of information after the rotation. Thanks for your work with this orthophotos and for the georeferene. --sk (talk) 11:50, 4 March 2026 (UTC)
If you wish to make rotations, they should be as derivative images.
Also, the example image is not "facing south"; it is facing straight down. It is (presumably) orientated with south at the top". We would talk about images facing in a compass direction when they are oblique (like, for example File:Raf 58 2445 psfo 0117.png). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:40, 4 March 2026 (UTC)
Probably best to make the rotation into a derivative image with an explanatory note about the rotation because if you rotate the image you gave as an example, the numbers at the top of the image will come up upside-down and people might attempt to fix that by rotating the image back. Nakonana (talk) 17:47, 4 March 2026 (UTC)
@Nakonana and @Pigsonthewing: ok, derivative images are another option. Regarding the numbers on the pics: There are different ways that those numbers were applied - some have the same numbers multiple times, e.g. this pic. So, an explanatory note would be in fact useful - good idea! Fl.schmitt (talk) 18:15, 4 March 2026 (UTC)
overwrite is specifically "reupload" a permission set by the software Special:ListGroupRights.
why is it not done by removing "reupload" from autoconfirmed users and adding it to autopatrolled users? RoyZuo (talk) 15:49, 7 March 2026 (UTC)
This would currently not allow any exceptions without granting user rights, not even for own uploads. GPSLeo (talk) 16:23, 7 March 2026 (UTC)
this seems solved; if not please remove this template Prototyperspective (talk) 12:41, 10 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:41, 10 March 2026 (UTC)
People voices audios
Where can I find all of them? Is there any common category? I've found only Category:Voice project but it contains not only audios. —Preceding unsigned comment added by Infovarius (talk•contribs) 12:26, 5 March 2026 (UTC)
If I have an image and want to show where it was taken I can use: {{Location|40.0000|-70.000}}. But what if I want to link an address in a news article, so that it can take me to one of the mapping sites, we link to. Id there a template for that? --RAN (talk) 18:58, 10 March 2026 (UTC)
seems to be solved – if not, please remove this template Prototyperspective (talk) 12:46, 11 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:46, 11 March 2026 (UTC)
Thanks! I think you got it. Distances are marked as "¾ inch". The typesetter had type for 1/4, 3/4 and 1/2 for measuring distance. They did not have fifths, and all times were measured down to the fifth of a second. Thanks again. ChatGPT: "Races were recorded in fifths of a second starting around 1862". --RAN (talk) 17:16, 12 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 19:01, 12 March 2026 (UTC)
Change links on main page
on the main page right under the title there're 4 links to Images Videos Sounds 3D Models, which link to the root categories of each of those types.
however, i think the root cats are not very helpful, especially for occasional users of this website who may not understand how to navigate the site, because those pages have long lists of subcats and sometimes files that are waiting to be moved to subcats. they look too technical and dont present some high quality files.
Oppose your proposed links aren't better and secondly these links can be added to those linked category pages. There's some useful links on these pages already. Prototyperspective (talk) 15:20, 5 March 2026 (UTC)
I feel like Commons:Featured pictures is the most similar to the links to other sites you were mentioning. Bawolff (talk) 03:40, 9 March 2026 (UTC)
I had a go with making my own version of that type of page - Commons:Explore. The galleries are random, and should change once an hour (or whenever someone does ?action=purge) Bawolff (talk) 10:21, 9 March 2026 (UTC)
Interesting and I'd suggest to links from that page to the category pages but I wonder why one would want to browse through a totally random good-quality images – I think just a small fraction of visitors is sometimes interested in that.
Things that could be better include having such autogenerated galleries linked well-visibly at the top of categories (maybe even partly embedded via a new panel where one can click [see more] to go to the full gallery page) and/or having images for all the subcategories in the gallery where one can then browse to the subcategory by clicking on the file's description/link.
That's basically what the gadget Help:FastCCI is about which dynamically loads featured pictures, quality images, etc for whatever category one is in. However, most visitors probably have not noticed the button and never used it; and the bigger problem is that like 90% of the time it doesn't work because the tool is down and still nobody has fixed whatever is causing it to go down at the time (see its talk page). Prototyperspective (talk) 12:30, 9 March 2026 (UTC)
I think many people coming from the main page might be interested in looking at a random selection of reasonable quality files. I don't think people go to the main page if they are looking for something specific. Although perhaps such people would be better served by Commons:Featured Pictures.
The probable reason nobody has fixed fastCCI is a mix between nobody caring and nobody having access. One of the problems with toolforge tools is access is usually restricted to the author. That said, as cool as fastcci is, i don't think its suitable for people wanting to browse. Bawolff (talk) 17:07, 9 March 2026 (UTC)
I didn't say most are looking for sth specific; I meant that most people aren't very interested in a totally random set of good-quality images from about every imaginable topic (albeit with strong bias for photos and nearly no statistics, videos, or diagrams) but instead are interested in more narrow sets of files. In my case that would be photos relating to say current events and science as well as up-to-date statistics of all kinds (again, not included in these featured pictures).
i don't think its suitable for people wanting to browse. I'd be interested in why you think that is – in specific because then maybe another tool / variant of it could be developed or FastCCI be improved accordingly. Prototyperspective (talk) 17:29, 9 March 2026 (UTC)
Why does this user think people all think the way they think and not in other ways?
"I didn't say most are looking for sth specific... most people... are interested in more narrow sets of files." Not specific but more narrow. What's all this exceedingly long rambling about? RoyZuo (talk) 17:41, 9 March 2026 (UTC)
I was describing what I meant to say/said in my prior comment. I could have written 'Why does Bawolff think people all think the way they think and not in other ways?' but I prefer more constructive less offensive and more friendly language. Thanks Prototyperspective (talk) 17:43, 9 March 2026 (UTC)
I think some people just want to look at pretty pictures. Some people are also going to want different things too. I think we already do a reasonably good job with narrow areas but not a great job for people who just want to be surprised with a broad selection of reasonable quality photos. Bawolff (talk) 17:47, 9 March 2026 (UTC)
And that's why I recommend adding that link to the category page. We should not assume all or the vast majority of users want to look at sets of pretty photos about random topics. They can open the link from there. Prototyperspective (talk) 17:48, 9 March 2026 (UTC)
So this user assumes "the vast majority of users want to look at" "the category page", and they want to "open the link from there"? RoyZuo (talk) 17:52, 9 March 2026 (UTC)
No, I'm not "assuming" anything; I was having a constructive discussion. Prototyperspective (talk) 17:54, 9 March 2026 (UTC)
Your codes are super. The pages generated are perfect. RoyZuo (talk) 17:34, 9 March 2026 (UTC)
Smooth rocks/Boulders
Besides the artic fox, the boulders are very interesting. I dont know what processes shapes these rocks. Is there any category for this? 'Round boulders' dont seem to accuratly describes these rocks. Smiley.toerist (talk) 22:18, 8 March 2026 (UTC)
I asked an LLM attaching the image and it returned The round boulders or rocks you're referring to are commonly known as ball boulders or spherical boulders. In geology, these are often referred to as concretions. They typically form through the process of sedimentation and mineral precipitation, resulting in rounded shapes over time.[…]. but I could not find a category named with either of these two terms so maybe it doesn't exist yet. I then searched for spherical boulders beach to find a similar image to check its categories and it found the one on the right with Category:Moeraki Boulders set but that cat has no broader cat about this in specific set. One could also create e.g. Category:Spherical rocks on beaches. Prototyperspective (talk) 12:41, 9 March 2026 (UTC)
The 2 requests are solved now. For further JSTOR requests or things like it, please post / reply at Commons:File requests. Maybe this page could be made more visible or get a new subpage for requests relating to access or Wikipedia Library. Prototyperspective (talk) 23:11, 16 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:11, 16 March 2026 (UTC)
Wrong meta data
"File:Electricity pylons in Eritrea" is from Mozambique, not from Eritrea. At the Mapillary link there are more pictures from the same location. On one car there is written „Moçambique elevaçao“. Probably it is Nampula due to the mistake of latitude north vs south.--Grullab (talk) 15:35, 16 March 2026 (UTC)
@Grullab: I'm not going to go looking around another site to see if I can find what you found, but nothing is stopping you from using {{Fact disputed}} and/or proposing a file move. I suggest that in doing so you provide the URLs for the content that led you to the conclusion. - Jmabel! talk 20:59, 16 March 2026 (UTC)
Thanks. Done. Best regards. -- Grullab (talk) 21:03, 16 March 2026 (UTC)
@Grullab I was able to identify the broader area. Per this, there is a board shown that points towards Murrupula, which is in Mozambique. I moved the file --PantheraLeo1359531 😺 (talk) 21:18, 16 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:11, 16 March 2026 (UTC)
Adding support to JPEG XL and HEIC files
Hi there everyone, I would like to know if there are plans by Wikimedia and Wikimedia Commons to add support to the new JPEG XL and HEIC type of files. Been experimenting with them in the last days and they seem really great, allowing to shrink the file size by very much. ----LucaLindholm (talk) 11:01, 9 March 2026 (UTC)
For JXL, see phab:T270855. The task is flagged as “stalled”. --Geohakkeri (talk) 11:09, 9 March 2026 (UTC)
@Geohakkeri Thanks, just saw it and people suggest to start discussion just here in the Village Pump on Commons to begin exploring whatever or not there is consensus on these new files. :D -- LucaLindholm (talk) 11:27, 9 March 2026 (UTC)
If the reason for its stalled status is lack of consensus to support these filetypes on Commons, I'd suggest making a thread proposing this at Commons:Village pump/Proposals where the benefits of adopting these filetypes and their characteristics are sufficiently explained. I did not read the full issue but it seems like there also are some technical challenges. Prototyperspective (talk) 12:45, 9 March 2026 (UTC)
JPEG2000 at least has some patent-related issues for some compressions, afaik. I don't know if JPEG XL has it, but I would approve the inclusion of modern filetypes, as long as they are free (thinking about OpenEXR, LAZ and glTF):) --PantheraLeo1359531 😺 (talk) 16:27, 9 March 2026 (UTC)
I would definitely support JPEG XL, as it's far superior to JPEG and manages to avoid most of the problems that doomed other JPEG replacements. Nosferattus (talk) 23:02, 9 March 2026 (UTC)
"If the reason for its stalled status is lack of consensus" no it is not. However consensus is definitely a requirement if you ever want Wikimedia to even consider doing something about it. Without that, you are at the mercy of chance or of external developers (as you might notice, I recently spent some time investigating both HEIC and JpegXL support). —TheDJ (talk • contribs) 15:24, 11 March 2026 (UTC)
questions about Game & Watch consoles
This image is a Quality image.This image shows all of the lit LCD panels, which occurs when the batteries are reinserted.
I'm a bit confused about uploading images of Game & Watch consoles to Commons.
Would the screens on the consoles count as a derivative work? In the United States, most photographs of game consoles (like the Nintendo DS) have utilitarian aspects, as stated in this section of the guideline. However, it states later in the guideline that anything on a utilitarian object may be subject to copyright.
I have several questions regarding this. Do the permanently colored backgrounds of the screens on Game & Watch consoles, such as those listed in Category:Game & Watch and its subcategories, count as utilitarian? When all of the LCD panels on the console are lit, would it not count as utilitarian?
In a similar manner to the derivative works questions, would some of the displays (either turned on or shut off) on the console be below the threshold of originality (for example, those in Category:Ball Game & Watch)? JudeHalley (talk) 18:35, 13 March 2026 (UTC)
The graphics displayed by a video game are fundamentally not utilitarian in nature, regardless of whether they're being displayed in the course of normal gameplay. Omphalographer (talk) 20:36, 13 March 2026 (UTC)
I would assume it would not count as de minimis, either, given the examples in that guideline.
Would this mean that most of the images that depict Game & Watch games need to be edited to conceal their graphics? (The reason I say most is that this would probably exclude ones like Ball with its screen off, which may be under the TOO.)JudeHalley (talk) 21:42, 13 March 2026 (UTC)
Probably; I may start a new discussion there. JudeHalley (talk) 13:43, 14 March 2026 (UTC)
Could some (if not, all) graphics fall under de minimis? JudeHalley (talk) 02:17, 14 March 2026 (UTC)
Not so much de minimis as ineligible for copyright.
Also: if there is an imae of a console we want to use, and the content on the screen is not relevant, it is easy enough to blur or otherwise cover anything that is not relevant to the purpose of the photo and would constitute a copyright violation. - Jmabel! talk 05:15, 14 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 16:41, 17 March 2026 (UTC)
Amazing research skills! --RAN (talk) 01:56, 17 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 13:31, 17 March 2026 (UTC)
Commons:Upscaling
I started a draft guideline at Commons:Upscaling that could use input. To be clear this section is not a proposal to make this a guideline but an invitation for users to edit or provide feedback on a page I plan to eventually propose as a guideline. I started to detail procedures for how to describe/tag/categorize upscaled images, but that got me wondering: what are the valid use cases for upscaling on Commons? I'm having trouble thinking of them. In some cases, upscaling is actively harmful. In others, it's a simple task that we should really just leave to our reusers if they want to. The only thing I can think of is if a Wikimedia project wants to upscale an image for use in an article. So maybe INUSE is the only realistic exception? Thoughts? —Rhododendritestalk| 17:34, 11 March 2026 (UTC)
I've made a bunch of edits since posting this message (and thanks, Jmabel for getting the exceptions started). Still hoping for additional comments or edits, even if to say "looks good". Planning to wait about a week and then start the proposal process at VPP. —Rhododendritestalk| 20:14, 12 March 2026 (UTC)
Bot request: replace old username in file descriptions
My username was renamed from Christo to Random photos 1989, then I've renamed back to Christo.
Many of my uploaded files still contain the old username in the description
(for example in the Author field of the Information template).
Could a bot replace "Random photos 1989" with "Christo" on my files?
This is not true: The Republic of China had its first copyright law in 1928 (Wikisource), with modifications in 1944 (minor change in 1949), 1964 and finally 1985. (I know there are more copyright laws later, but 1928-1985 is the relevant timeline.
As you can check in the wikisource links provided, the copyright lenght did not change between 1928 and 1965 reforms, being the most relevant of all the texts 1944 because it included for the first time movies. This is the articles and terms:
Art. 4 General Works (Individual Author) Life of the author + 30 years (for heirs)
Art. 5 Joint Works (Multiple Authors) Life of all authors + 30 years (after the death of the last surviving author)
Art. 6 Posthumous Works 30 years from the first date of publication
Art. 7 Corporate or Official Works 30 years from the first date of publication
Art. 9 Photographs and Sound Recordings 10 years
Art. 9 Film Works 10 years (must be legally registered)
Art. 10 Translations 20 years (Note: This did not prevent others from translating the same original work)
So, there was a deletion request for some pictures (photographs) made by a folk who lived in the Mainland during ROC times and then fleed to Taiwan, and those pictures were deleted, even if, obviously, somebody linving in the ROC (both Mainland and Taiwan) between 1947 and 1966 was under the current ROC copyright laws (all 1944, 1944 and 1964 recognised 10 years post publication lenghth) and had its copyright expired by the time the 1985 copyright law was implemented, and far before URAA applied in 2002.
And now it seems I need the whole Commons guidance for Taiwan (and probably China as a whole) to be changed: so it be.--TaronjaSatsuma (talk) 18:11, 12 March 2026 (UTC)
Just to clarify, by using for example Art. 7 and 30 years: does your statement mean that ROC government works up to 1954 would be considered public domain because they fell out of copyright before the laws changed in 1985? Or would that deadline rather be 1971, because the URAA date is 2002? Or does this work differently? Best, --Enyavar (talk) 19:05, 12 March 2026 (UTC)
Not a lawyer, but my understanding is:
If a work was PD by July 10, 1985 (when the Taiwanese Copyright law changes), then it's PD. Answering your question (what was PD by July 10, 1985?):
Works by people dead by 1954 (+30 years: 1st January 1985)
Corporate works made in 1954 or before (+30 years: 1st January 1985)
Photos and videos made in 1974 or before (+10 years: 1st January 1985)
Translations made in 1964 or before (+20 years: 1st January 1985, very rare to have in Commons)
Then, 1985 changed again to
General Works Life of the author + 50 years
Cinematic (and Photo) Works 30 years from completion
And 1992 changed Cinematic (and Photo) Works to 50 years after public release; remaining the General Works unchanged.
This means anything in PD according to 1985-1992 law by 2002 was already PD in Taiwan because of 1928-1966 laws (and anything made in the Mainland under ROC rule was also PD by then). For Commons effects, anything falling in PD because of 1985 or 1992 (or 2002) law is not eligible because URAA, until 2047, when post-1996 fall into PD (The movement should ignore URAA in order to improve out projects, but it's a different debate).
Comment, regarding the DR you linked, it was not correct to say "some pictures (photographs) made by a folk who lived in the Mainland during ROC times and then fleed to Taiwan". Per my comment in the DR, the photographs depict that person, so clearly the person did not "make" the photos. It is unknown who has taken the photographs, so we can only assume for the photographs taken in mainland China, the works of the unknown author are subjected to PRC laws, while for the photographs taken in Taiwan, the works of the unknown author are subjected to ROC laws. Thanks. Tvpuppy (talk) 19:57, 12 March 2026 (UTC)
That's a topic for The Undeletion requewst itself, and I can't see the pics (Where were those made?), but if the man moved to Taiwan in 1949 (mny guess: post-1949 are pics of Taiwan), then the whole rationale works.
And still: PRC had no copyright law at all, PRC did not have a Constitution (so, abolish all of the ROC laws) until 1954, and works made by people without PRC passport at the time (two pics, if made in the Mainland) fall into the copyright laws of the country who gives citizenship to the photographer, not the laws of the place where the pics are made. TaronjaSatsuma (talk) 21:52, 12 March 2026 (UTC)
When a new law extends the length of the copyright term, there are two possibilities:
The new term applies only to works that were under copyright on the effective date of the change, or
The new term applies to all works, including those whose copyrights under the old law had expired.
The second is less common, but the combination of the dates in the existing guidance looks like that might be the case in Taiwan. I don't read the language and I'd rather not trust Google translation with something as subtle as this, so I think we need a Chinese reader to look at that issue. .Jim . . . (Jameslwoodward) (talk to me) 20:07, 12 March 2026 (UTC)
I believe there is no combination in the existing guide, someone did 2002-50 = 1952, and followed up with the 2002 (1992) laws regardles of previous possible considerations.
About the possibilities you name, it's the first option, according to article 50 of the 1990 text, which I'll quote in Chinese (you can Google translate to get an idea while waiting for a subtile native translation which I can't provide because I'm not a native speaker).
I'm also not a lawyer, so below is just what I understood by reading the law:
I think the explanation can be found in the article 106-1 of 1998 law (for English translation, see "article106bis" in page 57 of this PDF, the PDF was for later versions of the law, but article 106 is the same).
From reading Article 106-1, I think it meant that for works completed before the WTO date (1 Jan 2002), if those works haven't obtain copyright under the previous versions of the law, and are still under the copyright terms of the current version of the law (e.g. death+50 years), the current law shall apply to those works (there are some exceptions for foreign works, but that's not the subject of discussion).
Article 117 also states Article 106-1 shall take effect on the WTO date (1 Jan 2002)
To me, this meant that most works created before 2002 shall be subjected to the current copyright terms, hence works that are not PD in 2002 will subject to URAA protection (with exceptions for some unpublished works, registered works and foreign works)
Article 106 has two clauses on it (quoting the English version you linked):
"this Act shall apply to works that were completed prior to the date on which the World Trade Organization Agreement took effect in the territory under the jurisdiction of the Republic of China":
where such works did not enjoy copyright under the provisions of the respective versions of this Act (condition 1, the works had copyright and expired under previous versions of the act)
but
where the term of protection for economic rights has not expired in accordance with this Act; (condition 2)
I'm not a lawyer, and I'm using now AI to help me navigate this but:
Once again, not a lawyer, but it seems like the works those whose copyright protection period expired before June 11, 1992, shall become public property because the copyright economic rights protection period has expired, and anyone may freely use them. TaronjaSatsuma (talk) 23:15, 12 March 2026 (UTC)
This introduces a new nuance: 1944 ROC law (and following ups) did include a provision (apparently, only for films) in which in order to be protected they needed to be registered (simillar to US law). Apparently, the law is retroactive for those films failing to fulfill legal register. But only for those (because the need to register in order to have copyright was only for films under the 1944 version, not in the original 1928 law) and not retroactive for works already in PD according to the then valid law.--TaronjaSatsuma (talk) 23:35, 12 March 2026 (UTC)
Indeed, this second TIPO documents seems to confirm what the "such works did not enjoy copyright under the provisions of the respective versions of this Act " in article 106 did mean: The law is retroactive but only for works not covered by the older versions of the copyright law (Movies not registered according to article 10 in 1944 law ( 電影片得由著作人享有著作權十年。但以依法令准演者為限). Indeed it's not exactly a US-like copyright registry, it seems every film was protected... unless they were censored films. For works which are not movies, the law was fully authomatic, so it will change nothing on the restoration proposal of deleted photos.--TaronjaSatsuma (talk) 23:53, 12 March 2026 (UTC)
The first statement by TIPO is referring to registered works. Please note that prior to 1985, all works are required to be registered in order to have copyright protection, so not just for films.
You can see this in Article 1 of any versions prior to 1985, which states "works that are registered according to this law shall have copyright". This register system was abolished with the 1985 law, and it was changed to the current system of "automatic copyright upon creation".
The 1990 text clarified (in Article 50-1, as you quoted above) that the 1985 law will restore copyright for unregistered works published after 10 July 1965. These works subsequently have their copyright terms extended under Article 106 of the 1992 law.
To me, the 1990 text also meant that unregistered works published before 1965, still have not "enjoyed copyright" under any versions of the law, until the Article 106-1 came in effect in 2002, and restore copyright to them.
The fact the register system exist before 1985 is exactly the reason why I specified there are exceptions to registered works. It has a slightly different calculation for their copyright terms, hence it is more complicated (similar to the registered works in the U.S.)
However, to my understanding, currently there isn't a digital system to check for past registration records in Taiwan (unlike the U.S. Copyright Public Records System), so not sure how people here in Commons can check if a particular work was registered or not.
Thanks for the nuance. All works had to be registered
Same
Unregistered works [only those] had its copyright extended, as clarified in 智著字第09300006140號 and 智著字第0920008530-0號. Registered works with their original copyright term expired are considered PD.
Yes, the system is complicated, but the current guidance and explanation is wrong. Works properly registered under 1928-1965 copyright law whose term expired before 1992 (indeed, before 1954/64/74) are PD. This should be explained, and those files should be in Commons.
IDK if there is a registry, but we can assume, at least, for movies, that any film not censored by the government was indeed registered (same for magazines; otherwise, they would not be able to publish it in a military dictatorship with censorship such as Taiwan). For photographs, especially non-professional ones, it can be tricky.
This simplifies the text of the future Guidance text: unregistered works from before 1965 are also PD.--TaronjaSatsuma (talk) 10:18, 13 March 2026 (UTC)
Curent status of works
Registered works by people dead by July 11, 1955 (+30 years: 11th July 1985)
Registered corporate works made in July 11, 1955 or before (+30 years: 11th July 1985)
Registered photos and videos made in July 11, 1975 or before (+10 years: 11th July 1985)
Registered translations made in July 11, 1965 or before (+20 years: 11th July 1985, very rare to have in Commons)
Any unregistered work made before July 11, 1965--TaronjaSatsuma (talk) 10:18, 13 March 2026 (UTC)
In terms of your undeletion request, you can see the different copyright terms for old photographs in Taiwan at {{PD-ROC-oldphoto}}, or you can see a more detail explanation (in Chinese) in this page. Thanks. Tvpuppy (talk) 00:54, 13 March 2026 (UTC)
The undeletion request is the undeletion request, we can talk about it in the specific pages. We have undeletion petition for works made in Taiwan, in the Mainland, for pictures, films and paitings. Each has a different case. TaronjaSatsuma (talk) 09:37, 13 March 2026 (UTC)
As I stated before, the paragraph in 智著字第09300006140號 (the first TIPO statement you quoted) are specifically referring to registered works, so it doesn't contradicts with my statement about unregistered works. The paragraph is simply stating for registered works that entered PD before the 1992 law, they would remain in PD even if the 1992 law extended the copyrighted terms.
Please note that 智著字第89007299號 (the second TIPO statement you quoted) was made in 29 August 2000. The statement did use the term "Article 106-1", but the text TIPO quote is definitely Article 106, not Article 106-1. So, the statement was probably referring to Article 106 only.
This means when that statement was made in 2000, it was definitely true that unregistered works published before 1965 was still in PD, since they do not meet the requirements of Article 106, which previously came in effect in 1998.
Article 106-1 (the important part) only came in effect in 2 years later in 2002, as dictated by Article 117 which states Article 106-1 to 106-3 shall come in effect on the WTO date. Only then in 2002, unregistered works published before 1965 have their copyright restored retroactively.
Please see this TIPO statement from 17 September 2003, which states, "又我國自九十一年一月一日加入WTO後，之前未曾依我國歷次修正施行之著作權法受保護之電影著作，將依著作權法第一百零六條之一回溯保護著作公開發表後五十年，亦即原先在我國未曾受著作權法保護之本國及外國人著作，將因適用回溯保護之規定而受保護（即四十一年一月一日至七十四年七月十一日間發行而未註冊之影片將因本條文規定仍受著作權法保護）".
Note that they specifically used the term "回溯保護", which means "retroactive protection".
The sentence in bold roughly translates to "unregistered films released between 1 January 1952 and 11 July 1985 will still be protected by copyright law under the provisions of this article". The sentence is referring to films because TIPO was answering a question about films, but I think it would apply to any unregistered works from 1952 to 1985.
1) Ok, I understand now. Obviously, we should focus on analizing both the registered and unregistered works
7) Ok, good find. I must admit I'm starting to get lost on details, but I get the 2002 law did override some of the conclusions I had arrive.
Focusing on what we can agree (changing the wording in PD-Taiwan, even creating a new template if necessary):
What is PD in Taiwan (and compatible with URAA)?
Registered works by people dead by July 11, 1955 (+30 years: 11th July 1985)
Registered corporate works made in July 11, 1955 or before (+30 years: 11th July 1985)
Registered photos, sound works and audiovisual works made in July 11, 1975 or before (+10 years: 11th July 1985)
Registered translations made in July 11, 1965 or before (+20 years: 11th July 1985, very rare to have in Commons)
Any unregistered work made before July 11, 1965 Any unregistered work made before 1st January 1952 (+50 years after creation in the time URAA was effective)
Taking into consideration the current discovering only affect works registered, perhaps instead of changing the existing templates should we create a PD-ROC-Registered template? I believe using ROC as name is better because it covers both Mainland and Taiwan period, but it could be named PD-Taiwan-Registered too.
Also, I'm unsure if the right date should be July 11 or January 1 (although I believe de facto will always be January 1 because works fall into PD at the begining of the year). @Tvpuppy: What do you think about this? TaronjaSatsuma (talk) 20:00, 13 March 2026 (UTC)
As I mentioned before, the copyright terms calculation for registered works is more complicated, so I cannot be sure if your calculation are accurate. However, I have some comments:
Registered works that entered PD before 11 June 1992 is in PD on the URAA date. This is because Article 106 of the 1992 law states the 1992 law only applies to registered works that are still in their copyright terms. This means the copyright terms of registered works whose copyright has expired in 1992 were not extended under the 1992 law, hence remained in the PD ever since.
For some registered works, there is a distinction between the creation date and publish date. This is because between 1985 and 1992, the copyright terms are calculated from the creation date. However, prior to 1985 and starting from 1992, copyright terms are calculated from the publish date. It is possible for works to be created and registered before 1985, but wasn't published until before 2002. This means the calculation might be different for those works.
I agree "PD-ROC-Registered" is more suitable than "PD-Taiwan-Registered", as some works might be registered to the ROC government when ROC still governed mainland China before 1949.
The concept of "works fall into PD at the beginning of the year" was only first introduced in Article 35 of the 1992 law. Prior to 11 June 1992, works fall into PD on the date it was created/published.
Proposal created. Feel free to modify it. I'm unsure if copyright runs after the public release or after the registration, but I did my best to create a first draft. Feel free to improve it.--TaronjaSatsuma (talk) 12:32, 14 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:16, 21 March 2026 (UTC)
Input requested on maps showing projections of the future
While looking at wanted categories, I noticed groups of categories for future years similar to these:
There are similar categories for places other than continents. There are also some categories that have been defined, like the first one listed here.
The issue is that our terminology "<year> maps" usually means maps produced in the indicated year, not maps showing data for that year. These categories were obviously not produced that 2028. Most of the content of these and similar categories I've looked at show demographic projections, so they don't represent actual data.
So these categories need to be named differently, but how? "Maps of Africa in 2028" wouldn't work, because the data doesn't represent a real situation. Maybe "Maps of Africa showing projected 2028 data"? Something else?
Since some of these have been created already, we might need to look at those to move maps of projected data into different categories.
@Tvpuppy: : pinging you because you created the Africa map listed above, and you edited Template:Map showing old data, which is used in at least some of these categories. (Do we need a separate template for maps showing projected data?) --Auntof6 (talk) 12:14, 17 March 2026 (UTC)
An extensively populated cat of that type is Category:2050 maps of the world. For non-ancient maps, the year in the cat title refers to the year of the data shown. For ancient maps that's more or less the same as the year the map made. It would be best if the cats for future dates are renamed or if subcategories for these are created. Maps of projections for the future that is now the past or present also need to be considered. You can find many or most, possibly nearly all such files via Category:Future and Category:Prediction (I've added most of these data graphics to these two cats and their respective subcats for maps).
A related issue exists for charts showing data also for the future (projections). I created for example Category:Charts showing data and projections through 2025 but there aren't many of these (sub)cats. (Again, they could be built using the two aforementioned cats). Prototyperspective (talk) 16:49, 17 March 2026 (UTC)
@Auntof6, there is a related discussion above at Commons:Village pump#Maps from Our World in Data. Not sure what is the best solution for future maps, but in the other discussion, they have created specific templates for OWID maps showing past data. Those templates will categorized these maps into a special OWID category under the "YYYY maps of each continent" category (e.g. see Category:1940 maps of Africa).
Perhaps we could try using this solution for these future OWID maps as well, or maybe the templates needs some adjustments for future maps. Thanks. Tvpuppy (talk) 19:44, 17 March 2026 (UTC)
Is there a way to move a batch of categories named ...
Is there a way to move/rename a batch of categories named "old alphabetic character string including spaces"+"numeric character string" to "new alphabetic character string including spaces"+"numeric character string"? The old category should be removed. For instance, I want a category named "Canadian National 1234" renamed to "CN 1234". Also, "Canadian Pacific Railway 1234" renamed to "CP 1234". In addition, all child categories should be updated to include new parent names. I suppose there should be a script that does all that. My-wiki-photos (talk) 02:29, 24 March 2026 (UTC)
To clarify, that script should rename a batch:
Canadian National 1234
Canadian National 5678
Canadian National 9012
Canadian National 3456
Canadian National 7890
Regardless of whether such a script exist, this is not a purpose for which you should use it. The current category names are preferable. Pi.1415926535 (talk) 03:49, 24 March 2026 (UTC)
I agree with Pi.1415926535. You are asking to move categories to less broadly comprehensible names. - Jmabel! talk 06:53, 24 March 2026 (UTC)
I disagree. These category names are not consistent across different railway companies. For instance, for Canadian National Railway, it's "Canadian National #number"; for Canadian Pacific Railway, it's "Canadian Pacific Railway #number", etc. What would the category name be for Canadian Pacific Kansas City Railway? The category name "Canadian Pacific Kansas City Railway #number" is just too long. These category names are all over the place. So, inconsistent. The short names for such railway companies are very well known: CN, CP, CPKC etc. Furthermore, these categories are child categories of the categories with full railway companies names, so its use is therefore justified, and moreover consistent. I hate to see the inconsistency in their current names. My-wiki-photos (talk) 09:48, 24 March 2026 (UTC)
The category name "Canadian Pacific Kansas City Railway #number" is not too long if it simply is the best name to identify the train.
The short names for such railway companies are very well known: CN, CP, CPKC etc. Perhaps these acronyms are well-known to you, or to people who are interested in railways in Canada, but I think most people will not associate these acronyms with the Canadian railway companies. For example, please see the disambig pages of en:CN and en:CP, which the acronyms can mean a lot of other things.
I think the rule of thumb is acronyms should only be used if they are internationally well-known, such as Category:USB or Category:NASA.
If you look at this category for instance: https://commons.wikimedia.org/wiki/Category:Canadian_National_2344, you will see that one of its parent categories clearly identifies the full railway company name. It is the standard for this type of category with the acronym, which is always visible on a locomotive, plus its number. So, at least, the company name in such categories is redundant. Plus, long names contribute to inconsistencies in naming conventions, which I hate to see. My-wiki-photos (talk) 10:59, 24 March 2026 (UTC)
The category names should stay as is.
As for CPKC, the locomotives do not hear that reporting mark, they are either CP or KCS even when repainted.
As others have said, it's best to keep using the spelled out name. Wolfy13399 (talk) 13:05, 24 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 13:22, 24 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 21:29, 25 March 2026 (UTC)
I recently used Nero AI denoiser and the results are a bit hyper-real and there is a certain "lie factor". I wonder if there are any guidelines on the use of such tools - should the manipulations be documented as part of the image description? If so what are the essentials? I think keeping the original also on Commons might be a good guideline. Thoughts suggested by this. Shyamal L. 03:45, 23 March 2026 (UTC)
@Shyamal, for restoration of photos, you can get a more authentic result by asking at the Graphics Lab. Moiré and halftone can be easily removed without AI. JayCubby (talk) 22:12, 23 March 2026 (UTC)
@Shyamal, there was also a recent discussion last month that led to a new guideline (currently a draft, still!): Commons:Upscaling. Your comparison image of Mr. Buck could also be used as an example for what can be done with AI but ideally shouldn't. --Enyavar (talk) 12:43, 25 March 2026 (UTC)
Importing from lokalhistoriewiki.no?
This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 21:29, 25 March 2026 (UTC)
I don't think it's a good idea to have threads here about unused individual files, especially when it's unclarified what you'd like to have changed and/or what your concern is. The file could be renamed, see Commons:File renaming or be nominated for deletion. Prototyperspective (talk) 13:24, 25 March 2026 (UTC)
Fixed for what purpose? I see no use case; it was apparently used by the uploader as a base layer for File:Africa road5.svg. The latter displays an incorrect O-o-A theory. Both images are unused, I will support a deletion request. --Enyavar (talk) 13:40, 25 March 2026 (UTC)
Why delete? Is there anything inaccurate about this map, or any problem with its licensing? - Jmabel! talk 23:49, 25 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 11:40, 26 March 2026 (UTC)
How can I add a template to multiple files?
I need to add a particular template (Supported by Wikimedia Österreich) to most of my new uploads. Until now, I have added it manually to each file, but this is a rather tedious process for larger photo sets I intend to upload. Is there a possibility to add a template to multiple files at once? Thanks! Aciarium (talk) 09:08, 26 March 2026 (UTC)
Thank you, this is what I was looking for! Aciarium ⚒ (talk) 13:48, 26 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 11:42, 26 March 2026 (UTC)
Flickr and restricted downloads
Has anyone found a way to download the highest resolution version of an image from Flickr, when the image is copyright-expired, but "The owner has disabled downloading of their photos"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:20, 19 March 2026 (UTC)
You can try viewing the highest resolution version and find the source URL, hover over the image and hit Ctrl+Shift+C in Chrome. A docked window opens and the highlighted HTML block could reveal the URL. --PantheraLeo1359531 😺 (talk) 17:11, 19 March 2026 (UTC)
@Pigsonthewing can you provide an example Flickr file or album? Thanks, -- Ooligan (talk) 00:34, 20 March 2026 (UTC)
I have a solution: The Web-Developer toolbar (for various browsers; I use if in Firefox); view the largest image, then open the toolbar and select then "Images -> "View Image Information". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:26, 20 March 2026 (UTC)
Photo → view all sizes → select the highest size → click the right button of your mouse save page as → save complete page → find photo in the uploaded folder. Does it help? Юрий Д.К. 13:41, 20 March 2026 (UTC)
should be easy to make a script to automatically do that. RoyZuo (talk) 21:36, 21 March 2026 (UTC)
It would benefit the most people or at least more if that was added to the open source addon linked above; could not find an issue about this there. https://github.com/qsniyg/maxurlPrototyperspective (talk) 21:58, 21 March 2026 (UTC)
Dan Breen: wrongly identified
The image File:Dan_Breen, circa 1920s.jpg refers. It appears on the en:Dan Breen article (a deceased Irish republican). The provenance is RTÉ, Ireland's national broadcaster, and I have asked them about it.
That Talk page has an item from a relative of Breen informing us that this image is not of Dan Breen but his younger brother Laurence "Lar" Breen, an Irish republican himself. I emailed this Mr O Riain as follows:
It came from RTÉ but the page in question is no longer available: https://www.rte.ie/news/2021/1129/1263845-the-treaty-debate-a-close-run-thing/
Can I ask how you know that this pic is of Laurence and not Dan? Fwiw, I suspect you are correct, for while there is a resemblance, it does not appear to be the same person.
While I'm not an administrator on Wikipedia, if there is any photographic evidence you can send me or point me to in order to prove that a mistake has been made, I will try and pass it on.
Reply: "I am delighted to hear from you, I've had to raise this issue with a number of people over recent years. The reason I am so sure about this that I happen to be a Grandnephew of both Dan and Laurence Breen. Their Brother Patrick Breen was my Grandfather and his daughter Josephine Breen was my Mother. I regret to say I don't have another photo of Laurence Breen(He died in the USA in 1940).
Paud Ó Riain"
What is the best way forward? I am happy to receive a message or messages about this.
Now that there has been no contrary evidence about the identity of the person in this image, is it in order to ask an admin. to rename it to: File:Laurence_Breen, 1920s.jpg and to identify the subject as: Laurence ("Lar") Breen, Irish republican and younger brother of Dan Breen
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 13:02, 27 March 2026 (UTC)
@PantheraLeo1359531, for {{Decade years navbox}}, the parameter padding is the string added after the prefix and before the suffix. It is currently default as a single space, but you can set it as an empty string. Thanks. Tvpuppy (talk) 12:12, 28 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. --PantheraLeo1359531 😺 (talk) 12:15, 28 March 2026 (UTC)
Increase text size
Hello, I was wondering if there is a way to adapt the size of text and images here on Commons. For one or another reason, today the images and text appear smaller than on the other chapters. Thank you so much for your help. Lotje (talk) 15:48, 28 March 2026 (UTC)
@Lotje: This may be browser-dependent. In my browser (latest Chrome on latest Windows 10), Menu / Zoom is affected by Ctrl-NumberPadPlusSign(or MinusSign) and Ctrl-mousewheel-up(or down). As this effects all tabs in all Chrome windows, it can take a little while to become visible. Sometimes, without warning, the zoom level will revert from my main 90% to 100%. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:11, 28 March 2026 (UTC)
@Jeff G.: thank you so much for coming back on this one. Do you also know what happens with a version Windows 11? Lotje (talk) 16:18, 28 March 2026 (UTC)
@Lotje: No, but if this behavior is not on other sites you use with that browser, it may be due to the new "Appearance / Text" in the new default skin Vector (2022) - see the "Skin preferences" in special:preferences#mw-prefsection-rendering and change "Text" from "Small" to "Standard" or "Large", then save that setting and refresh any page other than your preferences. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:30, 28 March 2026 (UTC)
@Jeff G.: Y're a star. It is normal again Thank you very, very much. Lotje (talk) 16:46, 28 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. --Tvpuppy (talk) 01:25, 29 March 2026 (UTC)
Neutrality and "Wiki loves Ramadan"
Hi everyone, am i the only who wonders what presence is given to the competition "Wiki loves Ramadan" by advertising it on the main page and on banners. For our big three competitions, WLM, WLE and WLF i understand such a promotion since their topics are neutral, for WLR i do not understand it. In my mind, there should be a policy of neutrality for main page advertisements and banners. PS: My comment is not about the WLR itself, but about the question if it should be advertised on same level as WLM etc. --Arnd 🇺🇦 (talk) 15:44, 17 March 2026 (UTC)
In fact, I did feel offended. Not exactly for reasons of Christian belief ... but where is "Wiki loves Lent (Fastenzeit, Carême, Quaresima)"? Where is "Wiki loves Easter"? ... or, on a more general scope, "Wiki loves Christianity"? -- Martinus KE (talk) 16:29, 17 March 2026 (UTC)
I don't think there is any reason why we couldn't have a Wiki Loves Lent or Wiki Loves Easter or Wiki Loves Passover or Wiki Loves Holi for more examples. Abzeronow (talk) 03:25, 19 March 2026 (UTC)
I think this is a good call and would suggest that instead the competition/campaign is made broader so as to be about religious practices or religious festivals. Additionally, I find many campaigns like this one slightly problematic since there already is good free media coverage of the subject but lots of other subjects without any such challenges are missing media files with lots of gaps. Prototyperspective (talk) 16:35, 17 March 2026 (UTC)
While Commons is not bound by the RfC linked above, there are good points brought up there. I think one of the best points is that the standard naming "Wiki Loves [X]" implies more of a celebration/preference than the reality of such projects entail. It's really more like "Wiki Documents [X]" (although that wording is perhaps drier than it needs to be -- I don't have a good alternative). "Document Ramadan With Wiki" maybe better. I, too, am uneasy with explicitly religious events advertised to everyone across the project, but appreciate that it's not realistic to disentangle religion and culture, which overlaps in some places more than others. —Rhododendritestalk| 19:20, 17 March 2026 (UTC)
I was aware of that when commenting and here is a RfC about that m:Requests for comment/Wiki Loves X. The (main) issue however is not with the naming but with the campaign topic where a suggested potential action could be to broaden it to religious practices or religious festivals or even religions overall. Prototyperspective (talk) 19:24, 17 March 2026 (UTC)
This particular event is timed to coincide with the month of Ramadan (18 Feb - 19 March this year) - even if the name or description of the campaign were changed, it's still inherently focused on one cultural event. Omphalographer (talk) 22:54, 17 March 2026 (UTC)
I propose(d) to change the timing too. Prototyperspective (talk) 22:56, 17 March 2026 (UTC)
i have an idea: "wiki looks at xxx", so it sounds neutral and keeps the acronym. RoyZuo (talk) 20:46, 17 March 2026 (UTC)
I agree that something like this is better language. It also irritates me to no end that it's "wiki loves x": there must be a better way to name that than anthropomorphizing wikis. —Justin (koavf)❤T☮C☺M☯ 23:17, 17 March 2026 (UTC)
Comment, on a side note, I expect the main page will change to promote Wiki Loves Africa 2026 after Wiki Love Ramadan ends this month. Do you think promoting this event on the main page (which have been done for the last 4 years) have neutrality problems as well, since it only focus on a specific continent? Thanks. Tvpuppy (talk) 00:00, 18 March 2026 (UTC)
Are there campaigns for other continents too? If so, which and why not the remaining ones? Prototyperspective (talk) 00:03, 18 March 2026 (UTC)
I don't think so, other than Wiki Loves Africa, I don't know any other continent-specific campaigns. There are some country-specific campaigns in the past (e.g. Wiki Loves México, Wiki Loves Sudan), and given their smaller scale, it makes sense these have not been promoted in the main page before. Thanks. Tvpuppy (talk) 00:28, 18 March 2026 (UTC)
They are sort of neutral, in a sense they at least pick different subjects. For example, there was Wiki Loves Pride, it was also criticised, but by different groups of users. If they equally represent concepts "loved" by different social groups or cultures, it might be not big issue. MSDN.WhiteKnight (talk) 04:54, 18 March 2026 (UTC)
My vote is clearly against Wiki loves Africa. For Asia, the corresponding campaign is Asian Month, so I'd rather have the Africa campaign also named that way.
Just imagine it the other way round: What amount of protest would be triggered by a campaign called Wiki loves Europe, or even Wiki loves Catholicism? My guess is that the protesters would get quite vocal ...
In the end, it depends on whether we want to have a somewhat neutral Wikipedia or an activist Wokipedia (as it's nicknamed by conservatives). -- Martinus KE (talk) 07:53, 18 March 2026 (UTC)
Sounds like a good idea. I just think the issue is not with the name but with the focus on a narrow subject where the other equivalent subjects do not have such campaigns. One idea would be to have campaigns for these too and not unlikely contributors interested in that could somewhat-readily set them up; another idea would be to broaden the scope so those other subjects can participate too. I don't think a Wiki loves Europe campaign would get much protest and for continents or large territories/regions like that it may make more sense to also run campaigns for equivalent subjects instead of broadening scope so I'd suggest somebody sets sth like that up (eg Wiki loves Europe, Wiki loves European Union, Wiki loves Oceania etc). If there are concerns that we have lots of media about the subject already or that there are no/very few media gaps etc – that applies more to Ramadan where I doubt there's still important media gaps to close when there's a whole campaign about that particular religious practice. Prototyperspective (talk) 13:41, 18 March 2026 (UTC)
This project supports European users very well. Nine out of the ten largest Wikipedias are European, with the exception having been threatened to get shut down because of the use of bots to make it larger. You speak Dutch, as 22 million people do? We have a Wikipedia with 2 million articles for you. You speak Welsh, as a half million do? We have a Wikipedia with a quarter million articles. You speak Hausa, as a 100 million people do? Have a Wikipedia with less than one hundred thousand articles. We have extremely good coverage of Europe, and pretty poor coverage of Africa. But, no, it would be unfair to support Africans in one way if we don't support Europeans in the very same way.--Prosfilaes (talk) 05:51, 19 March 2026 (UTC)
The German chapter also had a campaign Wiki Loves Democracy. We should not make guidelines, who can use this slogan as long as they are within our project scope and values. The question how large and global a campaign has to be, to be featured on the main page, is a different topic. There I think we should have some kind of guideline. GPSLeo (talk) 06:37, 19 March 2026 (UTC)
as a anti-islamist wikimedian, i believe this project is good for getting information from muslim communities. in year passed, muslim people getting more technology and know wikimedia better. we are the ones who bring information to them. i Support this project. yes, it is looking un-neutral, not secular... but in life everything has flaws. modern_primatඞඞඞ ----TALK 20:04, 18 March 2026 (UTC)
+we should do more projects like this. for people who got geting more and more access to internet. modern_primatඞඞඞ ----TALK 20:05, 18 March 2026 (UTC)
So is this campaign about Islam in general and not just the religious event called Ramadan of the religion Islam? Prototyperspective (talk) 22:44, 18 March 2026 (UTC)
Wiki loves Ramadan is basically a promotion campaign to get more images of Ramadan on commons. Cyberwolf (talk) 15:46, 19 March 2026 (UTC)
Support for RoyZuo's idea of "wiki looks at Topic", that is a much more neutral way to communicate what we are doing. "Wiki loves trees" sounds like we are superficial hippies, "wiki looks at trees" is telling that we encourage studying the topic. Not sure if the Wikilove groups can easily rebrand, but I would love it. To encourage people to upload media about sanitation, we can hardly campaign on "Wiki loves sewage".
(That said, I would not be against "wiki loves Easter" or "wiki loves Holi" either, although there are already plenty of Easter images so it is kinda hard to justify promoting it further. "wiki loves Lent", maybe.) --Enyavar (talk) 12:54, 20 March 2026 (UTC)
id agree unsure for what to call it tho. The whole wiki loves is to provide an encouragement that we value the images. But yeah in this case its odd Maybe “commons loves photography of (subject)” Cyberwolf (talk) 12:59, 20 March 2026 (UTC)
I get that keeping the "L" saves a little branding effort, but "Wiki looks at X" sounds contrived. Why not something more descriptive like "Wiki Documents X"? — Huntster (t@c) 18:33, 21 March 2026 (UTC)
or we could use a single umbrella term: "wiki media drive" (like blood donation drive). for each different topic simply append it like "wiki media drive - xxx". RoyZuo (talk) 09:08, 22 March 2026 (UTC)
It is highly strangely to see here what is indistinguishable from promotion of a particular religion. Sneeuwschaap (talk) 01:38, 22 March 2026 (UTC)
Wiki also loves Folklore etc. This seems to be much more about the subject matter and we, of course, want photos of Ramadan, like all religious festivals. Secretlondon (talk) 07:41, 23 March 2026 (UTC)
Well the discussion about the naming continues. I don't see a big problem with the name – the issue is that the campaign is about one specific religion where there are no campaigns for other religions or it being about religious practices overall; can we now also discuss this please and not just the name? Prototyperspective (talk) 11:36, 23 March 2026 (UTC)
Wiki loves Folklore is also about folk religions. Nakonana (talk) 13:54, 23 March 2026 (UTC)
Automated OCR for images of text
Are there any plans to detect images of text, and automatically run OCR on them, and add the text to the entry? We have lots of news articles without the text, and captions on news images that have not been transcribed. RAN (talk) 18:28, 19 March 2026 (UTC)
Someone showed me (maybe you!) ocr-test.wmcloud.org a few month's ago. It is amazing. Newspaper.com has done a terrible job with OCR so has the New York Times. Ones that were unreadable from both, have been 95% corrected using wmcloud. I am rerunning all the ones that were not readable through again and migrating the text to Wikisource. I just read that Newspapers.com is rerunning all their OCR again using a new AI-OCR. --RAN (talk) 22:42, 20 March 2026 (UTC)
I more familiar with JPG/PNGs because I work with them, so there is my interest. I imagine the pdfs can be run through Adobe and have the text mapped. --RAN (talk) 16:32, 23 March 2026 (UTC)
Categories for exact dates
Do we have categories for exact dates, so that I can click and see what news articles we have for that day? Generally news articles are categorized by the publication and the year. See: Category:The New York Times, 1920RAN (talk) 16:36, 11 March 2026 (UTC)
Yes, I am right now sorting clips of uncategorized weather maps into these by-day categories. Also, when I come across a newspaper file, I add the day category, but I am not aware of any systematic effort to sort newspapers into these categories. The last time I suggested to do so was in 2024, see the full discussion here. I would support this idea, but also suggest getting support from bots if possible. --Enyavar (talk) 17:26, 11 March 2026 (UTC)
Yes, that would be it. I was trying the wrong date formatting, and I could not find an example. Should it be News articles published on 2026-03-11, or just Articles published on 2026-03-11 so it can contain magazine articles, or just Works published on 2026-03-11, to be as broad as possible? Or should news articles be categorized by the day of the event, not the day published? News travelled slower in the past. That way someone looking up a day during the American Civil War would see the events of the day, not a day or two later, when it was published. --RAN (talk) 18:50, 11 March 2026 (UTC)
Should news articles be categorized by the day of the event, not the day published? News travelled slower in the past.
In this case, there should be a category for the day the article is published, and one for the subject the article is about. "Works published on..." would be a suitable parent category with "Articles published on..." being one of its subcats. ReneeWrites (talk) 21:58, 11 March 2026 (UTC)
Re "Works": Here I don't think we need to consider other periodicals, or books. The exact date of publishing is not too relevant with a scientific journal, so I don't think they would need to be categorized by date. The same with monthly periodicals: these are not daily newspapers, and should be categorized by month of appearance, even if they do have a day-date. That means, "Works published on..." (date) is really superfluous in my opinion, and will just lead to more fractures in the category tree. For example, 1876-06-09 is the exact publishing date of Twain's Tom Sawyer, but we do not need a category for "Novels published on 1876-06-09". Rather, "1876 novels" is precise enough, and "1876 books from Chicago" for the 1st edition (year book location-scheme). Ergo: Publications/Works where the publication day really matters, are (daily+weekly) newspapers, but little else. That is, I'm looking at the matter with pre-internet publications in mind. Post-1990 and post-2000, things may be different.
Then, RAN might have mixed two slightly different subjects in the comment above, namely newspaper issues (the full publication, or whole pages) and newspaper clippings (singular news articles). I think these should be approached differently.
I'm strongly supporting the idea of just categorizing newspaper issues only by date of publishing. In the times when news travelled at the speed of horses or sails, the same newspaper issue would contain stories about events that happened weeks and days ago, along with the local news of yesterday and today. Our users just should expect on their own that an earthquake that happened in Chile at a certain date in mid-19th century, would not appear in a London newspaper on the same day. Also, a weekly newspaper would still be filed by date of publication.
That said, a newspaper clipping of just a single story, should instead be categorized by the date of the event that is described in it. For example, 1921-06-22, but not 1921-06-23, despite being taken from a publication of the latter day.
I think that country subcategories will come up sooner than later, so I want to consider them early. That doesn't mean we should create by-day categories single newspapers, of course. But it still means several different patterns could be established, here I'm going for an example: "Newspapers of the United States, 1899-09-14" or "United States newspapers published on 1899-09-14" or "1899-09-14 newspapers of the United States". All three suggestions fit the existing patterns, I would say. My favorite would be the third: "<date> newspapers" and possibly "<date> newspapers of <country>" --Enyavar (talk) 05:19, 12 March 2026 (UTC)
Would you also prepend the country name, as also established with the photos? That would fit the second suggestion in my post above.
Another thing, would you also change the category names of the year? Right now, we have "Newspapers of the United States, 1826" but also 1826 newspapers of the United Kingdom. Once we take on the daily format, the year categories could be changed to "Newspapers of <country> published in 1826", which also has the advantage of more clarity. In that way we could harmonize the two rivalling category structures. (Just a suggestion to ask if someone else sees that need; needs further debate in a CfD.) --Enyavar (talk) 16:26, 12 March 2026 (UTC)
Some categories for exact dates are hidden and some are not, what should we standardize on? --RAN (talk) 18:50, 12 March 2026 (UTC)
I guess that photos of monuments/buildings that don't change daily don't need to have a visible by-date-category for the photos that depict them.
But newspapers? Hiding media by making the categories inaccessible is the best way for nobody being able to find them. I would think that these new-to-implement newspaper-by-day categories, however the name, should not be hidden. --Enyavar (talk) 14:39, 16 March 2026 (UTC)
I suppose I can add in two date categories for some news articles. The day of the event and the day of publication, if there is no event category. Where there is an event category, just the day of publication. --RAN (talk) 16:50, 19 March 2026 (UTC)
With merely events that are reported, I am currently just assigning the day-categories for the actual event, for example 1631-09-15, 1896-01-07. At least for historical timespans before 2000, I think that "events on 1985-09-31" is too granular for the events-category. After all, we are already subdividing events by location as well, and the logical consequence of maintaining location-categories (1985 events in New York City, Berlin, etc) and also the day-event category is that someone else eventually has the glorious idea to create "1862-03-03 events in Weingarten (Württemberg)". There is always such a someone-else, just give it a few years and the topic will come up. And that will lead to very narrow category definitions within un-navigable cat-trees, containing single-file entries like the example for Weingarten that I linked above. Which is the reason why I am not wholeheartedly support the idea of "events by day".
For whole paper issues, I don't think we have a problem, except one suggestion: I had concerns before about subdivisions by country... Right now, I think we should subdivide by language first and foremost: Spanish-language newspapers are produced in many countries, but all Spanish-speakers can read them, and it matters less when we only have 1 newspaper from Uruguay and 1 from Peru and 2 from Mexico and 3 from Spain. Similarly, most English-language newspapers are produced in UK and US, but that subdivision could take place one step down, if at all. Which means my preferred idea is for the substructures to look like this:
Looks good! --RAN (talk) 16:45, 24 March 2026 (UTC)
Cool. Provided that everyone else also agrees, these would be the next steps:
Creating the template Template:Newspaper date navbox that works essentially like Template:Date navbox but does create subcategories of the latter with essentially this content: [[Category:YYYY-MM-DD]][[Category:YYYY newspapers by day]]
Starting to create and fill the category structure. This breaks down into several parts:
identifying the publishing date of all newspapers in our digitized newspapers on Commons. A lot of archives available on Commons are already filled-out descriptions like | date = 1896-10-09; for these it is incredibly easy. Other archives do not have full descriptions, but the file names still provide follow a scheme that can be converted into ISO-8601.
categorize them by the identified date (Newspapers published on YYYY-MM-DD) and
create the respective categories (both for the newspapers and for the date itself) where they don't yet exist
Where possible and necessary: subdividing per language as per above.
For the timeframe of 1850-1950 alone we can expect up to 36'525 newspaper categories, and that is also the timeframe where I think we have the most publications. For practical reasons, I would suggest starting with newspapers that were in publication in 1899 and categorize them completely for all years they were published. Then expand to earlier newspapers going backwards until none remain. Then expand to later newspapers going forward until none remain.
... Wow. This is certainly a sizeable project, maybe it requires a project page to coordinate all that work. Disclaimers: I do not know how to create such a complex template as the one I proposed above; I do not know how to program and task bots; but I do have years of work still to be done on Commons. Which is why I don't volunteer much more than just ideas here. --Enyavar (talk) 21:00, 24 March 2026 (UTC)
Currently disambiguation categories say: "This category page should not hold any files." but most disambiguation categories do contain files because there are images and news articles that cannot be disambiguated without more information. There may be a John Smith in a news article/image, but no clue as to which John Smith. Should the warning mention that any images in the category need further disambiguation? I want to make sure people do not remove the files because of the wording. RAN (talk) 20:53, 22 March 2026 (UTC)
All of those files in disambiguation categories are problems waiting to be solved, and clear out the disambiguation category. But perhaps a rewording about should be diffused to zero or some such might be more appropriate. - Jmabel! talk 22:25, 22 March 2026 (UTC)
... or "This category page should ideally not hold any files." --NearEMPTiness (talk) 05:58, 23 March 2026 (UTC)
+1 – this needs a change at Template:Disambig; specifically Template:Disambig/en for the English version. Additionally, it would be good if a page about disambiguation that explains what it is was linked. Apparently none such exists or did I just not find it? Commons:Disambiguation redirects to an essay. Alternatively, one could add a section to Commons:Categories requiring diffusion and then redirect to that section. I think it would be useful because the page could explain things for people interested/confused and offer some backlog links and help, etc. Prototyperspective (talk) 13:28, 24 March 2026 (UTC)
The text says "should not" (describing the desired ideal state), not "must not" (describing a prohibition). I see no reason to change it, but NearEmptiness's suggestion is okay. So a +1 on that one.
Some background, I often add files to disambigs purposefully, for example when there are more people with the same name, like David Adams or when I am not able to do the disambiguation myself because doing so would require further research. I trust the wiki principle of someone else with more knowledge to step in later. But those potential others won't know that a proper category is missing when it doesn't even show up on the disambiguation page. People should not remove that category from a file just to achieve an empty disambig page; instead they should group the files about the same person into new categories that are then linked on the disambig. When that is not possible, the files should remain there - potentially for a long time. --Enyavar (talk) 12:30, 25 March 2026 (UTC)
The issue is that "should not" here is ambiguous so a certain fraction of readers probably misunderstand it and to a certain fraction it causes unnecessary confusion/required-investigation regarding what is meant. Prototyperspective (talk) 13:22, 25 March 2026 (UTC)
The wording has to be clear enough that people stop removing the images from the category unless they are further disambiguated. I only came across the problem after seeing images deleted, instead of further disambiguated. Some images may require a lot of research, or there is still not enough info today, but maybe in the future. A similar problem is removing red linked name categories. They should be added to surname categories, instead of deleted. In some cases the full name of the person depicted may only appear in the red link. --RAN (talk) 23:03, 25 March 2026 (UTC)
Question about original flag creations and COM:EDUSE
For the past couple decades, Wikimedia commons has been a magnet for amateur vexilologists to upload their original creations, usually either country flags that never existed or political flags that have never been used by any organisation or movement. Just as an example of the latter, see the category and various sub-categories for anarchist flags, which are full of original creations without any real-world usage. It seems to me that many of these files would not be realistically useful for educational purposes, as they would inherently serve a limited number of purposes, namely to mislead readers into believing this flag was associated with a certain subject or to promote the artist's original work. On various languages of Wikipedia, it has become a perennial issue for some projects, as artists try to push their original work onto articles or well-meaning people add a Wikicommons-hosted flag to an article (thinking it to be a real representation of the subject) despite it never having been used in real life or even outside Wikicommons.
I wanted to ask the community about this, as it seems to me that many of these flags fall firmly outside the project scope and liable to deletion, albeit up to consideration on a case-by-case basis. Would such original creations fit the criteria for deletion? Or will they likely be left up? In the latter case, is there any way to flag such uploads as original creations beyond the "Own work" field in the description? Cheers. Grnrchst (talk) 12:55, 25 March 2026 (UTC)
@Czar: Courtesy ping, as I've seen you expressing frustration with flag citogenesis since at least 2019. --Grnrchst (talk) 13:08, 25 March 2026 (UTC)
Thanks for posting these, I wasn't aware of these deletion categories. Seems like it's a lot more common for such requests to result in deletion than a keep. --Grnrchst (talk) 13:37, 25 March 2026 (UTC)
The categories are just scratching the surface, I'm afraid. There's probably thousands more deletion requests for fictitious flags, as well as a lot that get speedily deleted as personal images (i.e. "Flag of The Kingdom of My Backyard", etc). Omphalographer (talk) 19:23, 25 March 2026 (UTC)
I've just come across the enormous category for special or fictional flags and it seems like this goes way deeper than I'd imagined. I also found this decade-old discussion, so I'm far from the first to flag this as an issue. Perhaps a clearer policy about this specific area needs developing, or at least more bold action might need to be taken. --Grnrchst (talk) 14:53, 25 March 2026 (UTC)
Several users have over the decades contributed to the deletions of thousands of "special" flags of all kinds, each, and I count myself among them (still coming a bit short of 2000 DRs, regularly covering several flags at once though). Most of the "special" flags you see remaining here, are actually the "better" ones: those that are in use within at least one wikimedia project ("in-use" overrules "out-of-scope") and those where other users have hesitated because there is at least a flimsy source, etc. This is why we have not wholesale-deleted all of the content in the categories you pointed out.
The existing policies are sufficient in my opinion, but I agree that our current measures are rather stop-gap and that bolder action can easily be taken. Please volunteer to check the individual flags for being out-of-use AND out-of-scope, and then file the DRs. A tip: check if the same user has uploaded more fantasy files as well, the typical fake-nation has images of the flag, the coat of arms, maps, pictures of the monarch, diagrams... the whole shibang.
tl;dr: yes a lot has been done, and your help is appreciated. Whatever you do, do not forget to be kind and respectful since most flags come from different people often not aware of our policies. BEst --Enyavar (talk) 17:45, 25 March 2026 (UTC)
Thanks for the thorough response! I'll be sure to help check for flags that are both out of use and out of scope. I've already gone ahead and collected together the fictitious anarchist flags I noticed into their own category, which should at least help with sorting the wheat from the chaff in that area. I will of course be respectful of the people involved; in fact, I'm quite impressed by quite a few for their artistic capabilities, I just worry this isn't the right medium for their creations (i.e. commons is not a personal web host). --Grnrchst (talk) 21:57, 25 March 2026 (UTC)
Commons is not Wikipedia. Two archive links may be better than just one idk (may depend on how well the archival of IA works for YT videos). Prototyperspective (talk) 15:08, 19 March 2026 (UTC)
Archive today was using users ips to launch a ddos attack. It’s a security risk. The webmaster tried to generate ai porn of a blogger and extortion him with it from ars technica Archive.today maintainer sent threatsPatokallio told Ars today that he is pleased by the Wikipedia community’s decision. “I’m glad the Wikipedia community has come to a clear consensus, and I hope this inspires the Wikimedia Foundation to look into creating its own archival service,” he told us.In emails sent to Patokallio after the DDoS began, “Nora” from Archive.today threatened to create a public association between Patokallio’s name and AI porn and to create a gay dating app with Patokallio’s name. These threats were discussed by Wikipedia editors in their deliberations over whether to blacklist Archive.today, and then editors noticed that Patokallio’s name had been inserted into some Archive.today captures of webpages.“Honestly, I’m kind of in shock,” one editor wrote. “Just to make sure I’m understanding the implications of this: we have good reason to believe that the archive.today operator has tampered with the content of their archives, in a manner that suggests they were trying to further their position against the person they are in dispute with???” End quote. If this doesn’t justify a full cleansing of it here I don’t know what does Cyberwolf (talk) 15:28, 19 March 2026 (UTC)
If I'm not mistaken one can readily edit that template. You could remove the link and see if somebody complains. I think one archive link is enough but as said I don't know much about IA YT archiving. Prototyperspective (talk) 18:19, 19 March 2026 (UTC)
+1. The vast majority of archive.today links from this template simply land on a useless "no results" page anyway, as the site does not archive content without an explicit request to do so. Can someone please mark this template for translation so that we can start rolling out this change? Omphalographer (talk) 21:26, 19 March 2026 (UTC)
Everything archive.today is accused of is very convenient for creating moral panic. But in reality it doesn't even come close to outweighing its benefits. We don't have enough archive services to throw them away. There are many websites that aren't preserved in other archives. Or that even don't preserve properly in other archives. Pages with embedded posts or other complicated features often are not saved (properly or at all) in Wayback Machine, but are saved in archive.today. Blindly removing links to archive.today would create a great harm to the project. Sneeuwschaap (talk) 00:55, 22 March 2026 (UTC)
Good point(s) but do we need it for YouTube videos? Looks like IA has these archived anyway so it was a somewhat redundant link. Prototyperspective (talk) 10:49, 22 March 2026 (UTC)
You are right, in the particular case of YouTube videos Wayback Machine is better than Archive.today. It saves not only descriptions, but sometimes even the videos themselves. Sneeuwschaap (talk) 23:26, 22 March 2026 (UTC)
I appreciate the desire to archive for future reference, but relying on a site that has shown a willingness to co-opt users' systems to attack others is beyond irresponsible. Archive.today and related sites need to be blacklisted. — Huntster (t@c) 13:39, 22 March 2026 (UTC)
Maybe, current manager of Archive.today can be somewhat mentally unstable. Nevertheless, the service works for 14 years. And in the first years it automatically archived all links which appeared in various language versions of Wikipedia. And it contains many archives of currently dead pages which were not saved by other services. And for many websites it is incomparably better than other archives. Does the co-opting users' systems for attacks continue till now? Last time when I have read about it, the site was said to send requests with the interval of 50 minutes — in other words, practically never. Evidently, this is/was a temporary stupidity, triggered by an attempt of doxing of the site owner. Such stupidities are very convenient for criticizing and inevitably cause a moral panic, but in reality they are negligible compared to benefits of the service. Sneeuwschaap (talk) 23:26, 22 March 2026 (UTC)
I think you are confusing a "moral panic" for a "moral reckoning". Moral panic implies that there is not actually an issue at the heart of the community's concern. There is absolutely an issue here, and it's much more than a "temporary stupidity". The developer of the archive leveraged its widespread use to aim a DDOS attack at someone they dislike, threatened to change information in the archive in order to slander perceived enemies, and has basically been throwing a fit since this became public knowledge. We underestimate the damage done at our own peril. Honestly, we should never have allowed such a tenuous and legally dubious archive service to become so essential to any Wiki project; we should've seen something like this coming from a mile away. 19h00s (talk) 23:36, 22 March 2026 (UTC)
Reckoning must be rational, not moral. The fact is that the service has been providing verifiability of many sources for many years. In many cases, with no alternatives. With no evidence of harm to the users. And with no evidence of change of information on any archived pages which have realistic educational value. Throwing a fit and threats of creating a public association between a doxer's name and a porn are very terrible, but are not relevant to the case. Sooner or later the doxing-triggered scandal will end, but the archive service will remain. Sneeuwschaap (talk) 19:57, 23 March 2026 (UTC)
It's clear that you are unwilling or unable to see the bigger picture here. This is an independently operated archive service with no external (or even internal) mechanisms for oversight. The person running the archive service has explicitly shown that they are comfortable leveraging and modifying the archive to turn it into a kind of weapon. We cannot in good faith send people to that archive anymore when we know their use of the service could be powering an attack on a third party AND when we have reason to doubt the authenticity of material within that archive. The service may "remain", as you say. But it's no longer a trustworthy archive. It's a liability. 19h00s (talk) 13:30, 24 March 2026 (UTC)
I inform you that in wiki projects we discuss content, not the contributors. So your thoughts about what I am unwilling or unable to see are of no interest here. The known cases of modifying the archive are restricted to a particular conflict and name of a non-notable person. This gives no reason to doubt the authenticity of any encyclopedically significant materials. Or provide, please, examples of modifying archives which are educationally valuable and used in Wiki projects. Is there at least one example among more than 695,000 links? What about the attack on a third party, I wrote above that there are no reasons to think that attack of significant intensity continues till now. It was clear from the beginning that it is a temporary phenomenon. Modifying and attacks are very shameful, they are excellent targets for criticism. Everybody will say how terrible they are. There are far fewer people who will say how good it is to store hundreds of thousands of educationally valuable pages. But contributors of the encyclopedic project must weigh the harms and benefits. Sneeuwschaap (talk) 10:21, 25 March 2026 (UTC)
I'm discussing the content of your responses. And that content clearly shows that you are unwilling or unable to see the bigger picture. 19h00s (talk) 11:38, 25 March 2026 (UTC)
he created revenge porn of his critic. Cyberwolf (talk) 12:38, 23 March 2026 (UTC)
I think this maybe the actual owner of archivetoday Cyberwolf (talk) 12:39, 23 March 2026 (UTC)
This is not moral panic. I’m not sure what you are talking about. The webmaster created revenge porn (which in the us is a crime in all 50 states) of his critics. Which is unacceptable. This is not moral panic Cyberwolf (talk) 12:37, 23 March 2026 (UTC)
You clearly didn’t read the article i sent and my reasoning. He has no morals “Moral panic” No? There is a ocean sized line between right and wrong It is wrong to use your users on your website without their knowledge to commit an cyberattack You put users at risk for service termination. It is wrong to create ai porn of someone to attack them (crime in the eu and the us) Your defense crumbled already give up The internet doesn’t forget Archive today’s trust is 0 it doesn’t matter the functionality of the website. It matters that the webmaster used Wikipedia and others to funnel people into his cyberattack The archivetoday links are gone Cyberwolf (talk) 15:43, 23 March 2026 (UTC)
Sorry that you can’t use this scumbags site Cyberwolf (talk) 15:45, 23 March 2026 (UTC)
In discussions in encyclopedic projects, I prefer to think in other categories than "defense", "crumbled", "give up" and other war-related stuff. Also, I prefer not to stretch my replies with multiple line breaks to fill the entire screen. Also, statements are normally confirmed by links. Especially accusations like "created revenge porn". Sneeuwschaap (talk) 19:57, 23 March 2026 (UTC)
You either don't see the difference between creating and threats of creating, or simply did not read your own link, claiming that it was I who didn’t read It. Wonderfully. Sneeuwschaap (talk) 09:42, 25 March 2026 (UTC)
Brother. It doesn’t matter if its an threat or creation its wrong and Wikimedia shouldn’t funnel people into the scumbags site Cyberwolf (talk) 13:16, 25 March 2026 (UTC)
If you make accusations, you must be factually accurate and provide proofs. And I am not your brother. Sneeuwschaap (talk) 12:38, 26 March 2026 (UTC)
Boohoo do you want to die on this hill? Cyberwolf (talk) 12:42, 26 March 2026 (UTC)
@Cyberwolf: drop it. Yes, you are making this personal. Stop. - Jmabel! talk 04:02, 27 March 2026 (UTC)
I can see keeping these high-level categories for things that relate specifically to a phase of life--people at senior centers, for example, or an over-60 athletic event--but if we are going to categorize known, named individuals by their age, we should straight-out categorize them by their age in years, not a designation like "old." - Jmabel! talk 21:44, 21 March 2026 (UTC)
"we should straight-out categorize them by their age in years" Your examples already do that Trade (talk) 21:55, 21 March 2026 (UTC)
And, yes, I'm aware that during part of the year she would have been 70, but one look at Category:71-year-old human females will show you that has not been taken into consideration for 96 other similar categories and 13 photos. - Jmabel! talk 06:50, 22 March 2026 (UTC)
I think categories about people should be plain, not categorized categories. All information can be retrieved from Wikidata without having the inaccuracies our category system creates. GPSLeo (talk) 08:57, 22 March 2026 (UTC)
I don't know what you refer to with "All information" but there's many things regarding people not on Wikidata that is available on Commons. Then even for those things available in Wikidata, it's not always set by the Wikidata infobox so one would need to request some change to it to have it add a category. Then not all people files have their own category to begin with. Lastly, even for those cases where the files are in a dedicated category with a linked Wikidata item, the item's data is often very incomplete. Prototyperspective (talk) 10:54, 22 March 2026 (UTC)
The particular age is not always known. The WD infobox here defines old as 60+. I think this is useful and a parent cat like that is useful even if the age was known for all the people. There are also categories about 'young people' with the same issue. It's a valid issue but not a real problem and clearly not outweighing the rationale for having these cats and their benefits/usefulness as far as I can see. For example, it prevents other cats from being cluttered. And see Category:Young people, Category:Young adults, etc. Prototyperspective (talk) 11:54, 27 March 2026 (UTC)
This seems to be headed several ways that do not particularly address my original point. There is no reason to use this word in this manner in this context. - Jmabel! talk 04:16, 27 March 2026 (UTC)
I dont agree with the move. While 'Midi' can be translated to 'South'. In French it is more usual to use the word 'sud' for South, 'Midi' is more a general term for a region in the south, not a direction. Midi is not used in rail passenger communication. Smiley.toerist (talk) 13:03, 17 March 2026 (UTC)
I simply harmonised the Wikimedia category with the Wikipedia article, where this discussion already took place back in 2010 (see Talk:Brussels-South railway station). Please check WP's naming conventions for Brussels, where it is clearly stated that if an English name exists or it can be easily anglicised, that name should be used. For Brussels' railway stations, the names "Brussels-South", "Brussels-North", "Brussels-Central", etc. were chosen for the sake of neutrality and consistency. All the other variants (e.g. Brussels-Midi, Brussels-Zuid, etc.) are mentioned in the Wikidata entry. Jason Lagos (talk) 13:37, 17 March 2026 (UTC)
Midi is midday and at 12 oclock the sun is in the south. I think we can change the main category, but keep all subcategories. And certainly not change file-names. These refer massively to Midi or Zuid. Functionaly it is the main station. A lot passengera get confused and try to get of at Brussel Central for train connections. The German hauptbahnhof is much clearer.Smiley.toerist (talk) 14:28, 17 March 2026 (UTC)
Thanks for your quick reply. I am well aware of the origin and meaning of "Gare du Midi", as I am myself Brusselian and francophone.;-) It is true that the name causes some well-known confusion for international passengers, for the reason you mentioned. Again, the point of renaming the category was for consistency with the established conventions on Wikipedia.
Regarding your suggestions, I fully agree with you that we should not rename the files, as that would not make sense.
For the subcategories, I am more neutral, with a preference for moving them as well to match the head category. Would you see any reasons not to?
I would certainly give priority to first changing the station headcategories. The subcategories are less necessary and create a lot of churn. I have lots of images of the South station in my followlist.Smiley.toerist (talk) 10:38, 18 March 2026 (UTC)
Whatever you choose for the main category, please ensure subcategories are consistently (re)named, as per the Commons:Categories#Universality principle. Cluttering a watchlist is not a reason to ignore policies. --HyperGaruda (talk) 06:50, 19 March 2026 (UTC)
Thanks HyperGaruda - I agree. Right now, Category:Train stations in Brussels is a bit of a mess consistency-wise, with some entries named "xxx train station", others "xxx railway station", and others "xxx station", in contradiction to the principle you linked to. Some also use the (less common) Dutch name, instead of the (more common) French one, contrary to WP:NCBRUSSELS. Jason Lagos (talk) 13:24, 19 March 2026 (UTC)
@Smiley.toerist: I am happy to continue the renaming process as I am familiar with these guidelines, as well as the specifics of Brussels' stations (i.e. regular railway stations vs. multimodal hubs requiring a more general "station" name). Ideally, they should match the corresponding WP categories to maintain a harmonised naming system across the project. In any case, creating a lot of "churn" should not hinder progress if the guidelines request it. Jason Lagos (talk) 13:26, 19 March 2026 (UTC)
The churn is not trivial. As you are not yet a trusted user, lots of mutations are marked as to check in my followlist. I have bigg followlist (28.547) as I try to keep track of every file I uploaded. (started in 2008). As I have uploaded a lot Brussels rail pictures, I now have to increase the followlist parameters the last entries from 250 to 500. I want to keep this list clean and have to manualy Mark as checked each file. This takes time and I cant keep up. Would someone please give Jason to status of trusted, so that that there are not massive amounts of to check files? Smiley.toerist (talk) 09:42, 23 March 2026 (UTC)
OK - thanks again for the feedback. I have paused all these railway stations moves to give you some respite. Anyway, the bulk is mostly done (Brussels North, South, Central, West, Chapel, Congress, Luxembourg, and Airport). Any future moves will (hopefully) be less impactful for you, as those categories usually contain fewer than 50 pictures each. Jason Lagos (talk) 09:04, 24 March 2026 (UTC)
The backlog from 22/23 march is revolver.Smiley.toerist (talk) 09:50, 27 March 2026 (UTC)
Great - thanks for the update! Jason Lagos (talk) 15:58, 28 March 2026 (UTC)
Can we automate adding categories for files with an exact date?
We currently have a bot that formats dates, can it also add that date to a category? RAN (talk) 20:39, 22 March 2026 (UTC)
For photographs, the best way to do that is via {{Taken on}}, not an explicit category. And, either way, a bot won't be able to pick a category by location and date, which is what we typically want (at different degrees of granularity for location in various parts of the world). - Jmabel! talk 22:23, 22 March 2026 (UTC)
But we need it for news articles, doing it by hand is time consuming and incomplete. I see that {{Taken on}} will add a date category, so perhaps automate {{Taken on}} where we have a full date. --RAN (talk) 23:54, 22 March 2026 (UTC)
"Taken on" is a template for photographs and places files in the "Photographs taken on [date]" categories. News articles would need their own template, although it could be a derivative of the "taken on" template with some slight adjustments. ReneeWrites (talk) 12:30, 23 March 2026 (UTC)
Please remember that our (Commons) category system is already heavily stretched to the brink of being barely technically viable. The sysadmins only recently have bought us a bit of additional time, but things like “categories for every day in the history of time for each of the files we have” would be a VERY bad idea and will run the risk of getting technically ignored (and this useless) by sysadmins when required when the choice is having working servers vs working categories. —TheDJ (talk • contribs) 22:32, 25 March 2026 (UTC)
This is the first time I read about Commons running out of categories. I've been personally lobbying against one-file category atomizations for a long while already, but I was motivated not by technical concerns so far, but by creating meaningful groupings of similar files. And I do still believe that one of these meaningful groupings is having day-categories. Right now, we have day-categories for every single day in the 21st century. AND: most of them with dozens of subcategies as well: I would roughly estimate about ~400k subcategories of date-categories just for the 21st century? Aside of the 21st, we also have day-categories for most days in the 20th century and lots of days in the 19th. Further back, only days with notable events have categories right now.
RAN has created this thread probably in support for this other one, and my back-on-the envelope calculation for categories for every newspaper-cat in the last 325 years is: 325*365.25*(~10? 25?) = 1M-2.5M categories, as the utmost upper end of that calculation. While that is certainly a sizeable number, it could be narrowed down to just ~200k additional categories if we don't subdivide by language as the current proposal stands.
Could you please state your concerns in that other thread, and provide a more detailed explanation (or link to one) about this technical problem Commons might have? --Enyavar (talk) 23:58, 25 March 2026 (UTC)
Pinging @TheDJ: as I don't believe they got a notification for this message. ReneeWrites (talk) 18:56, 27 March 2026 (UTC)
I will use {{Published on}} moving forward, we just need a way to automate past entries. Update: {{Published on}} does not add a category, it will need to be modified to work like {{Taken on}}. --RAN (talk) 17:23, 27 March 2026 (UTC)
The dates are only added automatically if the file is a PDF, unfortunately. For images, those would still need to be added manually. ReneeWrites (talk) 18:54, 27 March 2026 (UTC)
@ReneeWrites and @RAN: Technically, without any indication otherwise, all of our uploads were "published on" the date of upload. {{Published on}} should take note of that and add the appropriate category automatically, regardless of filetype. Pinging @Gone Postal as author of that template. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:16, 28 March 2026 (UTC)
"Published on" is intended for works that have an actual known publication date established by a publisher, rather than the date a file was uploaded here. There are a lot of templates that add dates to file types automatically, such as {{Taken on}} or {{According to EXIF data}} for photographs. For files where only the upload date is known, we have {{Upload date}}. I added a description to the "Published on" template to make this distinction more clear. ReneeWrites (talk) 13:29, 28 March 2026 (UTC)
Can't crop image
I'm trying to crop File:Daytona Cubs P4060068.JPG using CropTool2 to just be the scoreboard as it's got advertisements on the bottom of the image, but when I try to save the image it says "Upload failed! [api] Received error: abusefilter-disallowed: ⧼abusefilter-warning-file-overwriting⧽". Any help? I have no idea what filter I could be tripping. RteeeeKed (talk) 01:03, 26 March 2026 (UTC)
@RteeeeKed I assume you have selected "Overwrite" instead of "Upload as new file" in CropTool2. Per Jeff G. above, if you want to overwrite files, you need to be autopatrolled to be able to do it. For more details, please see COM:OVERWRITE.
Only minor crops are allowed for overwriting, but in this case it may be suitable to overwrite if you are cropping the possibly unfree advertisement at the bottom. Thanks. Tvpuppy (talk) 01:33, 26 March 2026 (UTC)
@Tvpuppy: In this case, I think perspective correction and outright removal / blurring of the possibly unfree advertisements would be justified. CropTool2 can't do most of that anyway. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:58, 26 March 2026 (UTC)
Not really. Gamweb, who uploaded it, hasn't been active in a decade, so I can't really get their permission to overwrite. I'll upload a modified version under a different filename; if someone thinks the original should be DR'd, I'll leave that to them. - Jmabel! talk 18:04, 27 March 2026 (UTC)
You can still see the URL of one of the advertisers at the bottom. Trying to crop it out myself, I get the same error. RteeeeKed (talk) 19:02, 28 March 2026 (UTC)
You didn't say how tight a crop you wanted, I cropped it to my taste.
If you do not have autopatrol then, no, you still will not be able to overwrite. - Jmabel! talk 01:11, 29 March 2026 (UTC)
Uploading screenshots of Wikipedia
Are screenshots of Wikipedia considered own work or the editors'? --Like tW (talk, contribs, 🇧🇬 BG) 21:38, 28 March 2026 (UTC)
@Like the windows: Screenshots are derivative works, insofar as they are works at all. Each copyrightable contribution needs to be credited and licensed. (For the Wikipedia text, the crediting can be done via a link, since the history is visible there, but it would probably be most appropriate to account for any licensing of images.) If your own contribution includes some copyrightable modification, you can claim that as "own work", though obviously just screenshotting does not normally create a copyright. Jmabel! talk 01:16, 29 March 2026 (UTC)
Dynamic generated results such as weather grafics, departures boards, etc, are not creative works. However it nearly imposible to remove al the logo's etc wich are copyrighted.Smiley.toerist (talk) 10:27, 29 March 2026 (UTC)
It depends on what you're asking about – it's not considered fully or mostly own work. I don't know what's best to put into the author and source fields; I usually select Own work in the Upload wizard which puts {{Own work}} in there and via edit specify and that it's a screenshot which I made and specify of which page it is, sometimes with a little note like 'see article revision history'.
In any case, this query shows up to 9236 files are marked as own work and are or include Wikipedia screenshots (note: some have been edited such as to add a red rectangle highlighting a part of the page; and for some the screenshot is only a part of a broader file): deepcategory:"Wikipedia_screenshots" incategory:"Self-published_work". Prototyperspective (talk) 15:59, 29 March 2026 (UTC)
This Café meetup will be approximately two hours long. Attendees may choose to attend only for a part. Please see the Café page for more information, including how to register.
Is there a feature on the Wikimedia Commons that allows people to hide/blur NSFW images (images depicting nudity, gore, etc.)? If not, should we implement such a feature? Some1 (talk) 16:44, 14 March 2026 (UTC)
This is very difficult to build, if it should work on every display of a thumbnail. GPSLeo (talk) 21:09, 14 March 2026 (UTC)
This is a perennial suggestion. Even if technically feasible, the very large amount of volunteer work needed to tag images, and the vastly cultural and personal ranges of what would be NSFW, make it unlikely to be effective. If there are images you personally do not want to see, the suggestions at en:Help:Options to hide an image should be easy to implement on Commons as well. Pi.1415926535 (talk) 21:56, 14 March 2026 (UTC)
Tagging images would be as easy as adding them to a new 'NSFW' category or the like. And there should be an easier way for editors to hide/blur these images without to log in and mess with the common.js or .cs. Like how Google search has the 'SafeSearch' option that one could turn on to blur explicit images. With all the age verification laws cropping up around the world lately, there is a possibility that one day, the Commons will be affected. It's better to be prepared than to scramble when the time comes. Some1 (talk) 22:08, 14 March 2026 (UTC)
We have 136 million files. Adding this proposed category would require checking every one of them - a workload equivalent to about 1/8 of all edits ever performed on Commons (and about 1/5 performed by humans) - with no actual benefit to Commons. The automated systems used by sites like social media platforms have significant false positive and false negative rates, as well as significant biases introduced by their training sets, and would not be suitable for use here.
Unlike social media sites, Commons users also understand that there is no universal definition of NSFW. It depends massively on cultural norms, personal views and comfort levels, context of individual files, and what those with power wish to designate as "inappropriate" to further their own aims. Things as diverse as nudity, interpersonal acts like sex or kissing, depictions of religious figures, depictions of people, speech and symbols representing certain views, medical imagery, and animal behaviors may be NSFW to some people and not to others. Many governments would wish to designate files showing protests of dissenting views, the existence of LGBTQ+ people, and the existence of disabled people as NSFW because they represent contradictions to their ideology.
As I've written before when this topic came up, there may be some subject areas where an opt-in filter might have definable criteria, a relatively low chance of use for censorship, and a feasible number of files to check. Nazi symbols is a likely example. But those represent a very small subset of anyone's NSFW definitions. There is plenty of Category:Content-control software out there for those who wish to control what they see. Pi.1415926535 (talk) 23:12, 14 March 2026 (UTC)
I think you're letting the perfect become the enemy of the good. There are plenty of files on Commons which any reasonable person would consider NSFW - e.g. photos of human genitalia, images and videos specifically described as pornography, or those Panteleev photos (you know the ones). We don't need to review every single image; simply tagging images which are already in categories which identify it as likely to be objectionable could get us a lot of the way there. Omphalographer (talk) 02:16, 15 March 2026 (UTC)
@Some1: Oppose. We can't cater to everyone. What if my workplace was at the Taliban? See COM:CENSOR. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:53, 14 March 2026 (UTC)
What's wrong with allowing people to blur/hide NSFW images? No one is forcing anyone to turn the option on. Some1 (talk) 22:54, 14 March 2026 (UTC)
Your definition of what NSFW would be likely be different from what someone in Dubai would consider NSFW or someone in Singapore. Governments and organizations would want us to put everything related to LGBTQ+ behind a NSFW filter, Israel would consider pro-Palestinian protest images NSFW, etc. Nudity is also a cultural specific matter. Abzeronow (talk) 03:13, 15 March 2026 (UTC)
Easy: The WMF can add an option that allows individual readers/editors to checkmark certain categories they themselves want included in NSFW filter. Some1 (talk) 03:26, 15 March 2026 (UTC)
I think individual opt-in filters would be fine to have. The problem is how to implement this. The thumbnails on gallery pages are requested directly from the media server without a request on the file page content. GPSLeo (talk) 05:36, 15 March 2026 (UTC)
It works well on reddit and there is no reason to believe it wouldn't work here. Prototyperspective (talk) 13:55, 16 March 2026 (UTC)
We just deleted a video on order from the Australian internet censorship organization. COM:CENSOR is de facto not in force anymore Trade (talk) 21:53, 23 March 2026 (UTC)
Oppose. NSFW is subjective. This is a baby globe problem. JudeHalley (talk) 03:26, 15 March 2026 (UTC)
That is not much of a problem. NSFW-blurring works well on reddit and it could work well here too especially if one does not assume it has to be perfect. Prototyperspective (talk) 13:56, 16 March 2026 (UTC)
MediaWiki:Gadget-NSFW.js is related, it should be in your settings under gadgets with a checkbox to enable. No guarantee on that it will block everything NSFW. Snævar (talk) 16:59, 15 March 2026 (UTC)
Issues with this gadget:
I could not find it in the gadget preferences
It works with structured data statements but so far not all or most NSFW files have these set
It does not blur NSFL files such as images showing torn open dead human bodies
I'm not sure how it works – I think it would be best if it worked like on reddit where it blurs the file content and that one can see the individual file by clicking on a button on the image
Support improvements to this gadget and making it easily enable via the preferences and then some thoughtful discussion on whether and which additional things could be done (example: making the gadget usable to logged-out readers). Prototyperspective (talk) 16:39, 17 March 2026 (UTC)
Comment This keeps coming up, but we never get a coherent, concrete proposal, or even a good list of the considerations for a system that would support this without imposing censorship on those who do not want it, or a set of options on what we might consider supporting. I'd be very open to a serious discussion on this front, but it is almost impossible to react intelligently to what is little more than a hand-wave. - Jmabel! talk 23:08, 15 March 2026 (UTC)
Comment People often talk about this as if its a technical problem. It really isn't. The moment we start doing this we have to define what is and is not NSFW. Nobody wants to open that can of worms. The technical problems are trivial comparatively. Bawolff (talk) 23:09, 15 March 2026 (UTC)
Comment I don't think anyone has suggested full-out censorship. Even the OP just requested hiding/blurring. But especially the "Search Media" function should be configurable to have personal settings that blur certain images that come up while searching. The image would then only be displayed, when actively clicking on it. Which images would be blurred? All images from the category that you as a user have determined to be nsfw for yourself, for example all media in Category:Human sexuality or category:Violence (if you consider war paintings and pictures of swords as too obscene). --Enyavar (talk) 11:43, 16 March 2026 (UTC)
Makes sense. Currently, category:Violence would be way too broad to be usable for this. Moreover, it would need some sort of caching as the dynamic deepcategory search operator breaks on such large categories. Prototyperspective (talk) 14:00, 16 March 2026 (UTC)
Just directly in those categories or also subcategories. If you include subcategories, to what depth? Like this isn't as simple as you are making it out to be. Bawolff (talk) 18:48, 16 March 2026 (UTC)
This is the main problem: We would need to store huge index lists of these files to not slow down image loading when enabling such filters. GPSLeo (talk) 19:51, 16 March 2026 (UTC)
Honestly, I don't even think that part is that big an issue (or at the very least there are solutions to that problem). The real challenge is coming up with the list in the first place. Bawolff (talk) 15:55, 19 March 2026 (UTC)
It’s if we can get a local ai to scour the images for gore genitalia . This would be simple Cyberwolf (talk) 16:09, 19 March 2026 (UTC)
Do you have a specific AI system in mind? AI isn't magic, it still requires making decisions about what type of content the AI thinks is gore or genitalia. On top of that AI adds complications by often focusing on the wrong things (e.g. There was a famous AI system to identify NSFW photos that turned out to just be identifying photos where the subject was wearing lipstick). Bawolff (talk) 16:20, 19 March 2026 (UTC)
I will propose a system Media is requested from thumbnail media server sending an id 0 or 1 for safe search on or make it into a binary for selective Each image will be assigned a “rating” or classification as nsfw
a binary table
Gore
Violence
Non sexual depictions of genetailia
Sex
Etc
Etc
Etc
Etc
yes
1
1
1
1
1
1
1
1
no
0
0
0
0
0
0
0
0
Lets say i want to set my preferences as no gore. Violence no genetailia no sex That would become 01000 The server would let violence through like body cam footage Cyberwolf (talk) 16:03, 19 March 2026 (UTC)
If a simple binary rating system is implemented. I believe it would work Cyberwolf (talk) 16:04, 19 March 2026 (UTC)
I would also propose a scale then so no one has to really agree Cyberwolf (talk) 16:45, 19 March 2026 (UTC)
And for the Jesus on the cross would be a 1 on my scale Cyberwolf (talk) 16:47, 19 March 2026 (UTC)
You would still have to agree on the scale then. There is no way to do any sort of collaborative rating without deciding on a rubric. Bawolff (talk) 16:48, 19 March 2026 (UTC)
Yeah true but id assume a scale would see more support Cyberwolf (talk) 16:49, 19 March 2026 (UTC)
You make the flawed assumption that it has to be perfect. It's not perfect on reddit. It works on reddit. It's used on reddit. It can work here. Your first two examples are not NSFW. And one can readily discuss and refine criteria, types of cases etc or even just let people edit and work with whatever results there is. E.g. which SD depicts are set which is how the gadget currently works. Prototyperspective (talk) 18:17, 19 March 2026 (UTC)
I don't think it has to be perfect, I do think there has to be some shared agreement on the categories or at least a straw man proposal of what the definitions of the categories should be. Eventually people will fight over what should be in which categories, if the definitions of the categories boil down to WP:IDONTLIKEIT, the fighting will just never end. Reddit works by moderators making arbitrary, unappealable decisions. If people want that system, that's fine, but they should actually explicitly propose that. As far as the gadget goes, I'd say its fine if that's what people want but those depict categories are only correlated with what people generally mean by NSFW so I'm not sure people will actually be happy with it as a NSFW filter. In general I don't object to any of these idea so much as object to people hand waving all the details away. I just want people to make specific proposals detailed enough that they could actually in principle be implemented, so that we have something to actually debate the merits over. Bawolff (talk) 18:40, 19 March 2026 (UTC)
I don't think there will be much of an issue. Just define what should be blurred as NSFW and what doesn't. There aren't really any new categories or structured data – basically things already exist and one would only need to decide which to blur when the user turns on some NSFW toggle. Afaik things on reddit are blurred by whole subreddits blurring all posts by default, e.g. Videos of human sexuality would have all its files blurred, and less often are other kinds of posts marked as NSFW by the person posting based generally on common sense (probably <2% is mods tagging posts NSFW retroactively also based on loose common sense). A proposal consists largely of technicalities of how to make blurring files based on user preference possible and secondarily ways to identify which posts to blur where what's currently used by the gadget are a set of structured data tags. If this is implemented, discussion can follow which SD tags to put under NSFW if and how to make it possible to specify exceptions (individual files and files that also have specific SD) and how to tag all the relevant files (most or at least many do not have these SD tags set and they could be set via the categories). Prototyperspective (talk) 21:22, 19 March 2026 (UTC)
"Just define what should be blurred as NSFW and what doesn't" Why would an impossibly comprehensive list be needed in order to have such a feature on the first place?
Can't we just start with "close-up photos of veiny, human penises" and then later add more to the list as time progresses after community consensus on Commons:Village pump/Proposals?
I don't think anyone cares how narrow the criteria is just as long as the feature actually gets off the ground Trade (talk) 02:42, 24 March 2026 (UTC)
Sure, but someone needs to actually do that. Make a category of things that should be blurred, or an SDC property, or a template to put on image pages, or just a wiki page that lists all the images to blur or whatever. The technology part is easy, all it needs is some way to know if an image should or should not be blurred. I personally think creating such a list is politically difficult, but if you disagree, i'd suggest to prove me wrong by making the list. I promise that if someone makes a list of all the NSFW images, i will make a gadget to blur the images. Bawolff (talk) 04:09, 24 March 2026 (UTC)
How is this scope? I think it's narrow enough to avoid the slippery slope arguments @Bawolff:
My concern is not that it is a slippery slope per se (It of course can be), my concern is that nobody will be able to come up with an actual list of files that meet the metric (due to political infighting or community indifference). What I'm suggesting is that if someone actually creates a category (or some other means of listing files) containing all the "Sexual acts" images (etc), I'll happily make a gadget to blur them all. Bawolff (talk) 21:34, 25 March 2026 (UTC)
Wikimedia Commons content descriptor Here, you can join the proposal and explain more about your gadget and why this is something useful for Commons (obviously anyone reading this can also show up to voice their protest if they want) @Bawolff: --Trade (talk) 02:32, 30 March 2026 (UTC)
A bit of different angle. In Persian Wikipedia, there have been many attempts of abusing NSFW concept (and "think of the children") to censor educational images. To the point of trying to hide the statue of David (!!) or may I show you this entertaining incident where the state TV blurred logo of AS Roma. So I don't have any issue with showing nudity or eroticism or even "porn" as long as it's educational. What do I have issues with is gore. And not old pictures from WWII or Vietnam war, but high resolution videos/pictures of people getting beheaded or dying by ISIS or similar. It makes me physically sick. I don't have an easy solution but I wish those at least get some sort of blur filter like Telegram (or maybe we could reduce the resolution? just thinking out loud). Surely we don't need to see details of someone being beheaded to learn about actions of ISIS? I don't know. Amir (talk) 00:39, 20 March 2026 (UTC)
A blur filter, or a system of different access levels for different groups of users, is better than censorship. RoyZuo (talk) 09:11, 22 March 2026 (UTC)
Australia have the power to dictate what we are and are not allowed to host. Blurring has no bearing on that Trade (talk) 02:30, 24 March 2026 (UTC)
I wish we could have a serious discussion about this just for once without the unserious slippery slope arguments. Constantly having to throw photos of nudity into arbitrary subcategories is tedious busywork--Trade (talk) 02:26, 24 March 2026 (UTC)
I do have one question: would uncategorized images be automatically blurred? JudeHalley (talk) 11:58, 24 March 2026 (UTC)
In the gadget and if something else was implemented: no, obviously not. There's far too many uncategorized files. For blurring the SD and the categories would be used. One could however also blur files with certain terms in the file title or description (such as 'sex' or 'beheading') if the file does not yet have any categories set. Prototyperspective (talk) 12:15, 24 March 2026 (UTC)
I dont think anyone wants that Trade (talk) 03:41, 30 March 2026 (UTC)
Judging by how the discussion above is going and reading through Commons:Village_pump#Office_action:_Removal_of_file below, it seems like age-verification requirements are more likely to be implemented on the Wiki Commons way before any optional filters. Since there's no blurring features here for NSFW content, and since age verification laws are all the rage nowadays, I wonder if the governments will ever force the Commons to mark certain images as 18+ and then require users to undergo age verification with a logged-in account before they're able to view such images or files. Some1 (talk) 02:16, 26 March 2026 (UTC)
that would require them to actually tell Wikipedia and Commons apart so unlikely Trade (talk) 03:18, 26 March 2026 (UTC)
Age verification would be extremely detrimental to the Wikimedia movement as a whole as age verification is essentially a restriction on free speech, and would be a violation of the privacy of our contributors. And I have talked to former and current WMF lawyers about this, I have been told that Wikipedia could be construed as being under laws governing social media if those laws are broadly written. Abzeronow (talk) 03:08, 30 March 2026 (UTC)
If the options are between age verification or geoblocking countries with such laws, i would much prefer the later Trade (talk) 03:41, 30 March 2026 (UTC)
Same but such shouldn't be provoked nor aided via unexpected gore and NSFW files and not even having an option to have such files blurred. Prototyperspective (talk) 12:27, 30 March 2026 (UTC)
Are informations behind an unifying template still recognizable by bots?
I'm interested in adding the fact that Geneviève Hasenohr found parts of chapter 77 and 78 in the manuscript Valenciennes 239. Instead of modifying each page taking part in the image series File:Marguerite Porete, Mirouer des simples âmes, Chantilly BDC MS0157, 011 f.5v-6r.jpg, I would like to create a template for this series, call it in each image description and make the change in one single place, namely in the newly created template.
User:SchlurcherBot is gradually adding structured information to the images in the series and I fear that a template will mess up this process. Additionally, I don't want to have other bots treat the files as files without license data when such a template will be present - the license situation is clear and I don't want to cause havoc because the files get automatically deleted.
So, in short: is it safe to introduce a "template detour" which allows for efficient editing and still keeps the bots happy? --TLD35 (talk) 10:02, 29 March 2026 (UTC)
I tried it and it works without problems. Closing the topic.
This section is resolved and can be archived. If you disagree, replace this template with your comment. --TLD35 (talk) 23:42, 5 April 2026 (UTC)
License Review gadget leave a ] when reviewing sources with the format of [url xxxx ]. Can some sysop or interface sysop consider to automatically remove this "]" by code when identified? Lemonaka (talk) 18:48, 27 March 2026 (UTC)
@Lemonaka: A diff would help clarify what you are talking about. - Jmabel! talk 19:20, 27 March 2026 (UTC)
I looked at the code for about 10 minutes trying to trace it back, but nothing leaps at me. @Lucas Werkmeister and MGA73: any idea? @Lemonaka: if you don't get anything here, this might better be a question for COM:VP/T. - Jmabel! talk 04:45, 28 March 2026 (UTC)
My feeling, looking at those IDs, is that not just the ] is misplaced but actually the majority of the |id= shouldn’t be there – instead of |id=SUARTgpCaNw?si=jvFt1sM7AU7d2wzu Deguchi Natsuki at Biore] it should probably just be |id=SUARTgpCaNw? But I haven’t yet figured out where the gadget is taking this from. Lucas Werkmeister (talk) 13:07, 28 March 2026 (UTC)
I think in this part, index6 needs to account not just for \n but also for ? (and probably &), to slice off the si= tracking parameter? But I don’t know the gadget, so I’m hesitant to just try editing it without knowing how it works. Lucas Werkmeister (talk) 13:10, 28 March 2026 (UTC)
I also think that var index6 = idtemp.indexOf('\n'); asumes the line ends with a \n but in this case the end is the ]. So we might need to stop at both variants ']', '\n'. --MGA73 (talk) 11:49, 29 March 2026 (UTC)
But if we want to slice off the si= we also need to add '?' as a stop. But in File:20260319 Natsuki Deguchi 11.jpg it is still there and it seems to work. --MGA73 (talk) 11:52, 29 March 2026 (UTC)
si= is just a Youtube tracking parameter it should be removed from all links
yes. i think there're very rare instances where that si tracing parameter should be retained. a bot should be created to sanitise youtube links wherever this was not removed. RoyZuo (talk) 18:46, 29 March 2026 (UTC)
@RoyZuo: you say there are "rare instances" where it should be retained, but a bot should remove it. How will a bot identify those "rare instances" and leave them alone? - Jmabel! talk 19:50, 29 March 2026 (UTC)
I don't think there is any reason to keep it. But it could probably check if someone manually added it back and then not remove it REAL💬⬆ 17:43, 31 March 2026 (UTC)
Okay I tried but it did not work. So perhaps we should use a regex instead since the ID should always be 11 char long. So either (/v=([A-Za-z0-9_-]{11})/) or if we want to catch alternatives (/(?:v=|youtu\.be\/|embed\/|shorts\/)([A-Za-z0-9_-]{11})/). I suggested it on MediaWiki talk:Gadget-LicenseReview.js so feel free to Comment. --MGA73 (talk) 15:56, 30 March 2026 (UTC)
{{US states}}
Would anyone complain if {{Clickable map of USA Category}} was added to this template? Commons is a site with a large international audience and i feel showing people where the state they are looking for is located would make the site more user friendly towards those outside of North America Trade (talk) 04:14, 30 March 2026 (UTC)
I lean against this (it could get pretty cluttered, have a look at Maryland), but it might be OK if the map could be placed inside the box, justified either left or right. - Jmabel! talk 04:42, 30 March 2026 (UTC)
I weakly object due to the fact that the map omits the territories and the District. —Justin (koavf)❤T☮C☺M☯ 05:41, 30 March 2026 (UTC)
Can't we just not use it for territories and the District? Trade (talk) 07:04, 30 March 2026 (UTC)
If you'd like the situation to change, you could support the wish. If you have other feedback on the wish, that's welcome too. Note that a large fraction of Commons visitors is already on mobile and the problem described here is not limited to Commons categories but also all or most uses of <gallery> in Wikipedia articles and elsewhere (including when viewed through the Wikipedia app). Prototyperspective (talk) 18:08, 30 March 2026 (UTC)
I had this in mind, too, but always forget to speak up about it, thank you a lot:) --PantheraLeo1359531 😺 (talk) 20:12, 30 March 2026 (UTC)
I experimented a bit during the recent hackathon, with modifying the category view. You can find video here: https://www.youtube.com/watch?v=MkC7_HTIYhA I used a packed view, with full width images in mobile. I moved the other link types to the bottom and made the description collapsible. It was very much a hack, but i wanted to spur some people to reconsider what the category view should be. overall reaction was enthusiastic. —TheDJ (talk • contribs) 14:00, 31 March 2026 (UTC)
Interesting; thanks for doing this and I like this too except that I think the file titles kind of need to be shown by default with just an option to hide these (so they only show when hovered). Note that the titles could be trimmed to only display the full title at hover so they take only little and consistent page height.
only show when hovered — hovering is not possible on mobile. Nakonana (talk) 10:33, 2 April 2026 (UTC)
Indeed and thanks for the note; on mobile there could be a few pixels of screen height reserved for the title (similar to the Commons app screenshot) that can be trimmed to prevent it to be longer than eg needing more than 1 linebreak where one would need to tap on it on mobile to see the full title. There's images for which the title is redundant but usually or at least often it's useful.
A complication are file-titles in languages other than the one(s) the user understands but this problem is unspecific to mobile and for these cases one could show the caption if available in the user's language (however this still needs/would greatly benefit from language of file titles to be parsed). Note that captions are often not substitutes for file-titles, eg used similar to subheaders (eg info on the legend of a map instead of title a second time). Prototyperspective (talk) 13:45, 2 April 2026 (UTC)
Is this an android problem? On iOS hovering is possible with specific finger movement. It is of course not super reliable and sometimes results in an accidental click. GPSLeo (talk) 14:58, 2 April 2026 (UTC)
On the left [...] On the right [...] — those directions are a bit ironic given that this thread is about Commons' appearance on mobile, because, obviously, there's no left or right but only a "top" and "bottom";). As a mostly mobile user I'm used to the category looks by now (although I'd love to see more info being displayed (like license and author or even categorization) and the thumbnails being a bit larger).
As for, gallery pages, I don't really use them and have no opinion on them. However, when it comes to the gallery template (as it is used for the photo challenge and in some wiki articles) I'd really love to see this issue fixed:
Indeed, thanks for pointing it out. As for, gallery pages I didn't mention gallery pages but maybe they should be mentioned in the wish idk – I don't use them much either so broken uses of the gallery tag at places like the one in your screenshot are what I was primarily referring to with elsewhere at uses of <gallery> in Wikipedia articles and elsewhere.
I don't know if your screenshot should be included in the wish; probably better not (mentioned maybe?). But there should definitely be a bug report on phabricator about it. I haven't seen this yet since I don't use my smartphone much; will check on mobile later if that also occurs on my device. Could you create the bug report on phabricator?
As a mostly mobile user I'm used to the category looks by now (although I'd love to see […] on a related note, things would be much better already if one could conveniently open a Commons page in the Commons app. With most apps one can choose which app to open a link or open a website with if one has an app installed – for example one can easily open Wikipedia articles currently open in the mobile web browser in the Wikipedia app by selecting Open with -> Wikipedia app. Then one could switch to the Commons app view of whatever Commons page one is viewing in less than a second.
I'd just like to remind everyone that if we want to change the default gallery type for categories (in general not just mobile) to one of the other existing gallery types like "packed" we can. All we need is some sort of vote to deonstrate that it is the will of the community. Bawolff (talk) 19:45, 2 April 2026 (UTC)
We are currently categorizing all media needing categories as of 2021. We have started one year ago at 125,000 files to be categorized. Progress is now taking up momentum, as shown in Category talk:All media needing categories as of 2021. However, 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 check out the Commons:WikiProject Minimum One Category. leave a comment about your approach or your achievement either here or on the relevant discussion pages. --NearEMPTiness (talk) 02:09, 10 March 2026 (UTC)
Uncategorized files over timeWith the increasingly large numbers of uncategorized files, I think there needs to be some thought and work on how to address this at scale / effectively without consuming so much volunteer time. One idea is to better aid and facilitate uploaders to categorize their files at upload as outlined in Commons talk:WMF support for Commons/Upload Wizard Improvements#Guidance/facilitation of categorization; another idea would be to have tools suggest categories based on file-title, description, metadata, and content, similar to User:Alaexis/Diffusor.
On a related note, ultimately all of this is largely a two-stage process where adding initial category/ies is stage 1 and diffusion into more specific categories is stage 2; categorization can be improved a lot if initial category/ies are set if the one/s set is/are about the main topic/usefulness/uniqueness of the file. Probably both stages need some development.
.
I've created the chart on the right a few days ago using some new tool that I coded with the help of AIs – does somebody know how to get data for between mid 2015 and early 2024 or why there is this quick rise from 2012 to 2015 but a decline by 2024? Prototyperspective (talk) 12:58, 10 March 2026 (UTC)
The "two-stage process" that you describe is certainly helpful, e.g. by using Category:Unidentified by topic, but I am even more proud about files that I can categorize to their final location. In many cases, this might involve creating a new category for a person, of which a Wikipedia article exists in any language. This new category will, initially, most often contain only one file, but it can be inter-wiki-linked to the relevant Wikipedia articles via Wikidata. GLAMorous is a powerful tool, to find uncategorized photos of persons, of which a Wikipedia article exists. Until a suitable bot will be programmed, these photos have to be categorized manually one-by-one, please. NearEMPTiness (talk) 02:29, 11 March 2026 (UTC)
Just my two cents... I think it is the job of the uploader to choose a suitable category/categories. The "penalty" for not doing so, is that an image will remain unnoticed, and is unlikely to be used in a Wikipedia article. Trying to think of a suitable category is a nice way to pass the time, certainly. But we're looking at about 1000 uncategorized images per day, and I consider myself lucky if I can find a category for more than a handful. Regards, MartinD (talk) 20:27, 12 March 2026 (UTC)
If we find 200 volunteers, who will categorise at least 5 files per day, we will proceed faster than the uploaders of uncategorized files, especially if some of the volunteers will do more than 10 files a day. NearEMPTiness (talk) 20:31, 13 March 2026 (UTC)
Good point but there's also good counterpoints to this. These include that 1) many of these files are copyvios or would be good to delete for other reasons (like being blurry) so going over them is useful 2) often, categorization is hard depending on the file so it may need some Commons contributor to cat it properly 3) many of these files were just transferred from Flickr or other sites – these aren't just original content of the uploads so it's not the file creator who failed at that and many of especially these files are quite useful but missing in the cats which is a disadvantage to Commons and in Commons' interest to address.
The aforementioned guidance in the UploadWizard could involve showing the info that the image is less likely / easy to be found and used if there is no proper category set. Prototyperspective (talk) 23:23, 16 March 2026 (UTC)
And also while the uploader should do it, they don't necessarily know why or what a fitting category may be. Thus, better guidance/help with categories within the UploadWizard would be beneficial.
Additionally, it doesn't have to be specific categories or changes on individual files – instead of concluding contributors should not categorize uncategorized files, a better skeptical conclusion I think would be…
to limit things more to or prioritize categorizations of whole batches. For example, one can enter search terms and categorize dozens of files at once and more patterns like that would be great on the project page marked in yellow above.
and to categorizes lots of files at once at a glance without going into the details of the specifics – for example maps into Category:Unidentified maps and photos of landscapes into Category:Unidentified locations (here note that the photos should be about the locations, not about other things like specific events or specific objects that just happen to be at locations that are unidentified)
I've created a wish about the mentioned guidance/facilitation of better categorization at upload: W526: Guidance/facilitation of categorization of files at upload in UploadWizard (voting open). This could reduce the number of new under- and uncategorized files substantially. Further ideas could be added to the talk page and the wish could then be extended if there are some things to add. Prototyperspective (talk) 17:48, 22 March 2026 (UTC)
We reached the halfway point, by reducing all media needing categories as of 2021 from 125,000 to 62,500 files. Now we need more volunteers please for categorising the reminder. The objective is, to add the final category, please, not only the Category:Unidentified men. Ideally, we shouldn't all get stuck at letter A by working alphabetically from A to Z, but start somewhere in between and use the hints shown on Commons:WikiProject Minimum One Category. Do you want to help, and/or do you have an idea, how to do this more effectively? NearEMPTiness (talk) 14:02, 3 April 2026 (UTC)
User license-reviewed their own uploads
I just came across many files uploaded by user DarwIn, but their license were also reviewed by the same user, DarwIn.
Per Commons:License review#Instructions for reviewers, it states "reviewers may not review their own uploads unless the account is an approved bot...Reviews by image-reviewers on their own uploads will be considered invalid.". Perhaps I am missing something, since I understand the user is an admin here and also a VRT member, so maybe there is an exception to this restriction for admins and VRT members?
Fortunately, the license of the files I checked appears to be valid, and I trust the licenses were reviewed by DarwIn correctly, so I don't think there should be any files that needed to be deleted. The issue is just that possibly the license review on these files are invalid.
Not sure how many files are affected by this issue, but I think there is potentially a lot, since a quick search seems to show the user has reviewed more than a thousand videos. This is why I am asking here for advice on what to do. Thanks. Tvpuppy (talk) 02:56, 21 March 2026 (UTC)
I suppose someone could go through and re-review them. I am not volunteering.
@DarwIn: you're an admin here, you should know this isn't the way this is supposed to be done. - Jmabel! talk 06:41, 21 March 2026 (UTC)
In my defense, it should be noted that the license was actually reviewed by the video2commons tool, or else they wouldn't be uploaded at all, as the tool blocks uploads with an invalid license. So I supposed a second review was not needed (as a bot had actually already reviewed it), and since the Youtube reviewer bot, which used to mark those here, was not working at the time, it would only add to the backlog unnecessarily, so I marked them as reviewed myself, something which from what I recall didn't use to be problematic some time ago. DarwinAhoy! 01:38, 29 March 2026 (UTC)
Video2Commons can check that someone claimed a license on YouTube, but signoff by a human reviewer suggests they found that claim at least plausible. It's not hard to see why we stopped allowing people to self-review. (Personally, I'm not sure that was necessary for admins, but I still understand the logic.) - Jmabel! talk 19:47, 29 March 2026 (UTC)
In recent years we've had several deletion requests for files claiming that the license was done unintentionally or without approval. Are human reviewers supposed to take consideration for that too? Trade (talk) 03:44, 30 March 2026 (UTC)
@Trade: They're supposed to do the best they can, and competence is required. If, for example, you see that a Disney YouTube site operated from Papua New Guinea has offered a license for an entire song sequence from Frozen, you should probably find that highly suspect. I would say that anyone who did not find that suspect is probably not qualified to be a license reviewer. - Jmabel! talk 04:37, 30 March 2026 (UTC)
Comment until some time a decade or so ago, this self-review was actually allowed for admins, so I guess it is possible that DarwIn, who has been around for a long time, might not know current policy for this. I could probably make a similar mistake about policy on en-wiki where I am an admin, but not particularly active. - Jmabel! talk 04:14, 27 March 2026 (UTC)
Thanks for the info, I think your explanation is very plausible. By the way, I have now created the category Category:Files self-reviewed by DarwIn (re-review needed) and added the problematic files to it. I have started to go through them and re-reviewing these files, but as you can see, as of writing, there are 1,729 files in the category, so if anyone wants to help out, it would be greatly appreciated. Thanks. Tvpuppy (talk) 19:56, 27 March 2026 (UTC)
@Tvpuppy Hello. That episode happened years ago, but from what I remember, the review bot stopped working for some reason, so I started reviewing those myself, as they were not controversial and were actually already also verified by the video2commons app. I don't think any of those should be controversial, and those uploaded with video2commons, which should be the vast majority, were already verified by the tool used for the upload. At the time I didn't think it would be controversial in any way, but apparently it is, so I apologize for it. It was totally in good faith (and I doubt anything controversial will come out of that). DarwinAhoy! 01:30, 29 March 2026 (UTC)
Going forward, unless something extraordinary is found, can we have Video2Commons automatically review videos it converts? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:36, 29 March 2026 (UTC)
I support the suggestion, as it would reduce unnecessary bureaucracy. DarwinAhoy! 01:40, 29 March 2026 (UTC)
@DarwIn: Would COM:VPP be the right place for a discussion of and !voting on that, or a subsection here? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:45, 29 March 2026 (UTC)
@Jeff G. Maybe "proposals" would give more legitimacy to the debate. DarwinAhoy! 18:06, 6 April 2026 (UTC)
@Jmabel hello, that was the case indeed. I used to review those myself as they were not controversial cases, to not add to the backlog, as it was the use some time ago. Apparently it changed, so I'll leave it to others to verify the license. DarwinAhoy! 01:21, 29 March 2026 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:36, 3 March 2026 (UTC) 
Info, see announcement by WMF, it appears user javascripts have now been re-enabled. Thanks. Tvpuppy (talk) 01:15, 6 March 2026 (UTC)
Oppose your proposed links aren't better and secondly these links can be added to those linked category pages. There's some useful links on these pages already. Prototyperspective (talk) 15:20, 5 March 2026 (UTC)
Wyslijp16 (talk) 13:17, 14 March 2026 (UTC)
Comment, regarding the DR you linked, it was not correct to say "
Support this project. yes, it is looking un-neutral, not secular... but in life everything has flaws. modern_primat ඞඞඞ ----TALK 20:04, 18 March 2026 (UTC)
_Berlin_09.jpg)
.jpg)
.png)
,_081910.jpg){kind=link}
.jpg){kind=link}
![File:Dada "alliance".jpg](./File:Dada_"alliance".jpg){kind=link}
,_Ed._1_Thursday,_September_14,_1899_-_DPLA_-_776a4f1990f65cdded8fdb80e2d3f6ab_(page_1).jpg){kind=link}
,_Vol._5,_No._35,_Ed._1_Thursday,_December_31,_1896_-_DPLA_-_f7896efbf3d2f6c222aed9b7df670880_(page_1).jpg){kind=link}
_and_others.jpg){kind=link}
_-_Google_Art_Project.jpg){kind=link}
.png){kind=link}