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

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

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

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

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

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

This is false – in the preferences there is the setting "Remove {{Check categories}} and other minor cleanup" which one could uncheck. Prototyperspective (talk) 18:33, 12 January 2026 (UTC)Reply

Nice to have that preference (although hard to notice) but Hot-cat doesn't have it and it would be useful. Pere prlpz (talk) 15:26, 17 February 2026 (UTC)Reply

Because with HotCat a message displays that asks whether or not you would like to remove this template. Simply click No there. Prototyperspective (talk) 15:48, 17 February 2026 (UTC)Reply

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

This is a very good comment, indeed. I have subsequently categorized some of these people and found that this is easier than categorizing those grouped by dates. Thus, I think it is helpful, to put them temporarily into this category. You may skip the mass uploads starting with a number, if you want to categorize them manually. --NearEMPTiness (talk) 03:50, 5 January 2026 (UTC)Reply

You can combine the research of several people and get a result: File:Bakkikayam.jpg The description is in the Malayalam language. This limits the picture to the Indian state of Kerala, or the union territories of Lakshadweep and Puducherry (Mahé district). This is a dam on some river. But I dont want to speculate.Smiley.toerist (talk) 15:58, 9 January 2026 (UTC)Reply

Sometime the research is incomplete. File:Bernard Becker & wife Janet.jpg, There is an Wikipedia article about Bernard Becker. One problem is that he died in 2013, so this picture cannot have been taken in 2017.Smiley.toerist (talk) 16:20, 9 January 2026 (UTC)Reply

Based on the metadata and image quality, I have the impression that the photo was not taken in 2017, but that a scan of a photo was made in 2017. Wouter (talk) 19:25, 9 January 2026 (UTC)Reply

I have added a before date.Smiley.toerist (talk) 09:54, 11 January 2026 (UTC)Reply

Thanks for this effort. However, I think it's not nearly as useful and needed as for example categorizing files in Category:2020s maps of the world in unidentified languages (complete) or Category:Renewable energy charts with unspecified year of latest data (under construction) or Category:Diagrams in unspecified languages (under construction) or Category:Renewable energy charts in unspecified languages (complete) for example or any of the requested tasks in Commons:Categorization requests.

There also is the issue that most of the files in these needing-categories cats are of low quality and/or low usefulness/relevance so what categorizing them does is

• cluttering categories
• creating work for those contributors who keep these categories clean and well-subcategorized

Prototyperspective (talk) 18:41, 12 January 2026 (UTC)Reply

We are making good progress: 7,167 media needing categories as of 2020, but we need more volunteers, to clean the backlog by reviewing these files one-by-one or by semi-automated procedures. NearEMPTiness (talk) 10:04, 11 January 2026 (UTC) (count was updated on 18 Feb)Reply

Does someone know what the Italian phrase 'Coletti Gino' means? I categorized the first one, but maybe better if some Italian works on this.Smiley.toerist (talk) 23:46, 18 January 2026 (UTC)Reply

It seems to be some Italian person: it:Gino Coletti Smiley.toerist (talk) 23:50, 18 January 2026 (UTC)Reply

Warning: These four images are modern pictures taken with an i-phone, so the actual location is incorrect and all of the same place.Smiley.toerist (talk) 23:45, 19 January 2026 (UTC)Reply

I hope not to many files land in broad unknown categories. There are stil some frustrating files without location: example: File:Italy- handbook for travellers. First Part, Northern Italy and Corsica (1869) (14597135680).jpg. It could be in France (Corsica or Massilia? (in Provence?)).Smiley.toerist (talk) 11:12, 24 January 2026 (UTC)Reply

Would it be useful to start with the 5,951 images that are currently used in Wikipedia? -- Vysotsky (talk) 22:28, 25 January 2026 (UTC)Reply

@Vysotsky: Thanks, this is a very useful link, indeed. It is relatively easy to categorize these files, especially those of people. However, I am also interested in finding high-quality photos that are not being used, because they cannot be found, unless they are better described. NearEMPTiness (talk) 08:54, 1 February 2026 (UTC)Reply

Completely agree. Even more: categorizing photos not being used might be more important. At the same time, I think it is good to also look at the ones heavily used. Your call has worked fine so far: 34,000 uncategorized images brought back to 19,139 within one month. Thanks. Vysotsky (talk) 14:24, 1 February 2026 (UTC)Reply

Is there any idea what the backlog is for the following years of 2011, 2012 etc?Smiley.toerist (talk) 13:36, 6 February 2026 (UTC)Reply

The number of these backlog items is 0 – those are all solved. The number of such files used to be far smaller which is why addressing this at the source is needed. The number of files for 2025 is essentially unmanageable already. Prototyperspective (talk) 14:32, 6 February 2026 (UTC)Reply

Sorry, I meant the years 2021, 2022 etc. Smiley.toerist (talk) 00:21, 15 February 2026 (UTC)Reply

Question: When you clear these backlogs, do you attempt to provide meaningful categorization or do you just stick any old category on it and call it good? For years now, continuing to the present day, I've come across copyvios that have lingered on the site for years. This occurred mainly because the file contained a random, irrelevant category which effectively hid it from anyone knowledgeable about the subject. Oftentimes, they were originally uploaded by bad actors or just plain clueless contributors. Another phenomenon I've observed is with my own uploads where I didn't have time to add categories. The revision history shows an entire series of categorization edits which amount to kicking the can down the road. It's as if to suggest it's my responsibility to come back and properly categorize the files, while it's perfectly okay for them to fuck around incessantly. If you think I'm being unnecessarily mean, go read what COM:CAT says about including the most appropriate category in the tree. I believe that also applies to those editors. Taking an uncategorized file, adding Category:Men or similar, and walking away patting yourself on the back for what a great job you did is utterly ridiculous. RadioKAOS / Talk to me, Billy / Transmissions 02:54, 8 February 2026 (UTC)Reply

I, for one, would never remove the "uncategorized" template unless I had provided one or more quite relevant categories, and when I'm going through a list like this I often am nominating files for deletion (or speedying them) when I see problems. Hence my remark above about if all you can do with an image that is clearly supposed to depict a place is to categorize a tree, don't remove it from Category:All media needing categories as of 2020!. - Jmabel ! talk 05:02, 8 February 2026 (UTC)Reply

Yes, I fully agree that applying non-sense categories such as Category:Men or just their first name does not fulfill the objective of this exercise. I think, we should focus on enabling authors or readers of Wikipedia articles, to find relevant photos more easily. Currently, we are working on the 2020 files. Thus "anyone knowledgeable about the subject" had sufficient time to request the deletion of files. Requesting deletions can also more effectively be done in parallel to categorization. If we do not start from A to Z by alphabet, but if start by categorizing high-quality photos, for instance the uncategorized photos uploaded via Flickr. On some occasions it might be helpful, to add temporary categories such as Category:Unidentified cities or Category:Unidentified automobiles, because these are being looked after by motivated specialists. NearEMPTiness (talk) 05:18, 8 February 2026 (UTC)Reply

A lesser problem than copyvios are the duplicates wich become visible, when placed next to each other. Sorting the category by date makes them even more visible.Smiley.toerist (talk) 11:55, 8 February 2026 (UTC)Reply

More Information: Useful tools and some guidelines are currently collated at Commons:WikiProject Minimum One Category. We are looking forward to your contributions to this page. NearEMPTiness (talk) 06:14, 8 February 2026 (UTC)Reply

Thanks! Also added to this page. For the category here, I think now for the files left there is a large fraction of files for which SDs, DRs, and permission needed tags would be good to add or at least probably would be good to consider using more often. In part for the sake of making it more feasible to complete this, probably the cutoff for quality/usefulness expectations may be good to raise so that eg this file and this fall beneath it (these don't add much but clutter really). Prototyperspective (talk) 23:04, 9 February 2026 (UTC)Reply

In addition to requesting deletion, it might be useful to split some very populated categories into two parts, by using or setting-up a subcategory such as Category:Cats (low quality) or Category:Sunsets (low quality). NearEMPTiness (talk) 10:08, 10 February 2026 (UTC)Reply

Agree. This info would also be good to add to that page. Also similar ways to separate types of images, e.g. Category:Moon from Earth instead of dumping further low-quality photos where the Moon is somewhere in the image directly into high-level Category:Moon. There's probably more similar ways that would be good for categorizers to be aware of. Prototyperspective (talk) 13:26, 10 February 2026 (UTC)Reply

There are still approx 13682 uncategorized files, which are used on Wikipedia and related projects, as shown on Glam-Tools. Some of them can be easily categorised by using the lemma of the English Wikipedia. NearEMPTiness (talk) 21:03, 10 February 2026 (UTC)Reply

(13682 uncategorized files overall of which 4518 are used anywhere in the wikiverse of which 3584 are used in mainspace of any Wikimedia project) Prototyperspective (talk) 23:40, 10 February 2026 (UTC)Reply

I don't like "low quality" categories. For one thing, we have no systematic way to make such a judgement. For another, it unnecessarily insults users who may not agree with that description of their work. - Jmabel ! talk 00:45, 11 February 2026 (UTC)Reply

Would scale better and draw in less time resources if more was done to address this issue at the source; e.g. via what's suggested at Commons_talk:WMF support for Commons/Upload Wizard Improvements#Guidance/facilitation of categorization. Then we could worry about undercategorized files (example) and other tasks. Prototyperspective (talk) 13:54, 12 February 2026 (UTC)Reply

Location is the most important part in most cases an often frustrating: I have found three basic categories for File:Humans Being - Flickr - simiant.jpg (aquariums, Children and Pinnipedia), but the most important is where? Luckely I found the place in the flicker comments. From there I found alot more precise categories. Taken pictures from Flickr without correct descriptions is asking for problems. Smiley.toerist (talk) 23:34, 16 February 2026 (UTC)Reply

In terms of usefulness / likely applications, unique value and where people would look for a file like this, I think more useful than location in many and this cases is some category about 'people standing in front of large aquariums'. Theoretically one could have a tool try to suggest categories based on flickr tags, flickr comments, and the albums the file is in so one doesn't have to go to the flickr page or it could load these things directly on the file page. Prototyperspective (talk) 23:48, 16 February 2026 (UTC)Reply

It is tricky to have meaningful categories. In this case I dont think aquarium is correct. This is probably a water basin where aquatic air breathing mammals and birds swim around in, with an underwater window. No temperatur control and limited water treatment. In general I prefer using structured data to search for special combinations, instead of creating very specialized categories. SD is more flexibel and can be used by AI, scripts and search engines. Some users dont understand this and want to link combination categories to new dataitems, please dont. Dont import al the quirks and combination Common categories into wikidata. Each search system has its purpose. I would like the Common file to have at least a link to one content data item. (not the technical properties such as image size, its a picture, f-number, focal length, etc). Its easy work scanning the categories and using the SDC script. Find the correct data item by going to the upper categories until one finds a category linked to a data item.Smiley.toerist (talk) 15:07, 17 February 2026 (UTC)Reply

Please set fitting categories and don't ask users to not set fitting categories, thanks.

And one can't even get to 'people standing in front of large aquariums' via the set SD. SD are only set on less than 2% of files and even there often missing the key thing shown or having something super broad set. Prototyperspective (talk) 15:51, 17 February 2026 (UTC)Reply

I think the proportion is much larger than 2%, but that maybe that the subjects where I am interested, have a much larger part of SD filled. I certainly add a lot of SD to files (from categories from with data item). Have you any source for this 2%? Smiley.toerist (talk) 23:59, 19 February 2026 (UTC)Reply

No, it's just anecdotal from a) seeing changes to many files in the Watchlist and b) checking the SD of many files. Maybe SDs are set substantially more often, but when SD is set, they 1) are often missing at least one of the key things shown (eg 'microphone' is in the depicts but not the actual point of the picture which is the person holding it) 2) aren't nearly as comprehensive as the categories. SD could be written eventually from the categories of files (afaik that's also the most common way they are set along with during upload in the UW).

Regarding 2), the SD 'Aquariums' and 'Children' on a file wouldn't imply (or only show) children standing in front of aquarium windows. Additionally, querying for this would be intuitive and overly difficult to do, assuming it works at all because one would query if anything for 'Aquariums' and 'People' where it would then have to resolve the latter to also include items tagged only with 'Children' (and countless other items).

Either way, categorization itself is already more than enough work so instead of worrying also about setting SD, imo it would make more sense to see if some things could be encouraged to be done by uploaders at upload and whether some tools could help with all of this. Prototyperspective (talk) 01:01, 20 February 2026 (UTC)Reply

Its not either categorization or SD activity. If the files are correctly categorised (as specific as posible) its a matter of minutes to fill the SD side with the SDC script. The reverse from SD to categories is also posible, but a bit more dificult. So the research work is only done once.Smiley.toerist (talk) 13:47, 21 February 2026 (UTC)Reply

It's down to just 4,747 files now. Prototyperspective (talk) 13:49, 25 February 2026 (UTC)Reply

This project has now been successfully completed. Thank you very much for your contributions and comments. NearEMPTiness (talk) 20:08, 1 March 2026 (UTC)Reply

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

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

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

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

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

I've put my own opinion in italics to explain why I think this requires debate, but I would like for people to check out the scheme examples for themselves, and judge on their own. Peace, --Enyavar (talk) 08:11, 2 January 2026 (UTC)Reply

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

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

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

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

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

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

Categories denoted as old, or historic, are not terribly useful. Much better to put dates on them. Rathfelder (talk) 17:05, 15 January 2026 (UTC)Reply

Please read the original post, that is not a comment on the actual questions of this topic. Old maps are not the topic here, this is about history maps (i.e. Maps showing history of specific countries/centuries) regardless of when they were produced.

The term "historic maps" that can denote both, has rightfully fallen (mostly) into disuse. --Enyavar (talk) 16:23, 17 January 2026 (UTC)Reply

In our Commons:WikiProject Postcards we have the similar problem. Is this a "old postcard of the German Empire" or a "Postcard of Germany". There we are mostly agree, that today people often search for postcards be the locations of today. So many former German towns are now Polnish towns and so we are categorized this postcards under the polnish name of the town. See also Commons:WikiProject_Postcards#Categories. Best regards --sk (talk) 12:29, 12 February 2026 (UTC)Reply

Hi all,

I believe the guidelines in Commons:First steps/Quality and description, specifically the sentence "Generally speaking, image quality and resolution should be as high as possible so images can be used in high-quality printouts", should be modified to discourage upscaling beyond the native resolution of the original media. The file upload page also encourages users "Upload the highest resolution file that is possible", which can also be problematic.

I have run into a user who is upscaling their 5568x3712 images from their 20 megapixel Nikon D7500 camera to as large as 30893×17377 (537 megapixels) before uploading, in some cases ballooning an otherwise 5-10 megabyte file to over 100 megabytes for absolutely no benefit and significant detriment. I've notified their talk page about this, but this should be more clearly discouraged in policy. EDIT - the user responded and said this was a mistake with their export settings, and was not intentional.

I also think we should have clearer policies against upscaling (except for media explicitly illustrating upscaling as a technique), as use of AI and other tools to invent detail seems to run counter to the project's scope in hosting educational media. The only policy I've found against upscaling is on Commons:Overwriting existing files, which discourages overwriting existing files with upscaled ones. 4300streetcar (talk) 05:44, 19 February 2026 (UTC)Reply

Commons:AI-generated media used to require AI-upscaled images to be tagged and categorised, but this was dropped in June 2024 as this concerns images modified by AI, not images generated by AI. We should create separate guidelines to handle the former. I'm not sure what the per Rhododendrites refers to in that edit summary; if there was a connected discussion I can't find it.

Commons:AI images of identifiable people#Altered images requires upscaled photographs of people to be tagged as such, and to include a link to the original source photo for comparison, but it takes no view on aircraft or other non-human subjects. It doesn't rule that such images shouldn't be hosted here. Belbury (talk) 09:21, 19 February 2026 (UTC)Reply

•  Strong oppose upscaling. It should be prohibited. I've checked File:Gridiron Air’ Boeing 777-232ER ‘N866DA’ @IND.jpg and failed to find where 537 MP file is better that original (~8 MP). More, I even think that giant photo became more blurry than sharp and detailed original. Plus upscaling is just a useless waste of space. Юрий Д.К. 20:30, 19 February 2026 (UTC)Reply
•  Oppose I agree such upscaling is useless, and should be prohibited. Yann (talk) 20:39, 20 February 2026 (UTC)Reply
• Agreed with Юрий Д.К. and Yann to make this a more explicit part of the policy. --ReneeWrites (talk) 13:29, 21 February 2026 (UTC)Reply

• I just noticed that files are upscaled with AI to achieve higher resolution. Just for example, File:20230621 Lapillus (라필루스).jpg is a screenshot from a 4K YT video, which was upscaled to a 8k-x-5k image and then cropped for details. I have to admit, one has to look close to find inaccuracies, but in the respective video, this popstar wears some kind of multi-finger-chain-rings which the AI could not properly figure out and it looks like her hand got distorted as the result. The image IS properly tagged as required by the guideline that Belbury mentions. However, I do not really understand why we would allow ANY upscaling made by AI (and other reality filters) on images that are then placed in WP biographies and/or articles about the depicted people.
  That said, I do understand that reality-distorted images would be uploaded for technical explanations of AI/filter technologies. --Enyavar (talk) 18:52, 21 February 2026 (UTC)Reply
• per others. Original content in high-res is better ;) --PantheraLeo1359531 😺 (talk) 19:35, 21 February 2026 (UTC)Reply

 Strong oppose upscaling per above. It would be nice if others would express their opinions as !votes.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:01, 22 February 2026 (UTC)Reply

 Oppose to upscaling. It is really not needed, I find it increases file sizes & takes up more storage space unnecessarily while not actually increasing quality. A lot of these images look very weird, smooth and unnatural. Commons should be preserving original copies of media in their highest original resolution, instead of altering them with AI to achieve a false 'higher' resolution. If we really need to upscale an image in some rare cases where it could be useful, it should be clearly marked as so with {{AI upscaled}}, and not overwriting the original file. The vast majority of user-uploaded content taken with phones and cameras do not need upscaling of any kind so we should restrict this option. PascalHD (talk) 17:40, 22 February 2026 (UTC)Reply

• It only should be done when paired with the original image and marked {{AI upscaled}}. Upscaling was used in Get Back, no one is saying that the Beatles were unrecognizable in the project. Upscaling from just a few years ago has been improved. --RAN (talk) 19:24, 22 February 2026 (UTC)Reply

 Strong oppose upscaling images above their original resolution (with exceptions when needed, such as restoration of low quality old or otherwise significant images). Millions of media files (including redundancy and backups) need a lot of storage space, so that space must be used, not wasted. MGeog2022 (talk) 15:42, 26 February 2026 (UTC)Reply

First, a clarification that the "per Rhododendrites" referenced above concerns what I said during the proposal to make it a guideline (effectively, that it would be good to separate AI-generated from AI-manipulated images). I do still feel that we need guidance on the latter, but it's a little more complicated. Upscaling is a good example of something that could use a dedicated page that isn't specific to AI.
The traditional ways we've upscaled images aren't what we'd call AI, like the interpolation tools that have been built into Photoshop for ages. It's not about inferring shapes and details based on training data but about sampling pixels in the image itself. Very different. Then when we get into AI tools, there's a world of difference between them. If you just dump something into a chatbot and ask it to upscale, they typically do a terrible job (see this mess regarding a portrait of Alex Pretti, and there are many more like this on Commons). If you use something like Topaz Gigapixel, it does a much better job, but it is inferring shapes, edges, faces, objects, and adding plausible detail based on more than what's in the original. The result is typically better but less true than interpolation. Are they useful? Hard to say. If the goal is printing an image, that's something we can leave for users to do on their own. The only real use case I can think of is to scale up a very small image for use in a Wikipedia infobox or something -- increasing legibility, basically -- and I think we should allow that, although we should mandate disclosure.
For the sake of moving discussion forward, I've started a draft guideline at Commons:Upscaling and invite contributions, with the eventual goal (if others think it's a good idea) to propose its adoption. — Rhododendrites ^talk |  21:25, 26 February 2026 (UTC)Reply

A closer has taken their own view to delete a file against all other opinions. Can this be appealed on Commons, or is that how it works on Commons. Thanks Aszx5000 (talk) 21:14, 19 February 2026 (UTC)Reply

See COM:UNDEL for instructions. --Geohakkeri (talk) 21:28, 19 February 2026 (UTC)Reply

On Commons, admins are not bound by majority consensus, especially in matters involving copyright policy or legal compliance. They cannot disregard applicable Commons rules or copyright law just because most commenters prefer to keep the files. --Jonatan Svensson Glad (talk) 21:59, 19 February 2026 (UTC)Reply

Yes, you can ask for undeletion, but as one of the ones who is a regular at UDR, I agree with Jim's close. We would need COM:VRT permission. Abzeronow (talk) 04:27, 20 February 2026 (UTC)Reply

What's with the rationale that a professional photographer can't possibly take a photo of themselves? That appears to be central to justifying deletion in this case. We have an entire category tree, Category:Remote controls for cameras, which depicts technology used by professional photographers, including allowing themselves to do exactly that should they so choose. RadioKAOS / Talk to me, Billy / Transmissions 18:28, 25 February 2026 (UTC)Reply

Per the closing comment, "In the one, he is walking a tightrope and in the other hanging from a rock overhang." These are not situations which lend themselves to positioning oneself for a camera and using a remote shutter release. Omphalographer (talk) 19:45, 26 February 2026 (UTC)Reply

Commons:Courtesy deletions (It is still a proposal, never approved by the community. See /w/index.php?title=Commons:Courtesy_deletions&action=history )

I'd like to raise some questions for the community to clarify and decide.

The current practice of Commons:Criteria for speedy deletion#G7 is that uploaders can request speedy deletion of their uploads within a grace period of 7 days, and the requests are usually but not always granted.

Should such requests (within 7 days after uploading) be unconditionally granted?--RoyZuo (talk) 16:27, 20 February 2026 (UTC)Reply

Such requests are only denied if the file is in use. They have to discuss with the person who added it somewhere first. During this discussion the decision is on hold until there is an outcome of this discussion. GPSLeo (talk) 20:16, 20 February 2026 (UTC)Reply

Somebody takes the time to add an in-scope file to an article, and then they have to be harassed about it by some flake uploader? Doesn't sound fair or reasonable to me. Geoffroi 21:03, 20 February 2026 (UTC)Reply

Unconditionally? No, that goes too far for me. They're called courtesy deletions for a reason, it's not something the uploader is entitled to. Bear in mind also that by uploading files you own to Commons you're not only granting various Wikimedia projects the rights to use them, you extend this right to everyone. Though I don't object to the grace period being extended to two weeks, provided the file is not in use and hasn't been granted a special status (QI/VI etc.) ReneeWrites (talk) 13:19, 21 February 2026 (UTC)Reply

I think any such deletion should be on a case-by-case basis, as the uploader grants an irrevocable license. Granting a deletion unconditionally, even if it is within whatever timeframe is decided, effectively renders that moot. — Jkudlick ⚓ (talk) 21:16, 21 February 2026 (UTC)Reply

Deleting a file on Commons has absolutely nothing to to with "revoking" its licence. We're simply no longer distributing the file. (under that licence (which it still has)) ~TheImaCow (talk) 22:44, 22 February 2026 (UTC)Reply

Another question I think the community should consider.

Can the grace period (for uploaders) be changed? Changed to longer than 7 days, e.g. 10 days / 2 weeks / 4 weeks / 1 month...?--RoyZuo (talk) 16:27, 20 February 2026 (UTC)Reply

The original discussion that decided 7 days for G7 is Commons_talk:Criteria_for_speedy_deletion/Archive_1#c-NickK-2011-04-07T19:52:00.000Z-Author_or_uploader_request_deletion_of_recently-created_unused_page_or_file.

But I skimmed thru Commons talk:Courtesy deletions these old discussions in 2013. Some users thought that 7 days for courtesy deletion were too short and 30 days would be better, e.g. Commons_talk:Courtesy_deletions#c-MichaelMaggs-2013-08-04T23:42:00.000Z-An_actual_proposal.--RoyZuo (talk) 16:27, 20 February 2026 (UTC)Reply

One month seems long to me, but I could agree for a 2-weeks period. Yann (talk) 20:36, 20 February 2026 (UTC)Reply

People can always go through COM:DR where it will gather community feedback, and if no objections, I'd urge other admins to consider granting deletion in case the file is not in use in case it is younger than e.g. 1-3 months. --Jonatan Svensson Glad (talk) 21:21, 20 February 2026 (UTC)Reply

Will there be an RFC for this? Geoffroi 22:10, 20 February 2026 (UTC)Reply

Where do I put in my  Oppose? Geoffroi 21:03, 20 February 2026 (UTC)Reply

That depends what you oppose... you should state that together with your vote. Do you oppose the enitre drafted guideline, or whichever grace period?

Personally, I am fine with the current 7-day grace period as well with an extension to 14 days. Longer seems like a stretch. If one wishes to have the files deleted at an even later point, one should go through regular DRs; I've noticed (rare) courtesy deletions much much later, as long as a file was not in use and not deemed particularly useful. --Enyavar (talk) 18:55, 25 February 2026 (UTC)Reply

A suggestion in regards with the maps from Our World in Data: remove from each map the category <year> maps of the world.

These maps weren't published in the years referenced. In addition, it could make the categories of <year> maps of the world more easy to browse.

Thanks in advance. --Universalis (talk) 19:15, 22 February 2026 (UTC)Reply

As with other files in these categories, that's the year of the data. This categorization has large usefulness to find and update outdated images used on Wikipedia. And the category title does not imply that's the year the map was made. Prototyperspective (talk) 20:13, 22 February 2026 (UTC)Reply

+1 to Prototyperspective. - Jmabel ! talk 20:39, 22 February 2026 (UTC)Reply

I have been meaning to say something about these maps, and this is a good occasion. User:Universalis is right that these maps were not created in that year, and it IS practice on Commons to understand "<year/decade/century> maps" being the maps created in that timeframe, not the maps showing that timeframe - the latter would be better placed under "maps showing <year/decade/century>".

User:Doc James, who is creating the majority of recent OWiD maps that concern what might be called history, is producing them by the thousand each day, at least as far as I can observe. For 2026-02-24 I just checked and saw 5000 edits, most if not all of them creating and categorizing OWiD statistics/maps usually looking like this (1947), this (1664) and this (1800). That is an enormous output and just for example 1764 maps of North America is currently dominantly OWiD maps and I suspect that this is true for basically all year-maps-of-world/continent right now. Case in point: the categories for 1444 maps of Africa, 1445 maps of Europe or 1446 maps of Asia don't even exist right now, but they are already filled with OWiD maps.

With at least 300'000 OWiD maps already existing and no end in sight, I would really like to delegate all of these maps into specific OWiD-categories for each continent and year. My suggestion for File:Annual co2 cement, North America, 1764.svg would be Our World in Data maps showing North America in 1764 or Our World in Data maps of North America in 1764. These year-categories would themselves be categorized under Our World in Data maps showing 1764 and Our World in Data maps of North America in the 18th century.

The titles I suggest above are up for debate. Is it more practical to use "Our World in Data maps" or can it be shortened to "OWiD maps" ? Also, should it be "showing" (as per our category branch "maps showing <year>") or should it just be "of" ? --Enyavar (talk) 03:58, 25 February 2026 (UTC)Reply

Sure we can adjust the categories however folks wish. We have additionally build a tool to help with more fined toned mass categorization. See Help:Gadget-CategoryBatchManager.

With respect to numbers, yes have uploaded about 600K so far and it looks like I am maybe a third done, so maybe 1.2 million more to go. Will likely not finish until this fall. Doc James (talk · contribs · email) 06:03, 25 February 2026 (UTC)Reply

and it IS practice on Commons to understand "<year/decade/century> maps" being the maps created in that timeframe, not the maps showing that timeframe this is an inaccurate statement. Look into any of these categories of years of the recent few decades and you'll notice how what you said is false. What you said applies to old maps and there usually the data shown is not known better than year of map made or the same. Prototyperspective (talk) 13:47, 25 February 2026 (UTC)Reply

So what do folks want us to do? Doc James (talk · contribs · email) 09:00, 26 February 2026 (UTC)Reply

In 2014, it has been decided that "<year> maps" should essentially be empty disambiguations, and we should use "maps created in <year>" and "maps showing <year>" instead. Practically, this rule has never been enforced, and has lead to many simmering debates ever since. I'm striking my quarrelsome nitpicks from my previous comment, in order to focus on the suggestion at hand: Creating special categories for OWiD maps. Okay? --Enyavar (talk) 11:04, 26 February 2026 (UTC)Reply

If you'd like to these could be subcategorized in the maps by year cats...I tried to keep them as flat as possible to enable viewing all the relevant files on one page, have easier to understand standardized cat names, and not start deep nesting that can cause queries and scans to break. Many hundreds of files would be moved. If there is agreement and no objections, should they be named Category:Our World in Data maps of the world showing 2014 data or Category:OWID maps of the world showing 2014 data or Category:Maps of the world showing 2017 (OWID) or Category:Our World in Data maps of the world showing 2014 or Category:2014 Our World in Data maps of the world or Category:2014 maps of the world (OWID) or sth else? (It's mostly maps of the world that I'd move.) Prototyperspective (talk) 12:40, 26 February 2026 (UTC)Reply

Doc James has stated above that we are going to have about ~1'800'000 maps once the current run of creating these files is finished. And I don't even think that will be the end of it. So I agree, we need to have a good standardized cat structure, and I am willing to hear if Doc James also has input on good names, or input on which names are less good. With that lead:

As far as I can see, we do have the following seven regions over which these maps are distributed: "the world", "Africa", "Asia", "Europe", "North America", "Oceania", "South America". These are the seven most common frames I noticed so far, please correct me if there are more. "World" is probably going to be a bit larger, but I don't think we should neglect the other regions, which are all going to be equally densely filled.

Now, thinking about the best name structure. I would prefer to pre-fix the data source, similarly to how we do it with other major map providers like "OpenStreetMap maps of...", "USGS maps of...", "ShakeMaps of earthquakes in...": The most important qualifier gets frontloaded. For easy manual input, I would prefer the name "OWiD maps of...". However, the categories are unlikely to get assigned manually, and it is much easier to understand what the acronym means when it is written out. So right now, I would tend to go with the general Our World in Data maps of... as the prefix, then followed with the seven (?) regions identified above.

Afterwards comes the suffix. Prototypeperspektive suggested ... showing <year> data, my own ideas leaned towards ... in <year> or ... showing <year>. These suggestions all look equally good to me. Prototype's suffix has the advantage of pointing out that these maps are data-driven and not cartography-driven. So I think that would be best.

Following that idea, we could go with Our World in Data maps of <region> showing <year> data. Taking an existing map like File:States involved in state based conflicts, Oceania, 1947.svg, one would assign Our World in Data maps of Oceania showing 1947 data instead of the current three categories Our World in Data maps of Oceania, Maps showing 1947 and 1947 maps of Oceania. That new category would itself be categorized directly under the existing three categories it replaces.

If the above suggestion seems agreeable... how difficult is it for Doc James to change the automated exports and the templates that are currently in use? And would you be able to do an automated re-categorization of all the already existing files? Would you need help? --Enyavar (talk) 18:54, 28 February 2026 (UTC)Reply

Yah I think doing this in an automated fashion should be fairly easy. This would be subcategories of what main category? Doc James (talk · contribs · email) 19:01, 28 February 2026 (UTC)Reply

[[:category:Our World in Data maps of <region> showing <year> data]] would be subcategory of [[:category:Our World in Data maps of <region>]], [[:category:Maps showing <year>]] and [[:category:<year> maps of <region>]]. At a later point, I would like to reshape the last of the three parent categories to bring the OWiD maps under the 20th-century/1940s branches of <region>. With the example above, there is currently no sufficient subdivision of Maps of the history of Oceania, but the idea is creating Maps of Oceania in the 20th century and Maps of Oceania in the 1940s, and that would again be a subcategory of Oceania in the 1940s... But I think that work would not affect the OWiD-maps and their templates itself. --Enyavar (talk) 19:13, 28 February 2026 (UTC)Reply

Plan was to categorize once the initial uploads are completed, which will not be until this fall. And work on the 1.8 million or so files at that point. Doc James (talk · contribs · email) 19:18, 28 February 2026 (UTC)Reply

You are currently categorizing them upon upload by two mechanisms, one is the template:Map showing old data, the other is assigning regular categories. Right now, neither of these mechanisms is a bespoke template designed for OWiD content.

I can imagine a template that works like {{OWiD maps showing|Africa|1758}} that would create the categories we contemplated above, including links to skip forward/backward and also links to skip to the other continents/world extent. If we used such a template to create the category framework discussed above, couldn't you adapt your exporting automatism once that exists? I can only image it would take less work later.

Before I attempt working on such a template myself, I'm asking a few users who I suspect have more routine in templating, @Clusternote, AnRo0002, and Reinhard Müller: My question is how you would go about it: templates for the file descriptions; templates for creating these categories; or both? Are there pitfalls I am not aware of? We are talking here about ca. 2 million standardized files ranging from very few around the year 1021 to an abundance of such files for 2021, with hundreds of files per year per continent in 1834 already. The maps are optimized to be used in slider-frames elsewhere; for Commons I'm more concerned with handling the categorization. Thanks in advance! --Enyavar (talk) 21:51, 3 March 2026 (UTC)Reply

Here is my suggestion: Maps of Oceania in the 1940s anro (talk) 22:18, 3 March 2026 (UTC)Reply

Dear Commons friends,

–

Summary: Wikimedians have become very good at dealing with copyright issues. But today, there are other important legal risks to navigate: the main ones here are privacy law (the “right to be forgotten”), and online safety rules. More than ever, we want to encourage Commons to be very diligent at defining and applying COM:EDUSE. When hosting controversial content, it’s legally vital to be clear about its educational value - especially when it comes to content that depicts real people, or content that risks triggering user protection (e.g. age gating) laws. Commons could take inspiration from the Wikimedia projects’ already robust approach to copyright (including “fair use justifications” under legally risky media).

–

Hi all - my name is Phil, and I work in the Legal Department at the Wikimedia Foundation (WMF). Wikimedia Commons is a thriving and rich community, providing great societal value, and it has learnt to deal well with a key legal restriction on sharing content online: copyright law. So well, in fact, that when worried EU legislators controversially imposed additional copyright filtering and takedown obligations for platforms, they exempted Commons.^[1]

The aim of this post is to draw the community’s attention to heightened legal sensitivity in two newer but equally important sources of legal risk: privacy laws (also called “data protection” laws), and online safety laws. Both of these relate to how the Commons community defines and applies COM:SCOPE - and in particular, COM:EDUSE.

We want to thank and congratulate all of you that take a careful approach to assessing whether content should be kept or removed from Commons. That’s super important - now, more than ever. We want to encourage everyone to be doing exactly like you. We also wanted to inspire you to consider further improvements in Commons’ policies and practices. Here’s why.

a. Privacy laws

Over the past decade, privacy disputes have become the #1 source of litigation affecting the Wikimedia projects.

Privacy laws around the world^[2] often give individuals the right to demand the deletion of content about them. Some call this the “right to be forgotten” (RTBF). Thankfully, it is not an absolute right: just like copyright, there are exceptions that protect freedom of speech, and education.

The way these laws usually work is that if someone demands erasure of content that identifies them, there needs to be a balancing exercise of public versus private interest. Each case might be different, but the general rule is that if content is more intrusive (for example, if a photo was taken at a private meeting, and/or it tells you about someone’s political or sexual orientation), it probably needs a stronger “free speech” justification. In any case where the justification isn’t strong enough, the photo/video/etc should either be removed, or made less intrusive (e.g. by cropping or blurring).

As you can see in our Transparency Reports,^[3] it’s exceptionally rare that WMF actually has to remove content due to RTBF demands. There are two big reasons for this. Firstly, WMF devotes a vast amount of time and expertise to fighting removal requests; we even have a pending case at the European Court of Human Rights about one.^[4]

A second and probably more important reason is that the Wikimedia community often deals with this issue very well. We want to encourage this.

On Commons specifically, the legally-critical balancing exercise means fairly and carefully deciding what’s more important: the educational value of the content, or the possibly harmful impact it might have on an individual. You can see why COM:SCOPE (and in particular, COM:EDUSE) plays an essential role here: it guarantees that content on Commons will be realistically useful for an educational purpose. That's where you assess whether media has a sufficiently strong public interest to override the potential privacy concerns.

b. Online safety laws

Secondly, online safety laws are rolling out almost everywhere. Some are specifically imposing restrictions on porn sites, but others are much broader in scope. In response, some services are having to block visitors from particular regions, shut down completely, or impose other strict restrictions on their users. WMF and many others are working tirelessly on this issue, by talking to legislators,^[5] challenging bad laws,^[6] removing CSAM,^[7] and more - to make sure these sorts of laws preserve access to knowledge, and don’t unfairly restrict what the Wikimedia projects have been lawfully doing for decades. But that work is just the background, compared to the even more important things you do. Once again, the key factor, here, is COM:EDUSE.

Your creation, refinement and application of COM:EDUSE allows our allies and advocates to prove to judges, lawmakers and everybody else, that whilst there might be controversial content on the site, it should be legally protected: Commons is not a porn site, it is not a “gore” site, it is not a general filehost, and it is not a social media "Wild West"; it is an educational project.

Evolution of best practice:

These issues are not new to the projects,^[8][9] but the legal risks are high. Continuing to robustly define and apply COM:EDUSE is currently the number one protection against those risks.

We really appreciate when you have thoughtful, well-justified deletion discussions. It is good that you’re deciding to remove content when there isn't a good enough justification for it; and that when you do decide to keep content, you’re clearly explaining why. When we can show that to judges, they can quickly understand why Commons should win the legal battle.

We expect that some of you will have really great ideas about how to continue evolving project policy and practice. One evolution that we’ve come to appreciate in the past, when it came to managing legal risk around copyright (on projects that decide to allow fair use images), was the adoption of robust fair use evaluation criteria,^[10] and clear documentation of how those criteria applied to potentially disputed content.^[11]

We’re sure that many people in the Commons community will have their own ideas around how to stay strong and effective against these newer legal threats, maximizing the educational value of Commons, and making sure that existing processes are working as they should. If we can help with this, we hope you’ll let us know.

To all of you, we offer our deepest thanks for everything that you do. On behalf of the whole Legal Department at WMF,

Phil

1. ↑ Article 2(6) of the EU Digital Single Market Directive on Copyright
2. ↑ See, e.g. Graham Greenleaf, Global Data Privacy Laws 2023: 162 National Laws and 20 Bills https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4426146
3. ↑ https://wikimediafoundation.org/who-we-are/transparency/
4. ↑ https://medium.com/wikimedia-policy/what-happened-in-the-c%C3%A9sar-do-pa%C3%A7o-lawsuit-f91b7fb5e54b
5. ↑ https://medium.com/wikimedia-policy
6. ↑ https://medium.com/wikimedia-policy/wikipedias-nonprofit-host-brings-legal-challenge-to-new-online-safety-act-osa-regulations-0f9153102f29
7. ↑ https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_Combating_Online_Child_Exploitation_Policy/en#Child_sexual_abuse_material_(%22CSAM%22)
8. ↑ https://foundation.wikimedia.org/wiki/Resolution:Media_about_living_people
9. ↑ https://foundation.wikimedia.org/wiki/Resolution:Controversial_content
10. ↑ https://en.wikipedia.org/wiki/Wikipedia:Non-free_content_criteria
11. ↑ https://en.wikipedia.org/wiki/Wikipedia:Non-free_use_rationale_guideline

PBradley-WMF (talk) 12:51, 24 February 2026 (UTC)Reply

• @PBradley-WMF: Thank you for this carefully written and thorough message. At some point, if you think it would be helpful to have a Wikimedia Café session for live discussion, whether recorded or unrecorded, then please feel free to ping me on my Meta user talk page. ↠Pine (✉) 15:24, 24 February 2026 (UTC)Reply
• Thanks for posting this. It's a good reminder that the processes we've developed (and enforce on a daily basis) are important beyond Commons. I do read this as somehow straddling "keep up the good work" and "there's room to improve", but without concrete guidance on what needs to be improved. Perhaps that's by design, either for legal or community relations reasons. I'd be curious to get your unofficial thoughts on this sometime. One of the obvious liabilities regarding Commons and EDUSE is that we automatically consider something to be educationally useful if absolutely any Wikimedia project has it in use (including those with few active participants, with poorly developed media use policies, with no recent changes patrollers, etc.), and the prospect of going to that project to resolve the issue for them is typically frowned upon. In other words, even if we determine it would not otherwise be educationally useful, even someone using their own image in an article on a very small project invalidates our determination. — Rhododendrites ^talk |  16:12, 24 February 2026 (UTC)Reply

  if we determine it would not otherwise be educationally useful 1. where is the need to delete it unless it has some copyvio, dignity or similar issue – one could add for example a warning template to the page and/or rename the file 2. those places where files are used are editable and there's users there one could ping as well as discussion places. People too often depict the policy as being flawed. It isn't and it's super important to uphold; the conduct around it has maybe been flawed. We should not editorialize other projects without even notifying and including them.

  As far as I can see Commons currently deletes files that are realistically educationally useful (for educational websites, educational videos, maybe not Wikipedias, where specific realistic use-cases are described) while keeping things that are not realistically useful because a few people vote against deletion in DRs without being able to describe a specific educational use-case. Your creation, refinement and application of COM:EDUSE allows our allies and advocates to prove to judges, lawmakers and everybody else, that whilst there might be controversial content on the site, it should be legally protected: Commons is not a porn site, it is not a “gore” site, it is not a general filehost, and it is not a social media "Wild West"; it is an educational project. Been saying this all along; maybe it gets better understood now. Prototyperspective (talk) 11:19, 25 February 2026 (UTC)Reply

Most discussions we had around these topics came to the conclusion that the VRT would need handle possible new procedures as they require confidential information (one example). The VRT volunteers refused to be responsible for this. If we need better processes to prevent privacy and personality right violations, we need paid staff to do this, as we do not have enough volunteers. We could have more volunteer capacity to go into such a complex topic, if we would not wast so much time because of problems with the software and our tools. GPSLeo (talk) 16:36, 24 February 2026 (UTC)Reply

Sadly, deletion discussions on Commons are barely functional due to a lack of participation, and as Rhododendrites correctly notes above INUSE means that a lot of images that are extremely questionable as "educational" are left up. Many Commons users seem to have an extremely broad view of "educational images", seeming to view Commons as a place they can dump any sort of photographs that are in the public domain, such as old family photos found on Flickr and the like (which are uploaded under the premise that their copyright was never renewed/claimed to begin with). Due to its nature, Commons inevitably contains content that is educational but pornographic (such as old stag films) as well as gory (photos of people killed in conflicts) that regardless of educational value may lead to legal issues. Hemiauchenia (talk) 18:23, 24 February 2026 (UTC)Reply

Very recently, users had a discussion in which the possibility of having editors/curators was raised: Commons:Village pump/Archive/2026/02#Openly licensed propaganda/terrorist material. RoyZuo (talk) 18:29, 24 February 2026 (UTC)Reply

@PBradley-WMF: I echo Rhododendrites' request for some unofficial guidance from you. If there are areas in which we need improvement, it would be good to know. Abzeronow (talk) 04:21, 25 February 2026 (UTC)Reply

Hi all, just checking in to let you know we're actively following this discussion (and really appreciative of the reception it's receiving). It's already raising some interesting points and questions, and we always want to give as much breathing room as possible for communities to think things through and discuss what makes sense to you (rather than to some distant lawyer), so we might stay slightly peripheral/watchful for a little while. Just to take stock of what I think has been raised so far, in terms of "guidance" and ideas:

1. My original post emphasized the importance of careful assessment of deletion requests (or other admissibility debates) around privacy-sensitive or controversial content (at this point I don't really want to be drawn into debates over what constitutes controversial/NSFW content, but if you would like an idea of what some of the legal systems I have to deal with are thinking about, I can provide some examples). The more sensitive you think some content might be, the more emphasis there should be on having a robust and clearly-expressed educational use rationale for it (and if nobody is coming up with a particularly convincing educational use rationale, this might be a sign that the media in question belongs elsewhere on the Web, but not on Commons). Remember that it's not just your own peers in the community that need to be convinced of the overriding value of an item/category - my colleagues and I might also need to convince a very sceptical judge, jury, lawmaker, etc.
2. Drawing on our own practice in Legal when a complaint comes in (of going and looking at what debates the community has had about the content), we really appreciate the practice, on en-WP, of having a nicely drafted-up Fair Use Rationale for an image, e.g. https://en.wikipedia.org/wiki/Wikipedia:Use_rationale_examples . For controversial media or media depicting individuals perhaps against their will, having something similar (robustly explaining the educational use rationale) - either on the image itself/its Talk Page, or at least per-category (being mindful of workload) - could be something to think about.
3. On the topic of robust EDUSE rationales and what @Rhododendrites and @Hemiauchenia had to say about INUSE: is INUSE (in its current form) being used to undermine/bypass the Commons community's own discretion and experience in determining educational value? From my side, I will cautiously admit (noting that this is a public setting) that it's not always ideal having to defend Commons content, e.g. in court or administrative proceedings, solely on the basis that someone created (e.g.) a Wikidata item about something, and happened to pop an image in there. Maybe VRT agents and Village Pump/Help Desk responders feel similarly, when dealing with complaints from the public.
4. @Hemiauchenia also raised something we've sometimes observed when interacting with Commons: that sometimes, copyright considerations become dominant over others: if it's freely licensed, then that is "all that matters" to some members of the community (I exaggerate). Legally of course, that is often not true: copyright is there to protect the interests of the person behind the camera (or whoever else owns any IP rights in the work); but other laws, e.g. privacy law, are there to protect the person in front of the camera. The protection of IP rightsholders certainly matters, but I think it's absolutely correct that folks in the Commons community are equally concerned about the personal rights of the person shown in the photo/video/etc (especially in the era of LLMs usage etc). And that's where the balancing-of-interests test I mentioned in my first post, comes into play (if you'd like a quick example of how that test plays out in court, this is an interesting case).
5. @Hemiauchenia and @GPSLeo touched on workload problems. This is something we're acutely sensitive to - participating in Commons should be enjoyable; and a heavy backlog of DRs is in nobody's interest - almost by definition (since some DRs are valid), a backlog means there are files lingering on Commons that create risk (legal, reputational, etc), as well as work (community curation, persistent/recurring complaints, legal defense, etc). The significant ongoing growth of content on Commons^[1] is, in principle, a good thing - the enrichment of the digital commons - but it's important that the systems to support that (including/especially the human systems!) can keep up. Even though I work closely with folks in WMF Product & Tech, I'm from WMF Legal, so this perhaps isn't the right place to discuss tech work that could support this (though I encourage you all to keep engaging with P&T in all the appropriate spaces). Also, since well functioning systems help reduce legal risk, it would be remiss of me to not mention the admiration we have for everything the community does to find solutions to issues itself, e.g. @Ladsgroup's pretty nifty-looking idea for an alternative dashboard for DRs.^[2] We love pointing judges, lawmakers and reporters to just how unique that kind of empowerment is, and how well it works. That alternative dashboard is proof that this is a space that's ripe for further innovation. On the "human systems" side, it's nice to learn from @GPSLeo and @RoyZuo that there's active work going into assessing (and where necessary, improving) how folks in your community organize yourselves. We'll look into those discussions (in slower time) to see if there's any value WMF can add to those discussions.

1. ↑ https://analytics.wikimedia.org/published/reports/movement-metrics/current_monthly_report.html#content-metrics
2. ↑ https://wikicordo.toolforge.org/

PBradley-WMF (talk) 11:27, 25 February 2026 (UTC)Reply

Off topic: I think it's easier to read if you leave the links in the middle of the text, or use <ref>. RoyZuo (talk) 13:22, 25 February 2026 (UTC)Reply

I took the liberty of transforming the notes in a wiki-form. --Sannita (WMF) (talk) 15:31, 25 February 2026 (UTC)Reply

Hi @PBradley-WMF: did you intend to delete your reply to me, or did you intend to move the reply but it got lost in the process? ↠Pine (✉) 02:53, 28 February 2026 (UTC)Reply

Hi @Pine - yes, it was a deliberate removal for now - I think we'd be very interested in coming to a conversation, but I'm going to check with colleagues (working on related issues) what their own preferences are (re. timings, format, etc) so that I can come back to you with something more concrete. PBradley-WMF (talk) 20:22, 28 February 2026 (UTC)Reply

Is there somewhere in particular we can start a discussion on best practices in this respect? I have things to say, but I don't want to see this particular thread turn into an open-ended discussion that might get into real or even hypothetical cases. - Jmabel ! talk` 02:47, 27 February 2026 (UTC)Reply

Hi @Jmabel If it's a discussion with me/my colleagues that you have in mind, then for anything confidential there's legal [~@~] wikimedia.org ; and for anything that can be discussed openly, I think we're happy to be pointed to wherever makes sense for your community - be that a Village Pump, the Talk Page for COM:SCOPE/EDUSE, etc. As I said, if it's tech, then there are perhaps other places (Phab, Meta, this VP, etc) that make sense for that, too. PBradley-WMF (talk) 15:16, 27 February 2026 (UTC)Reply

• @PBradley-WMF: Please, I'm simply trying not to derail your thread with lengthy discussions of past controversies and of hypotheticals, proposals on best practices, etc. Don't derail your own thread! - Jmabel ! talk 19:21, 27 February 2026 (UTC)Reply

Is this only about depiction of people or other things, too? I'm wondering about privacy concerns regarding photographs of buildings: we've got regular DRs for photos of architectural heritage monuments, which currently are still in use as houses of private people. Those people discover photos of their homes here and then ask for deletion. What should be done in such a situation? Nakonana (talk) 10:35, 1 March 2026 (UTC)Reply

Hi @Nakonana - if in doubt, applying that balancing test (strength of EDUSE vs. degree of privacy intrusion/harm) is probably a good move. In my career, I have seen complaints (e.g.) about non-consensual photographs taken inside a vulnerable person's apartment (showing religious iconography, bedroom contents, etc) - so you can perhaps imagine that not all pictures of "property", including buildings, play into such an assessment in quite the same way. PBradley-WMF (talk) 17:15, 2 March 2026 (UTC)Reply

I want to add my quick 2c to this thread. As a user with VRT access, I’ve seen removal and deletion requests citing privacy reasons increase dramatically over the past few years. Whether each one is truly driven by privacy concerns or sometimes serves as an easier route to removal is something I won't speculate on here.

One of the fundamentals of our policies is that if a file is actively in use on any other Wikimedia project, it is by definition being used for educational purposes — whether that use is perfectly executed or not. In my view, this is the gold-standard "educational rationale". We can talk all day about potential educational value, but actual, real-world use on a sister project (even a small one with limited editors and oversight) is concrete evidence that the file serves an educational function.

One could argue that a particular use isn't automatically a "strong" or ideal educational application, but in my book practice beats theory every day of the week. This approach has served us well when balancing educational value against other legal interests, and I believe it remains one of our strongest protections. --Jonatan Svensson Glad (talk) 17:24, 2 March 2026 (UTC)Reply

Since wikicordo has been mentioned here, any ideas or ways to improve it (specially if it's missing a common keyword for tagging), please let me know. I hope it's useful for people. Amir (talk) 14:36, 27 February 2026 (UTC)Reply

• @PBradley-WMF: You raise multiple complex issues which the Wikimedia community has discussed seriously multiple times over the past 20 years. Before I respond to your questions, I have a response to the way that you are asking. Instead of asking here in this forum, I request that the Wikimedia Foundation somehow make a resource investment in thoughtfully collecting Wikimedia community feedback on these social and ethical issues, and then further invest in summarizing and documenting what the community says. The Wikimedia volunteer community deliberation process has lots of successes in its history, but some conversations are too complex to discuss with posts on discussion boards. Without some kind of convening and organization, virtual or otherwise, and without dedicated labor to make sense of more points and text than volunteers can casually process, it is challenging to advance conversations.

To the content of your questions, here are some possible discussion directions -

• I have a collection of edge cases in permissions for photos on Commons at Commons:Model license/Case studies. I framed this as a discussion about "model licenses" on Commons, which may not be best, but in any case, these are discussions where Wikimedia community members said that Commons should not be hosting photos of people without permission of the subjects of the photos. Some recurring cases here are medical photos intended for physician education; photos of naked people of all kinds for many reasons; photos of people protesting, demonstrating, or marching in public spaces to advocate for a cause; people-on-the-street photos capturing scenery; promotional photos from governments depicting people without consent; and photos where the uploader claimed to have consent of the depicted but for which Commons had no satisfying process to confirm this.
• I want to share an opinion and remark which comes up frequently in Wikimedia projects. I edit with Wikimedia LGBT+. People take photos of Gay Pride Marches. These are very popular events, familiar to people in large cities around the world, and which have happened for decades. It routinely happens that people marching in those events, who are comfortable demonstrating publicly on the streets for gay rights, and perhaps holding signs and doing other attention-seeking behavior, also have an expectation of privacy around what they are doing and an expectation that they should have control over the photos which people take of them, if someone posts their pictures online. The conflict here is that Wikimedians and others feel a right to take photos of people on streets demonstrating, while the subjects of those photos complain of a right to have those photos removed from Commons.
• Going beyond gay pride, for every sort of protest imaginable, the general case is that people doing protests around the world in any protest for any matter, often complain of Wikimedia projects retaining their photos. Wikimedia Commons does not have a mechanism for counting such requests. Because Wikimedia LGBT+ is an organization, its members have organizational memory of encountering the requests specifically on LGBT+ demonstrations.
• On the taboo topic of child exploitation, I support the Wikimedia Foundation in taking measures to stop it. At the same time, I am aware of child safety being a dishonest and fake accusation which governments around the world have directed at tech platforms to pressure them to reduce civil rights to communication, reduce privacy, and to deter participation. I know that this is a sensitive area. I am aware of the Wikimedia Foundation's annual transparency reports and the count of how many child safety alerts we received. In that context, it is my belief based on the evidence that Wikimedia projects have better protection for child safety than any of the other platforms with which we could be compared, but also, Wikimedia projects get accused much more frequently and more harshly than we deserve. When Wikimedia projects are accused of lacking child safety, I think that often the reason for that is because we are an independent media source publishing neutral information which may conflict with the views of powerful and wealthy institutions. I personally have never heard of anyone anywhere in Wikimedia projects who has encountered or spread a rumor that Wikimedia projects have been used for child exploitation. In comparison, I think it is common knowledge among people in Internet culture that the major platforms such as Instagram, YouTube, Twitter, Google products, and all other major tech platforms are routinely channels for transmitting such content, but I feel like there is a tendency for governments to forgive major commercial platforms for known offenses but to accuse smaller community efforts of being theoretical offenders. I do not want the Wikipedia platform to harshly restrict access to people's right to read and edit Wikipedia based on unfounded fears and problems which are routine in commercial platforms.

Thanks. Please support efforts for third-party university or other expert researchers to examine Wikimedia projects, and for Wikimedia users to talk with each other, and for Wikimedia Foundation staff to better understand Wikimedia community values and ethics. Incidentally, I do not feel that the Wikimedia community ever had a productive direct conversation about en:reporting of child pornography images on Wikimedia Commons. So far as I know based on everyone I have ever met, the consensus from that event is that there were zero offending images ever found in that accusation. Whatever the case with that, I wish that the Wikimedia Movement could collectively admit any offenses, and teach the community to understand how we prevent such problems. That event in 2010 was a chaotic disruption including for Wikimedia coverage of sexual health and LGBT+ topics. The outcomes of that event were not public, so I have limited understanding of what happened in that event or what the full list of deleted media was, but so far as I know, the deleted images were of the sort which which are routinely posted as art or education in platforms like Instagram. I recognize the wish to put the past behind but also I question whether Wikipedia can ever move on from this issue and our past with it, and feel like we have strength in community awareness and collective decision making on how to protect our ethics and values. Bluerasberry (talk) 19:03, 2 March 2026 (UTC)Reply

This seems to be going increasingly deep into being a discussion of specifics, effectively derailing the discussion of a process by which we will address this policy area. - Jmabel ! talk 19:38, 2 March 2026 (UTC)Reply

Hi all

I remember a few years ago someone, I think someone at WMF created a tool to generate graphs using data from Our World in Data on Wikimedia projects. Does anyone know what happened to it? I'd like to use the tool on an outreach project with one of the UN agencies that produces data they use.

Thanks

John Cummings (talk) 17:42, 24 February 2026 (UTC)Reply

Are you referring to Template:Owidslider? A related gadget is m:OWID Gadget and a related tool is the OWID Uploader tool. Prototyperspective (talk) 18:31, 24 February 2026 (UTC)Reply

Hi Prototyperspective thanks very much. I left a couple of questions on the talk page about using the gadget, I would really love to use it in a project I'm working on. John Cummings (talk) 22:40, 24 February 2026 (UTC)Reply

@John Cummings and Prototyperspective: coincidentally, a discussion regarding interactive graphics is scheduled for a May 2026 edition of the Wikimedia Café. ↠Pine (✉) 02:23, 25 February 2026 (UTC)Reply

Hey John, the folks working on this are not the WMF but myself and Wiki Project Med Foundation. Though we have received some generous funding from the WMF. Ping me if you have questions. Doc James (talk · contribs · email) 05:53, 25 February 2026 (UTC)Reply

Hi @Prototyperspective, Pine, and Doc James: thanks very much :) It's wonderful its working, can I ask a few more questions?

1. I'm not very knowledgeable on kinds of tools on Wikimedia, does it being a gadget mean that non logged in users (99.9% of readers) can still see and interact with the interactive graphics?
2. Currently I think the level of documentation isn't detailed enough for me and people I'm working with to use since none of us have a technical background, are there any plans to expand the documentation into a step by step guide? Or even plans to expand the gadget to make it easier to generate graphics?
3. Is it possible to use any dataset currently on OWID? Or is it limited to specific sets? Also do the maps magically update over time as new datasets supersede the old ones?

Thanks again

John Cummings (talk) 09:50, 25 February 2026 (UTC)Reply

It is visible to all readers. You can see an example live here[1]

Super easy to use, just copy and past the code from here Commons:List_of_interactive_data_graphics

Each of the pages there has a little "translate" tag if you want to use the translate tool to convert it into another language

Yes the hope is that we can develop a somewhat automated updating method

We have so far uploaded 813[2] and there are another 1300 or so to be uploaded.

Doc James (talk · contribs · email) 10:23, 25 February 2026 (UTC)Reply

Hi Doc James

Thanks very much, a few thoughts:

1. The examples are great but I don't understand how it works just from examples, there is too much assumed knowledge. Honestly I think what is needed is a explanation of the different parts and how they fit together and then a step by step guide on exactly what to do. How to find data on OWID and how to use that on Wikipedia. I think this is just a natural process of moving from a small group of people with a lot of knowledge using and developing a tool to a wider audience. I might be able to help with improving the instructions after the end of the month if I can find some time.
2. Do you mean that if new data is added to OWID (eg a new year of data is added for a dataset) that the template does not see this new data and doesn't update the graphic.

Thanks again

John Cummings (talk) 11:19, 25 February 2026 (UTC)Reply

There are alot of moving parts and we have built multiple methods to do the visualizations. Might be easier to run through by videochat. Doc James (talk · contribs · email) 19:57, 25 February 2026 (UTC)Reply

With respect to your 2nd question regarding updating. We have built one method that could potentially update automatically / or not depending on what the editor wants. And the other method we have built does not update automatically but we are working on tools to support easier updating.

Hope to have the opportunity to speak about this at Wikimania. Doc James (talk · contribs · email) 08:59, 26 February 2026 (UTC)Reply

Re 1. how to use it is described at c:Template:Owidslider. So using interactive charts that were already uploaded to Commons is easy (the steps are finding template, copy, and paste); adding new charts which have not yet been uploaded to Commons is not (one needs to use the owid uploader tool). Prototyperspective (talk) 12:23, 26 February 2026 (UTC)Reply

I was 1 click away from nominating {{Verified account}} for deletion because a VRT agent literally said it has no purpose. At the last moment I stopped. Asking here is probably less disruptive than starting a DR. This just can't be right. Right?
Right?
Are my eyes deceiving me? Should that template be nominated for deletion? Am I completely misunderstanding what's going on? - Alexis Jazz ^{ping plz} 15:28, 16 February 2026 (UTC)Reply

I think there is a bit of a range of disagreement over what VRT can and cannot do, and that range extends into the membership of the VRT itself.

My own view? The VRT are the only people here authorized to handle confidential correspondence. If there is a need to verify the identity of the holder of a particular account, and the account-holder wants to do that, and the only way to do that involves confidential correspondence, it seems to me the VRT should do that. I'm honestly unsure of what would be the argument against that, other than, "Resources are limited." If that's the only argument, then (1) we probably should be recruiting more VRT members. I haven't seen any active recruitment, but might have missed something. (2) It's hard for me to see why this would be a lower priority than validating the permission for a particular photo.

If the argument is that confirming a particular identity would somehow breach confidentiality, in this case that is absurd. Of course they cannot name a person who wishes to keep their actual name private, but if the whole point of a particular correspondence was to establish their identity, and if they are publicly asserting that identity here on Commons, there is no confidentiality to breach. - Jmabel ! talk 19:49, 16 February 2026 (UTC)Reply

I think it is more along the lines that we can't 100% truly identify someone, only take their word, accept that an email's been sent from an official looking email domain, etc. We can never be 100% sure, and the account may even be shared etc. That's my guess on Krd's weird comment, since we are tasked on at least Commons and enwp, to verify identity (e.g. on enwp, users are directed to to VRT in order to verify identity in case of e.g. notable name in username). --Jonatan Svensson Glad (talk) 20:05, 16 February 2026 (UTC)Reply

IMO verifying an identity means requesting a copy of an ID document. And it has been done. So I am surprised by Krd's comment. Yann (talk) 20:13, 16 February 2026 (UTC)Reply

We really should not request or store ID cards, per different countries laws. I think there's a policy page about that, but don't have time to check right now... --Jonatan Svensson Glad (talk) 20:20, 16 February 2026 (UTC)Reply

My country has an app to blank unneeded information from copies. That strongly reduces the abuse potential. If someone sends VRT a scan of an ID to prove they share their name with a notable person there's no need for the photo, date of birth, gender, social security number, etc.
VRT shouldn't request unblanked IDs IMHO. Whether they are (or should be) allowed to request partially blanked IDs is a good question. But if not, I'm unsure how someone could prove they share their name with a notable person. Maybe with a partially blanked scan of a non-identity document? (would you accept a random w:loyalty card?) Either way, {{Verified account}} would have a purpose in this. - Alexis Jazz ^{ping plz} 05:23, 17 February 2026 (UTC)Reply

Yes, I agree. If ID documents can partially edited, but still sufficient to prove an ID.

BTW this remains me of an anecdote a few years ago on the French Wikipedia. A minor actress contested her day of birth published by several sources, and claimed to be around 10 years younger. So some proof was requested. She then sent a copy of an ID card where her date of birth was indeed around 10 years later than what sources said. After careful examination, it appeared that the ID card was fake. So the copy of an ID document is not an absolute proof. Yann (talk) 20:20, 20 February 2026 (UTC)Reply

In the example of this case, I think it'd sufficient if VRT found the person to be mailing from a domain that is controlled by the subject (e.g. "@FirstnameLastnameLLC.com"), law firm or professional PR company. Alternatively they could prove they have control over such a domain or verified social media account. Law and PR firms could technically lie about representing the subject, but the potential for reputational damage makes that unlikely. VRT is not writing legally binding contracts, but helps us distinguish between randos and people who most likely are who they say they are, whether that's the author of a particular work or (a representative of) a notable person.
{{Verified account}} should be perfectly usable for this, hence the confusion. - Alexis Jazz ^{ping plz} 04:58, 17 February 2026 (UTC)Reply

1. this discussion doesnt concern sysops only.
2. how does other websites' verification work? fb ig twitter youtube...?
3. could their verification methods be feasible for wikimedia?

RoyZuo (talk) 20:49, 20 February 2026 (UTC)Reply

1. Yes, please open the discussion where you think is best.

2. & 3. These websites do not require an ID, but block on sight if they think you are doing wrong. Some public domain movies where deleted from my YT account without any prior warning, but with a warning that my account may be blocked. I contested the deletion, but didn't receive any answer. Yann (talk) 21:41, 20 February 2026 (UTC)Reply

I think RoyZuo meant verified accounts. (like blue check marks) @RoyZuo:

• YouTube requires 100K subscribers and possibly "documentation".
• FB/IG: $15/month
• Twitter: will probably be thrown in as a freebie with any purchase of an Optimus real boy.

Some platforms (especially when they don't "like" your IP address) require a phone number just to create an account. VRT could maybe sometimes verify someone's identity if their phone number is publicly known? - Alexis Jazz ^{ping plz} 04:56, 21 February 2026 (UTC)Reply

If a template has lost its purpose just tag it as {{Deprecated}}. No need to delete it. Ruslik (talk) 19:49, 25 February 2026 (UTC)Reply

The issue is that the template is in use on user pages, and states that users can contact VRT to verify an account's identity. If VRT isn't actually able to service these requests, the template is misleading, and it should probably be removed.

As a point of comparison: if a user has {{User administrator}}) on their user page, and they are not actually an administrator, it's perfectly reasonable for anyone to remove the template - it's misleading. {{Verified account}} is a similar claim of authority; if it's actually an empty claim, it's misleading too. Omphalographer (talk) 00:09, 27 February 2026 (UTC)Reply

I regularly use this template. Unfortunately, identity verification through VRT is not a well-documented process, which is why you have so many different agents with different views on how it should be done (or if it should be done at all). At least in my experience, identity verification through VRT does not usually mean confirmation of offline identity through ID cards and the like. A much more common scenario is if a Wikimedia user frequently uploads their work to another website, but they don't want to put a free license or mention their Wikimedia username on that website. In that case, an email from that domain confirming that the Wikimedia account belongs to them allows their account to be marked as verified so that they can upload their works without sending a permission statement to VRT every time; the clickwrap on the upload form is sufficient as long as we are confident they are the same person. -- King of ♥ ♦ ♣ ♠ 07:37, 28 February 2026 (UTC)Reply

This probably comes up a lot but is there any way to replace a PNG (File:Union Jack, 1x1.png) with an SVG that supersedes it (File:Union Jack, 1x1.svg)? If so, can I do it myself or do I need to put in a request somewhere? The PNG seems to be used on a lot of pages as the result of one or more templates of some sort but I can't seem to find it/them. GPinkerton (talk) 05:45, 26 February 2026 (UTC)Reply

Looks like a lot of one-off user license templates like User:Poco a poco/credit. You'll have to change them all individually. Omphalographer (talk) 08:53, 26 February 2026 (UTC)Reply

GPinkerton, User:CommonsDelinker/commands says: To avoid drama, CommonsDelinker will ignore a command to replace an image if the new image is svg and the original is not.
https://global-search.toolforge.org/ might be helpful. I'm generally more reluctant to change user pages if the replacement is not an indisputable improvement, which it hardly ever is. - Alexis Jazz ^{ping plz} 00:57, 27 February 2026 (UTC)Reply

That To avoid drama thing may be changing. See User talk:CommonsDelinker/commands#Replace images with .svg version and, I suppose, User talk:CommonsDelinker/commands/talk#svg image renames. It would appear that User:Grin has not followed up on the latter. If someone else wishes to, I'd be fine with that. - Jmabel ! talk 01:56, 27 February 2026 (UTC)Reply

@Jmabel: "To avoid drama" was changed from "To avoid World War III" in this edit 16:00, 23 March 2019 (UTC). "To avoid World War III" was added in this edit 13:30, 19 July 2007 (UTC). Thus, I conclude that this action was contentious enough 19 years ago that the developers had to enact a specific prohibition against it. It is probably still contentious.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:20, 28 February 2026 (UTC)Reply

Possibly. 19 years ago, we had a high percentage of crappy SVGs, and not a lot of people here who knew how to do good ones. I think that has changed. - Jmabel ! talk 20:37, 28 February 2026 (UTC)Reply

Another thing, 19 years ago takes us back to 2006-2007, and IIRC, the technological support for SVG in browsers back then was not very developed. The Internet Explorer on Windows XP or Windows Vista wasn't really able to digest them, for instance. Regards, Grand-Duc (talk) 21:19, 28 February 2026 (UTC)Reply

Participate at Commons talk:Project scope#Proposed change: excluding images do not comply with COM:AIP from COM:INUSE rules.

So far, 10 out of 19284 Commons contributors with over 1000 edits have participated. Prototyperspective (talk) 12:48, 28 February 2026 (UTC)Reply

Misleading framing. Nobody has proposed getting rid of INUSE. INUSE contains Files that are currently in use may still be subject to deletion for reasons beyond their scope, including but not limited to:, and the proposal is to add a bulletpoint to that existing list. But yes, could use additional participation. — Rhododendrites ^talk |  13:13, 28 February 2026 (UTC)Reply

One could also ask if we should keep INUSE files. In any case, your view that this is not getting rid of COM:INUSE is misleading because that policy is about exempting files that are in use unless there's reasons beyond their scope – and people now want to start excluding more and more files from the policy that they object to being within scope. If the policy is rewritten to say INUSE applies unless contributors decided in other Commons policies that the files are outside scope or is just ignored in select cases, then that's abandoning COM:INUSE we currently have and having a new variant of it – so the old variant of it is not kept as the policy gets changed at its core. Prototyperspective (talk) 13:22, 28 February 2026 (UTC)Reply

I notice that some of these are hidden cats and some are considered topical. I was surprised to see that Category:Photographs by Asahel Curtis was hidden when Category:Photographs by Edward Sheriff Curtis (his brother) was not, so I changed the former, but now I see Category:Photographs by Frank H. Nowell (among other things, the official photographer of the Alaska-Yukon-Pacific Exposition) is also hidden.

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)Reply

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)Reply

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)Reply

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. — Rhododendrites ^talk |  16:08, 1 March 2026 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

I requested the creation of a New Jersey Public Domain license, and I have listed my rationale for the request in my original post in Commons:Template requests. I was informed that such a license template used to exist but was deleted in 2013, and again in 2018. Has this consensus changed such that it could permit the creation of a new public domain license for New Jersey? ForeverFlying (talk) 01:30, 22 February 2026 (UTC)Reply

 Comment, convenience links:

• Template request: Commons:Template requests#New Jersey public domain license
• Template: {{PD-NJGov}}
• Deletion request: Commons:Deletion requests/Template:PD-NJGov

Thanks. Tvpuppy (talk) 01:37, 22 February 2026 (UTC)Reply

ForeverFlying (talk) 00:08, 2 March 2026 (UTC)Reply

The relevant laws are [3] and [4]. This act only makes "data" and "datasets" (and any associated maps, charts, or graphs) PD. As noted in the DR, most such information would already fall under TOO in the US under decisions like Feist v Rural. While it's possible some more complex images could benefit from this license (a voter map perhaps), it's not enough to justify a whole template, as the DR noted. It would be too confusing to most people, who would just see the template and slap it on things. -Nard (Hablemonos) (Let's talk) 02:05, 2 March 2026 (UTC)Reply

Thank you for finding the legal citations! As someone who is not well-versed in copyright law, I agree with your assessment that having a template available without expressly making it clear that it's for data only would result in misuse. As far as whether even making a template solely for datasets available is something I cannot comment on, as I have no experience uploading or maintaining datasets on here. ForeverFlying (talk) 02:14, 2 March 2026 (UTC)Reply

Commons wouldn't host raw data sets. There are some forms of data that could be relevant here: maps of election results or crime statistics, for instance, but this is a bit far fetched, as most such maps are user generated anyway. -Nard (Hablemonos) (Let's talk) 02:18, 2 March 2026 (UTC)Reply

• I may have made the template in the past. I think it was used for birth, marriage, and death certificates that were released into the public domain by the state, but it was agreed that the documents were ineligible for copyright, so it was seen as a duplication to {{PD-ineligible}}. From time to time, birth, marriage, and death certificates are challenged as eligible for PD-ineligible, but I believe consensus has been steady since then, that they are PD-ineligible. --RAN (talk) 05:21, 3 March 2026 (UTC)Reply

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)Reply

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? HurricaneZeta^C 15:02, 2 March 2026 (UTC)Reply

@HurricaneZeta:

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)Reply

@Jmabel I was thinking that the template would categorize it into the category. I have seen quite a few templates like {{Official Prime Video AU & NZ YouTube channel}} (essentially the same as {{YouTube}} with an explanatory note), although maybe something like {{YouTubeReview}} would suffice. HurricaneZeta^C 19:54, 2 March 2026 (UTC)Reply

{{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)Reply

https://www.youtube.com/watch?v=33y9FMIvcWY

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)Reply

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)Reply

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)Reply

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)Reply

• Mass rename started. - Jmabel ! talk 06:58, 3 March 2026 (UTC)Reply
• @PinkBee: should all be done, let me know if some admin-specific task remains. - Jmabel ! talk 07:36, 3 March 2026 (UTC)Reply

  Thanks. Please could "PinkBee" be replaced with "Pink Bee"? This should put the files in Category:Lingua Libre pronunciation by Pink Bee. Pink Bee (talk) 07:55, 3 March 2026 (UTC)Reply

  @Pink Bee I have replaced them, let me know if I have missed any. Thanks. Tvpuppy (talk) 20:53, 3 March 2026 (UTC)Reply

  Looks good. Thank you :) Pink Bee (talk) 23:17, 3 March 2026 (UTC)Reply

Do we have a tool or script for importing PD works from Google Books? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 23 February 2026 (UTC)Reply

Here is my Violentmonkey user script to download all the pages I am using it to download all the public domain issues of Jet magazine this can be saved as bookmark or run in browser console it doesnt need Violentmonkey I forgot I was trying another approach that needed it

javascript:(function() {
	let scroller = document.getElementsByClassName('scroll-background')[0];
	scroller.scrollIntoView({ behavior: 'smooth', block: 'end' });
	setTimeout(function() {
		scroller.scrollIntoView({ behavior: 'smooth', block: 'start' });
		setTimeout(function() {
			scroller = scroller.parentElement;
			setTimeout(function() {
				const looper = setInterval(function() {
					scroller.scrollTop += 835;

					let title = document.getElementsByClassName('gb-volume-title')[0].innerText;
					let urls = [];
					let filenames = [];
					let imgs = document.getElementsByClassName('pageImageDisplay');
					const imgsOffDiv = imgs[imgs.length-1].getElementsByTagName('img');
					let url = null;
					for (let i = 0; i < imgsOffDiv.length; i++) {
						const curr = imgsOffDiv[i].src;
						if(!curr.endsWith('.gif')) url = curr;
					}
					url =url.replace(/\&w\=.*/g, '&w=12800');
					const filename = title + '_pg_' + url.replace(/.*\&pg\=/g, '').replace(/\&.*/g, '');
					const link = document.createElement('a');

					link.href = url;
					link.download = filename+".jpg";

					document.body.appendChild(link);
					link.click();

					document.body.removeChild(link);
					if(Math.ceil(scroller.scrollHeight - scroller.scrollTop) === scroller.clientHeight) clearInterval(looper);
				}, 500);
			}, 2000);
		}, 3000);
	}, 1000);
})();

${\displaystyle 999}$ REAL 💬 ⬆ 14:37, 23 February 2026 (UTC)Reply

Cool script! I imagine when it comes to Google Books it's a big problem that usually only some pages are available so I doubt it's an ideal or even good source with exceptions. Nevertheless, there may be some page where this script could be useful and linked, ideally with info how to quickly make a PDF out the individual page images. Maybe Help:PDF. Prototyperspective (talk) 22:51, 23 February 2026 (UTC)Reply

It should be possible to totally automate it and do it in the background as a program with Selenium for external inputs I think there was one that does that but it didn't work for me I can try making one myself ${\displaystyle 999}$ REAL 💬 ⬆ 02:49, 24 February 2026 (UTC)Reply

This should not be an issue in the cases to which I refer (such as [5], [6]), where a single PDF file is available from a "Download PDF" button; I'm looking for a tool which will fetch that, and the related metadata, and upload them to Commons. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:49, 3 March 2026 (UTC)Reply

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)Reply

Hello everyone. It's my "officially" first time to announce the winners of this challenge.

Congratulations to @Julian Herzog, KaiBorgeest, Foeniz, Gzzz, Muzzudan, and Fischer1961. This is Taiwania Justo speaking (Reception Room) 15:41, 3 March 2026 (UTC)Reply

Danke Fischer1961 (talk) 20:02, 3 March 2026 (UTC)Reply

Thanks :-)) Gzzz ^zz 20:13, 3 March 2026 (UTC)Reply

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)Reply

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)Reply

Richard Arthur Norton, only works on articles with a Wikidata item and sitelinks for other projects on Wikidata. - Alexis Jazz ^{ping plz} 02:00, 4 March 2026 (UTC)Reply

• 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)Reply
  • @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)Reply
• No, let me delete Chrome and re-install it. --RAN (talk) 05:23, 4 March 2026 (UTC)Reply

  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)Reply