Commons:Village pump

Shortcut: COM:VP

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

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

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

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

Village pump in Rzeszów, Poland [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive User talk:CommonsDelinker/commands#Replace images with .svg version (5 August 2025) Category talk:Heroes' Cemetery in the Philippines#RfC: Cemetery name (18 July 2025) Hosting of free fonts in Commons (18 July 2024) Template: View   ■ Discuss    ■ Edit   ■ Watch

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

December 30

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

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

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

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

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

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

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

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

• 
• 
• 
• 

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

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)

@Smiley.toerist I just added some categories. ;) LucaLindholm (talk) 11:16, 9 March 2026 (UTC)

This file has been overwritten and categorized by now. NearEMPTiness (talk) 09:45, 1 February 2026 (UTC)

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)

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)

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

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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

Is there a follow up for Category:All media needing categories as of 2021? Smiley.toerist (talk) 12:22, 4 March 2026 (UTC)

@Smiley.toerist: The follow project is Commons:WikiProject Minimum One Category. There we deal also with the images of 2021. The main goal is to have zero uncategorized media. --sk (talk) 13:14, 4 March 2026 (UTC)

The page is an manual, not a project with discussions. For example: How to deal with a person 'Ruby Kinghorn' in File:Ruby Kinghorn, aged about 2, Pilrig Park (5723272734).jpg. There is only one other hit in the Commons and the person is not famous. (no Wikipedia article, and several minor leads in Google). So create a commons category for the person? or just ignore the information?Smiley.toerist (talk) 14:29, 5 March 2026 (UTC)

The page has a talk page which is the place for discussions. So create a commons category for the person? Probably not unless the person is notable. Prototyperspective (talk) 15:03, 5 March 2026 (UTC)

January 02

History maps of Europe

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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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)

February 22

Maps from Our World in Data

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)

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)

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

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)

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)

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)

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

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)

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)

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)

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)

[[: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)

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)

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)

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

I can happily come up with a suggestion for a template based on the Navigation by system. But first let me make sure I understand correctly:

1. The template would be used for categories like Our World in Data maps of Oceania showing 1947 data, right?
2. Would we also have Our World in Data maps of Oceania showing 1940s data (decade) and Our World in Data maps of Oceania showing 19th-century data (century) as parent and grandparent of the year category?

Thanks --Reinhard Müller (talk) 09:07, 4 March 2026 (UTC)

Thanks Reinhard, regarding #1 yes that is idea.

{{OWiD maps showing|Africa|175|8}} --> Our World in Data maps of Africa showing 1748 data

{{OWiD maps showing|Oceania|194|7}} --> Our World in Data maps of Oceania showing 1947 data

As for #2 I would have suggested "... showing the 1940s" and "...showing the 20th-century" as parent categories. But you're right, I talked above about "<year> data" so "<decade>s data" and "...<century> data" would be the logical consequence. Now I'm less sure about the format. I am not married to the idea of requiring the "data" suffix, but as long as the template could be made, I see no real problem. @Prototyperspective: , what do you think about "Our World in Data maps of Oceania showing 20th century data being the respective category on the century level? Enyavar (talk) 19:11, 5 March 2026 (UTC)

I have now created:

Templates

• {{Category description/Our World in Data maps by continent and century}}
• {{Category description/Our World in Data maps by continent and decade}}
• {{Category description/Our World in Data maps by continent and year}}

Example use

• Category:Our World in Data maps of Oceania showing 20th-century data
• Category:Our World in Data maps of Oceania showing 1940s data
• Category:Our World in Data maps of Oceania showing 1947 data
• Category:Our World in Data maps of the world showing 1947 data

The usage of the templates is super easy, no need for any parameters specifying the continent or the year, they take everything they need to know from the name of the category they are used in.

The names of the continents are automatically translated using Wikidata labels. The first part of the title and the text above and below the navigation blocks are just examples. These can be used as an explanation for the category which is centrally maintained and must only be changed once if something should be changed, and if the texts are final, we can also make them translatable.

Please let me know what you think. --Reinhard Müller (talk) 09:52, 6 March 2026 (UTC)

P.S. Looking at the currently existing category tree about maps, I really think that the OWiD categories shouldn't be in Category:1947 maps of Oceania or Category:1940s maps of Oceania. For centuries, we already have Category:Maps of Oceania in the 20th century, and I think it might be a good opportunity to introduce these categories also on a decade and year level. If you want, I can also create the templates for "Maps by continent and century/decade/year shown". And/or whatever you consider useful for building the correct parent structure for the OWiD categories. --Reinhard Müller (talk) 14:37, 6 March 2026 (UTC)

@Reinhard Müller: Thanks a lot! This is even easier to apply than I thought. I populated three continents for the 1940s (Africa, Asia, Oceania) and also the world.

The decade-template for the world in the 1940s did not work (lua template cannot find "the world"), I hope this can be fixed. Aside from that it looks pretty great. Sorry, two more nitpicks, some links only appear once some other part of the structure has been fully built up. The year-ribbon only shows up once the decade-category is in place; and it seems as if the decade template only shows up once the century-category is in place? Also, I think that the subcategories could be sorted with a space (" ") instead of the "@".

I agree with your proposal that instead of "1947 maps of Oceania" we should have "Maps of Oceania in 1947" which would be the "maps showing"-version. "Maps of Oceania in 1947" would be a subcategory of "Maps showing 1947", "Oceania in 1947", "Maps of Oceania in the 1940s" respectively. This category would then hold the OWiD maps and all maps that show Oceania in 1947 through the historian's lens, similar to how we already have Maps of Poland in the 16th century (see also one thread above...) and Maps of the world in the 1940s.

@Universalis, Prototyperspective, Jmabel, and Doc James: when you check the bolded links... does this new structure look okay? --Enyavar (talk) 15:22, 8 March 2026 (UTC)

Very nice. Are you using a bot to apply this? Or have you tried Help:Gadget-CategoryBatchManager? Doc James (talk · contribs · email) 16:46, 8 March 2026 (UTC)

Thanks for the feedback!

• I fixed "the world" (ooh, it feels good to write this ;-))
• It is generally true that the template works best when the categories are created top down (i.e. first the centuries, then the decades, then the years). Still the navigation ribbons should appear even if the parent category does not exist (yet), I will have to investigate why they don't. But for the addition of the correct parent categories for new categories, it is important anyway that the parents pre-exist.
• I have (years ago) thought a lot about the question of logical sort keys, currently they are used very inconsistently across commons. I've even made a page summarizing my thoughts which you may or may not agree with. About this specific case, I think the space is widely used for meta categories (Blah blah by xyz) and should be reserved for that, and that the @ has the advantage of being sorted after all the other special characters, so if for example the category key "*" is before the alphanumeric subcategories, it is also before the numeric subcategories if the numeric are sorted as @. In the end I don't think in our case it makes much of a difference as long as all the subcategories use the same key so they are sorted correctly - which is taken care of by the template.
• About the "Maps of Oceania in 1947", would you want to also create them right now? Should I create a {{Category description/Maps by continent and year}} (and decade and century), and adapt the OWiD templates to the new parents?
• I don't use a bot, and I think that the CategoryBatchManager can add parent categories, but not a template. But since you don't have to change a single letter when copying the template from one category to a similar one, it can be done very fast. --Reinhard Müller (talk) 18:02, 8 March 2026 (UTC)

About the "Maps of Oceania in 1947" - yes, you could create a template for that, as well. We already have parts of that, but right now they were created in a manual fashion: North America/1770s and Asia/18th and Europe/11th. I'm not yet fully eager and ready to apply this structure as long as the other treat about #History maps of Europe is still unresolved. But having the templates prepared now might help later. Once those maps-per-continent-shown-by-year exist, the OWiD template would be switched from "1940s maps of Asia"+"Maps showing the 1940s" --> "Maps of Asia in the 1940s" and so on. --Enyavar (talk) 19:51, 8 March 2026 (UTC)

I have created:

• {{Category description/Maps by continent and century shown}}
• {{Category description/Maps by continent and decade shown}}
• {{Category description/Maps by continent and year shown}}

I have not (yet) changed the parent categories for the OWiD categories. Please just let me know when I should do that.

Also please don't forget that the texts above and below the navigation ribbons are just placeholders (in the OWiD templates and the new templates), and they should be finalized before the templates are widely used. --Reinhard Müller (talk) 22:02, 8 March 2026 (UTC)

But first, we need to categorize the OWiD maps. I populated the 1940s structure with a few hours of Cat-a-lot, but there is a catch: all these maps currently have the template {{Map showing old data|year=1942}}. For the 1940s alone, removing that template means manually editing 17'500 files. We must use a bot to do these edits, I think. The algorithm, for all ~75'000 maps of Asia would be roughly as follows:

• for all files in [[Category:Our World in Data maps of Asia]]
  • if "{{Map showing old data|year=YYYY}}" occurs in the file:
    • take the YYYY as a variable to insert "[[Category:Our World in Data maps of Asia showing YYYY data]]" //** a single category for the location and year of the map **//
      • if that inserted category does not yet exist: create it with "{{Category description/Our World in Data maps by continent and year}}" //** (as helpfully provided by Reinhard)**//
    • take the file name as the variable topicname and strip File: and , Asia, YYYY.svg (or ,Asia,YYYY.svg) from that variable
    • insert "[[Category:Our World in Data maps showing ||topicname]]" //** for example Category:Our World in Data maps showing Absolute change co2, neatly collecting ~1800 files like this one or ~200 files like this one: a single category for the topic of the map, to have them all easily assembled **//
      • if that inserted category does not yet exist: create it with "[[Category:Our World in Data maps by topic]]" //** in many cases, better names might be found, but that cleanup can be handled afterwards manually where needed **//
    • remove all occurences of "{{Map showing old data|year=YYYY}}", ""[[Category:YYYY maps of Asia]]" and "[[Category:Our World in Data maps of Asia]]"
  • (else leave the file alone)
• repeat the same with "Africa", "Europe", ["North America" or "NorthAmerica" would need to be mapped onto "North America"], "Oceania", and so on.

I do not know how exactly to program a bot, but I think this would do the trick, not only to create and populate the categories for continent-by-year, but also to have distinct categories for each topic. Right now, I don't think the latter exist yet. --Enyavar (talk) 19:51, 8 March 2026 (UTC)

For the 1940s alone, removing that template means manually editing 17'500 files: I haven't been following all of this, but why manually? - Jmabel ! talk 20:53, 8 March 2026 (UTC)

True, the bot run would also touch those files. I just wanted to emphasize that so many files cannot be realistically processed manually, and then formulated how I think this could be automated. I struck the word in my earlier response. --Enyavar (talk) 22:21, 8 March 2026 (UTC)

February 24

Educational use rationales for controversial content (a note from WMF Legal)

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.

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 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, 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.

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, challenging bad laws, removing CSAM, 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, 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, and clear documentation of how those criteria applied to potentially disputed content.

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

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

• @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)
• 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)

  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)

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)

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)

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)

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

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 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. 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.

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

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)

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

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)

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)

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)

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)

• @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)

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)

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)

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)

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)

• @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)

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)

I would certainly welcome this request for comment to be divided into multiple more specific questions. Bluerasberry (talk) 17:10, 4 March 2026 (UTC)

VRT is unsure if accounts can be verified

Moved from COM:AN#Template:Verified account: To allow for broader discussion as the scope of the discussion widened. - Alexis Jazz ^{ping plz} 18:04, 24 February 2026 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

• en:Wikipedia:Identity verification <-- I drafted documentation and put comments on the talk page of this proposed English Wikipedia guideline. Briefly, VRT has a history of purporting to do identity verification. In my opinion, the system brings benefits and has successes, and also it has a low rate of causing problems, but also it is not robust. Bluerasberry (talk) 17:14, 4 March 2026 (UTC)

March 01

"Photographs by" categories

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)

I thought the "hidden" criterium is more for user categories (photographs by Wikimedians who upload their images by themselves), and "topical" cats for photographers that are non-Wikimedians? --PantheraLeo1359531 😺 (talk) 10:00, 1 March 2026 (UTC)

That's how I understood the split to be as well. Most "Photographs by photographer" categories are hidden because they're userspace categories. There are a few notable photographers who are also Wikimedians, who can have photographs both in main- and userspace. For the photographers mentioned by Jmabel (and others this would apply to) it doesn't seem fitting to have these categories be hidden. ReneeWrites (talk) 15:28, 1 March 2026 (UTC)

Same, although there have been a couple incidents where Commons users demanded to be unhidden, and I don't recall there being consensus that it was absolutely required. User categories can get pretty expansive, though, since many of us have hidden category systems we use to organize our own stuff (doesn't make much sense to unhide "Quality images of birds by Rhododendrites" or "Photographs taken by Rhododendrites - Poland"). There's another use case that's often hidden: files from [some particular flickr account]. But in general, yeah I think photographers other than Wikimedians should be unhidden by default. — Rhododendrites ^talk |  16:08, 1 March 2026 (UTC)

Imo category-hiding is slightly overused. Usually it's useful to be able to go to images made by the same person – these often have certain similarities such as subjects the reader/visitor may be interested in. For Commons contributors, people can go to the user-page. For photographers, a category is useful. If I'm not mistaken, hidden categories are not displayed to people who are not logged in and have enabled the display of hidden cats. So it would be best to unhide most if not all of these categories. Categories where there's just very few files in them probably aren't useful. Categories about who made a photo are not topical as they are not about the topic of the image but they're nevertheless useful and not just for maintenance purposes or useful only at the category pages instead of also at the file pages that most people would not benefit from seeing. Prototyperspective (talk) 12:02, 1 March 2026 (UTC)

Btw, it may also be a good idea to link to the category page in the Author field of the information template which currently links to the Wikipedia article. One could add sth via template like (see more photos of this creator/photographer). Then there would be less need for the category to be unhidden but even that would not mean the cat is better hidden. Prototyperspective (talk) 12:07, 1 March 2026 (UTC)

Typically, the Wikipedia article links (at least by the normal interwiki links via Wikidata) to the main Commons category for the person, and the "Photographs by" category is a subcat. Exactly as for any other creator and their works, if their works (or representations of their works) are on Commons. Not sure why photographers would be different from, say, painters, for this. - Jmabel ! talk 06:37, 2 March 2026 (UTC)

Not sure how this is meant to relate to my comment – if one was looking for further photos a direct link to the page with more photos of the photographer that's easily visible to all in the Information template would be useful and the same applies also to painters. Even if that was widely done I think it would be better to unhide these categories. Prototyperspective (talk) 11:12, 2 March 2026 (UTC)

It sounds like we aren't certain exactly where to draw the line, but that the people I'm asking about are certainly on the "should not be hidden" side of the line. I will unhide these and similar ones I come across. - Jmabel ! talk 06:37, 2 March 2026 (UTC)

March 02

Creating new public domain license for New Jersey

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)

 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)

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

The relevant laws are [1] and [2]. 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)

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)

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)

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

Μιλάς ελληνικά? Do you speak Greek?

Please add at least one more category to 1,855 files in the Category:Images with file name and description in Greek language

Today, 2,700 poorly categorized files have been added to the Category:Images with file name and description in Greek language. All of these need at least one more category, please. Can you help, to categorize them, please, or even use them in an article? Do you have any recommendations, how to achieve this more effectively? NearEMPTiness (talk) 12:26, 2 March 2026 (UTC)

What's the criteria for a new license template?

So there's one user on a site, and on their profile they say all of their uploads are released under a CC BY 4.0 license. There's no license laundering apparent and it appears to be their own work. This user has uploaded thousands of images. Would that warrant creating a separate template and license review category for it? HurricaneZeta^C 15:02, 2 March 2026 (UTC)

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

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

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

Why Wikipedia Can't Explain Math

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)

Not specifically a Commons topic but as a person with degrees in both Math (including graduate-level work in topology) and Computer Science, almost every time I tried to edit a math-related article on Wikipedia to make it more comprehensible to lay readers, I was reverted on the basis of insufficient rigor. (I had not removed any existing, rigorous, content, just added paraphrases in lay terms.) Of course I stopped trying. - Jmabel ! talk 19:58, 2 March 2026 (UTC)

Questionable flags

There are quite a lot of purported flags from history on Commons, where their actual historical status is unsourced or otherwise uncertain. Most of the time these have been uploaded in good faith and they're not "fictitious", but they often reflect misconceptions that have gained popularity online. I wasn't sure which template to use, have started a thread at Template talk:Fictitious flag#Disputed flags but I was thinking perhaps to start something more specific like a flag version pf {{Lacking insignia source}}.--Pharos (talk) 19:33, 2 March 2026 (UTC)

March 03

Google Books

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)

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

Script

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); })();

$999$REAL 💬 ⬆ 14:37, 23 February 2026 (UTC)

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)

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 $999$REAL 💬 ⬆ 02:49, 24 February 2026 (UTC)

This should not be an issue in the cases to which I refer (such as [3], [4]), 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)

A new Mapillary importer: Curator

Hi!

I would like to introduce Curator. It is a tool that allows the import of image sequences from Mapillary. The tool was rolled out and tested and has reached a stable state. Before you try it out, check out COM:Curator and remember issues like Freedom of Panorama. Mapillary covers many areas, which have a Wikipedia article, but no image in it. Or Mapillary maybe shows areas and structures that don't exist anymore. Happy testing! --PantheraLeo1359531 😺 (talk) 13:31, 3 March 2026 (UTC)

Photo challenge January 2026 results

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

Brutalist architecture: Entries • Votes • Scores

Rank	1	2	3
image
Title	Architectural detail on The National Theatre in London.	beautiful brutalism in Metz	Everson Museum of Art, Syracuse, New York, 1969, currently digitized
Author	Julian Herzog	KaiBorgeest	Foeniz
Score	29	12	12

Peace: Entries • Votes • Scores

Rank	1	2	3
image
Title	Signpost in Christiania (Copenhagen).	Artistic peace symbol at Toronto Distillery District	Menhire für den Frieden
Author	Gzzz	Muzzudan	Fischer1961
Score	10	9	9

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

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

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

Congrats. The Brutalist architecture has a large number of very high-quality files – the entries/scores gallery is very much worth a visit. I found most files in the Peace challenge didn't have much to do with the subject – it seems difficult to capture this subject in photos. Prototyperspective (talk) 23:40, 3 March 2026 (UTC)

March 04

Rotate Orthophotos / Aerial Photographs Facing South?

While trying to georeference a bunch of aerial photographs from Staatsarchiv Sigmaringen Findbuch Wü 160 T 5, I've found that some (but not all) of those photos are facing south (in german: "gesüdet"; example for photo facing south), not north as usual ("genordet"). Aerial images facing south are hard to work with, since nowadays all modern maps (and modern Orthophotos) are facing north. Currently, there's no category for aerial photographs / orthophotos with such a cardinal direction, as it's the case for maps. Is it OK to rotate the images currently facing south by 180° or should they keep their current orientation? What's your opinion? --Fl.schmitt (talk) 10:12, 4 March 2026 (UTC)

@Fl.schmitt: I think we can rotate this images. There now loss of information after the rotation. Thanks for your work with this orthophotos and for the georeferene. --sk (talk) 11:50, 4 March 2026 (UTC)

If you wish to make rotations, they should be as derivative images.

Also, the example image is not "facing south"; it is facing straight down. It is (presumably) orientated with south at the top". We would talk about images facing in a compass direction when they are oblique (like, for example File:Raf 58 2445 psfo 0117.png). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:40, 4 March 2026 (UTC)

Probably best to make the rotation into a derivative image with an explanatory note about the rotation because if you rotate the image you gave as an example, the numbers at the top of the image will come up upside-down and people might attempt to fix that by rotating the image back. Nakonana (talk) 17:47, 4 March 2026 (UTC)

@Nakonana and @Pigsonthewing: ok, derivative images are another option. Regarding the numbers on the pics: There are different ways that those numbers were applied - some have the same numbers multiple times, e.g. this pic. So, an explanatory note would be in fact useful - good idea! Fl.schmitt (talk) 18:15, 4 March 2026 (UTC)

March 05

People voices audios

Where can I find all of them? Is there any common category? I've found only Category:Voice project but it contains not only audios. — Preceding unsigned comment added by Infovarius (talk • contribs) 12:26, 5 March 2026 (UTC)

@Infovarius: If your start point the Category:Voice project then you can use the search with this searchtext: deepcategory:"Voice project" filetype:Audio. --sk (talk) 13:38, 5 March 2026 (UTC)

Category:Audio files of human voices if I understood you correctly. --Prototyperspective (talk) 14:28, 5 March 2026 (UTC)

You may also be interested in Com:Voice intro project. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 5 March 2026 (UTC)

Change links on main page

on the main page right under the title there're 4 links to Images Videos Sounds 3D Models, which link to the root categories of each of those types.

however, i think the root cats are not very helpful, especially for occasional users of this website who may not understand how to navigate the site, because those pages have long lists of subcats and sometimes files that are waiting to be moved to subcats. they look too technical and dont present some high quality files.

i tried to look around for a random or regularly updated gallery of files, but couldnt seem to find one. so here's an idea. what if a bot regularly (weekly?) generates galleries, and the main page links to those instead? another idea is these links https://commons.wikimedia.org/w/index.php?search=date&title=Special%3AMediaSearch&type=image&assessment=any-assessment https://commons.wikimedia.org/w/index.php?search=video&title=Special%3AMediaSearch&type=video&assessment=any-assessment , but these search results might be quite static, stale and boring over time.

something like https://www.gettyimages.com/editorial-images https://www.loc.gov/free-to-use/ https://www.flickr.com/explore/ is more interesting for main page visitors. (Commons:Picture of the day and Commons:Media of the day are close but still contain too much text and technical details.)

Category_talk:Videos#c-Gloweave-20221027093200-Adult_videos prompted this thought. RoyZuo (talk) 15:04, 5 March 2026 (UTC)

 Oppose your proposed links aren't better and secondly these links can be added to those linked category pages. There's some useful links on these pages already. Prototyperspective (talk) 15:20, 5 March 2026 (UTC)

I feel like Commons:Featured pictures is the most similar to the links to other sites you were mentioning. Bawolff (talk) 03:40, 9 March 2026 (UTC)

I had a go with making my own version of that type of page - Commons:Explore. The galleries are random, and should change once an hour (or whenever someone does ?action=purge) Bawolff (talk) 10:21, 9 March 2026 (UTC)

Interesting and I'd suggest to links from that page to the category pages but I wonder why one would want to browse through a totally random good-quality images – I think just a small fraction of visitors is sometimes interested in that.

Things that could be better include having such autogenerated galleries linked well-visibly at the top of categories (maybe even partly embedded via a new panel where one can click [see more] to go to the full gallery page) and/or having images for all the subcategories in the gallery where one can then browse to the subcategory by clicking on the file's description/link.

That's basically what the gadget Help:FastCCI is about which dynamically loads featured pictures, quality images, etc for whatever category one is in. However, most visitors probably have not noticed the button and never used it; and the bigger problem is that like 90% of the time it doesn't work because the tool is down and still nobody has fixed whatever is causing it to go down at the time (see its talk page). Prototyperspective (talk) 12:30, 9 March 2026 (UTC)

March 06

Help needed to close 6,323 Category for Discussion cases

There is a large and growing backlog of open CfDs. It would be great…

• if more people would participate in these discussions to move them toward closability and
• if more admins or CfD/backlog-experienced users would to go through CfDs to close closable discussions (if there is a way to filter these for discussions with 3+ participants, that would be useful)

CfDs over time – this chart was made possible by generative AI and uses data of scraped from Wayback Machine archives of Category:Categories for discussion via a new tool

The oldest open discussions are from 2015. If you have any ideas how to increase participation or more easily solve more CfDs, please comment. For example, maybe there is a way to see CfDs for subjects one is interested/knowledgable in or users could identify users relevant to CfDs and ping them from there to get these to participate (e.g. top authors of the linked Wikipedia articles identified via XTools).

CfDs shouldn't be closed for the sake of it prematurely though – the reason for why they have been started should really be solved before they're closed – sometimes this requires some restructuring, renaming or categorization work. For info about CfDs, see Commons:Categories for discussion. Prototyperspective (talk) 13:55, 6 March 2026 (UTC)

A backlog like this is a disgrace. Will nobody think of the poor nominators? Laurel Lodged (talk) 14:10, 6 March 2026 (UTC)

Perhaps we can categorize CfDs like we categorize DRs, so people who are only interested in a specific subject can browse CfDs relating to that subject more easily. Thanks. Tvpuppy (talk) 15:19, 6 March 2026 (UTC)

I agree that categorizing CfDs could be useful, both for users to find them to comment, and for admins to find them to close. (That's especially true where the discussion hinges on specific knowledge bases, or is conducted in non-English languages.) I don't love the idea of canvassing users, even by neutral/automated criteria, unless it's strictly opt-in.

Like many other tasks, the CfD backlog is mostly due to a shortage of admin time. (Experienced non-admin users can also close discussions, and I think it's a great place to learn admin for those considering the mop, but obviously they are not able to delete categories when needed.) There's also a notable lack of tools to efficiently work with CfDs, which means that the workload for a given CfD is substantially higher than a DR. I can close DRs or process speedies on my phone in a few spare minutes on the bus, but closing CfDs requires my laptop and a longer block of time.

• Tool to close CfDs - it should be one click to add {{Cfdh}}, {{Cfdf}}, etc, just like it is with DRs.
• Tool to rename all categories in a category tree, and move associated files
• Tool to add/remove CfD notices on all categories in a given category tree
• There are some other less common but time-consuming CfD closure tasks that would benefit from tools. For example, sometimes we decide to merge two category trees with identical structures but different names, or to upmerge a large swath of categories. Having to work through these can make a single CfD close take hours.

Some of these may exist in some form on enwiki or other wikis, which could reduce the work required from "write from scratch" to "localize to Commons". Given the importance of the CfD process and the limited capacity of volunteer developers, I really think these should be developed and maintained by the WMF. Pi.1415926535 (talk) 20:31, 6 March 2026 (UTC)

some are just missions impossible unless the right person interested and capable in that task can be found.

for example Commons:Categories for discussion/2025/01/Category:Gothic jewellery seems pretty straight forward. we just need 2 categories, 1 for gothic as a style and 1 for the things related to goths the ethnic group, but it contains many files and subcategories. to distinguish and separate them takes a lot of time for people without that specific knowledge. RoyZuo (talk) 15:31, 7 March 2026 (UTC)

also the problem plaguing many cat names will vanish when cats can be like wd items which can take on multilingual labels, descriptions and aliases.

we dont need to settle on a single title.

technical solutions and infrastructure upgrade are much needed for commons. RoyZuo (talk) 15:40, 7 March 2026 (UTC)

Flickr upload with Upload Wizard

Is uploading free licensed files from Flickr via Upload Wizard currently down? I've repeatedly tried uploading files by long time good Flickr users with 2 different browsers on 2 different machines and can't get anything to upload. (Uploading files directly from my machine works fine.) Wondering, -- Infrogmation of New Orleans (talk) 19:18, 6 March 2026 (UTC)

Yes, discussed in Help desk and Technical VP. Reported in phab:T419263. --Geohakkeri (talk) 19:25, 6 March 2026 (UTC)

Thank you. -- Infrogmation of New Orleans (talk) 19:41, 6 March 2026 (UTC)

seems to work again and this is a technical issue where it would be best to centralize further discussion at the thread in Village_pump/Technical. Prototyperspective (talk) 12:32, 9 March 2026 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:32, 9 March 2026 (UTC)

March 07

Why is overwrite controlled by abusefilter

1. Commons:Village_pump/Proposals/Archive/2023/08#c-GPSLeo-20230813073100-Limit_file_overwriting_to_users_with_autopatrol_rights decided to limit overwrite.
2. overwrite is specifically "reupload" a permission set by the software Special:ListGroupRights.

why is it not done by removing "reupload" from autoconfirmed users and adding it to autopatrolled users? RoyZuo (talk) 15:49, 7 March 2026 (UTC)

This would currently not allow any exceptions without granting user rights, not even for own uploads. GPSLeo (talk) 16:23, 7 March 2026 (UTC)

2023-01_ai_image_of_man_01.png

File:2023-01 ai image of man 01.png - AI-generated image of ordinary man, likely isn't useful, but I am not sure about policy. Evelino Ucelo (talk) 16:31, 7 March 2026 (UTC)

Not specifically against policy, but not terribly useful either. Created Commons:Deletion requests/Files in Category:AI-generated images by Ziko van Dijk. Omphalographer (talk) 19:07, 7 March 2026 (UTC)

this is not how to file a deletion request Prototyperspective (talk) 12:33, 9 March 2026 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:33, 9 March 2026 (UTC)

March 08

Smooth rocks/Boulders

Besides the artic fox, the boulders are very interesting. I dont know what processes shapes these rocks. Is there any category for this? 'Round boulders' dont seem to accuratly describes these rocks. Smiley.toerist (talk) 22:18, 8 March 2026 (UTC)

Commons:Expert identification or categorization requests may be a or could become a better place to ask questions about categories for individual images (what the fitting category would be and if it exists).

I asked an LLM attaching the image and it returned The round boulders or rocks you're referring to are commonly known as ball boulders or spherical boulders. In geology, these are often referred to as concretions. They typically form through the process of sedimentation and mineral precipitation, resulting in rounded shapes over time.[…]. but I could not find a category named with either of these two terms so maybe it doesn't exist yet. I then searched for spherical boulders beach to find a similar image to check its categories and it found the one on the right with Category:Moeraki Boulders set but that cat has no broader cat about this in specific set. One could also create e.g. Category:Spherical rocks on beaches. Prototyperspective (talk) 12:41, 9 March 2026 (UTC)

https://www.instagram.com/p/DNf8wyyuLUY/ this may answer your question. RoyZuo (talk) 13:52, 9 March 2026 (UTC)

March 09

Adding support to JPEG XL and HEIC files

Hi there everyone, I would like to know if there are plans by Wikimedia and Wikimedia Commons to add support to the new JPEG XL and HEIC type of files. Been experimenting with them in the last days and they seem really great, allowing to shrink the file size by very much. ----LucaLindholm (talk) 11:01, 9 March 2026 (UTC)

For JXL, see phab:T270855. The task is flagged as “stalled”. --Geohakkeri (talk) 11:09, 9 March 2026 (UTC)

@Geohakkeri Thanks, just saw it and people suggest to start discussion just here in the Village Pump on Commons to begin exploring whatever or not there is consensus on these new files. :D -- LucaLindholm (talk) 11:27, 9 March 2026 (UTC)

If the reason for its stalled status is lack of consensus to support these filetypes on Commons, I'd suggest making a thread proposing this at Commons:Village pump/Proposals where the benefits of adopting these filetypes and their characteristics are sufficiently explained. I did not read the full issue but it seems like there also are some technical challenges. Prototyperspective (talk) 12:45, 9 March 2026 (UTC)