History maps of Europe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Stefan Kühn: , I have not responded before since I am not sure how this constitutes a similar problem, or what action you expect other users to take on behalf of your project. My own case is less about the exact nationality of specific locations; and more about hatnote definitions of these categories in general.

As nobody has yet voiced any opinion on the subject matter, I'm resolved to wait a bit longer. --Enyavar (talk) 11:29, 2 June 2026 (UTC)

Maps from Our World in Data

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks Reinhard, regarding #1 yes that is idea.

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

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

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

I have now created:

Templates

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

Example use

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

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

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

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

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

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

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

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

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

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

Thanks for the feedback!

• I fixed "the world" (ooh, it feels good to write this ;-))
• It is generally true that the template works best when the categories are created top down (i.e. first the centuries, then the decades, then the years). Still the navigation ribbons should appear even if the parent category does not exist (yet), I will have to investigate why they don't. But for the addition of the correct parent categories for new categories, it is important anyway that the parents pre-exist.

FWIW, this is now also fixed. --Reinhard Müller (talk) 19:51, 9 March 2026 (UTC)

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

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

I have created:

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

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

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

Looks great; thanks very much. I just don't know how complete these cats currently are and will be. They could be made complete via deepcategory category intersections and moving files with cat-a-lot. Prototyperspective (talk) 18:22, 9 March 2026 (UTC)

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

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

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

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

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

I added the above request to Commons:Bots. --Enyavar (talk) 16:03, 12 March 2026 (UTC)

Commons:RemoveGPS

We are wanting to turn this into a gadget that can be activated / inactivated via preferences. From what I understand we would need an interface admin to add it here MediaWiki:Gadgets-definition. Other work required? Pinging User:Yaron Koren who built it for us. Doc James (talk · contribs · email) 15:49, 10 July 2026 (UTC)

Sounds like a great idea. I've seen people accidentally sharing their home address a few times when uploading a photo of a book. - Alexis Jazz ^{ping plz} 16:49, 10 July 2026 (UTC)

As the creator of the script, I definitely support this - and I'm happy to do whatever additional work is necessary to turn this into a gadget. Yaron Koren (talk) 19:13, 10 July 2026 (UTC)

Yaron Koren, idea/feature request: what if users could set one or more locations (stored in user preferences with userjs- prefix, not publicly) and a radius, and automatically remove GPS from metadata when it's within the radius of those location(s)? (such a thing might need to be implemented into UploadWizard/apps/etc, though your script could maybe handle Special:Upload?) - Alexis Jazz ^{ping plz} 20:55, 10 July 2026 (UTC)

Very cool gadget. Thanks for making it! Nakonana (talk) 10:01, 11 July 2026 (UTC)

Support in principle. I do have some suggestions however:

- Add translations for at least the main interface elements

- use encodeURIComponent when you do things like: "https://exif-gps-removal.toolforge.org/?file=" + removeGPS.pageName

- set Api-User-Agent header on ajax requests, so that it's traceable which tool is making the requests

- you are NOT allowed to retrieve and send the user's email address to toolforge like that. There was no explicit user approval of reading their email address and forwarding it, nor was it retrieved via an OAuth2 claim. See https://wikitech.wikimedia.org/wiki/Wikitech:Cloud_Services_Terms_of_use#7.2_If_this_is_a_Toolforge_Project

- also, not everyone has an emailaddress configured, this situation doesn't seem to be handled right now ?

- use mw.Api instead of $.ajax so that you get automated token fetching, renewal and error message handling etc.

- this doesn't ensure that ooui is loaded. declare your dependencies —TheDJ (talk • contribs) 08:49, 15 July 2026 (UTC)

@Doc James and Yaron Koren: forgot to ping. —TheDJ (talk • contribs) 09:11, 15 July 2026 (UTC)

Thanks, Yaron will work on these improvements for us. Doc James (talk · contribs · email) 13:12, 15 July 2026 (UTC)

@TheDJ - thank you for these helpful comments. Most of these look quite reasonable - but the one about the email address, I'm not sure how to deal with. You can see what's done with the email address here, if the email address exists (and yes, the possibility of no address is indeed handled). The email address, if it's set, is used as the "Reply-To" address in the email sent to Commons administrators/oversighters, if one is sent, so that they can easily communicate with the user if they have any questions/comments. It's not necessary, but I think it's nice to have. So I see two possibilities: get rid of the email address handling, or add a note like "This will result in your email address getting sent to the Commons administrators" somewhere in the interface. (I suppose a third possibility is simply keeping things as they are now, if this specific use turns out not to count as a privacy violation.) Any thoughts? Yaron Koren (talk) 06:45, 17 July 2026 (UTC)

Maybe have a consent popup were we say we are using their email to contact commons oversight, tell them what email we are using, give them the opportunity to add / change the email. Or decline to use an email. And than a button to remember their choice for next time, Doc James (talk · contribs · email) 13:06, 17 July 2026 (UTC)

Just send a Wikimail to User:Oversight Commons. GPSLeo (talk) 13:31, 17 July 2026 (UTC)

You can use Special:EmailUser/Oversight Commons indeed, but that doesn't allow you to specify a body. But you can also use API:Emailuser. Just make sure to inform the user that their emailadress will be shared with the recipient of the message. —TheDJ (talk • contribs) 15:34, 17 July 2026 (UTC)

@TheDJ - alright, I just modified RemoveGPS.js to incorporate (I think) all of your feedback. Please let me know what you think! Yaron Koren (talk) 19:05, 17 July 2026 (UTC)

@Yaron Koren I made some further improvements in User:TheDJ/RemoveGPS.js. I've not dealt with further improvements to the email flow yet, and honestly error handling should probably be improved a bit. —TheDJ (talk • contribs) 13:24, 20 July 2026 (UTC)

@TheDJ - thank you very much! I just copied over your code, with some slight changes - and also added you as an author. I agree that error handling could be better - right now a lot errors only show up in the console, if even there. Yaron Koren (talk) 05:48, 21 July 2026 (UTC)

Are [my] contributions worthwhile?

Is there a tool where I can check which of my uploads (photos) are getting used the most? Basically, the exam question I am trying to answer is (1) are my contributions useful to anyone, and (2) if so, which ones are, and which ones aren't. I know I can click through them individually to see, but wondering if there's a better solution. Thanks! Galileo01 (talk) 06:02, 12 July 2026 (UTC)

Is this what you are looking for? (The "File usage details" tab more specifically) whym (talk) 06:20, 12 July 2026 (UTC)

Usage on the Wikiprojects is not everything. From time to time I look at my uploads and check, where they are used outside the Wikis and some that are not used here are definitely useful to people in other places. However I don't know of any tools that do bulk processing for this - you will have to do this file by file. Kritzolina (talk) 07:27, 12 July 2026 (UTC)

@Galileo01@Kritzolina try https://www.google.com/search?udm=2&q=(%22Galileo01%22)+AND+(%22Wikimedia%22+OR+%22Commons%22+OR+%22Wikipedia%22+OR+%22CC%22+OR+%22CC0%22+OR+%22CCBY%22+OR+%22CCBYSA%22)+-site%3Awikimedia.org+-site%3Awikipedia.org

i learnt this trick from User:Stephan Sprinz special:diff/747591119. RoyZuo (talk) 14:40, 12 July 2026 (UTC)

i just turned it into Template:File usage search Google.--RoyZuo (talk) 15:11, 12 July 2026 (UTC)

Handy, thanks. Nakonana (talk) 17:27, 12 July 2026 (UTC)

Very cool, I found a few great instances of re-use! --Kritzolina (talk) 18:55, 12 July 2026 (UTC)

Super, thanks. Galileo01 (talk) 06:28, 13 July 2026 (UTC)

Much of the public impact of images uploaded to Commons has little to do with Wikimedia project reuse. Photographs I have uploaded to Commons have been used by journalists and academics in widely published articles, most often with poor or no attribution. Apart from reverse image searching, it's not possible to generically measure that "value" added to public knowledge. --Fæ (talk) 09:32, 12 July 2026 (UTC)

@Fæ @Kritzolina - those are all fair points, and I agree that usage outside of Wikimedia projects is probably the true measure of usefulness.

@Whym - this is exactly what I was looking for. Thank you. I think this is a good proxy of which files are most useful; albeit, as other noticed in the discussion, non-Wikimedia usage is not possible to easily capture. Galileo01 (talk) 10:32, 12 July 2026 (UTC)

How about knowing which of those files are? It only shows the number of files, not the specific files themselves. JWilz12345 (Talk|Contributions) 13:10, 12 July 2026 (UTC)

I found the way. Never mind. The issue that I am facing now, when trying to run the tool with Photographs by User:JWilz12345|Photographs of roads by User:JWilz12345|Photographs of rail transport by User:JWilz12345 on the category field, the "HTTP 500 for https://petscan.wmcloud.org/" error triggers. The category field should support multiple categories, like in my case in which I categorize my images of roads and rail infrastructure in two separate subcategories. JWilz12345 (Talk|Contributions) 13:19, 12 July 2026 (UTC)

you can set how deep you want https://glamtools.toolforge.org/glamorous to count a category.--RoyZuo (talk) 14:57, 12 July 2026 (UTC)

Still throws GLAMorous error message even if I set the depth to 2 or 3 or 5 or 10. JWilz12345 (Talk|Contributions) 17:38, 12 July 2026 (UTC)

Your uploaded files can be very useful even if not used in any Wikimedia wiki or external site. In addition to some of them being possibly used in works not published in the open web, there are also uses that are not reuses. In each file page, you have "View history -> Mediaviews analysis" (for the file itself) and "View history -> Number of watchers -> Page views in the past 30 days" (for the file's description page), to see how many times the file or its page were viewed.

There are a number of ways users can arrive to an unused file: search engines (including, but not limited to, image search), by browsing Commons categories (the starting point could be a "Wikimedia Commons has media related to ..." link from a Wikipedia article), or by looking at a Commons gallery (some of them are really good).

As soon as a user (any person, not only Wikimedia contributors) finds a file and learns something from it, the file is useful. MGeog2022 (talk) 12:45, 14 July 2026 (UTC)

I don’t know of any tool but I wanted to comment. I often wonder the same thing (am I just wasting my time?!?!). But I don’t think there’s a way to truly measure the impact of our contributions. Your uploads are beautiful and varied - even if they’re not necessarily reused, they might be what someone needs otherwise. They will remain online and might be helpful years in the future, after you’ve forgotten they’re even there! I hope this makes sense. In short, your contributions here are important and I hope you’ll keep adding more! :) Stampdragon (talk) 15:01, 20 July 2026 (UTC)

I agree with RoyZuo, I have used Google Image Search to try to find uses of my images outside of Wikimedia. (I also used to try Bing image search, which used to work better but no longer does.) Yes, some sites use pictures without attribution even when the license requires it. At least one prestigous news website even used to display one of my photos with a blatant false attribution. But I also find pages that do give attribution and enough details to find the source image on Commons. – b_jonas 08:10, 25 July 2026 (UTC)

Could we talk about pure blank pieces of paper?

We're just populating Category:MLS real estate blank cards, which collects together blank cards, entirely white blanks apart from being perforated on the left hand side. Some users are reluctant to see these types of blank images deleted as they are part of groups of other stuff, but that seems a weak solution to the issue of whether Commons needs to host every page of documents or books which were scanned as separate images. More usefully these can be compiled as pdfs or djvu documents with only pages with photos and illustrations as correctly in scope separate Commons hosted image files.

Note, in this particular collection of MLS cards there are also "blanks" which have nothing but a filled in footer, identical and duplicating footers on other cards about the same estate that are not blank. In a literal way, we are not classifying these as blanks even if, uninteresting. This indicates that these completely blank pages are printer chuck pages between reports, not indicating anything meaningful. BTW, identifying blanks was a side-effect of finding photos for MLS real estate cards with photos, no extra processing time was needed.

In general Commons does not host files "that contain nothing educational other than raw text" with some exceptions, based on potential usefulness on other projects or obvious 'historical' educational value. These are a lower standard than that, because they don't even have meaningful raw text. For now, we seem to be by passing the policy of OOS/Scope and if these blanks are to become exceptions, we should have a consensus to reword the policy. Fæ (talk) 10:11, 16 July 2026 (UTC)

FWIW, the origin of the "raw text" thing was mainly to say "no, you can't take your article that was rejected from Wikipedia, put it in a PDF, and upload it here." - Jmabel ! talk 17:47, 16 July 2026 (UTC)

Plus not being a host for coding... I guess the way to reduce this question of policy to the basics and the long term mission, is to think of the reasoning in a deletion request based on a scope rationale of no discernible educational value of the individual file. If there is an counter rationale of a blank being a "placeholder" in a multi-page document, then that's why what should be hosted is a multi-page document of clear value, rather than a set of individual images, the weakest of which could be deleted any time in the future. Fæ (talk) 18:43, 16 July 2026 (UTC)

I fully agree. We should not have all these "(page XY)" files. Merging them into one PDF should be more suitable for scanned documents. I do not think that many files would run into problems with the file size limit. GPSLeo (talk) 19:11, 16 July 2026 (UTC)

+1 to that. I also raised that concern previously e.g. here. Documents should in my opinion ideally be uploaded in a document format - that being a single PDF instead of countless individual images. The main problem is that Commons is simply not at all designed to properly deal with this style of media storage - example: let's compare this random item, "1929 Appointment Diary of Mayor William Jackson". If we search for it on the source site, we get it as a single & as first result, that being the entire book consisting of 380 individual scans. If we do the same search on Commons, we get almost 400 results - all the individual pages, in a completely random order, with no useful structure to view the entire work whatsoever. The source ohiomemory.org stores the entire work also as single image files, with the difference that their software ("ContentDM") is actually capable of properly presenting these files. (To be fair, our MediaWiki software is not even at all intended to be used as a mass digital media archive (IIIF whats that), but I digress)
Note that this style of uploading multi-page works as individual images is absolutely nothing limited to DPLA uploads, it has been widely used in a variety of mass uploads (on many tens of millions of files). For example, the first duplicates of this empty file with 1,600 duplicates have been introduced in 2007 by bulk "individual page book" uploads. ~TheImaCow (talk) 20:14, 16 July 2026 (UTC)

Speaking of Category:MLS real estate cards with photos, we're creating more dead-end categorization? None of the ones I spot-checked contained categories related to date taken, location, type of building, style of architecture, etc. RadioKAOS / Talk to me, Billy / Transmissions 22:38, 16 July 2026 (UTC)

Picking out the cards which include photos at all is a first step. The majority of images in the collection are non-photographic, e.g. cards containing a diagram of the lot, textual information about the property, or blank cards as shown above. Omphalographer (talk) 22:57, 16 July 2026 (UTC)

Without saying what should be done, I do note that where we have a document stored as individual pages, there is quite a bit we could do with templates to make that more sanely navigable. - Jmabel ! talk 01:54, 17 July 2026 (UTC)

When the sorting in this case example is done, I might analyse exactly why these blank pages exist. Given the massive automated cover page cropping we've been doing to get rid of Google cover pages from pdfs, and another task to crop out pure white blank pages in the front of some book collections, there's an easy and uncontroversial precedent to compare with for 'terminal' blank pages which is probably what is happening here.

Maybe what we need to have sensible rewording of policy, is these exemplars settled in an uncontroversial way as our 'case book'. Consensus is then based on simple facts and precedent. Fæ (talk) 08:55, 17 July 2026 (UTC)

As highlighted, it's worth forming a view based on the parent category of 185,038 files, rather than the still populating sub category with c.500 files in it. Not sure I understand exactly what 'dead-end categorization' is, we do need source categories so that volunteers and bots can search across the large category as a specific type of 'sample space' or do smart category intersections using standard tools. These are useful in their own right and the intention is not to empty a source category. Fæ (talk) 08:59, 17 July 2026 (UTC)

How big would a composite document be? ShakespeareFan00 (talk) 18:55, 17 July 2026 (UTC)

Too big. There are 185,038 files in the category, with a total size of nearly 293 GB. Omphalographer (talk) 22:40, 17 July 2026 (UTC)

Rather than everything in an impossible document, this particular collection seems to be broken into regions for the agent. In https://digital-collections.columbuslibrary.org/digital/collection/p16802coll36/id/179579 there are 122 cards, several are blanks and a few are photos, so that would be a small 122 page PDF if 'compiled'. If the photos are automatically broken out, there's nothing else of interest apart from text notes and some rough sketches of road layouts. These may be of interest to someone researching the modern development history of the local area, but very, very unlikely to be of general interest on Commons or for transclusion to Wikipedia articles.

My feeling about this example of 185,000 images is that they are just space fillers. If Wikimedia Commons is going to claim an eventual "one trillion free images" it would be rather cruddy if half of that is blanks and fairly useless nonsense that could be held in 1/100th the number of documents. Fæ (talk) 10:15, 23 July 2026 (UTC)

File:DE CDB 1 18 285.jpg has many 1-pixel duplicates --PantheraLeo1359531 😺 (talk) 13:40, 23 July 2026 (UTC)

Amazing. Why were these created? Fæ (talk) 18:49, 23 July 2026 (UTC)

new versions instead of 3 separate pics

Hello,

dealing with

File:München Hbf Blick entlang Querbahnsteig mit Tragkonstuktion und Bauwand.jpg

just now I learnt how to replace a file with (or add to the same collection) a newer / better one.

There are three versions of

• File:München Hbf Umgebungsplan.jpg
• File:München Hbf Umgebungsplan 2.jpg
• File:München Hbf Umgebungsplan 3.jpg

with growing quality that a sort of bot seems to have linked ("other versions"). Is it useful to concat these three files the way of the first - and if yes, how can that be done?

Thanks --Ousw (talk) 17:21, 17 July 2026 (UTC)

Hallo @Ousw

@Derkoenig: hat wohl genau das gemacht, was du haben wolltest, ohne von deiner Frage etwas zu wissen oder ohne das er hierzu antwortete. Wie das geht das siehst du hier. Ist deine Frage beantwortet? זיו「Ziv」 • For love letters and other notes 05:45, 18 July 2026 (UTC)

Hallo zurück, danke für die Antwort, sie passt leider nicht ganz, da die 3 Files oben jeweils einzeln unter ihrer "File history" als "current" gelistet und damit nicht automatisch durch die neue Version ersetzt werden. So gesehen müssen das ja zwei verschiedene Arten von "Verknüpfung" sein. IMHO ist es sinnvoller, wenn die unterschiedlichen Files jeweils in einer Historie erscheinen.

NB: Ich hatte den Verweis in der arabischen Seite, die noch auf

• File:München Hbf Umgebungsplan 2.jpg

verlinkt, IMHO erfolgreich auf "... 3" geändert, aber irgendwie wurde das vermutlich zurückgesetzt (ich kann das auf der arbaischen Seite ja nicht nachkontrollieren, es war kompliziert genug, die "2" durch die "3" zu ersetzen). Ousw (talk) 12:49, 18 July 2026 (UTC)

Warum brauchen wir überhaupt 3 files, keep it simpleOursana (talk) 13:49, 18 July 2026 (UTC)

Sigh. The 1st one was very poor quality, so the 2nd one a little better was uploaded (up to that time I only had poor experience here) and yesterday the 3rd pic with satisfactory quality - and since the 2nd is used by an arabic article, I thought about an appropriate solution.

But the question was if it is possible to connect more than one files _after_ upload to one page with a history and not just linking them via

• other versions={{Other versions|München Hbf Umgebungsplan 2.jpg|München Hbf Umgebungsplan 3.jpg|gallery=yes}}

Ousw (talk) 14:02, 18 July 2026 (UTC)

Ousw If you want the earlier versions preserved (probably a good idea for purposes of anyone who may have used them on a licensed basis) you can re-upload them as "new versions" of File:München Hbf Umgebungsplan 3.jpg (with appropriate upload comments), and revert File:München Hbf Umgebungsplan 3.jpg to its current version; then we can replace the file pages for the earlier two versions with redirects. - Jmabel ! talk 19:26, 18 July 2026 (UTC)

@Jmabel Thanks for your detailed answer, now I know how things work. I hoped that there is an easy way to change the one sort of link to the other (in the best case without invoking others). Since this is not the case, I think it's the best choice to keep things as they are - for one picture it should be o.k. as it is (the oldest pic was replaced by the second within two days and the latter is used by an arabic article). Ousw (talk) 15:42, 20 July 2026 (UTC)

Sorry, but I forgot the real showstopper: One cannot Upload the same file a second time because the Upload Wizard recognizes that and rejects to process. Ousw (talk) 14:43, 21 July 2026 (UTC)

@Ousw: I don't know if there is any override for this on the Upload Wizard, but there is for Special:Upload. (Also, since I'm not sure what exactly you are trying to do, you definitely cannot re-upload exactly the same file over itself, since it has no useful effect.) - Jmabel ! talk 17:44, 21 July 2026 (UTC)

The Last MPEG-4 Visual Patent Has Expired

https://www.phoronix.com/news/Last-MPEG-4-Patent-Expired

I propose that we allow uploading MPEGs directly to Commons now. ―Justin (koavf)❤T☮C☺M☯ 19:52, 19 July 2026 (UTC)

No, we should not. Most "MP4" video files actually use the H.264 codec, which still has active patents associated with it. MPEG4 Visual is a different video codec - it's an older, transitional format which is not generally supported for playback by web browsers. (Some implementations of this format were known as Xvid.) As far as I'm aware, MediaWiki cannot distinguish between the two at upload time - and, in any case, uploading MPEG4 Visual files is not desirable. Omphalographer (talk) 23:20, 19 July 2026 (UTC)

It cannot right now distinguish between them, but I do have a patch in the works that would allow us to make this distinction reasonably well. —TheDJ (talk • contribs) 13:29, 20 July 2026 (UTC)

definitely fantastic news. We definitely should move towards some form of MP4 support. Yes, there are still years to go before popular codecs expire, but mp4 support would be a tremendous boon to Commons. Abzeronow (talk) 05:40, 25 July 2026 (UTC)

Audrey (Peake) Teago

Hi! I’ve come across several illustrations by Audrey (Peake) Teago. She died in 1974, and since her work was published in England, I believe it may still be under UK copyright (life + 70 years).

Before I tag anything individually, could someone confirm whether these uploads should be reviewed or whether there’s an existing guideline for handling this illustrator’s work?

Here’s the search page with the files: https://commons.wikimedia.org/w/index.php?search=Audrey+teago&title=Special%3AMediaSearch&type=image or an individual example, File:Latinka and Her Dog, Fig 1.jpg

Thanks — I just want to make sure I’m approaching this correctly. — Preceding unsigned comment added by Stampdragon (talk • contribs) 15:01, 20 July 2026 (UTC)

@Stampdragon: For any works that had "simultaneous" (within 30 days) publication in the U.S., we can consider US publication to be the "first publication". If any of those are PD-US, we don't have to consider their UK copyright. However, for any of her other works, you are correct. - Jmabel ! talk 18:27, 20 July 2026 (UTC)

Thank you! I’ll look into these and see if that applies. Copyright laws can be so confusing! Thanks again for taking the time to explain! :) Stampdragon (talk) 14:31, 21 July 2026 (UTC)

I made a category for her at category:Audrey Peake Teago and applied the {{NoUploads}} template. Arlo James Barnes 22:37, 21 July 2026 (UTC)

Thanks so much! Stampdragon (talk) 13:10, 24 July 2026 (UTC)

sdc potd motd

Wikipedia:Picture of the day (Q6998859): daily selection at Wikimedia Commons

Project:Picture of the day (Q18371963): Wikimedia project page

Q25652443:

as i was once again looking at possibly existing schemes of recording com:potd com:motd etc. in com:sdc, i saw these 3 items. someone might wanna check if they should be merged. RoyZuo (talk) 13:45, 21 July 2026 (UTC)

For Wikipedia:Picture of the day (Q6998859), how is a selection on Commons "Wikipedia" picture of the day? - Jmabel ! talk 17:46, 21 July 2026 (UTC)

they should all merge to Q6998859, or have labels and aliases changed so they dont get confused with it, coz Q6998859 is what com:mediasearch is using according to https://phabricator.wikimedia.org/T419131#11745838 .--RoyZuo (talk) 11:54, 22 July 2026 (UTC)

OpenGeofiction: Dual-licensed under CC BY-NC-SA and ODBL?

Conflict of interest! I have an OpenGeofiction account, as Lemuria.

Hello, I would like to discuss the copyright status of Wikipedia:File:OpenGeofictionContinentsSeptember2024.png. I have a belief, but am not yet confident, that this file may be licensed under both CC BY-NC-SA 3.0, and ODbL 1.^[1] I am planning to transfer the file to Commons, but need to see if there are any issues I haven't seen and would like extra eyes on this.

I'm noticing conflicting statements on OpenGeofiction's copyrights page^[2] that both disagree on the license being used.

The text itself is adapted from OSM's copyright page, and the text explicitly licenses itself under CC BY-SA so it should be fine to quote here.^[3]

Our documentation, and the map and wiki data our users contributed is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 license (CC BY-NC-SA 3.0).

...

You must also make it clear that the data is available under the Open Database License. You may do this by linking to this copyright page.

What is it, OGF?

If I go to their export page, example: ^[4], I see this statement: "OpenGeofiction data is licensed under the Open Data Commons Open Database License (ODbL).". However, I can't tell if this is just a find and replace on their end and they did not intend to put it under ODbL, or if they really did know. Oh wait, that downloads XML, not PNGs. But still.

I think the most relevant thing here to Commons is probably the map tile rendering itself; we're not here to upload PBF files, just PNG files of whatever Mapnik spits out when it eats PBF.

It's a license mixture nightmare out here!

Is there preexisting precedent on Commons about what we do when an entity is being internally inconsistent about its licensing?

A diehard editor (talk) 13:47, 21 July 2026 (UTC)

Update; I've been refining my understanding of this. I am now pretty sure that the map data is what's under ODbL, while the map tiles are indeed CC BY-NC-SA 3.0. However, because the map data is ODbL, does that mean I'm allowed to go into QGIS, make my own render, using the ODbL data, and license MY render under CC BY-SA 4.0 or anything compatible with ODbL? A diehard editor (talk) 14:07, 21 July 2026 (UTC)

The OpenGeofiction Contributor Terms I found look to only tell their contributors that their contributions are to be licensed under CC BY-NC-SA 3.0 and don't mention ODbL. I generally wouldn't assume that contributors in general have agreed to also license their contributions under ODbL unless there's something elsewhere that they would have agreed to saying so. I think the main "precedent" about what's done if a source isn't being clear about its licensing is to try to contact the source to get clarification, and not include it in the meantime if there's significant doubt about compatible licensing. However, if it turns out that the data contributed has in fact been under the ODbL somehow, then yes if you render your own tiles/graphics from the data then you should be able to license your file in any way you want that complies with the ODbL license. PeterCooperJr (talk) 14:48, 21 July 2026 (UTC)

I see. I think an admin said in their Discord server that the map data was ODbL, but that's obviously not verifiable to people here. Would it be a good idea for me to email OpenGeofiction and CC the VRT email, and then if OGF replies that the map data is indeed ODbL 1, I'll then upload my self-rendered map to Commons? A diehard editor (talk) 17:15, 21 July 2026 (UTC)

I don't know if it's the OpenGeofiction administrators' opinion of the license the data is under, so much as what the individual contributors of the data thought about what license they were offering their creative works under. I could understand someone who thought that they were creating a world for non-commercial use only being surprised and unhappy if they were to discover that Commons was providing it for use in commercial activities as well. For a little bit of background, when OpenStreetMap changed their license from CC-BY-SA to ODbL ages ago, they got approval from their contributors or else removed their contribution. I don't know if OpenGeofiction may have done something like that which might be part of the reason for the conflicting licensing information out there. But this all is getting much more complex than my understanding of the intricacies of things, so you may want to wait and see what other people here have to say since it's entirely possible I'm misunderstanding something. — PeterCooperJr (talk) 17:33, 21 July 2026 (UTC)

There's also a COM:NCR: The outline of the continents was trademarked, IIRC by Thilo Stapff, in order to make hostile forking more difficult. And I'll note that the technical aspects of getting data from OGF and putting it into QGIS or other GIS software may be affected by this update. — Arlo James Barnes 21:04, 21 July 2026 (UTC)

Should we start Banning or Blocking .webp images?

Should we start banning or blocking .webp images from being uploaded on commons? Obviously the format was created for use on websites and i have not come across a single .webp images here which was free and its usually void of EXIF data (which is what it was designed for) so cannot be guaranteed as a free image and no real photographer will ever convert their images to this format intentionally so all in all, all .webp images are not free, so why do we allow them?. Atleast with .svg and other vector formats, its not photographs that are converted into them so are nearly always free and in public domain. I'm not sure if a discussion regarding this ever took place on commons and if not, why? at the very best, we could force a warning to anyone uploading .webp to confirm the image was "taken" by them and to warn them why .webp images are not a trusted format and should not be uploaded, atleast with .png, we can confirm if they were taken off a video, webp images are also hard to reverse search so will become an issue for admins and licence reviewers in the future to verify their authenticity. ....--Stemoc 06:33, 22 July 2026 (UTC)

Yes, I agree with that assessment. At least 99% of WEBP images uploaded to Commons are copyright violations. I don't know of any device which output images in WEBP format by default. And I don't see the benefit for Commons to use it. At the very least, it should be restricted to users with some advanced rights (like MP3). Yann (talk) 07:07, 22 July 2026 (UTC)

 Support — Draceane ^talk_contrib. 07:18, 22 July 2026 (UTC)

 Support conditional upload ban. Grant only to the admins/sysops, template admins, and autopatrolled users the privilege (not right) of uploading images with w:en:WebP format. Do note that tagging problematic files has become slow due to problems when searching images using Google Lens, see this comment of mine. That's why slowing down problematic content uploading is crucial, if we cannot eliminate it completely. I'll also add that a couple of WebP uploads, likely from regions like the Indian Subcontinent, West Asia, and Africa, are personal images that are out of COM:SCOPE. One previous discussion: Commons:Village pump/Proposals/Archive/2023/11#Restrict_webp_upload？. JWilz12345 (Talk|Contributions) 07:37, 22 July 2026 (UTC)

 Comment I have come across many images that were free and in WebP format, such as those copied from US Government websites. I think it'd be a shame if we couldn't have copies of images from NASA or from the USACE here, amongst others. I could support requiring some level of permissions here before being allowed to upload them, such as is done with MP3, but I don't think an outright ban would be the best plan. PeterCooperJr (talk) 12:54, 22 July 2026 (UTC)

The first image listed is available as a PNG at the source site - . (And it's a somewhat blurry photo, possibly captured from a video stream; nothing would be lost by converting it to a JPEG.) Omphalographer (talk) 22:20, 22 July 2026 (UTC)

Yeah, that probably wasn't the best example, it was just the first thing that popped up in my search of PD-USGov webp files. Just in general, WebP is an open format, that organizations and individuals can (and have) provide useful images in. PeterCooperJr (talk) 22:45, 22 July 2026 (UTC)

 Comment While it has been my own policy to convert WEBP images to JPEGs before uploading, yes, I have run into a fair number of PD images that download as WEBP. - Jmabel ! talk 22:51, 22 July 2026 (UTC)

 Comment WEBP has its use in tracking problematic files, as WEBP ≈ copyvio is often true. But that doesn't consider workloads of people patrolling files. On the other hand, a ban would encourage some people to simply convert their copyvios into the inconspicuous JPEG format. A middle ground could perhaps indeed be found in enforcing some restrictions, autopatrol as for MP3 could work. Regards, Grand-Duc (talk) 01:35, 23 July 2026 (UTC)

 Comment Maybe only allow upload with higher user rights. I sometimes upload WebP files from a CC0 website :) --PantheraLeo1359531 😺 (talk) 13:42, 23 July 2026 (UTC)

•  Comment Possibly only block if claimed as "own work". (As Jmabel notes, some archival public domain images can be found online only as webp - I too generally convert them to jpg or png before uploading.). -- Infrogmation of New Orleans (talk) 14:08, 23 July 2026 (UTC)
• As for JWilz12345. We can accept these from trusted users. Otherwise we're better without, because (and only because) of the copyvio likelihood. I don't see 'own work' claims as a useful discriminator here. Andy Dingley (talk) 14:15, 23 July 2026 (UTC)

 Support, as others have already mentioned, the right should be granted starting at Autopatroller or even Patroller level. זיו「Ziv」 • For love letters and other notes 18:13, 23 July 2026 (UTC)

•  Oppose Some uploads are copyvios, but there is not enough reason for a full ban. You say that “no real photographer will ever convert their images to [webp]”, but Commons is not only for photographs. Some illustrations will look ugly if you write them as jpeg even in good quality, and are unnecessarily large size if you write them as png. We do need a more modern format (or two really, since webp is a hybrid with separate lossy and lossless modes) even if adoption is slow. – b_jonas 07:57, 25 July 2026 (UTC)

  SVG is best for illustrations. A diehard editor (talk) 16:34, 25 July 2026 (UTC)

Who can help to categorise the 7,000 media as of 2022?

So far, we have reduced the files listed in Category:All media needing categories as of 2022 from 80,000 to 7,000. Now we need more volunteers please, to reduce this number to zero. After the low hanging fruit have been harvested, these need to be categorized one by one but not necessarily in alphabetic order. Who can help? --NearEMPTiness (talk) 10:19, 22 July 2026 (UTC)

@User:Stefan Kühn, @User:Prototyperspective, @User:Gbawden, @User:ProtoplasmaKid, @User:Wracking: I am contacting you, because your are listed in Commons:WikiProject Minimum One Category#Project members. We are making good progress, but need to team-up again during the countdown, please, to categorise the remaining 3500 media needing categories as of 2022 most efficiently. --NearEMPTiness (talk) 10:17, 26 July 2026 (UTC)

Category:Valued images sorted by promotion date

Category:Valued images sorted by promotion date, as well as any sort of chronological cats or lists, would be more interesting if it's "from new to old" instead of "from old to new", so that you see different stuff being constantly added to the sets at the top instead of always the oldest elements of the sets.

the way this cat was realised is

{{#time:U|{{{2}}}}}

in Template:Valued image which converts any recognisable strings of text for a timestamp to unix time.

to make new to old, one method i've used is sorting by the result of 9999999999-unixtime .

but really, when will commons be able to sort files by "time taken" like flickr? RoyZuo (talk) 11:33, 22 July 2026 (UTC)

Ooooh yes, would love a built-in sort-by-"date/time taken", rather than or in addition to the sorting by edit and creation date we have now. --HyperGaruda (talk) 05:34, 23 July 2026 (UTC)

fwiw, having multiple sorting methods is harder then just switching methods. So if there is an alternate to alphabetical people want, that is probably do-able. Bawolff (talk) 14:14, 23 July 2026 (UTC)

Changing the sorting to reverse chronological order sounds like a good idea to me. Is that something you (or someone else) could go ahead and implement, or do we need to vote on it first? ReneeWrites (talk) 18:48, 23 July 2026 (UTC)

to be clear, this would still be a long process that may get bogged down in red tape. I would say let me make an implementation first, then we have some showing of community consensus, then i try to convince WMF powers to enable it. Bawolff (talk) 19:07, 23 July 2026 (UTC)

I think some wires are getting crossed here, upthread you talked about enabling different sorting methods for categories (for which WMF would need to get involved), but I'm just talking about a fairly minor edit on a template that we could do by ourselves. My question is if we want to go ahead and do this, or if we want to discuss it first (either here or on the template's talk page). ReneeWrites (talk) 19:18, 23 July 2026 (UTC)

oh my bad, you're right i misunderstood Bawolff (talk) 20:02, 23 July 2026 (UTC)

sorry i'm lost at your comments. mediawiki already has multiple sorting methods mw:Help:CirrusSearch#Explicit_sort_orders.

what it doesnt have is sorting by "time taken (created)" of files.

that doesnt seem super difficult. it seems to me flickr assigns a value (unix timestamp?) to every file. commons could do the same for all files that have exif. the exif timestamp = time taken. for edge cases, erroneous exif, etc., files could be manually given a point in time.

built-in sort-by-time-created is way better than all these makeshift hacks that use some sort order systems invented by users.

it's again mediawiki being unsuitable for commons. for commons, the time when a file was created in the world, is more useful than the time when that commons file page was created. RoyZuo (talk) 22:02, 23 July 2026 (UTC)

Seeking Portuguese-speaking volunteers for the permission-pt VRT queue

Hello everyone,
We are currently looking for volunteers to help with the permission-pt queue in the Volunteer Response Team (VRT) — the Portuguese-language permissions queue.
Unfortunately, we have no active volunteers at the moment handling these requests. This has resulted in a significant and growing backlog.
We are therefore seeking Portuguese-speaking who would be willing to help review and respond to permission requests. Any help would be greatly appreciated.
If you are interested, please apply to volunteer.
For any questions, feel free to ask here in this thread, contact me directly, or reach out to any VRTS administrator.

On behalf of VRTS administrators. -- Geagea (talk) 19:44, 22 July 2026 (UTC)

Proposed deletion of PNG Cedar City flag

Hello, I recently vectorized the flag of Cedar City, Utah, because it has come to my attention that the ratio of the PNG flag is weirdly the widescreen format, or 16:9. As a result, I decided to vectorize the flag and fix the ratio to 3:5, which matches other city flags (and even the state flag), such as St. George, Ogden, Salt Lake City, Provo, etc. So I need to hold a debate on whether or not the PNG flag of Cedar City is considered unneeded due to its weird size, when in reality the flag should (presumably) be 3:5. I wasn't sure whether to make it 2:3 or not but after finding out about the other city flags across the state it only made sense to make the SVG of Cedar City 3:5. https://commons.wikimedia.org/wiki/File:Flag%20of%20Cedar%20City,%20Iron%20County,%20Utah.png https://commons.wikimedia.org/wiki/File:Flag%20of%20Cedar%20City,%20Utah.svg ₘₒd cᵣₑₐₜₒᵣ ✰ ʜᴀʙʟᴀ ⍟ コントリビューション 03:38, 23 July 2026 (UTC)

The flag design on Cedar City's official website has an aspect ratio of 16:9. This photo of the flag having physically been made also shows the flag with an aspect ratio of 16:9. Flags of countries or states tend to not be universal in size or (in the case of Nepal) shape. It's best to let go of the idea of how a flag should look and turn to what the source material has to say about it.

As for getting the file deleted, you need to start a deletion discussion for that by nominating the file for deletion (which should be a widget on the file page itself), though this isn't a valid reason to have a file deleted, as far as I know. The Village Pump is more for things that concern Commons as a whole, or if someone has questions or needs help from the broader community. ReneeWrites (talk) 18:05, 23 July 2026 (UTC)

Fingerposts and directional signposts

Currently, Category:Fingerposts is a subcategory of Category:Directional signposts, but the images in either look the same. The only technical distinction I can see, is the separate link to the German pages de:Armsäule and de:Wegweiser respectively. Would that mean Category:Fingerposts is supposed to only contain finger/arm-shaped posts? Thoughts? --HyperGaruda (talk) 08:30, 23 July 2026 (UTC)

Most images in Category:Directional signposts could be moved to Category:Fingerposts. But "Directional signposts" also serves as a parent category of Category:Directional road signs, which contains images that aren't fingerposts (such as File:BA road sign III-92.2.svg). ReneeWrites (talk) 18:35, 23 July 2026 (UTC)

And there are a fair number of images even directly in Category:Directional signposts that don't belong in Category:Fingerposts. E.g. File:Die Soldaten des Führers im Felde. Vor Warschau. The soldiers of the Führer in the field, before Warsaw. Poland, 1939.... - NARA - 559370.tiff or File:FSTC Kafanchan signpost 2.jpg, each with a single sign that happens to include a directional arrow; File:Romeinse wegwijzer in de woestijn langs de weg van Malula naar Damascus, Bestanddeelnr 255-6056.jpg where I'm not even sure of the sense in which it is "directional", but certainly doesn't involve any pointing; or File:Sign-1210129, Dingle Peninsula, Co. Kerry, Ireland.jpg which seems to indicate that a pilgrim way continues forward, but is certainly not a fingerpost. But, yes, most of what is directly in Category:Directional signposts could be moved to Category:Fingerposts or one of its subcats. - Jmabel ! talk

So using the examples given, would I be correct to classify them as follows:

• Category:Directional signs: File:FSTC Kafanchan signpost 2.jpg
• Category:Directional signposts: File:Die Soldaten des Führers im Felde. Vor Warschau. The soldiers of the Führer in the field, before Warsaw. Poland, 1939.... - NARA - 559370.tiff, File:Romeinse wegwijzer in de woestijn langs de weg van Malula naar Damascus, Bestanddeelnr 255-6056.jpg, File:Sign-1210129, Dingle Peninsula, Co. Kerry, Ireland.jpg
• Category:Directional road signs: File:BA road sign III-92.2.svg (should this even be a subcategory at all, considering these signs are not always on a post?)
• Category:Fingerposts: any sign with one end stuck to a post and the other end pointing into a direction, but then what would File:Radwegweiser Morsbronn 1.jpg and File:Guidepost 296637.jpg be? --HyperGaruda (talk) 06:57, 25 July 2026 (UTC)

• @HyperGaruda: Mostly agree, although File:FSTC Kafanchan signpost 2.jpg seems to me to be barely even "directional" (cat would be harmless, I guess, though I'd never have added it) and I can't work out the directional aspect of File:Romeinse wegwijzer in de woestijn langs de weg van Malula naar Damascus, Bestanddeelnr 255-6056.jpg (can anyone explain)? I'd definitely consider those last two to be fingerposts, not sure what is in doubt about that. - Jmabel ! talk 19:36, 25 July 2026 (UTC)

  @Jmabel: regarding the stone, I would have personally called it an ancient Roman milestone. However, instead of mijlpaal, the archive from which this was uploaded, decided to call it a wegwijzer, which is more closely translated as a direction sign. So I suppose a case of lost in translation. My doubt about the last two signposts stemmed from File:Radwegweiser Morsbronn 1.jpg essentially being a "plural" version of File:Die Soldaten des Führers im Felde. Vor Warschau. The soldiers of the Führer in the field, before Warsaw. Poland, 1939.... - NARA - 559370.tiff, yet the latter is not a fingerpost(?) --HyperGaruda (talk) 20:18, 25 July 2026 (UTC)

  @HyperGaruda: with regard to essentially being a "plural" version, yes, it's really subtle. It's a matter of where you draw the line. In the narrowest sense of a fingerpost:

  • there is a single post rather than multiple supports (e.g. one at each end of a flat sign).
  • the signs themselves are shaped like arrows, rather than just having arrows drawn on them.
  • there are multiple directional signs.
  • the signs stick outward from the post, rather than being centered on the post.

  So I guess it's a question of how much of that you can "relax" without it ceasing to be a fingerpost. My own inclination is:

  • Single post: mandatory.
  • Shaped like arrows: if they are long rectangles, that is close enough; the closer to square (or to a painted/drawn arrow being a relatively minor part of what is not mostly a directional sign), the more I would see that as a strike against.
  • Multiple directional signs: optional, but "one strike against" if other factors come up short.
  • Stick outward from the post: optional, but "one strike against" if other factors come up short.

  Three strikes and you are definitely "out". The only thing tricky about that is that the "shaped like arrows" thing is not a clean binary.

  To be honest, I never thought this through rationally until you asked, it was just gut feeling. - Jmabel ! talk 21:57, 25 July 2026 (UTC)

@Jmabel and HyperGaruda: I'm quite sure that the Roman milestone shown by File:Romeinse wegwijzer (...) is identical with CIL III, 06723 (the link points to the EDCS database which also has a photo of the milestone). Its text (as far as I can read the letters) and damaged parts (e.g. in line 4, around "OCOS") do match. The location information however differs substantially.

Anyway, Roman milestones do not indicate directions. Generally, their inscriptions name the emperor who built or restored the road, and his titles often allow dating (in our case, that would be the year 198 AD). Sometimes, the distance from the next major town is also given in Roman miles (or in leugae, in some parts of the Empire).

Their images are best placed in Category:Miliaria or its "by country" subcategories such as Category:Miliaria in Syria (if available), and additionally in categories for the inscriptions, such as Category:Ancient Roman inscriptions in Syria and categories for inscription publications (CIL volume, etc.). -- Martinus KE (talk) 23:55, 25 July 2026 (UTC)

Thanks @Jmabel; I tried distilling these features into a decision table at Category:Directional signposts. Feel free to modify where you see fit. @Martinus KE: well spotted! I can also distinguish "VRELIO" on the line below, corresponding nicely to the transcribed [A]urelio, and the stone also has the same crack running over it, so I agree fully with your identificaiton. --HyperGaruda (talk) 07:57, 26 July 2026 (UTC)

Request for comment (the future of Abstract Wikipedia)

You are invited to voice your opinions in a request for comment about the future of Abstract Wikipedia. Thank you! Kowal2701 (talk) 12:24, 24 July 2026 (UTC)

(This message was sent to Commons:Txokoa and is being posted here due to a redirect.)

AI query

What is wrong with this image? File:KewSparkle24-34.jpg Faces seem AI, but rest of set seems ok. No Swan So Fine (talk) 20:04, 24 July 2026 (UTC)

Looks like an editing attempt that went totally wrong. GPSLeo (talk) 21:11, 24 July 2026 (UTC)

Deletion request seems the right step. It's unclear why this is so weirdly AI generated and can be deleted as that's not declared and it's not of realistic educational value. Fæ (talk) 21:21, 24 July 2026 (UTC)

Listed for deletion. -- Infrogmation of New Orleans (talk) 21:45, 24 July 2026 (UTC)

My guess is that these photos were taken in low-light conditions, and the camera (probably a cell phone) is doing a bad job of inferring details from what is probably an extremely dark, noisy source image. Omphalographer (talk) 21:54, 24 July 2026 (UTC)

Can "Adobe Photoshop Camera Raw 17.0.1 (Macintosh)" do this?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:58, 24 July 2026 (UTC)

The only other awful ones are File:KewSparkle24-29.jpg and File:KewSparkle24-27.jpg. No Swan So Fine (talk) 22:09, 24 July 2026 (UTC)

The filter on modern smart phone cameras applies a smoothing effect that's similar to the surface blur filter in Photoshop. This creates an artificial smoothness/sharpness, but it doesn't distort images in the way shown here. ReneeWrites (talk) 23:42, 24 July 2026 (UTC)

@ReneeWrites: I'm not sure a phone camera couldn't distort like this. See File:Down North 02.jpg (which I took with a phone). I believe it is close to the limit of acceptable distortion of this sort, but it does seem to be the same sort of distortion. - Jmabel ! talk 05:20, 25 July 2026 (UTC)

The smartphone camera on blurry or extremely zoomed-in images smoothes out areas, creating a kind of blotchy/posterized effect. It is a kind of distortion, but it's different from what we see here. ReneeWrites (talk) 22:37, 25 July 2026 (UTC)

Has anyone got experience of auto detection of odd untagged AI images/enhancements like this? It feels like this is something that could be usefully mass tagged if there's a reliable way of doing it. --Fæ (talk) 07:55, 25 July 2026 (UTC)

An experimental search for "Adobe Photoshop Camera Raw 17.0.1 (Macintosh)" was not much use for detection. The random handful selected from other uploaders looked okay rather than hyper-corrected. See https://quarry.wmcloud.org/query/107666 Fæ (talk) 08:09, 25 July 2026 (UTC)

Request for OSM to support Structured Data on Commons (SDC) and MediaInfo entity (Mxxxxxx)

cc: SandraF_(WMF) SFauconnier

Question is this the best place to look for feedback from the community?

Looking for feedback from the Commons community: Linking OSM objects to Structured Data on Commons (MediaInfo entities)

Hi everyone,

I have started a discussion in the OpenStreetMap community about improving the way OSM objects link to files on Wikimedia Commons:

"Linking OSM objects to Structured Data on Commons (MediaInfo entities)"

The idea is to explore whether OSM should be able to reference

Commons MediaInfo entities (M-IDs) instead of (or in addition to) traditional file names.

Today, an OSM object typically links to a Commons image using a filename:

image=File:Example.jpg

The OpenStreetMap discussion is here:

https://community.openstreetmap.org/t/linking-osm-objects-to-structured-data-on-commons-mediainfo-entities/145727

I hope we can get input from both communities before any concrete proposal is developed. Thanks!

-- Salgo60 (talk) 10:27, 25 July 2026 (UTC)

Looks like no support from the OSM community to support SDC see voting Salgo60 (talk) 20:07, 26 July 2026 (UTC)

Category: July 2026 in Amsterdam

Lately, I've noticed that this category is invariably overwritten by "Photographs taken on etc." if more photos were taken that day. I have no objection to this, but the first category was visible to everyone (and mentioned Amsterdam), while the second is invisible (and doesnot mention where the picture was taken). To see which photos are in it, you need to know the exact date, but you cannot retrieve them together. Is this intended (as it currently stands)? It seems better to me to simply continue the category "July 2026 in Amsterdam" and add "Photographs taken on" as an extra public or hidden category.Ceescamel (talk) 09:52, 25 July 2026 (UTC)

I repeatedly raised this topic before, without much success. Ymblanter (talk) 13:03, 25 July 2026 (UTC)

@Ceescamel: what you describe as "better" is how I always do it when adding {{Taken on}}. But I have no idea why the "Photographs taken on [DAY]" categories aren't simply made visible. Nor why, now that we have Template:World cat, they aren't all implemented with that template. - Jmabel ! talk 19:40, 25 July 2026 (UTC)

I'm also not sure why "Photographs taken by day" categories aren't visible. I would be in favor of changing that, I feel like that would solve a lot of issues related to this topic. ReneeWrites (talk) 22:32, 25 July 2026 (UTC)

+1 on making the by day categories visible. Nakonana (talk) 09:45, 26 July 2026 (UTC)

Personally identifiable information

I notice that there is currently no info about "personally identifiable information" (PII), including but not limited to photo coords, licence plates photographed, names, addresses, phone numbers, emails...

I think they can all be classified into 3 situations:

1. PII is intentionally published.
2. the author or the persons whose PII is published dont mind PII being published.
3. PII is not supposed to be published but accidentally published.

Some users remove, delete or oversight other users' such files. I think there should be a guideline for when and how this is done.

I found only 1 old discussion Commons:Village_pump/Archive/2020/01#c-Downtowngal-2020-01-28T01:20:00.000Z-Please_review_photo_of_a_driver_license.--RoyZuo (talk) 19:42, 25 July 2026 (UTC)

In my opinion, all PII (mostly gps coords) there in my files are intentional. other users shouldnt remove them unless they are erroneous (e.g. gps drift), even though some coords were my previous homes.

And i think this applies to any users. unless users have explicit permission from creators or persons related to those PII, they should not remove other users' files' PII.

Then there's the problem of being unable to contact those persons. in that case, users should not remove PII since they dont get the permission. if one day i stop editing, i still dont want other users to remove my files' PII.

Also there could be an option. if the default community practice is "remove PII even if no permission can be obtained", i want an option to explicitly override this to say that PII in my uploads are intentional and should not be removed.

Coz i'm irritated by do-gooders. if info is removed from my uploads, that means something is lost and potentially time and effort i put in are undone. so far nothing seems to have happened to my uploads, but i've seen users doing this to other files.--RoyZuo (talk) 19:42, 25 July 2026 (UTC)

Normally, the only time we should remove personally identifiable information about the user who put it there is that we genearly assume that new/inexperienced users who put their email or phone number in discussions, etc. are usually either (1) making a mistake because they probably haven't considered just how public this is, or (2) know full well how public this is, and are spamming. Either way, we customarily remove those from public view, and often even suppress revisions. I see no reason to change that.

Also, with reference to identifiable third parties, we have our policies about not "outing" people, and the user's/uploader's wishes barely come into play if that line is crossed. We routinely delete images that are probably legal but appear to be intended as "outing", doxxing, harassment, etc.

With reference to location data giving information about the uploader, we generally defer to the user's wishes as to whether to keep locations visible or not.

When the personally identifiable information is about other people, laws vary widely from country to country. In the U.S., if you are in a public outdoor space, you have approximately no legal expectation of privacy; basic decency toward one's photographic subjects would come into play long before the law did. And I'm not sure it should be entirely the uploader's prerogative: for example, in the U.S. you could legally publish a picture of an unattended 6-year-old playing in their front yard, if the yard if visible from the street or sidewalk. If there was some reason for Commons to keep that picture, we would probably not want to have geocoordinates on it, and I don't think that would be left to the uploader's choice. Conversely, in France or Germany, legal rights to privacy have a lower threshold than any global policy we would be likely ever to consider. There are pictures on Commons I've taken in New York or Seattle and published unedited, where I would not even consider doing so if the picture were in Paris or Berlin. - Jmabel ! talk 22:41, 25 July 2026 (UTC)

Example file: file:New Mexico standard horizontal driver identification card obverse - non-PubL109-13 and with neutral gender designator and number and address redaction.png (currently nominated for deletion for reasons unrelated to PII); this is my card, and originally I kept all the information that was on it, but another user redacted and version-trimmed it so I requested a rename to clarify what was missing. Arlo James Barnes 22:25, 26 July 2026 (UTC)

Replace main page links to search links

Today during Unpopular Talks it was proposed to replace links currently using technical and kind of confusing categories like Category:Images (something that is mostly text), with something that shows actual media to our readers.

This idea seems to have received warm feedback from the people on site (on Wikimania). So let's fix it :)

(a) The basic idea would be to replace the image link etc with a generic search of a specific type, like so:

• images
• video
• audio

Works best for images and video.

(b) Another option is to vary the links for different languages: images, search for "en" – this could maybe search using the current user's language, which should kind of give local images (most of them would be local; for example, "pt" might show a periodic table at the top, but still better than a generic category).

What do you think? Shall we engage? ;) Nux (talk··dyskusja) 21:19, 25 July 2026 (UTC)

my attempt is at commons:explore (the selection of images will change everytime you purge the page or if you wait enough time) Bawolff (talk) 23:10, 25 July 2026 (UTC)

I think step one would be to decide (1) who is the intended audience for those links and (2) what are we trying to communicate to them. -Jmabel (talk) 22:44, 25 July 2026 (UTC)

1) Intended audience is mostly new users and users unfamiliar with Commons. Other people know their way around and can find categories if they need to.

2) We should be trying to communicate that we have a lot of media of different types. Nux (talk··dyskusja) 23:23, 25 July 2026 (UTC)

So you believe it's new end users, rather than new contributors? Wondering if that is general agreement; I've never really given it much thought, myself. But if that's the case, then I agree that categories are a poor choice. - Jmabel ! talk 00:10, 26 July 2026 (UTC)

i would go with its for anyone who wants to browse the commons collection instead of look for a specific file. I think that can be both old and new users, but probably an emphasis on newer users. Bawolff (talk) 04:12, 26 July 2026 (UTC)

I agree. Having a link to a search page would both allow browsing through everything and easily refine search to browse through topics. Nux (talk··dyskusja) 06:50, 27 July 2026 (UTC)

What are the inclusion standards for obscure pride flag/symbol designs?

We have a lot of little-known/used/recognized sexuality and gender identity flags and symbols. Commons is very tolerant in its scope, and doesn’t care about “notability” in the enwiki sense of only allowing things that are substantially covered by the mainstream media and scholarly publications. Most scope-based deletions target quality and redundancy more than anything else. So where do we draw the line for files that are neither low quality nor redundant, that have at least a hypothetical educational utility, but take the form of abstract symbols that require widespread adoption to have any meaning whatsoever? Is anything made up by anyone fine? Does it require a 3rd-party source, no matter how flimsy? Does it need to be covered by at least a reliable source? Do we need (at the opposite extreme of no standards whatsoever) Wikipedia-level sourcing requirements proving notability? A major concern here is whether we should allow citogenesis-style creation of original designs or only document existing ones. Commons is generally more skeptical of original content if it lacks obvious educational utility. My personal stance is that we should maybe make an exception to our “no such thing as notability” philosophy here, and require either at least one mainstream/scholarly source documenting a design and/or at least two or three alternative sources that are independent from each other and the creator. We shouldn’t gatekeep based on enwiki standards, but we’re also not a place for anyone to dump their cool new design for an examplesexuality or placeholdergender pride flag. Dronebogus (talk) 07:17, 26 July 2026 (UTC)

 Agree, I've seen files being kept that should by all rights have been deleted for being out of scope due to having no realistic educational value. ReneeWrites (talk) 07:57, 26 July 2026 (UTC)

We already have an exception: Commons is not a hosting website for personal art, nor is it a place for advertising / activism. Pride flags have been deleted on that basis. If a flag isn't in use by any group, then it's just personal art.

If you want to read a lengthy case of someone, who uploaded such flags, even getting blocked for the out of scope uploads and failing in getting the files undeleted and themselves unblocked, see this unblock request for example. Nakonana (talk) 14:09, 26 July 2026 (UTC)

Rather than 'mainstream', it would be friendlier to say realistically in use and published as such. There are special style Pride based flags, badges or logos for protest groups and social groups. There are also anti-LGBTQ type flags, again it can be useful to have a record of these, so long as there is a history of being realistically in reasonably wide use, not an individual on a disruption campaign.

I'll share this VP thread in our WMLGBT+ user group (which has its own Pride style emblems on Commons...), though worth noting that inclusion/exclusion of rainbow flags is a recurring discussion. Fæ (talk) 21:17, 26 July 2026 (UTC)

I've brought a number of these files up for deletion in the past, e.g. Commons:Deletion requests/Files uploaded by Nonbinary-Naturalist. A standard test I've proposed for inclusion of identity/pride flags is that they should only be kept if it can be demonstrated that the flag is recognized as representing some group, by people who are outside that group. Omphalographer (talk) 00:29, 27 July 2026 (UTC)

I think it’s unreasonable to require people outside a certain group to recognize something for it to be legitimate, especially given sexual and gender minorities are discriminated against and the further from “normal” society they are the less likely they are to receive any recognition or discussion outside their own group. A symbol should be widely adopted within a community, and sources from within the community should be acceptable to demonstrate that. Dronebogus (talk) 00:36, 27 July 2026 (UTC)

I agree with Dronebogus here. The bar for these should be pretty low (as it should be for political flags and emblems), but there should be some evidence of "real-world" use extending beyond the person who created the flag and their personal friends. When a single individual claims to have created the flags for a dozen different sexual orientations, I for one get pretty skeptical. - Jmabel ! talk 01:49, 27 July 2026 (UTC)

Rather than a hypothetical discussion, a case book would be a practical approach. It would establish the types of image that raise questions, and help to define what counts as reasonable educational value for these emblems or flags. Perhaps there are some useful deletion discussions with varied results that illustrate the current community consensus? Fæ (talk) 04:01, 27 July 2026 (UTC)

You are welcome to check out Category:LGBT related deletion requests for precedents Dronebogus (talk) 04:26, 27 July 2026 (UTC)

The deletions are useful to review. Certainly it is not controversial to delete unused and not notable pure fictional flags, user created works with no evidence of being in use, and "solo" works where the only evidence is one person creating a flag and using it by themselves. In one of the deletions a flag with Confederate symbolism was mentioned as having been seen in use, and had there been supporting links to video or photos of it in use, that might have been sufficient for a keep result.

In general I doubt there's much of an issue as the numbers involved are quite small compared to wider discussions about flags and maps. Fæ (talk) 04:41, 27 July 2026 (UTC)

Category:Sinners seems to be a bit of a mess.

It seems to act as if it's for a German musical group (but presumably not the metal band which is at Category:Sinner (band)), but also contains other images which seems to be depicting persons who have commited Christian sins. StarTrekker (talk) 13:04, 26 July 2026 (UTC)

11 files is few enough that this could be resolved manually, such as by moving the band's files to Sinners (rock band); then Sinners can redirect to Sins. Arlo James Barnes 22:31, 26 July 2026 (UTC)

That’s a good idea Dronebogus (talk) 04:24, 27 July 2026 (UTC)

COM:SCOPE vs COM:AIIP

Not sure of the best way to move this forward: there was a discussion at Commons talk:Project scope/Archive 4#Proposed change: excluding images do not comply with COM:AIIP from COM:INUSE rules that ran from December to March about whether COM:SCOPE took precedence over COM:AIIP or vice versa. It was archived with no action, and it remains ambiguous what view Commons takes on AIIP images which are in use on other projects. Some DRs keep them when the guidelines are pointed out, others delete them.

Can I request a formal retrospective review of that discussion - either interpreting and applying its outcome, or judging that it was made in the wrong place so carries no weight and should be restarted elsewhere? Belbury (talk) 09:58, 27 July 2026 (UTC)