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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Congratulations to Donvikro, Mensch01, Lusi Lindwurm, Ger Hagens, Pierre André Leclercq and Gannu03 Jarekt (talk) 16:42, 6 February 2026 (UTC)Reply

@Jarekt Thank you for the encouraging scores. Sincerely Pierre André ^(talk) 16:50, 6 February 2026 (UTC)Reply

Congrats! I like these results. (I just wished there would have been more photos of modern active industrial factories in the Factor interiors challenge.)

Could a template with a category or just a category be added to the Photo challenge winner photos? I think the info that the file won (place 1-3 at least) a photo challenge would be interesting to the visitor on the file information page. Additionally, I'd like to add it to Category:Community-based media evaluation and the top x files could maybe at some point be upranked somewhat in search results are to being more likely relevant and of good quality. Prototyperspective (talk) 19:20, 7 February 2026 (UTC)Reply

There is already {{Photo challenge winner}} and Category:Photo challenge winners. Thanks. Tvpuppy (talk) 20:33, 7 February 2026 (UTC)Reply

Thanks. This hasn't been added to the winning pictures here and neither to those of the prior challenge posted about further up this page. Is it just missing for these or was it not added for files of earlier challenges too? I check some files of the latest challenges in the archives and the template was not set on this, this and this. Maybe there is a way to query for all PC-winner files without the template somehow. Prototyperspective (talk) 21:10, 7 February 2026 (UTC)Reply

It seems like it would need a way to see files used on Commons on pages like "Commons:Photo challenge/[some changing text here]/Winners" or "Commons_talk:Photo_challenge/Archives/year". Other than that, there doesn't seem to be anything consistent for these files and I couldn't find a way to query for pages linking to even just a particular Commons page under File usage on Commons. Is there a way to do this with petscan? I tried entering "Commons_talk:Photo_challenge/Archives/2025" into Templates&links linked from (linked to also didn't work). Prototyperspective (talk) 18:45, 8 February 2026 (UTC)Reply

Prototyperspective, I agree, we should be adding winning images to Category:Photo challenge winners. I will work on it and see if we can do that automatically in the future. Thanks for suggestion. --Jarekt (talk) 00:39, 9 February 2026 (UTC)Reply

Thanks for categorizing the files into there!

What do people think about creating a second category for files voted far up but not in the top 3 (3 is an arbitrary number), probably place 4-10 or 4-15 or 4-20? Is it feasible to categorize the files into a new category for such, e.g. Category:Photo challenge runner-up (places 4–15)? (probably using the scores pages like this) These are not called winners, for why this would be useful, please read on.

I think we probably better use all the community quality assessments that we can get on Commons because this would raise the chance that for any given search on Commons there's at least a few files that we could slightly uprank so as to increase the quality of files in the top search results and there aren't so many indicators available.
When searching for "herd" for example, it would be best if the search results showed on the first (first few) pages high-quality results (with herd in title or description or category etc) based on quality indicators like number of uses in Wikipedia, whether it's a featured pictured, and whether it's a photo challenge winner.
However, for many searches – especially for more niche or specific things – there probably aren't any or many files that have any of these indicators.
So I think a category for files from the challenges that are more likely to be of good quality but not necessarily very high-quality or 'winning' – as defined by reaching spot 1-3 – could still be useful. For these second-class category files either only another template would be added or not template at all but just the category. It's not just about the search results though, one may want to browse these files or work on them to make sure they're well categorized, this gets me to the next point which is also another way this categorization can be practically useful:

• This query on Quarry (thanks to Bawolff again) shows the photo challenge winner files sorted by number of set categories. Even when just considering the top 3 winning files of each photo challenge (currently 887 files overall), many files only have a single nonhidden category set. For some files that's probably fine but for maybe circa ⅔ there are categories missing like a topical category for what's actually shown. I've created a report page at Commons:Photo challenge/Undercategorized files table 1 for the files containing just 1 or 2 nonhidden categories (this is the case for 376 files). If anybody would like to, you could use this report to help add categories to undercategorized winning files. As suggested above, if a new category for runner-up files is created, an additional report could be created where I suspect some good-quality files don't have any topical set at all.

Prototyperspective (talk) 18:37, 11 February 2026 (UTC)Reply

@Jarekt: Do you think adding a category to e.g. files places 4-15 is feasible to you? Having them in a category can e.g. be used to categorize these files better via the mentioned reports. Prototyperspective (talk) 14:24, 13 February 2026 (UTC)Reply

@Prototyperspective: I would have to write custom python code for that to read and parse /result pages. It is feasible but a lot of work. I do have a code to parse /Winner files, but it would be useless. If we want to do that we should create new template based on Template:Photo challenge winner for runner-ups. Also I am not sure what we would call it. English term "runner ups" is usually used for 2nd and 3rd place and we do not have a term for others other than "participants". It might be easier to categorize all participants, but not all are good. Jarekt (talk) 16:08, 13 February 2026 (UTC)Reply

Thanks for clarifying. Finding the name shouldn't be the difficult part and one could change the category's name later; maybe Category:Photo challenge files (places 4–15)?. I asked an LLM 'there is a challenge with places 1-3 but how to call files that reach place 4-15? (of 100 files only few get there)' and suggested terms include Honorable Mentions, Notable Entries, Spotlight Files but I guess one would keep it more neutral and short by not choosing any such term and just have it in the title that those are places x to y. Prototyperspective (talk) 16:17, 13 February 2026 (UTC)Reply

More properly pluralized as "runners-up". And it can refer to something pretty far down the scale. I've heard phrases like "9th runner-up."

It would be nice if the category sorted in order, insofar as there is an order. If nothing beyond the first 3 are specifically ranked, the sort key could still be 1, 2, 3, 4, 4, 4, etc. and the 4s would sort alphabetically. - Jmabel ! talk 19:33, 13 February 2026 (UTC)Reply

It sounds like a gallery is a better solution for this than a category. ReneeWrites (talk) 13:31, 18 February 2026 (UTC)Reply

One can create the gallery from the category as done with Commons:Photo challenge/Undercategorized files table 1 and a gallery can't be used for searching, filtering, and sorting and also does not add the info to the file. I wonder what the use of a gallery of hundreds of these files would be.

Ideally, there would be both: and if a category exists, a gallery can be easily created. Regardless of how it's created, having subheaders for the topics – eg the title of the photo challenge – would make it much more useful. A gallery containing all of the files however would load only slowly and (unused) galleries of the photo challenge files (one per challenge) already exist. Prototyperspective (talk) 13:41, 18 February 2026 (UTC)Reply

I mean a gallery of the top 10 images. Also you can add text to galleries. ReneeWrites (talk) 13:50, 18 February 2026 (UTC)Reply

(Basically I'd make the same comment as earlier.) The existing galleries do show the files sorted – it's a the wikilink "Scores" in the post. Prototyperspective (talk) 13:53, 18 February 2026 (UTC)Reply

I misunderstood the initial proposal, but I understand now what you're going for and what the goal is with this category. As for what to call it, I like "runners-up" as well. The name isn't as explicit about its inclusion criteria as "places 4–15", though I'm unsure if that's ever going to be a problem. ReneeWrites (talk) 15:06, 18 February 2026 (UTC)Reply

The description at the top of Category:Photo challenge pictures and several of its subcategories note that these categories are no longer being used, though I can't find a discussion where this was decided. I think it would be a good idea to "un-retire" these categories. I quite like the way content is categorized under Category:Photo challenge/2014 and I think we could apply this structure to the other years as well. ReneeWrites (talk) 10:54, 10 February 2026 (UTC)Reply

The discussion was made here: Commons talk:Photo challenge/Archives/2014#Proposal re challenge categories. It appears until August 2014, users are require to add their images to both the challenge page and category. Back then, there was a problem where users only added them to one location, so in the discussion they decided to stop using the categories.

So, I don't think there are any problems with these categories themselves, hence I agree it is a good idea to reuse these categories again. Thanks. Tvpuppy (talk) 11:24, 10 February 2026 (UTC)Reply

I get the message outlined below when trying to update a page even when I am logged in. Being logged in should override the IP address block and allow the update.

You do not have the permissions needed to carry out this action. Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis.

The block was made by ‪JJMC89‬. The reason given is Open proxy/Webhost: See the help page if you are affected.

Start of block: 00:51, 3 July 2024 Expiry of block: 00:51, 3 July 2027 Your current IP address is 52.94.133.131. The blocked range is 52.94.128.0/20.

Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the Stewards Block Wizard.

My-wiki-photos (talk) 21:05, 15 February 2026 (UTC)Reply

@My-wiki-photos: Hi. That is a global block of an Open proxy/Webhost. Please read m:WikiProject on open proxies/Help:blocked.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:39, 15 February 2026 (UTC)Reply

I know. However, if you are logged in, the fact that you are no longer an anonymous user should override the block. By logging in you are assuming all the consequences of your actions. If a user does something wrong, such a user can be blocked. My-wiki-photos (talk) 22:54, 15 February 2026 (UTC)Reply

It appears you need IPBE (IP Block Exempt) right.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:59, 15 February 2026 (UTC)Reply

No, I don’t really need it personally. I was just thinking it would make more sense for the IP address block to be overridden when a user is logged in and their credentials are known. My-wiki-photos (talk) 04:49, 16 February 2026 (UTC)Reply

It is intentional that IP blocks apply to logged-in users by default. This prevents certain types of abuse. Omphalographer (talk) 05:30, 16 February 2026 (UTC)Reply

No, the default is that they only apply to anon users. They only apply to logged in users and account registration if multiple abuse accounts used the IP. GPSLeo (talk) 06:33, 16 February 2026 (UTC)Reply

Registering an account doesn't make you not anonymous, it just gives you a username. Open proxy users are anonymous by default and due to their ease of abuse blocked from editing, as they should be. You can ask for an IP block exemption as Jeff recommended, or disable your VPN. ReneeWrites (talk) 08:25, 16 February 2026 (UTC)Reply

Maybe people with roles demonstrating that the community has trust in them (e.g. file mover, patroller, rollbacker, template editor) should be IP exempt? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:34, 16 February 2026 (UTC)Reply

This would not be useful as one would need a whole lot of editing before that occurs and request extra permissions and just quite few users have any such. 'demonstrating that the community has trust in them' would better be done via something like account age + fraction & count of unreverted edits. Prototyperspective (talk) 18:50, 16 February 2026 (UTC)Reply

Well, if you reason like that, any IP address is anonymous. Internet Service Providers won't reveal their clients' information due to privacy reasons. My-wiki-photos (talk) 18:42, 16 February 2026 (UTC)Reply

No, that specific argument only addressed your point on why registering doesn't make someone not anonymous anymore. It is also besides the point, as the issue is not about anonymity inherently. Jeff G. linked the Meta-Wiki page about open proxies, have you read it? What is the reasoning stated on that page for why open proxies are blocked? ReneeWrites (talk) 23:03, 16 February 2026 (UTC)Reply

@ReneeWrites Yes, I have read the explanation provided for open proxies. That does not change my opinion. As I have already stated, if a user is logged in using their account, there is no valid reason to block an edit simply because they are connected through an open proxy. Any abuse on their part can be addressed through their account. Furthermore, please prevent the registration of new accounts through open or residential proxies. My-wiki-photos (talk) 08:07, 19 February 2026 (UTC)Reply

@My-wiki-photos: Are you using a VPN? If so, which one?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 08:33, 16 February 2026 (UTC)Reply

@Jeff G. I don’t use a VPN at home. As I mentioned earlier, I don’t really need an IP block exemption. I simply wanted to perform a quick update from my workplace, which uses an open proxy. After logging in, I discovered the update had been blocked, which was quite inconvenient at the time. It occurred to me then that many others likely face this same issue. As I’ve said before, if a logged-in user abuses their account, they can be blocked before causing further damage. Therefore, it doesn't seem reasonable to me that open proxies are blocked by default. My-wiki-photos (talk) 18:56, 16 February 2026 (UTC)Reply

I support allowing the use of VPNs for registered editors without requiring any extra "IP Block Exempt" permissions or similar. Maybe only users of a certain age and/or minimum count/fraction of unreverted edits. This would better protect privacy and safety. Prototyperspective (talk) 11:44, 16 February 2026 (UTC)Reply

yeah it's becoming a bit ridiculous. half the internet is on an open proxy and we will have fewer and fewer people NOT in that situation. We need to find different ways. Maybe with like dynamic blocking and unblocking of ranges whenever there is abuse or something. This overblocking is costing us editors. I hear people wanting to try editing complain about it all the time. We mostly don't hear that, because we don't see those people, which is convenient... I guess. —TheDJ (talk • contribs) 12:59, 16 February 2026 (UTC)Reply

Mass uploaders who fail to categorize or have appropriate filenames seems to be a perennial problem, and end up creating a ton of work for other users. I just stumbled upon a user who uploaded 125 uncategorized photos from Flickr2Commons in the span of 7 minutes, and I am giving up for the night and just dumping all the photos into a further-categorization-needed category.

Would it be possible to rate limit mass uploading from Flickr for non-autopatrolled users to something reasonable (say, maybe 10 to 30 uploads per 24-hour period) to combat this? There's probably some reasonable number which holds back badly-done mass uploading without preventing users from properly contributing useful content. From my personal observation complaints over poorly-curated mass uploading stems pretty much entirely from Flickr transfers; there seems to be little to no issue with people directly uploading their own media, so rate limiting Flickr2Commons seems reasonable. If an uploader has proven themselves to be trustworthy and want to say, transfer more than 30 files a day from Flickr they can go for the autopatrolled right.

Thoughts? 4300streetcar (talk) 13:36, 16 February 2026 (UTC)Reply

Presumably this user: KMB1933 (talk · contributions · Move log · block log · uploads · Abuse filter log) block user

I don't think rate-limiting is a fix here. A slower problem is still a problem. I'd be interested to hear @KMB1933: 's side of this. Andy Dingley (talk) 14:16, 16 February 2026 (UTC)Reply

I personally think a slower problem is better than a faster problem; a slower problem gives editors more time to catch up on new uploads (e.g. I don’t have the time to categorize 125 photos every night, but I can do 10), gives more time for problematic mass uploaders to be identified and dealt with, and reduces the mess that problematic mass uploaders generate. 4300streetcar (talk) 16:21, 16 February 2026 (UTC)Reply

Also want to add that another potential benefit of rate limiting is to slow uploaders down to the rate where they can actually be expected to properly curate their photos. 125 photos in 7 minutes (about 18 files per minute, or 3 seconds per file) is way faster than anyone can reasonably curate their files. Rate-limiting doesn't have to be per-day; it could be per-hour (e.g. 30 files per hour would mean 2 minutes per file, which is a reasonable rate for someone to properly curate their files). If you rate limit to even 30 files per hour, people aren't transferring files faster than what's possible to curate, and it might encourage them to actually curate their files while waiting for the rate limit to expire. 4300streetcar (talk) 04:02, 17 February 2026 (UTC)Reply

These are both sound arguments imo. There isn't anything we can do to fully solve the issue of people uploading poorly curated images (or images that are out of scope, or violate copyright etc.) to Commons, but fixing it partially is still a solution worth pursuing. In other words, in this particular case a slow problem is indeed preferable to a fast problem. ReneeWrites (talk) 13:34, 18 February 2026 (UTC)Reply

I think mass imports by humans should be treated as bots requests (i.e. thins should be right) and requester should be hold accountable for initial filtering, proper naming, describing,categorization, adding Structured data. EugeneZelenko (talk) 16:15, 16 February 2026 (UTC)Reply

I'm fully in support of autopatrolled and/or bot request being required for mass uploads (and being yanked for misuse). The vast majority of mass uploads have substantial issues with file content (copyvios, scope, duplicates, etc) and/or curation (lacking useful filenames, descriptions, and/or categories), and the uploaders simply do not care about fixing that. Pi.1415926535 (talk) 20:38, 16 February 2026 (UTC)Reply

If we make this a right, I wouldn't want to just tie it to auto-patrolled; there would need to be a way to petition for it separately. It would prevent at least one completely valid workflow it would prevent, and it's one I've used for some batches of photos: (1) upload all of your content to Flickr; (2) selectively or otherwise (depending on the nature of the content), transfer it to Commons via Flickr2Commons or a similar tool.

Since there is no sane way to transfer in the other direction, anyone without a super-fast connection who wants to upload their own content to both sites has to do something along these lines. - Jmabel ! talk 21:03, 16 February 2026 (UTC)Reply

How often are you transferring more than say, 30 of your own files per day though? Properly curating 30 uploads (categorization, descriptions, geotagging, etc.) is probably 1-3 hours of work. I'm also proposing only rate-limiting Flickr2Commons and not UploadWizard. 4300streetcar (talk) 03:50, 17 February 2026 (UTC)Reply

@4300streetcar: Almost any time I'm using this workflow for my own photos, I'm tremendously exceeding 30 files in a day. I've already written on Flickr the same descriptions that are needed on Commons. I don't generally do geotagging (my camera doesn't geotag, so any that I do is manual estimates; if I'm doing it at all, I've already done it explicitly on Flickr and it is a minor reformatting edit after uploading to Commons). Categorization is a bit of an issue, but often not much, certainly not 1-3 hours for 30 photos. When I'm doing this, it usually includes multiple photos of the same subject(s), so I bring them over in appropriate batches that can be tagged at once, on upload. - Jmabel ! talk 03:21, 18 February 2026 (UTC)Reply

For the relatively small number of users who have both the number of files and the trustworthiness to do this, and who aren't already autopatrolled, it seems like it would be not difficult for us to make exceptions (or grant autopatrolled) upon request. Pi.1415926535 (talk) 22:43, 18 February 2026 (UTC)Reply

I'd be on board with some form of this. I've seen way too many situations where a user saw a couple of good topical photos on Flickr and eagerly imported the user's entire feed - leaving Commons with a bunch of uncategorized vacation selfies, DW / FOP copyvios, and unusable vintage-filtered "art" photos. Anything that encourages users (especially less experienced users) to think twice before importing large batches of photos will help. Omphalographer (talk) 22:02, 17 February 2026 (UTC)Reply

Hello. I am wondering if there is something like a geographic search for pictures. I am thinking of a map on which the Wikimedia photos are located as icones so that you can select them with a click of the mouse, for example. I'm sure I'm not the first person to look for something like this but couldn't find a related discussion yet. --Alfrejg (talk) 07:18, 17 February 2026 (UTC)Reply

You could try Wikishootme. It might take a while for the site to load, but if the uploader has taken the trouble to add the geographic oordinates correctly, it should do the job. Kind regards, MartinD (talk) 07:56, 17 February 2026 (UTC)Reply

Hi MartinD. That's just what I needed, thanks a lot. Alfrejg (talk) 17:36, 18 February 2026 (UTC)Reply

There is a map in Commons app that shows files but I haven't used it sufficiently to tell whether it can be used for this.

There also is https://wikimap.toolforge.org/ but I think it has the same problem as the map for Wikipedia articles in the Wikipedia Android app that I described at phab:T360213 (An option to show all article-dots directly on the Nearby places map (instead of having to tap on clusters)). One has to zoom in super close to be able to click on individual files.

Additionally, I think it only shows files with geocoordinates which are probably less than 3% of photos. Regarding this, see Template talk:Geogroup#Also include files geolocated to countries/places via subcategories but not coordinates (1 reply so far, stale, maybe not the best place to ask).

In practice, it's best to use categories to search/see files by location. You can browse the category branch such as Category:cityname via its subcategories or (at the most relevant category) use the deepcategory search operator to browse the files in a wall-of-images where you can just scroll through the files– for this put deepcategory:category name into the search bar. Prototyperspective (talk) 13:14, 17 February 2026 (UTC)Reply

As other answers say, Wikishootme is the place to go for geolocated images and categories for all of them. However, other more sofisticated tools exist like Commons:SPARQL query service and even PetScan with some combination of categories and queries. Pere prlpz (talk) 15:30, 17 February 2026 (UTC)Reply

I'm wondering whether a new help page about geographic maps should be created that lists the tools, has info on how to use them, and mainly makes them discoverable to users on Commons or on Web search engines. "Wikishootme" is not a descriptive self-explanatory name that users interested in this are likely to find and go to. It also doesn't load some map by default – one first has to enter a specific place.

In its options in the top right, one can disable the display of Wikidata items with no image and of Commons images with geocoordinates. Most useful I think is the display of Wikidata items when they have a Commons category where one can then the Commons category link in the popup when clicking on the item (bottom left). May be best if all of this was included in OpenStreetMaps maps, and possibly it is – I think the app OsmAnd does it (I don't use it because one has to download maps in advance rather than just browse around with things loading ondemand as with Google Maps etc). The main issue with wikishootme is that it's not part of an app and many (me included) would use this feature only or mostly while on the go (especially if it was integrated in map apps that one already uses anyway). One also can't see which items have Commons categories and the symbols are all just dots without eg symbols in them making it easier to see which kind of items they are. Here I requested/proposed that items that have a Commons category are colored differently: m:Talk:WikiShootMe#Media in existing Commons categories. Which things are useful and which tool is right depends how one is using that; eg if for search then some very specific search or search in the sense of 'all media around this area'? I'd probably use it more for discovery such as for checking which routes would be interesting.

I've created this category where one can find more or less all the relevant pages, categories, and files about this subject so far so far: c:Category:Wikimedia projects and maps. Prototyperspective (talk) 11:04, 18 February 2026 (UTC)Reply

Coloring the dots according to whether they have a Commons category or the kind of item they are (that is, instance of (P31)) isn't hard to do with Commons:SPARQL query service. The problem is that it's less user-friendly than Wikishootme and you might need a custom query for your needs or your area.

And I don't urderstand "It also doesn't load some map by default – one first has to enter a specific place" about Wikishootme. Wikishootme opens by default at your location but you can zoom and scroll the map to wherever you want - not different from Google Maps and most app aplications. Pere prlpz (talk) 11:21, 18 February 2026 (UTC)Reply

One could add queries like this to the envisioned page then assuming it doesn't already exist.

When opening up Wikishootme, it does not load some map – it's just large whitespace and one has to figure out what it is and that one has to first enter a place in the search in the top left to make it load a/the map. I don't give any websites permission to my location and if I did it would be an inaccurate one. That's on desktop where many and maybe most people first find this site, not on mobile indeed. Btw, integrating this map into the Commons app would be great. Prototyperspective (talk) 12:36, 18 February 2026 (UTC)Reply

Well, that can be solved by allowing permissions to location but it's a personal choice.

Anyway, it would be good that Wikishootme assumed a default location in case the actual one is not available. Pere prlpz (talk) 12:46, 18 February 2026 (UTC)Reply

https://wikishootme.toolforge.org/#zoom=10&q=Q220

i always open it this way. with zoom and wd item values of your choice, open it once then the browser remembers.

the author should really solve this problem, but i dont wanna set up a bitbucket account so i leave most problems of his tools to others. RoyZuo (talk) 15:37, 18 February 2026 (UTC)Reply

nearcoord is pretty nice too. see mw:Help:CirrusSearch#Geo_Search. RoyZuo (talk) 17:38, 17 February 2026 (UTC)Reply

I use WikiShootMe for all geotagged photos of an arbitrary area. More often I add {{Geogroup}} to a category that I'll often be looking into. Jim.henderson (talk) 03:59, 18 February 2026 (UTC)Reply

It makes little sense that we allow (in SVG uploads) as an XML namespace the URI for Dublin Core 1.1 (http://purl.org/dc/elements/1.1/) but not DC Terms (http://purl.org/dc/terms/). Desaccointier (talk) 04:38, 18 February 2026 (UTC)Reply

While we’re at it I would also advocate allowing all the common RDF namespaces as defined in the canonical RDFa Core Initial Context. At the very least we should also permit Schema.org, seeing as how prevalent it is online. Desaccointier (talk) 04:40, 18 February 2026 (UTC)Reply

@Desaccointier File a request in Phabricator. The current list of accepted namespaces is here btw: https://github.com/wikimedia/mediawiki/blob/HEAD/includes/Upload/UploadVerification.php#L543 —TheDJ (talk • contribs) 14:40, 18 February 2026 (UTC)Reply

.see Phab:T283316.

.see also User:Glrx#MediaWiki_whitelisted_namespaces.

Glrx (talk) 22:47, 19 February 2026 (UTC)Reply

Hi, is it possible to find images with only red categories. - When I work for Commons:WikiProject Minimum One Category and add a misspelled category to one uncategorized image then the Template:uncategorized was delete from this image and the image had only one red misspelled category. - Is there a way too find other images with only red categories? --sk (talk) 19:19, 18 February 2026 (UTC)Reply

Maybe one can adjust the query used for the report Commons:Report UncategorizedCategories with redcats to show files instead of categories. This query which does show files and has an output one could add to a report page with thumbnails could be used to build it I think. Prototyperspective (talk) 19:48, 18 February 2026 (UTC)Reply

Hi, Please see Template talk:Artwork#Dimensions. Thanks, Yann (talk) 20:12, 18 February 2026 (UTC)Reply

Hi all,

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

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

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

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

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

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

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

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

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

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

in english, if Commons:File captions are not full sentences and start with words that arent proper nouns, should the first letter be capitalised?

or should it be like wikidata item labels and descriptions that do not want the 1st word capitalised?

or it doesnt matter?

e.g. for File:Apple splitting 01.ogv, if any of these is preferred?

1. splitting an apple by hand
2. Splitting an apple by hand

RoyZuo (talk) 16:29, 19 February 2026 (UTC)Reply

I, personally, prefer capitalisation and no dot at the end. --NearEMPTiness (talk) 17:30, 19 February 2026 (UTC)Reply

Same here. Sometimes caption can be two sentences where there are dots but these are rare. Prototyperspective (talk) 18:10, 19 February 2026 (UTC)Reply

I also think every good caption should be a full sentence and therefore first letter should be capitalized. GPSLeo (talk) 20:19, 20 February 2026 (UTC)Reply

I'm not objecting to the capitalization, but I think plenty of good captions are not full sentences: "Stephens Block, Binghamton, NY, 2025"; "Main entrance to Pike Place Market, 2004"; "Exterior of Marienkirche, Berlin-Mitte, 2017".

•  Support Prefer capitalisation, dots aren't mandatory Юрий Д.К. 20:39, 19 February 2026 (UTC)Reply

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

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

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

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

This is a new category about an important subject with potentially many files.

• It's currently missing many or most files – maybe other users could help with it
• What about videos like the one on the right that apply fully to microbiological functioning of the human body but also to other animals (eg should they be included or go to a new parent cat that has only such or merely be anywhere in the large Category:Videos of biology…

Many files about the human body are currently not in the Category:Human physiology/Category:Human body branch. Note that this is not for videos anyhow showing people; it's videos about the human body which includes videos showing the body in some sophisticated and educational way that makes it a video sufficiently about and not just of the body. Such videos include for example explanatory MRI videos I think, videos explaining lactose intolerance, the anatomical composition of the human eye, these, cold sensation variability in humans, human thermoregulation, etc. Prototyperspective (talk) 14:09, 20 February 2026 (UTC)Reply

We could theoretically have a category for videos about humans under Category:Homo sapiens and on up the tree, but that only makes sense if we have a page or more to fill each such category. One could easily extrapolate that to photos.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:22, 20 February 2026 (UTC)Reply

That's a different subject though – that would be a parent category (or further superordinate cat). Don't understand what you mean with "each such category". Prototyperspective (talk) 16:24, 20 February 2026 (UTC)Reply

@Prototyperspective: Going up the topical tree of nonhidden categories, I mean starting with Category:Videos of Homo sapiens, and then starting by building out with Category:Videos of Species of Simiiformes, Category:Videos of Species of Hominidae, Category:Videos of Homo by species, Category:Videos of Pleistocene life, Category:Videos of Holocene life, Category:Videos of Cosmopolitan vertebrates, Category:Videos of Omnivores, Category:Videos of People, etc. I built this using the parents of Category:Homo sapiens in the topical tree (not hidden). Extrapolation could start with Category:Photos of Homo sapiens.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:18, 20 February 2026 (UTC)Reply

Well that's another subject and I don't think creating categories for photos makes sense. Moreover, it's not so much Videos of the human body here than about the human body. Prototyperspective (talk) 20:08, 20 February 2026 (UTC)Reply

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

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

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

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

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

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

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

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

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

Another question I think the community should consider.

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

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

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

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

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

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

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

Recently, the English Wikipedia community came to a consensus that archive.today should be immediately deprecated. See Wikipedia:Requests_for_comment/Archive.is_RFC_5.

For Wikimedia Commons, the problem is that there is now evidence that the contents of some archived pages have been tampered with. This is a problem because Commons contributors have been using archive.today in order to document the existence of free licenses for files uploaded to Commons. For example, people have used archive.today to prove that a YouTube video is licensed under CC BY 3.0. This way, even if the CC BY 3.0 were to be removed in the future, the video can still be hosted on Commons.

Is there a guidance page like the one on English Wikipedia (Wikipedia:Archive.today guidance) that would tell users what to do with existing archive.today links on Commons? If not, I think there should be. In addition, if there is not one currently available, should we also have a page recommending users reliable alternatives, such as the Wayback Machine, Ghostarchive, Megalodon, and perma.cc?

In the case where archive.today is the only available archival link, could one solution be to use Wayback Machine to archive a page on archive.today, and then use the link to the "second-hand" archive?

FunnyMath (talk) 03:12, 21 February 2026 (UTC)Reply

Hmm… the template {{From YouTube}} might need to be changed to reflect this. HyperAnd [talk] 06:11, 21 February 2026 (UTC)Reply

Yes, that is a big one. We should remove the link to archive.today ASAP. FunnyMath (talk) 06:31, 21 February 2026 (UTC)Reply

@Gyrovagueblog: Notifying you, in case you would like to add something. FunnyMath (talk) 06:29, 21 February 2026 (UTC)Reply

 Comment, I have read about the situation, and obviously it is very concerning to learn that the site was apparently used to perform DDoS attack against another website, and archived content was altered.

As mentioned above, the site is often used as an additional archive source to Commons:Internet Archive, such as in {{From YouTube}} and {{Ebay item}}. For me, this site is useful as a backup when license reviewing as some deprecated source pages don't have a proper archive at the Internet Archive.

So, I just want to say blocking or deprecating archive.today here in Commons may have an impact on license reviewing work. However, I think in this situation, the risks of allowing links to archive.today may outweigh its benefits. Thanks. Tvpuppy (talk) 11:25, 21 February 2026 (UTC)Reply

I think allowing and keeping the links outweigh the benefits – many sites or only archived there and just removing the links often means the source is not accessible anymore. Prototyperspective (talk) 12:15, 21 February 2026 (UTC)Reply

@Prototyperspective: allowing and keeping the links outweigh the benefits. I can't make out what you are saying here. Is there a missing antecedent phrase, e.g. "[The risks of]"? But even then, your next sentence seems to say the opposite of where that would seem to lead, so I can't make sense of this. - Jmabel ! talk 20:13, 21 February 2026 (UTC)Reply

I think allowing and keeping the links to archive today outweigh the benefits of prohibiting it. Prototyperspective (talk) 22:15, 21 February 2026 (UTC)Reply

I used to use archive.today/ph to save eBay listings. Some of the listings that are still live, I will re-save them using Web Archive, but some are gone now. I don’t want to outright remove the links for those yet, as many images will lose their source. What should I do about it? PascalHD (talk) 15:20, 21 February 2026 (UTC)Reply

There are two things that should not be confused:

• The ability to verify that a licence is correct.
• Leaving links to a site that is not secure, exposing readers to having their computers hacked.

The first is pointless, as no one will try to sue Commons if the files were originally published under a free licence (I know some will disagree), but the second is irresponsible, as we cannot expose readers to hackers.

On frwiki, my bot is currently disabling the links and replacing them with a link to a help page explaining the problem with archive.today [1].

The URLs are nevertheless left in the page code so that they can be reused once a permanent solution has been found, but they are no longer functional and cannot be used without being aware of the problem. Şÿℵדαχ₮ɘɼɾ๏ʁ 17:03, 21 February 2026 (UTC)

AFAIK an archive of a YouTube video doesn't actually store the video file itself -- it's just a snapshot of the video page as it existed at the time. If that's all we're trying to replace, why couldn't we just take a screenshot to verify the same thing? Or print to pdf from the browser or something else that doesn't require site archiving? — Rhododendrites ^talk |  23:21, 21 February 2026 (UTC)Reply

I think that's a good idea. It will be even better if Commons or WMF can develop a tool to support this archiving method. Thanks. Tvpuppy (talk) 23:55, 21 February 2026 (UTC)Reply

When it comes to license review of (YouTube) videos, please see this idea: Commons talk:Video2commons#Removing the need for manual human review for future uploads with v2c.

Snapshots or screenshots could also be nice but consider that the most useful thing there is the video description which often has license-related info and it would need to fully visible in the screenshot. Additionally it should show the video thumbnail so the video content can be verified to some extent. I guess it's something that would be added to User:InternetArchiveBot…I don't know how it finds links and which it decides to archive. And Internet Archive do store the video file itself – I don't know if it's done only sometimes or always but I've watched deleted YT videos on there. Prototyperspective (talk) 00:25, 22 February 2026 (UTC)Reply

I didn't know what happened to archive.today because I used it to make snapshots of everything since the early 2020s. However, I have to save everything as MHTML (even though there are limitations) or as an image. - THV | ♂ | U | T - 01:28, 22 February 2026 (UTC)Reply

Currently, quite a few videos from the main(?) Wikimania evens such as the one that took place in Nairobi, Kenya in 2025 are

• only accessible on YouTube but not Commons
• only accessible in huge per day videos with undescriptive titles and even without chapters (many talks in one video with no info which talks are included)

Any plans to get these onto Commons? I've asked about it at the talk pages of two videos I found interesting (wikimania:2025:Program/Building a Sustainable Future for Wikimedia Contributors and wikimania:2025:Program/Wiki Loves Broadcast: Creative Commons Video Edit-a-thon). Is there maybe some plans to get these onto Commons or some list of all the missing videos? For the latest WM it seems to be items on wikimania:2025:Program where there is no video but "lecture" or "workshop" in the caption. Maybe somebody is interested in getting the remaining ones onto Commons.

• That they're not on Commons makes it difficult to share it within the community, makes it impossible to put these videos into the Commons categories about the subject, and makes it impossible to embed them anywhere such as related metawiki pages
• It also makes it difficult to watch one talk at a time. Wanted to watch some of the talks on a train but it's a pain to refind the videos (also related to them not being in the Commons categories and that the Commons app where one can bookmark categories like Category:Wikimania 2025 videos can't play videos).

Prototyperspective (talk) 14:06, 21 February 2026 (UTC)Reply

This also relates to wish W506: Discovery feed in Wikipedia app similar to social media apps (incl article segments, vids, …) (voting open). Especially to the point at the bottom. I would find it neat if there was some feed that showed or ideally included Wikimania lecture videos with a brief summary / pitch – if one is interested by that description, one would click open/play and watch (until scrolling further to see other videos/content if it turned out to be not interesting). Prototyperspective (talk) 14:15, 21 February 2026 (UTC)Reply

I've restored Tower St. Chrischona.jpg original version (some time after noticing author(s) at talk there). Please review this action, as it might be "controversial" because the newer upload version of the image has already been used in some proposals/votes. Maybe restoring original version under different name would really be better solution in this case. --Mykhal (talk) 13:22, 22 February 2026 (UTC)Reply

i think dewp sysop should upload the highest resolution version here. it seems the "861×2679×8 (291729 bytes)" version, aka the "original" you said, is a crop. RoyZuo (talk) 10:00, 24 February 2026 (UTC)Reply

What is to be sone with Category:Internet Archive (uncrop needed), which says:

JPEG files placed in this category will be automatically "uncropped" by Faebot (checked at least once a day)

given that Fae and his bot are no longer active here? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:51, 22 February 2026 (UTC)Reply

I think the category is useful and should remain active, so anyone who wants to can manually uncrop files. If another bot is found in the future to replace Fae, even better. --Micione (talk) 00:08, 23 February 2026 (UTC)Reply

On English Wikipedia there recently was a post where users discussed the subject of 250 Category for Discussion still being open and what could be done about it.

On Commons here, there are over 6,200 open categories for discussion – see Category:Categories for discussion.

There is relatively little participation in these. Thanks to all users who participate in these discussions whether it's giving input or closing discussions.

I think it would help the community to cut down on this large backlog by having separate lists or categories for the following types of CfDs:

1. CfDs with no comments – these would greatly benefit from other users giving constructive input; users could browse these and comment when they do have sth to say about any
2. CfDs with comments from two or more users – many of these may be closable, at least the old ones if they can also be sorted by date of creation; admins may browse these and close the ones that are reasonably closable

How could such lists (or categories?) be created? Maybe this could be done via the search by using search operators like insource: or via some Quarry query.

If this gets done, maybe users here are interested in helping out to cut down on this backlog. Note that for many CfDs, some work such as restructuring, renaming, splitting, cleanups, or similar are needed. One could probably close more if one created a category like Closed categories for discussion that need work to be done. A tool to rename many categories at once or change many categories at once (e.g. to add a template) would be very useful for many of these.

The oldest open CfDs are from 2015.

Any further ideas on how the backlog could be cut down? Prototyperspective (talk) 15:25, 22 February 2026 (UTC)Reply

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

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

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

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

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

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

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

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

The titles I suggest above are up for debate. Is it more practical to use "Our World in Data maps" or can it be shortened to "OWiD maps" ? Also, should it be "showing" (as per our category branch "maps showing <year>") or should it just be "of" (again, a majority of these maps are re-projections that assume in this case that countries existing in 2026 were in 1400 already out and measuring national economies in 2011 dollar values based on a 1990 ratio scale - this map does not actually show anything that resembles Europe in 1400). --Enyavar (talk) 03:58, 25 February 2026 (UTC)Reply

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

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

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

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

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

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

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

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

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

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

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

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

Hello

  seems to behave strangely: all the thumbnails since 2020 aren't served because we are supposedly rate-limited (429 HTTP code). But this doesn't happen for any other file.

Does anyone know why? And how to solve it? Best, Wikisquack (talk) 22:11, 23 February 2026 (UTC)Reply

See also Commons:Village pump/Technical/Archive/2025/11#Image thumbnail problem (I had asked if one could fix this problem across the project, not just one or so individual file at a time). Seems to be the same problem as e.g. File:United Kingdom general election 1831.svg listed there. Prototyperspective (talk) 22:47, 23 February 2026 (UTC)Reply

Dear Community, I would like to open a discussion regarding the recent decline of a rename request for a file documenting a historic milestone: the Artemis II mission. The request was declined by an administrator with the comment: "rename request declined: does not comply with renaming guidelines. That is not a way files are named." (File:Pobrany Poziomo Bilet mojego Gemini w formacie PDF.pdf) A contributor has consistently used a logical, modular naming system for archival contributions since 2009: User, Event Subject, Participant, Date.pdf (comma-separated modules). This is not a random string of characters. It is a system designed to: Identify the Contributor (User:Alians PL). Categorize the Event (Artemis II). Specify the Participant (Human or AI Assistant). Provide the exact Archival Date. The Artemis II mission is a unique event. The inclusion of symbolic binary code (which the contributor is willing to shorten or move to the description) was intended to reflect the "digital presence" of AI in 2026. However, the modular structure itself (User, Event, Participant, Date) is the contributor's established signature since 2009. If "local VIPs" or automated scripts are allowed to enforce rigid, non-modular names, the author's intent and a valid, structured way of archiving history are lost. A contributor's consistent method, especially one used for 17 years, should be respected over generic naming rules that fail to account for complex, occasional documentation. The community is asked: Should a logical, modular archival system (User, Event, Participant, Date) be protected as a valid naming standard for major historical events? (If it's not post-Soviet, then it's definitely not?).
Update regarding the administrative "correction": I would like to highlight the irony and inconsistency of the current enforcement. While my modular, logical request was declined for "not complying with guidelines," the administrative action resulted in a filename that is arguably more chaotic and less functional. The file was moved from my structured proposal to: File:Commemorative NASA Artemis II ticket for Bronislaw Jacek Wesolowski (Alians PL). Binary code- NASA ARTEMIS II.pdf This "official" name contains spaces, parentheses, and extreme length—exactly the issues typically avoided in clean database management. It proves that the refusal of my modular system (User, Event, Participant, Date) was not based on technical necessity, but on a rigid dismissal of an author’s 17-year-old established style. If the community prefers long, descriptive prose over a clean, comma-separated modular archival system, it significantly hinders the efficiency of categorizing major historical events like Artemis II. I advocate for more "positive energy" and respect for the author's systematic intent over such arbitrary administrative "creativity."
Applies to file names:

1. /wiki/File:Commemorative_NASA_Artemis_II_ticket_for_Bronislaw_Jacek_Wesolowski_(Alians_PL)._Binary_code-_NASA_ARTEMIS_II.pdf
2. /wiki/File:Pobrany_Poziomo_Bilet_mojego_Gemini_w_formacie_PDF.pdf

Regards, Alians PL Alians PL (talk) 10:52, 24 February 2026 (UTC)Reply

@Alians PL: the file history shows that you screwed up while typing the name: Special:Diff/1170609996/1170617441. It was correct to decline a renaming towards a string of 0 and 1; a name like you described above wouldn't have been refused. And: could you please explain on how your AI generated image is in scope? It gives a look and feel of unusable personal art. Regards, Grand-Duc (talk) 11:47, 24 February 2026 (UTC)Reply

@Re: Challenging a rename decline – Response to Grand-Duc

@Grand-Duc: Thank you for your comment, but I must respectfully disagree with your reasoning for several technical and substantive reasons:

1. System vs. Chaos (Technical consistency)

You declined my modular request (User, Event, Participant, Date), citing "renaming guidelines," yet the resulting administrative "correction" produced:

File:Commemorative NASA Artemis II ticket for Bronislaw Jacek Wesolowski (Alians PL). Binary code- NASA ARTEMIS II.pdf

This filename is excessively long, contains spaces and parentheses, and is objectively more chaotic for database management than my proposed comma-separated modular system. My system, used consistently since 2009, was designed for archival efficiency, not "personal art."

2. The role of AI in 2026 History (Project Scope)

A question was raised about whether an AI-generated image is "in scope." The Artemis II mission is a milestone for humanity and the digital era. The "Participant" module in the naming system (Human or AI Assistant) documents the interaction between human explorers and AI systems in 2026. The names, PINs, and digital signatures generated by these AI entities for this event are historical metadata. Rejecting this disregards the reality of recording historical events in the mid-2020s.

3. 17 Years of Established Practice

An author's consistent method, maintained for 17 years, should carry weight against a rigid, subjective interpretation of "guidelines." The modular system: [User: Alians PL, Event: Artemis II, Participant: AI Assistant, Date: 2026-02-24] provides more searchable, structured data than the descriptive prose imposed. The author's approach to naming is rooted in systemic standards. The author's first version of the Linux system was at the turn of the year 1997/1998. The author used the book "LINUX same konkrety" by Bob Rankin published by MIKOM, which was published in Poland in 1997.

Conclusion

A reconsideration of the naming standard for this file is requested. The goal is to preserve a logical, modular archival system that respects the author's long-term method and the unique digital nature of the Artemis II documentation.

I quote. The correct names of all three PDF files are based on the following rule:

For the participant signed with binary code: (User: Alians PL, Event: Artemis II, Participant: AI Assistant, Date: 2026-02-24) The correct filename for the AI Assistant is: Alians_PL,Artemis_II,AI Assistant,2026-02-24.

For the participant Gemini_Pro-2026-Lublin: (User: Alians PL, Event: Artemis II, Participant: Gemini_Pro-2026-Lublin, Date: 2026-02-01) The correct filename for the participant Gemini_Pro-2026-Lublin should be: Alians_PL,Artemis_II,Gemini_Pro-2026-Lublin,2026-02-01.

On the other hand, I can give up my personal participation in such an event in the documentation within the Wikimedia Commons resources as a so-called "man from Poland"; however, since I have been participating in this project for 19 years, the correct name for my commemorative participation in this historic flight around the Moon as a participant of the Wikimedia Commons project is: (User: Alians PL, Event: Artemis II, Participant: BronislawJacekWesolowski, Date: 2026-02-01) Which means the file of my commemorative digital participation should have the following name: Alians_PL,Artemis_II,BronislawJacekWesolowski,2026-02-01.

Alians PL Alians PL (talk) 16:51, 24 February 2026 (UTC)Reply

 Comment @Alians PL: there is no way in the world I am going to slog through this wall of barely formatted text. I imagine a fair number of others would feel the same way. If you want useful responses, please try to express this succinctly. - Jmabel ! talk 04:46, 25 February 2026 (UTC)Reply

Dear Commons friends,

–

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

–

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

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

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

a. Privacy laws

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

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

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

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

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

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

b. Online safety laws

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

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

Evolution of best practice:

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

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

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

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

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

Phil

[1] Article 2(6) of the EU Digital Single Market Directive on Copyright

[2] See, e.g. Graham Greenleaf, Global Data Privacy Laws 2023: 162 National Laws and 20 Bills https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4426146

[3] https://wikimediafoundation.org/who-we-are/transparency/

[4] https://medium.com/wikimedia-policy/what-happened-in-the-c%C3%A9sar-do-pa%C3%A7o-lawsuit-f91b7fb5e54b

[5] https://medium.com/wikimedia-policy

[6] https://medium.com/wikimedia-policy/wikipedias-nonprofit-host-brings-legal-challenge-to-new-online-safety-act-osa-regulations-0f9153102f29

[7] https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_Combating_Online_Child_Exploitation_Policy/en#Child_sexual_abuse_material_(%22CSAM%22)

[8] https://foundation.wikimedia.org/wiki/Resolution:Media_about_living_people

[9] https://foundation.wikimedia.org/wiki/Resolution:Controversial_content

[10] https://en.wikipedia.org/wiki/Wikipedia:Non-free_content_criteria

[11] https://en.wikipedia.org/wiki/Wikipedia:Non-free_use_rationale_guideline

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

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

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

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

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

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

Hi all

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

Thanks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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