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)

80,000 high resolution antique and old maps and related pages

A long term puzzle for Commons has been the small resolution images of the David Rumsey Historical Map Collection which are hosted on the internet archive. Being bold, all of the images of maps published before 1875 have been uploaded in the last week and there is a second longer term process of overwriting these with high resolution versions of the same image. Some more recent but still public domain maps have been uploaded as an exception, for example the UK Ordnance Survey maps for which the UK Gov licensing means any published before 1976 are public domain.

It would be great for volunteers to start looking at the use of the high resolution maps using a search like this one, or taking a look in Category:Images dezoomed by Fæ. Adding categories would be great, however for several weeks, avoid moving files that have not been 'upgraded' out of the parent category, as they'll probably be missed. If any need renaming please keep the IA number in the filename.

• Selected examples
• 
  1920s Llanelly in Carmarthenshire
• 
  1872 Afrika
• 
  1700 the terraqueous globe

--Fæ (talk) 12:58, 29 June 2026 (UTC)

Thanks for all these.

It would be useful, I'm sure, if we could agree some sort of strategy for dealing with these consistently. What sort of categorization should they end up with? How do we manage the workflow? Is there interim categorization, such that we can see the workflow queues easily with a simple query on Petscan. Andy Dingley (talk) 13:11, 29 June 2026 (UTC)

A project page for the DRHM would be sensible as there are several issues to resolve as well as a categorization strategy, like best way to organize crops, clipped artwork, improved dating, mass SDC additions and ensuring that necessary deletions due to copyright errors are implemented across the whole collection without lots of extra volunteer time. For the moment Commons:IA books#DRHM might be sufficient if discussion is materially on the VP or my talk page. More information about batch changes can be added there. Though these are jpgs, they are all pages from atlases.

The parent category has a lot of sub categories based on the atlas names or types. As a precedent that seems reasonable though with the volume uploaded there might need an extra categorization, say by author or publisher. Fæ (talk) 13:21, 29 June 2026 (UTC)

I would suggest by attribute. In which year/decade it was produced? What area is shown? What projection is used? What language (if others than English) are used? Maybe this :3 --16:17, 29 June 2026 (UTC) PantheraLeo1359531 😺 (talk) 16:17, 29 June 2026 (UTC)

Very cool, thank you for that! --PantheraLeo1359531 😺 (talk) 16:16, 29 June 2026 (UTC)

I did upload several thousands of these 3 years ago. It would be wise to check what is already on Commons. However I copied the files from the original source, not from IA. Yann (talk) 20:50, 29 June 2026 (UTC)

It would be sensible to automatically navigate these to decide what to do about possible duplicates, and whether they are duplicates. If they can be identified before upgrading the resolution, then skipping the higher resolution and removing the small resolution image makes sense, unfortunately there seems to be no obvious easy way to find a unique ID for each (jpg) image if it has not been based on the IA release. Taking File:Cartes générales des Royaumes de l'Europe et des particuliers de France (14353021).jpg the source links with the file are not unique to the image, so searching Commons throws up multiple matches. Based on the related IA upload (found by looking through the visual matches), a unique ID from the source site would be "RUMSEY~8~1~339088~90107224", but this has not been used in the alternate. In terms of literal checksum duplicates, in 11,000 'upgraded' cases this has not come up so far; it would be useful if they were digitally identical as then the API will handle rejecting the upload gracefully.

Using filetype:jpg "David Rumsey" -intitle:IA filewidth:>2000 shows 2,218 pre-existing files of higher resolution that were not part of the IA uploads.

Worth noting that the uploads from IA appear to have significantly more detailed information, which is more 'comfortable' to copy to Commons because the first release of those texts was to IA rather than here. These make the images more self contained to explain copyright etc. and much easier to defend against possible take down requests. Fæ (talk) 03:21, 30 June 2026 (UTC)

Created a script to back search from the parent pub number and display back to me thumbnails of matching images in a quick grid. Unfortunately the API is heavily throttling me thanks to the hostile way of constraining volunteer access, so frustratingly even one image search (36 thumbs) is costing waits of up to 3 5 minutes. If someone knows a way to stop my IP getting throttled it would be nice to know. I have tried forcing a login as Faebot, but as these are just reading thumbnails the throttling policy is bizarrely unhelpful and using a bot account seems to make no difference. Dropping the research for the moment. Trying contacting bot-traffic@wikimedia.org but no idea if that actually helps as opposed to pointing me to read the policy which amounts to either do everything on toolforge or already be a sysop. Fæ (talk) 10:26, 30 June 2026 (UTC)

Good news, firstly that duplicates seem rare, probably less than 1% of the final high resolution uploads (400 to 800 files?). This is based on a random walk using a sample of 200 'seed' files from the high resolution uploads based on IA. A test script filtered out the publication number and used that to find a candidate list of files that were not uploaded from IA. There were 4 matches of that type, with 1 or 2 matched files, but only 1 was a visible duplicate:

• File:Arabien. (with) Die Sinai Halbinsel oder das Petraeische Arabien. (with) Hedud el-Haram oder has heilige Gebiet von Mekka ... (IA dr arabien-with-die-sinai-halbinsel-oder-das-petraeische-arabien-with-he-00954040).jpg
• File:Weimarer Hand-Atlas - Arabien, 1848 (DRMC 2077045).jpg

There are an interesting comparison because they are both the same pixel size resolution but the upload from 2017 is 17mb and the most recent is 20mb. In theory the png tiles from the source should be identical, so the non-lossless process of assembling a jpg must be the difference. Presumably making the latest a jpg of slightly higher quality. Looking at these, the decision to delete either is not obvious, it might even be fine to keep both. The test analysis at least shows that detecting any duplicates can be done and could be fully automated based on the basic code already working, just needing an image matching routine. It makes sense for a later deletion discussion to decide if it's easiest to delete all the more recent duplicates or if there are other differences than file size.

The same basic code can be used to generate cross-linking galleries as a field for the new uploads, if that would be helpful, or possibly to add them to an uncreated temporary publication category for each atlas if there are several related files. Fæ (talk) 14:19, 30 June 2026 (UTC)

Proposal: How would folks feel about mass creation of unmade (red) categories like Category:Rename me to the atlas title - DR 252214343.000 which would be populated by all matches to a search for pub_list_no 252214343.000? This would be fairly easy to do in parallel with upgrading the resolution of map images. Fæ (talk) 17:59, 30 June 2026 (UTC)

About 8 speedy deletions raised this morning for globes, i.e. spherical format maps on stands. The photographs have a non-commercial claim which is valid as these are not faithful images of 2D works. Photographs where the edges of the atlas/book are seen are normally judged as within the 'faithful reproduction' limit as they are not the focus of the photograph, nor have any creative element to being incidental to the image. Fæ (talk) 08:54, 30 June 2026 (UTC)

Thanks a lot from my side as well! There is a lot of interesting, even fascinating stuff in this treasure trove of maps! What an overwhelming amount of files ...

However, a first look into the files of a few subcategories showed me that there seem to be quite many spelling errors in file names and file descriptions, at least for German and French. Missing letters, hyphens, accents, wrong translations (such as EN "by" = DE "bei" where DE "von" is meant and even printed in the original document), ...

Can these errors be addressed somehow? When the digitized text is harder to read than the 19th-century calligraphy in the image files, it's not exactly reader-friendly anymore ... -- Martinus KE (talk) 14:26, 30 June 2026 (UTC)

The text imported from IA was itself exported from the Rumsey database. If there was any automated OCR it was probably done years ago. If there's a group of fixes, like the atlas title has a typo in it for multiple files, then VFC is probably the best solution. This is still a manual fix but it does mean a faster one than individual file page edits. Fæ (talk) 14:47, 30 June 2026 (UTC)

Once again, thanks a lot, Fæ! – Even if VisualFileChange just helps reducing the number of manual tasks by a factor of 10 or 100, this will have a significant impact.

So far, I'm not familiar with the tool. But I took a note, and I'm quite confident that I'll give it a try, rather sooner than later. -- Martinus KE (talk) 12:38, 1 July 2026 (UTC)

Whoops. Managed to get to 14,535 upgraded files, but the davidrumsey site has blocked my IP. I'm unsure if their system will let me back in at some point, or if there's a possible throttle level that would stop getting blocked again. --Fæ (talk) 13:32, 2 July 2026 (UTC)

Uploading is ticking away after a few days of being blocked. It's unclear if anything changed. Fæ (talk) 13:08, 7 July 2026 (UTC)

Thanks a lot from me as well, Fae. As a cartophile, I am still busy categorizing Eran Laor maps, Gallica maps, Polona maps, Rijksmuseum maps, NYPL maps and NARA maps right now. I have a few ideas for optimization here, but I'm not sure whether or not this is possible.

The first one, is to create subcategories for your batch upload, in order to distinguish your new uploads from the old ones that have been up for a long time already. The old ones are usually already categorized; your new batch is not. Also, grouping all files from the same work (Atlases or sub-collections) in the same category would be a great boon, and would help along categorizing these maps. Maybe also creating subcategories for maps from the same author: the most notable cartographers are in Maps by cartographer, and a category that already groups Category:Maps by Nicolas Sanson in the David Rumsey Historical Map Collection would also help. I'm not sure whether such author-subcategories should be only temporary. I also don't know how reliable Rumsey's author information is, so maybe it's best to filter the files with ad-hoc search requests like the one above.

Yet another idea is more tricky, and it involves searching existing file titles, and possibly matching "other versions" already. Just for example, already the second of your uploads I checked right now, was Daphne, and just today I had already categorized Daphne! A neat coincidence, but this will not remain the only one. I'm fairly certain that for most engraved maps, we already have uploaded variants from other digitizing institutions, e.g. the ones I stated above. --Enyavar (talk) 21:53, 8 July 2026 (UTC)

create subcategories for your batch upload, in order to distinguish: sorry of I'm stating the obvious here, but don't we usually cover this by uploading with something like a Category:SOME SOURCE OR COLLECTION to check as well as Category:SOME SOURCE OR COLLECTION, and then when it's checked the former can be removed? - Jmabel ! talk 01:30, 9 July 2026 (UTC)

Exactly, that's what I'm asking for here; a great example is Gallica. Of course, other collections are currently not organized that way, for example Rijksmuseum and Eran Laor. --Enyavar (talk) 09:43, 11 July 2026 (UTC)

The are also a (relatively) small number of visual duplicates. We're waiting on finishing the dezooming to consider how to fix those. A lot of the selecting by cartographer or atlas title can be done with COM:VFC, for the moment as dezooming is ongoing, without removing the parent category. This type of VFC edit was done to create Category:Stanford's London atlas of universal geography yesterday. The "safe" rate of dezooms may mean it will take a couple of months before trimming off the parent category.

(Tip) The dezoom process is currently prioritizing any documents mentioning 'London', so those publishers are the first ones to think about to set a precedent. Fæ (talk) 12:51, 9 July 2026 (UTC)

Pleased to say the population of high resolution maps and atlas scans is 25% done, i.e. c. 20,000 files so far. The original estimate of 2 to 3 months to complete these turned out to be about right. Both on the source side speed has to be limited or we get blocked, plus on the Wikimedia upload side there are significant delays due to the throttling of volunteer contributions through the API. We frequently see error 500 and error 429 despite the upload rate being unremarkable and file sizes rather modest (around 10 MB to 100 MB), including when using a bot flag. This particular project would be inadvisable to go via Toolforge as we would not want to IP ranges used by WMF servers getting flagged as bots or falsely flagged as AI harvesting in 'security databases'. --Fæ (talk) 08:47, 17 July 2026 (UTC)

"Upload a new version of this file": Now with a large button!

Hello everyone. I noticed yesterday that the "Upload a new version of this file" function is now displayed as a large button at the bottom to every file. Apologies if there is already a discussion about this somewhere; I couldn't find anything at a quick glance. But I have to ask: which genius implemented this? I think it's terrible; it only leads to more users who aren't familiar with the rules overwriting files, see COM:OW. Best regards, זיו「Ziv」 • For love letters and other notes 14:15, 3 July 2026 (UTC)

for reference https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1304636 . I do agree that it seems a little too prominent now. If we keep the button maybe it should be styled as a codex "quiet" button instead. Bawolff (talk) 14:29, 3 July 2026 (UTC)

@Bawolff: Thanks for the link. No, that is simply bad design, just because one user had trouble finding it. Right now, it actually looks like an invitation to overwrite files. זיו「Ziv」 • For love letters and other notes 14:37, 3 July 2026 (UTC)

I agree with this. Commons generally favors uploading a new version rather than overwriting existing ones, and we had to restrict overwriting because of how common unconstructive overwrites were (to say nothing of vandalism). People who aren't often on Commons don't understand our policies and those who are, don't have an issue finding the button. This change was not needed. ReneeWrites (talk) 22:31, 9 July 2026 (UTC)

Hi, I made that change. I don't think it's okay to call people "genius" sarcastically for doing changes you disagree with but I understand you don't like it. There are many reasons to make this change: You don't have trouble finding it but not everyone has the eyesight you have and accessibility is vital. Here are many resources that explain when to pick a button (action) and when to pick a link (navigation): https://tailkits.com/blog/link-vs-button-accessibility/ and https://accessibilitymadeeasy.substack.com/p/buttons-vs-links-making-them-accessible.

On that it will cause vandalism. With the same logic, we should hide edit button too. I understand vandalism is a problem (as a long-timer) but it should be protected against with other means: Rights (unregistered users can't override), abuse filters, monitoring, protection of widely used images, etc. Hiding the link to re-upload is basically security through obscurity which never works in long-term. Amir (talk) 15:03, 3 July 2026 (UTC)

Hello @Ladsgroup.

Thanks for your detailed reply, and I apologize for the sarcasm. You’re probably a genius, actually—it’s just that the execution in this case here was poor. The old layout was perfectly adequate; I currently don't see the point of turning it into a button. Best regards, זיו「Ziv」 • For love letters and other notes 15:13, 3 July 2026 (UTC)

The only button that should be prominently displayed is actually just "Mark this file version as patrolled," because that one is genuinely helpful and useful. But perhaps I am completely alone in my opinion regarding your change, and I would like to hear other views on the matter. זיו「Ziv」 • For love letters and other notes 15:26, 3 July 2026 (UTC)

Addendum: Just as a side note, I wear strong glasses too myself; so much for visual acuity. And this is one of the reasons why I have the global CAPTCHA exception. זיו「Ziv」 • For love letters and other notes 15:33, 3 July 2026 (UTC)

Thanks for the kind words. I actually made that a button too (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1059444) mostly because I really can't spot small things on the screen.

As a way forward, I propose this: I will monitor the rate of re-upload and how many of them end up being reverted (and how many users have re-uploaded, etc.). If there is a negative effect on these numbers, we can for example make it a quiet button. Would that sound good to you? Amir (talk) 15:41, 3 July 2026 (UTC)

Please take a look at the files I’ve uploaded here. As an admin, I spend a lot of time deleting duplicates. Much of this actually stemmed from files being overwritten incorrectly. I’m concerned that the new visible button will lead to even more of this happening. זיו「Ziv」 • For love letters and other notes 15:47, 3 July 2026 (UTC)

I totally understand yours concerns and I'm thinking of ways that it could be tackled. One idea. Currently MediaWiki:Uploadtext shows this on re-upload: "Please mind our guidelines on overwriting existing files. You agree to publish your upload under the same license as stated on the file description page."

IMHO, this should be completely revamped. For example, it needs a warning box since the one above it is a gigantic box, this looks like a small text below it and is barely visible. Also, barely anyone is going to click on the link of the guidelines. If there are certain types of mistakes that happen all the time and we can list them there in a bullet point like "Do not re-upload for newer picture of someone, upload a new file instead" (with link to upload wizard or something).

What do you think? I think it could be quite impactful. If you can provide me with some text. I'm going to mock up something for it! Amir (talk) 16:01, 3 July 2026 (UTC)

But.. is t it so that most people cant even overwrite files any longer because of the abusefilter that Commons has put in place ? —TheDJ (talk • contribs) 11:53, 4 July 2026 (UTC)

I noticed it too and thought the same thing. @Ladsgroup: even "edit" is a link, not a button. "Upload file" is also a link (to Special:UploadWizard), so why should "Upload a new version of this file" (which links to Special:Upload with some pre-filled in fields) be a button? It always stood out to me though, maybe this link should be in the "tools" menu or part of the Read / Edit / View history tabs? - Alexis Jazz ^{ping plz} 16:01, 3 July 2026 (UTC)

Also that massive blue block on Special:Upload should be hidden/collapsed/compacted for reuploads, with relevant advice for reuploads given instead. I actually hate that blue block, my screen is too small so I need to scroll past it to access the form *every single time*, I never read it. (it can probably be hidden with CSS.. will do that now) - Alexis Jazz ^{ping plz} 16:08, 3 July 2026 (UTC)

One reason why the link is where it is might be that somewhere near the list of old versions and their thumbnails seems like a natural place for users to expect an action to another version of the file. whym (talk) 03:02, 4 July 2026 (UTC)

 Comment I agree with Ziv. Completely useless change. Yann (talk) 16:03, 3 July 2026 (UTC)

I am sorry, but I stand by my previous opinion. It was a change that was not strictly necessary and should be reverted to the old version as soon as possible. זיו「Ziv」 • For love letters and other notes 16:14, 3 July 2026 (UTC)

Another detailed answer: @Ladsgroup.

You need to bear in mind that your new version practically invites edit wars over files such as File:Flag of Syria (2025-).svg and this is just one. Other users or admins will then have to deal with the resulting problem and may have to protect such files. I personally like the idea from @Alexis Jazz, of ​​hiding this option, for example, in the "More" section. זיו「Ziv」 • For love letters and other notes 16:52, 3 July 2026 (UTC)

I also agree with Ziv. This button is for users who already have certain plans for overwriting a certain file. It should not be prominent. Prominent button would be an invitation for incompetent users to overwrite for the sake of overwriting. Sneeuwschaap (talk) 17:09, 3 July 2026 (UTC)

I see a lot of piling on here, but do remember that for several years now, to overwrite a file that you did not upload yourself, you need at least autopatrol permission. If someone has that level of permission, they presumably have a fair understanding of how things work here. If they are doing stuff they shouldn't it is unlikely to be out of ignorance. - Jmabel ! talk 22:30, 3 July 2026 (UTC)

Jmabel, file that you did not upload yourself, you need at least autopatrol permission.
You mean (auto)confirmed: Special:ListGroupRights. - Alexis Jazz ^{ping plz} 00:23, 10 July 2026 (UTC)

@Alexis Jazz: If auto-confirmed is still enough, then Commons:Overwriting existing files is incorrect. Not being affected by it, I just went by what I read. But I believe that what is in ListGroupRights is the basic ability to overwrite (which we have to grant to let someone overwrite their own uploads). The other is, I believe, enforced by a filter. - Jmabel ! talk 00:36, 10 July 2026 (UTC)

Jmabel, you're right. When trying to upload something with an autoconfirmed account I get MediaWiki:Abusefilter-warning-file-overwriting. - Alexis Jazz ^{ping plz} 14:35, 13 July 2026 (UTC)

It seems like the reupload workflow has been an afterthought for a long time, should be better re-designed. It's a bigger issue than changing or changing back the styling of the reupload link/button, though. The styling itself is not a problem in my opinion - it's just a normal MediaWiki button like any others. Accidental overwriting is a problem that should be prevented, and making it harder to find the option is not the only way. How about adding a prompt saying something along the line of "do you really want to do it? you might want to upload it under a new name" in an opt-out manner (that can be disabled in preferences)? The current reupload page does say "Please mind our guidelines on overwriting existing files(...)" but that seems too obscure and too late. I think it's more important to make sure it's read by people trying to reupload, especially people who have never done that.

That said, as a temporary solution, I think we could overwrite the styling just for Commons. @Ladsgroup: Can you suggest a CSS rule for MediaWiki:Common.css to do that (e.g. make it grey or some other dim color)? whym (talk) 02:59, 4 July 2026 (UTC)

• Thanks for the change! Despite contributing for decades, I still would have to scroll up and down looking for it. I wanted to ask for making it more obvious for several years. --RAN (talk) 03:37, 4 July 2026 (UTC)

  Seconding this. The button was too obscure. It looks better now. Nakonana (talk) 06:57, 4 July 2026 (UTC)

  Just echoing that I also appreciate this change. I help onboard new Commons contributors, and the option to overwrite files is a frequent question and point of awkwardness. It was absolutely not perfectly adequate. I think the core issue is actually that the action is in an odd place. Most actions are either at the top (editing) or in the dropdown/sidebar (moving, purging, etc.). The new-version link being in the file history section never really made sense to me, but at least having the overwrite action now be a button helps it stand out in its otherwise awkward location. If people prefer a less prominent button, or can figure out a new location for the link altogether, that is fine by me. I understand the concern that the button may invite unconstructive overwriting, but I'm not a fan of letting potential bad actors hinder improvements to our archaic UI. As Amir mentioned, that feels like security through obscurity. If bad overwrites are a frequent problem, then we should revisit the overwrite flow itself. I like some of the options Amir proposed, like better surfacing guidelines and advice. ~Kevin Payravi (talk) 16:13, 4 July 2026 (UTC)

I would suggest to have the overwrite button on the same menu as the rename button as both actions are similar important and similar often used. GPSLeo (talk) 09:03, 4 July 2026 (UTC)

@GPSLeo I agree with this actually. And the file history doesnt belong there either, nor does “what uses this file”. These are all historical accidents that people now feel attached to, but make no logical sense if you were to design from scratch. —TheDJ (talk • contribs) 11:56, 4 July 2026 (UTC)

i'm not sure i agree about links. Finding out what links to a page on a normal page is a pretty rare operation. Articles are primarily about their content. Image pages on the other hand are primarily about managing the image, so it makes sense to make metadata like where the image is used be prominent as that is a major reason people go to image pages. At least in a wikipedia context, maybe the logic doesn't hold quite as much on commons where the image is the primary content. Bawolff (talk) 23:51, 9 July 2026 (UTC)

An update that the button is now a neutral button instead of progressive, meaning it's not blue anymore but the size stays the same. It'll be deployed next week but you can check it in beta cluster if you create account and have rights. Amir (talk) 11:37, 10 July 2026 (UTC)

Here are pictures in case you don't want to go through the hassle of setting up account in beta cluster: phab:F92777139 and phab:F92777188 Amir (talk) 11:40, 10 July 2026 (UTC)

@Ladsgroup: Hi, This is a completely useless change. It only unnecessarily invites to overwrite the file, which should not be done in most cases. Could you please revert this to the previous state? Thanks, Yann (talk) 11:55, 10 July 2026 (UTC)

Even though there were a few positive voices here welcoming the change, I see it the same way as Yann. Best regards, זיו「Ziv」 • For love letters and other notes 23:47, 10 July 2026 (UTC)

I think the neural color is a reasonable default for many wikis that use MediaWiki, if not for Commons. The policy of strongly forbidding overwriting is not embedded to MediaWiki. Assuming there is a CSS rule to identify it, we can discuss Commons-specific styling for it at MediaWiki talk:Common.css. whym (talk) 00:19, 11 July 2026 (UTC)

as many users have said, uploading new version is restricted by filter, so making the button bigger doesnt encourage people to make unnecessary edits but only improve accessibility.--RoyZuo (talk) 15:11, 12 July 2026 (UTC)

And, the number of reverts hasn't changed since the deployment. I'm collecting and monitoring those, if it turns out that a lot more being reverted, sure I'll change it but so far the number is quite low and hasn't increased since July 3rd. See phab:P94793 (reverts) and phab:P94794 (new version uploads). Amir (talk) 01:38, 13 July 2026 (UTC)

Currently we have a huge button that is not useful for most users as they hit a filter when using it. This is like putting a huge delete button on the page that can only be used by admins. GPSLeo (talk) 05:17, 13 July 2026 (UTC)

making a button that doesn't work bigger seems really bad UI and would lead to frustration. Is there a reason we use abusefilter instead of changing the permissions in mediawiki? If we change the perms in mediawiki the UI should adapt accordingly. Bawolff (talk) 05:08, 13 July 2026 (UTC)

Making MediaWiki adopt isn't hard honestly. Would you mind filing a ticket? Amir (talk) 09:59, 13 July 2026 (UTC)

The reason this was done with a filter is that nothing currently in the MediaWiki software can distinguish the right to overwrite your own upload from the right to overwrite someone else's. - Jmabel ! talk 17:19, 13 July 2026 (UTC)

no, there are separate rights, reupload and reupload-own. By default in mediawiki you have to be auroconfirmed to overwrite another person's file, but any user can overwrite their own. So it sounds like all we need to do here is move the reupload right from autoconfirmed to autopatrol. Bawolff (talk) 19:46, 13 July 2026 (UTC)

Jmabel, Bawolff, this was done on purpose to allow overwriting of some files. See MediaWiki:Abusefilter-warning-file-overwriting and Commons:Village pump/Proposals/Archive/2023/08#Implementation problem. - Alexis Jazz ^{ping plz} 11:53, 14 July 2026 (UTC)

Of course, I should have realized that. Enforcing at the wiki level would not let us make exceptions for {{Current}} etc. - Jmabel ! talk 21:10, 14 July 2026 (UTC)

If it's not possible to do it via mediawiki because of the exceptions, maybe it can be hidden via Common.js? I know it's not super nice but at least saves them a failed attempt regardless of how the reupload link looks like. We'd have to duplicate exceptions somehow though. Amir (talk) 22:19, 14 July 2026 (UTC)

We'd need to do something with Common.js that (1) would be aware of their rights level and (2) would distinguish whether the file page has {{Current}}. I can see how we would do the latter, but is there something in he HTML that lets us do the former? - Jmabel ! talk 01:20, 15 July 2026 (UTC)

yes, you can look at mw.config.get('wgUserGroups') Bawolff (talk) 07:13, 15 July 2026 (UTC)

Jmabel, if ( mw.config.get('wgUserGroups').indexOf('autopatrolled') == -1 && ! document.getElementById('id of an element from a template') && document.getElementById('mw-imagepage-reupload-link') ) { document.getElementById('mw-imagepage-reupload-link').style.display = 'none' } - Alexis Jazz ^{ping plz} 07:32, 15 July 2026 (UTC)

Good. Rather than just mw.config.get('wgUserGroups').indexOf('autopatrolled') == -1 you'd want mw.config.get('wgUserGroups').indexOf('autopatrolled') == -1< && mw.config.get('wgUserGroups').indexOf('sysop') == -1; there might be something else that ought to be checked for. Given that this is technically possible, I'm all for it. We'd need to account for both {{Current}} and {{Allow Overwriting}}. - Jmabel ! talk 20:04, 15 July 2026 (UTC)

Also: we'll need some sane way (in the HTML) to determine whether they are the original uploader. It should be possible to find the original uploader with something like #mw-imagepage-section-filehistory bdi:last-of-type, though I'm not sure that is at all future-proof. - Jmabel ! talk 00:48, 16 July 2026 (UTC)

Category:Burials in the United States by cemetery

At Category:Burials in the United States by cemetery each cemetery is in both "Category:Burials in the United States by cemetery", and the individual state list. Was this done on purpose to have a flat-list? Or should they be removed from "Category:Burials in the United States by cemetery" if they appear in one of the 50 state lists we have? RAN (talk) 23:21, 8 July 2026 (UTC)

I counted 38 by-state subcats, not 50. Regardless, why do we have so many when a healthy percentage of them are underpopulated? Using the mere existence of something as an excuse to create a category is a Wikipedia thing. RadioKAOS / Talk to me, Billy / Transmissions 02:14, 9 July 2026 (UTC)

I would agree that if a "Burial at [location]" category is subcategorized in one of the by-state subcats, that it can be removed from the main "Burials in the United States by cemetery" category, but there might be a good reason why it's set up this way. @WFinch: this discussion might be relevant to your interests, as you've been fairly active in this area. ReneeWrites (talk) 22:23, 9 July 2026 (UTC)

I agree—the by-state subcategory is enough. — WFinch (talk) 15:51, 14 July 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)

DPLA bot

More views would be appreciated on the DPLA bot creating over 100,000 identical duplicate uploads this year. A request to urgently stop the bot from creating identical duplicates is at User_talk:DPLA_bot#Urgent_stop_request.

As explained there, by design, rather than taking notice of the upload API warnings before upload, the bot instead does the upload and might later mark them for deletion, giving administrators a never ending amount of work. Clearly this is by design as {{DPLA duplicate}} describes itself for that purpose.

Checking the database, in the last 24 hours alone, the DPLA bot has created 2,634 identical duplicates. https://quarry.wmcloud.org/query/107243 --Fæ (talk) 12:53, 14 July 2026 (UTC)

@Dominic: as the bot operator. Please explain here what kind of solution you have in mind to ensure the bot no longer produces duplicates, or produces almost none at all. זיו「Ziv」 • For love letters and other notes 13:13, 14 July 2026 (UTC)

This is a different issue entirely. The files I spot-checked in that query are duplicates in the source at NARA, so that is the reason it ended up on Commons that way. It’s very odd. Dominic (talk) 13:27, 14 July 2026 (UTC)

Haven't we been through this before? If a NARA file already exists on Commons, why is another upload from DPLA necessary? זיו「Ziv」 • For love letters and other notes 13:31, 14 July 2026 (UTC)

No, I am saying something else was happening in this instance. This a fresh upload (like File:Robert L. Maxwell, Class of 1945, Twin Engine Pilots - DPLA - 56075261900f1d058c1232ea7d05a6b5 (page 1).jpg and File:Robert L. Maxwell, Class of 1945, Twin Engine Pilots - DPLA - 56075261900f1d058c1232ea7d05a6b5 (page 2).jpg) where the item itself had a data issue with multiple pages being listed all with the same file. This a bug in NARA's data, that occurred across a singple collection of a ~1000 images, tripling them all. Not ideal at all, but not something we were previously handling because I have not come across it before. Dominic (talk) 13:56, 14 July 2026 (UTC)

• @Dominic: I'm confused, both links in the prior paragraph are the same, so I don't know what other file this meant to refer to. - Jmabel ! talk 21:17, 14 July 2026 (UTC)

• @Jmabel: You're right, it was a typo, I just fixed it (the second link should have been for page 2, though now that is a red link as it was resolved). Dominic (talk) 21:37, 14 July 2026 (UTC)

So, it's almost like in a supermarket (3-2): "Buy two, get a third free." Sorry for the joke, but again, if the example already exists as a NARA upload (I haven't checked that), why was a DPLA upload necessary in the first place? זיו「Ziv」 • For love letters and other notes 14:05, 14 July 2026 (UTC)

I mean that this item was never uploaded before. The only duplication was a new item which is in fact a single phot, but in the data the same image was listed as a multi-page document with the same file for each page. NARA is a part of DPLA, and this work is done with them. (Just for clarity, DPLA is an actual partnership of all of these institutions, not a third-party entity.) Dominic (talk) 14:22, 14 July 2026 (UTC)

(Technical side bar) The upload pages for the 3 duplicates in the Robert L. Maxwell example photo are 3 unique references. I believe that means that the Wikimedia Commons database has stored the image as 3 identical duplicates. I would be interested to see that verified or not at the database level and to understand whether once deleted the file will take space in deleted storage. Fæ (talk) 14:57, 14 July 2026 (UTC)

The DPLA bot is uploading digital identical duplicates of files previously hosted on Commons for many years. It does not matter at all what NARA or other archives have as current catalogues on their websites, if a file already exists on Commons, sometimes uploaded years ago from their archives, it is completely unacceptable for a bot uploader to keep uploading digital identical duplicates rather than paying attention to the API flag that is built into the mediawiki software. It's there for good reason and people with the privilege of using accounts with bot flags should be trusted to only override the automated rejections for excellent reasons.

Note that Dominic has a declared paid interest as the DPLA Director of Community Engagement, and knows better than to damage the reputation of this excellent partnership by wasting administrator and volunteer time by uploading over 120,000 digitally identical duplicates, resulting in c. 500 GB Commons storage of duplicates, rather than handling duplicate records in advance without needing to keep uploading duplicates multiple times.

The DPLA bot should be blocked as per the invitation to administrators on the bot user page, where it recognizes that it should be immediately blocked if misbehaving. The bot has been misbehaving for months, and this problem has been discussed for that long. --Fæ (talk) 14:42, 14 July 2026 (UTC)

Hi Fae, multiple issues are being conflated. The single collection we uploaded last night that generated the 2 thousand duplicates was not "uploading digital identical duplicates of files previously hosted on Commons for many years", as I explained above. There was separate issue weeks ago that I have been working on solving actively. Dominic (talk) 14:56, 14 July 2026 (UTC)

"Weeks ago" is untrue. This was uploaded by DPLA on Sunday, not weeks ago:

• File:Newspaper extract, March 1, (1816) - DPLA - 8d2fefa39dd1ef53e78793e951a08d25 (page 1).jpg

This version was uploaded by me in 2017:

• File:Letter signed John Todd to Thomas Jefferson, August 16, 1779 - DPLA - 86b0660c82a1860ebd6795f33689393a (page 2).jpg

These are not multiple different issues, this is the DPLA uploading entirely avoidable duplicates, repeatedly, and wasting valuable administrator time by expecting them to tidy up after a bot that should never make this huge mess.

The DPLA bot needs to be blocked at least until whatever solutions there might be are tested and the backlog of over 42,000 pending duplicates is handled before any more uploads run. This is wasting significant Commons resources of unpaid volunteer time and Wikimedia Commons operational resources. Fæ (talk) 15:04, 14 July 2026 (UTC)

Ah, an even more recent case is

• File:"Howard A. Wooten." - DPLA - 85bb32d501333deea74b4e6c0cd33754 (page 2).tiff

which DPLA bot uploaded this morning and the original was uploaded 15 years ago, by another bot you were responsible for.

• File:"Howard A. Wooten.", ca. 12-1944 - NARA - 512886.tif.

Note, this has become "obscured" because DPLA bot renamed the file on Commons, making the 15 years old upload look like it was uploaded as part of the more recent DPLA project. That does not seem acceptable as an arbitrary rename, Wikimedia Commons is a snapshot of uploads as they were, not being constantly changed to whatever DPLA or other external organizations want to see their names on. --Fæ (talk) 15:28, 14 July 2026 (UTC)

These files have the same checksum. This should create a warning during the upload process, why does your script ignore these warnings? GPSLeo (talk) 15:16, 14 July 2026 (UTC)

Yes, there is logic in the code about stopping the upload if it is a duplicate. Each institution gets re-run across the whole corpus to pick up new uploads, so this logic is working on almost every file every time. The only time it doesn't stop the duplicate is a faithful representation of the original (i.e., the institution has duplicate files). That seemed to work, because in other rare cases, you DO want to respect the duplicate—such as some institutions that are inserting the same placeholder blank page for blanks in a multipage item. In the example here with Thomas Jefferson, these files come from different documents in the source institution, but for some reason there is a duplicate in their own data, similar to the NARA case above. So, there is a technical solution to stop doing this, but also it is mostly a non-systemic issue that cropped up in some recent uploaded collections and is surfacing now. Dominic (talk) 15:23, 14 July 2026 (UTC)

This does not make sense. The DPLA is ignoring the warning, there's no way to create the duplicates without ignoring the checksum warning. There is no Commons policy or consensus that allows digitally identical duplicates to be created.

Examining the rename of ("Howard A. Wooten.", ca. 12-1944 - NARA - 512886.tif) this looks like the interest here is the DPLA getting the name on files rather than respecting the Wikimedia Commons collections.

The bot should be blocked. The paid conflict of interest and less than meaningful arguments, without having a proper consensus in advance, is disturbing. Fæ (talk) 15:33, 14 July 2026 (UTC)

I would prefer to refrain from blocking the bot at this time, as it's not yet entirely clear what should be done with the 42,000 duplicates now. DPLA normaly would then tag them for deletion itself. What can be deleted and what can't, if no one marks it. Previously, OptimusPrimeBot also tagged DPLA files for deletion but no longer does; another change I suggested. Don-vip then programmed his bot so that DPLA would henceforth mark its own duplicates for deletion, essentially saying, "Clean up your own mess!" זיו「Ziv」 • For love letters and other notes 15:36, 14 July 2026 (UTC)

It would be useful if we could keep some things in perspective here – by a conservative measure, DPLAbot has uploaded in the range of more than 11 million files in its many years of operation, and if we take the maximal range of issues here, we are talking about less than 1% of its uploads being questioned. @Dominic has been a longtime champion of Wikimedia in the GLAM wiki space and his good faith and competence here should be beyond a doubt.

There are different sets of issues going on here – some are duplicates that are tough edge cases, some are trying to update metadata that may be out of date from their original upload dates, and others are errors that need cleanup that Dominic, without the privs to actually execute them, has clearly tried to work with the community on resolving. As @VIGNERON said, these are quite easily addressable and fixable for folks with the right privileges. So @Fæ, as someone who is not unfamiliar with the challenges of working at scale to benefit Commons, in the spirit of collaboration and collegiality, could be slow our roll and give some space for this to collaborate on solutions before we talk of bans and blocks? - Fuzheado (talk) 18:08, 14 July 2026 (UTC)

FYI, some of the numbers here seem inflated because they (funnily enough) double-count duplicates. You are claiming 2,634 identical duplicates have been created in time frame when only 1,645 uploads were even made. The true number of redundant files over the last 24 hours was 988 by my calculation. In the Quarry query, you counted each version of an upload, even the duplicate, as a duplicate of each other and any other duplicates, counting them all two or three times each. Dominic (talk) 15:39, 14 July 2026 (UTC)

Also, certain of the accusations being made here are not based in reality. The bot's renames have nothing to do with "DPLA getting their name on files". The original "NARA" upload was done by me, as was the subsequent rename. NARA is the largest partner organization of DPLA. We are doing this work together and I even meet with them. Renaming the files is a way to better standardize and organize files that were uploaded at different times. Dominic (talk) 15:46, 14 July 2026 (UTC)

You still try to justify why you should continue uploading duplicates. Just skip all files where the same file, as in every bit is the same, is already on Commons. GPSLeo (talk) 15:59, 14 July 2026 (UTC)

I am not justifying at all. However, I did offer an explanation as to how this happened. All of the 900 duplicates from the last 24 hours were deleted already, with thanks to VIGNERON. Dominic (talk) 16:19, 14 July 2026 (UTC)

Thanks for doing some measuring of the mess your bot created, and correcting for double counting as I suggested in discussion yesterday, which no doubt you took time to read. --Fæ (talk) 15:55, 14 July 2026 (UTC)

@Fæ: I just deleted the 988 duplicates files of your query (could you update it to make sure there is no duplicates anymore ?). Also, It took me less than 10 minutes, not a big deal. finally, on a total of ~11 millions is a ridiculously low number (even 100 k files is less than 1%!), I wish everyone could make such low rate of mistake (including you). Cheers, VIGNERON (talk) 16:19, 14 July 2026 (UTC)

There are more than 42,000 duplicates in the backlog category that is mentioned on the bot talk page. In total there were over 66,000 existing duplicates on Commons that the DPLA has created. As the DPLA bot has arbitrarily moved files that were created by volunteers, you need to also make sure that the deletions are for DPLA created duplicates, not other files. This is not as simple as listing and deleting duplicates, there is also the problem of reverting renames and restoring file text data that the DPLA has erased without any consensus. Fæ (talk) 16:27, 14 July 2026 (UTC)

This sample category has 1,213 duplicates. These were a sample of uploads over 24 hours from yesterday through to this morning. Category:Digital duplicates uploaded by DPLA. Fæ (talk) 17:48, 14 July 2026 (UTC)

BTW my rate of mistakes is significantly less than 1%, the last time I checked. That's due to an abundance of caution on copyright. Certainly we don't automatically trust 'copyright free' statements in archives without understanding why. Fæ (talk) 17:55, 14 July 2026 (UTC)

Policy status of Commons:Licensing/Justifications

Commons:Licensing/Justifications was categorized as a policy in 2011 by @Koavf, boldly I think. Recently, Rose Abrams added the {{Policy}} notice to it.

However, the page does not actually read like a policy. It's intended to provide an argument to potential contributors about why they should release their work under a free license that includes commercial reuse, not as authoritative guidance on what you can/cannot do. I've also been meaning to try to streamline it (right now it's so long I don't think most photographers I could send it to would actually read it), which is harder to do on a policy page as those are expected to be comprehensive.

As such, I tried to remove the policy tag, but @Jeff G. objected based on its tenure. Therefore, I'd like to have some discussion here about whether or not this page should be a policy. Thoughts? Sdkb ^talk 15:30, 15 July 2026 (UTC)

As it's been 15 years since that edit, I can't entirely recall my reasoning, but I believe the thinking was that it was linked from Commons:Licensing or another page in that namespace. I support whatever change the community thinks should be made to the page's status. ―Justin (koavf)❤T☮C☺M☯ 16:03, 15 July 2026 (UTC)

I'm the one who added the notice, but I saw it as a maintenance action and have no real opinions on the matter. Rose Abrams (talk) 17:04, 15 July 2026 (UTC)

As a procedural matter, I would support the removal of the policy tag, as the page contains no statements of policy. Omphalographer (talk) 19:45, 15 July 2026 (UTC)

Would it be reasonable to call this a guideline? or just an essay? - Jmabel ! talk 20:14, 15 July 2026 (UTC)

Essay, I think. To use the language of RFC 2119 - a policy page describes what editors MUST or MUST NOT do; a guideline describes what editors SHOULD or SHOULD NOT do. This page is neither; it's an explanation of why some policies are in place. (The IETF might call it "informational".) Omphalographer (talk) 20:34, 15 July 2026 (UTC)

It is technically under COM:L policy. I did indeed object. If the consensus is "informational" and "essay", I could go along with that. As author of the COM:LJ redirect, I like to cite it as to why we disallow -nd (no derivatives) and -nc (no commercial use) licenses; an anchor inside COM:L under COM:L#Acceptable licenses could do just as well if both nd and nc are addressed in the same place.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:04, 16 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)

Type of building in Budapest

This building is used by tram staff (lines 23 and 24). The outlook post was probably used by a supervisor in the past. Terminus of the lines 23 and 24. Smiley.toerist (talk) 10:04, 17 July 2026 (UTC)

Category:Railway control towers? Nakonana (talk) 18:21, 17 July 2026 (UTC)

Do we know what purposes tram staff use it for? E.g. is it more of a place to rest or used for other purposes? Maybe something under Category:Breaks in work?

Also, we should almost certainly create something under Category:Rail transport buildings and under Category:Rail transport buildings in Hungary specific to trams.

Jmabel ! talk 23:34, 17 July 2026 (UTC)

I certainly see some personel traffic. This is the end-point of two tram lines. So it seems logical that staff take their break (toilets / koffee) and start and end their service there. In many tramnetworks everywhere, there are places where staff can go to the toilet and take a break. Often it is a small building where they have the keys to. I hope some local has more knowledge about it.Smiley.toerist (talk) 09:26, 18 July 2026 (UTC)

There are also several (computer) screens visible in the window, hence my assumption that it might be some kind of control tower. And just the way the windows are arranged and protrude from the facade as if to offer the best possible overview of what's going on at the station below. Nakonana (talk) 09:40, 18 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)

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)

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)

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)