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)

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)

How to categorize All media needing categories as of 2022?

The Category:All media needing categories as of 2022 still contains a bit more than 15,000 files. A small team started to reduce this number from 80,000 to zero in February 2025, but now we got stuck at letter E. Do you want to help categorizing the remainder manually, by reviewing the files one by one, or do you have a recommendation, how this could be done more effectively, based on the hints shown in the Commons:WikiProject Minimum One Category? --NearEMPTiness (talk) 06:37, 2 July 2026 (UTC)

Files that are already being used in an article can be found using Glamtools. This simpliefies the categorisation for new volunteers. NearEMPTiness (talk) 02:13, 4 July 2026 (UTC)

14,000 files to be categorized, please. We need more volunteers now, because it is getting increasingly difficult, since the low hanging fruit have been harvested. --NearEMPTiness (talk) 18:57, 4 July 2026 (UTC)

I did some, but 13,108 still to be done. If people just try, they will surely find some they can do. Good luck! B25es (talk) 15:38, 7 July 2026 (UTC)

It's anonymous work, but it doesn't go unnoticed. I find it particularly rewarding, if I can find a good photo for a previously pictureless article. NearEMPTiness (talk) 16:28, 7 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)

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)

Lilypond question

Hi! Is there a chance to put music notation objects (like ABC and Lilypond) on Commons? Will the Lilypond-source then be rendered? --Bebbe (talk) 09:22, 4 July 2026 (UTC)

@Bebbe: Are these formats unencumbered by patents and copyrights? - Jmabel ! talk 04:05, 5 July 2026 (UTC)

Yes! This is traditional music, which is very old. We even don't have to pay GEMA, if music groups play these songs in public. Bebbe (talk) 05:17, 5 July 2026 (UTC)

Lilypond notation is already used in Wikidata. The format is part of Lilypond, a GNU licensed software, and the documentation specifically comes under GNU FDL.

ABC notation is documented on abcnotation.com with CC BY-NC-SA 3.0 on the documentation content. Michalporeba (talk) 08:24, 5 July 2026 (UTC)

@Bebbe Lilypond can already be used right? Or do you mean use it as a File object, including the special File transclusion syntax, as opposed to using the score extension element ? —TheDJ (talk • contribs) 11:42, 8 July 2026 (UTC)

Dear TheDJ, thanks for your answer. I am not sure, as it seems, commons can do syntax highlighting: Category:LilyPond SourceCode. But I didn't find any examples for compilated Lilypond-things in Commons. Bebbe (talk) 16:41, 8 July 2026 (UTC)

Dear Lilipond, can you help here?

@Bebbe This is an example of how to use lilypond:

<score>
{c' d' e' f' g' fis' es' cis' c'2}
</score>

gives

This is a wikicode feature, described at help:Score. —TheDJ (talk • contribs) 18:24, 8 July 2026 (UTC)

Dear TheDJ, thank you very much. Is this only possible in talk-Pages or is it possible to put a <score> as a single document in commons? Bebbe (talk) 20:43, 8 July 2026 (UTC)

@Bebbe This is wikicode. Lilypond cannot be uploaded as a file object. You can just make pages outside of the File namespace of course, but those cannot be transcluded into other wikis.

part of the reason why this is not implemented like this, is because a rendered version of it has no ‘native’ predictable dimensions., which is generally required to make an object transcludable. Also what are you transcluding in that case, the sheetmusic rendering, or the midi rendering. Cant really have both. That makes it harder to decide how a File object of lilypond should behave if it were to be implemented as a document type. —TheDJ (talk • contribs) 10:40, 9 July 2026 (UTC)

So, there's no chance to put scores, which can be processed further, somewhere in the wikiverse? Bebbe (talk) 12:22, 9 July 2026 (UTC)

@Bebbe: Scores can be uploaded to Commons in PDF or DjVu format, and can be transcribed in Wikisource (s:Help:Sheet music for English). Yann (talk) 12:53, 9 July 2026 (UTC)

Sorry, but that doesn't help me. I need an independent place, where Lilypond-Files can be stored and the raw files, SVGs or midis can be used in several projects. The compiled files of Wikisource have unpredictable filenames and because of this they cannot be used somewhere else. The main target of Wikisource is transcribing sources, the main target of commons is providing files for other projects. So, I think, Commons would be the best place to put the files there. But it doesn't provide the necessary functionality. Bebbe (talk) 07:15, 10 July 2026 (UTC)

@Bebbe: Wikimedia doesn't allow global transcriptions in wiki markup. It has to be done locally. But if they are uploaded as SVG or MIDI, them it should be OK. Yann (talk) 07:36, 10 July 2026 (UTC)

In the Score extension you can suppress the score and just generate the midi file, w:Help:Score#MIDI only. Whether you can do that directly in Commons as a transposable file or would have to save the midi file and upload that to Commons, I don't know. Nthep (talk) 11:03, 10 July 2026 (UTC)

Yes, in the file you can say, what should be compiled, the score or midi. This would be a great thing in Commons. I think this could be a great thing not only for me, for all music, which is not protected by law. Bebbe (talk) 14:51, 10 July 2026 (UTC)

Could the code be kept in the Data: namespace, such that a local template or module could feed it to the Score extension to interpret in the manner required?—Odysseus1479 (talk) 21:25, 10 July 2026 (UTC)

Category:The Sketch

Hi, FYI, I am uploading scans of this UK magazine. Issues from before 1906 to Commons, and issues after that to English Wikisource: s:Category:The Sketch. For the later issues, they may not be in the public domain in UK, depending on the content and the authors of each magazine, but big parts of them are (anything which was published without an author). These pages could be copied to Commons, as they are not freely accessible at the source.

BTW, it would be nice if someone who has access to (or even a copy of) missing volumes (1, 2, 4, 5, 6, 7, 11, 17, 20, 22, 25, 26, 50, 58, 60, 103) could upload them. Regards, Yann (talk) 10:59, 4 July 2026 (UTC)

@Yann: is this any use? https://www.britishnewspaperarchive.co.uk/titles/the-sketch - Jmabel ! talk 04:08, 5 July 2026 (UTC)

@Jmabel: Thanks for your answer. This requires a login. Yann (talk) 07:52, 5 July 2026 (UTC)

Sadly the British Library, founded to be a national archive for the people, grubbily sold off all the newspaper archive digitization to https://www.dcthomson.co.uk/. This is why the public domain archives are not "free" despite legally being "free".

Even without a BL card, access to UK libraries normally includes full access to the newspapers and/or access to ProQuest British Periodicals when using the library computers. This might mean tediously manually downloading to a USB stick then uploading. If these remain missing, I may be able to try this over the next month or two without getting my library access blocked. --Fæ (talk) 11:40, 6 July 2026 (UTC)

Poking at this online, it is clear that the 'British Online Archives' have an exclusive "copyright". Consequently Gale/ProQuest do not have The Sketch even though they have other publications by the same publisher. This gets worse every time it is examined more closely. Fæ (talk) 12:28, 6 July 2026 (UTC)

• Gale/ProQuest used to have exclusive access to the New York Times archive and claimed a copyright on public domain news articles. I think this is just a rote copyright statement like we see at the New York Times website themselves: File:Hiram Boardman Conibear obituary.png. Ultimately USA/UK copyright law must be followed, and anything else involves the Terms Of Service (TOS). --RAN (talk) 00:00, 9 July 2026 (UTC)

  The nuts and bolts issue here is that even manual downloads of a single page cannot be done via local libraries as ProQuest do not have The Sketch on their database. Because the British Library "partnered" with DCThomson who make money from these scans of public domain by age magazine pages, the only way to digitally access them without paying a third party (for doing the job of getting in the way) is physically at the British Library. It appears that even standard University contracts that provide access to the other British Library newspaper databases have deliberately excluded The Sketch.

  It's a very poor show from the British Library; almost worth writing to Members of Parliament about as the BL is "sponsored" by the Department for Culture, Media and Sport because they are failing to meet the 1972 British Library act by failing to meet their own strategy "Knowledge Matters" which was published to oversee operational decisions through to 2030. The strategy repeatedly makes claims about free access and online public access for research, which this case demonstrates they are doing precisely the opposite by locking free public domain archive records behind an *external* paywall. Fæ (talk) 08:19, 9 July 2026 (UTC)

Wiki Loves Yoruba Heritage Photography Contest

Dear colleagues, the Wiki Loves Yoruba Heritage photography contest will start on August 1, 2026. We invite everyone to help document and celebrate the rich heritage of the Yoruba people by contributing photographs of our culture, traditions, historical sites, festivals, architecture, arts, and other aspects of Yoruba heritage. To reach more people outside the Wikimedia community, we have proposed a CentralNotice banner to promote the contest and encourage wider participation. Thank you. Agbalagba (talk) 11:08, 4 July 2026 (UTC)

Help needed! Is this really CC BY 4.0?

• https://www.data.rio/apps/PCRJ::geo-pal-planejamento-urbano-1/explore

This page, from an official website of the Rio de Janeiro city government, features satellite photos of the city and its surroundings ranging from 1999 to 2025. The images are very good, with an amazing resolution (I can even identify the existence of people on the streets in some cases). According to the details, it is licensed under the CC BY 4.0 license, which would be great for Commons.

However, on the 2025 map for instance, the bottom right corner reads "NASA/USGS | Prefeitura da Cidade do Rio de Janeiro Powered by Esri". On the 1999 one, it reads only "Prefeitura da Cidade do Rio de Janeiro Powered by Esri". I have not checked all the years, but I would like to know if, at least in the cases where "NASA" is written, the map can be screenshotted and uploaded here. And what about "Powered by Esri"? Thank you! Yacàwotçã (talk) 18:21, 4 July 2026 (UTC)

Seems to be a partnership between NASA and the Rio de Janeiro city government. I don't see any reason to not accept the CC BY 4.0 license. Darwin ^Ahoy! 18:29, 4 July 2026 (UTC)

AI-mediated editing?

I stumbled upon Category:Cagar Budaya Provinsi Banten earlier today, and noticed a bunch of categories duplicating already existing ones. So I just went ahead to merge and clean up where needed (taking a break currently at section "S"). At some point I wondered about the user that seems to be at the source of it all, Arif Permana Putra (talk · contribs). Their edits seem to be superhumanly rapid (I counted 500 similar edits between 2026-06-23 02:59:02 and 2026-06-23 02:41:19, or about one edit every 2 seconds), which is of course possible with gadgets, but as far as I know, these are tagged as such. Being untagged, they have to be regular edits, right? But to load a page > copy+paste a line of wikicode > switch to the summary field > copy+paste a summary > and save every 2 seconds for 500 consecutive edits? And that for a user who has been active for just over two months? My question to the audience here: what do you think is going on here? And if it is AI-assisted editing, would that be subject to COM:BOTS rules? --HyperGaruda (talk) 19:55, 4 July 2026 (UTC)

@HyperGaruda: Didn't you ask this user first? Also you should have notified them, which I did for you this time. Yann (talk) 21:03, 4 July 2026 (UTC)

HyperGaruda, why AI? These look like repetitive edits. I've made many semi-automated untagged edits with user scripts I wrote myself. Look no further than my impressive 15K edit count on nvwiki. - Alexis Jazz ^{ping plz} 01:39, 5 July 2026 (UTC)

Sorry about that, I thought linking the user was sufficient as ping and notification. As to why AI rather than a script: I got triggered initially by their last couple of 2026-06-23 Wikidata edits, using "hallucinatory" in their edit summaries while fixing some very remarkable values for the "located in..." property. From here on, it's admittedly assumptions and suspicions, hence why my initial post is formulated as more of a question. Perhaps something that points more towards AI involvement, are the Commons category creations and file categorisations at the start of 2026-06-23, each with edit summaries that feel a bit too perfect and artificial:

• Creating parent category
• Creating subcategory and linking to parent
• Categorizing file into [insert link to specific category here]

--HyperGaruda (talk) 06:06, 5 July 2026 (UTC)

HyperGaruda, I didn't really look into it, but are there significant problems with their edits? - Alexis Jazz ^{ping plz} 06:48, 5 July 2026 (UTC)

Well, if that is the reason for the duplicated categories (e.g. Category:Masjid Caringin, Category:Masjid dan Menara Agung Banten Lama, Category:Mercusuar Cikoneng Anyer etc.), including the related duplications on wikidata, then I'd say yes. --HyperGaruda (talk) 07:04, 5 July 2026 (UTC)

Category:Winter in the Philippines

Is this category even a thing? We only have two seasons: dry season (November to May) and rainy season (June to October). I'd assume even nonsensical categories like Category:Autumn in the Philippines also exist. JWilz12345 (Talk|Contributions) 23:35, 4 July 2026 (UTC)

Agreed, seems pretty nonsensical to me. It is mildly funny to see that "winter" necessarily includes sleds (i.e. bobs): Sleds in the Philippines is for some reason part of winter. Funny thing, even Sleds in the United Kingdom looks pretty different from what I expected.

I'd suggest you make a CfD for Seasons in the Philippines with your objection; then create two new seasons and (re)categorize images accordingly. --Enyavar (talk) 09:00, 9 July 2026 (UTC)

Dance by location

For files in the subcategories of Category:Dance by location, which use "of" (e.g. Category:Dance of Estonia), are they meant to be categorized by the origin of the dance or by the location where the dance was filmed? So e.g. if I film a traditional Chinese dance being performed in France, should that go under Category:Dance of China or Category:Dance of France? Sdkb ^talk 17:48, 5 July 2026 (UTC)

Category:Dance of China for sure; I'd consider Category:Dance of France (or something even more geographically specific) if the performers were French residents, but probably not if it were a visiting Chinese troupe. Also almost certainly Category:Chinese culture in France or some subcat of that (e.g. there are specific subcats for Dragon and Lion dances in France). - Jmabel ! talk 18:13, 5 July 2026 (UTC)

If we find that to be the consensus interpretation, I would strongly recommend adding something to the category description page(s) to document it and remove the current ambiguity. Sdkb ^talk 20:28, 5 July 2026 (UTC)

Might it be helpful to create a separate hierarchy for "Dance by culture" and move a lot of the current by-location categories into it? This would also help split up messy categories like Category:Dance of the United States, which encompasses everything from square dance to hula. Omphalographer (talk) 00:03, 6 July 2026 (UTC)

1. Both of those are dance forms of the United States with folk origins, albeit from very different regions.
2. For those dances, the origins are pretty clear (though Henry Ford's popularizing of square dance and the various more commercialized knock-offs of hula dancing make it a bit trickier). But in other cases, it's going to be hard to say whose culture originated a particular dance form. Consider the hora (national dance of both Romania and Israel), or classical ballet (starts in France, but some of what we now take for granted is definitely Russian), or for the complicated mix if African, African-American, and European dance forms in the history of social dance of the United States. - Jmabel ! talk 02:40, 6 July 2026 (UTC)

• Categories "(activity) of (place)" indicate cultural origin. Categories "(activity) in (place)" indicate location where it is happening. -- Infrogmation of New Orleans (talk) 20:38, 6 July 2026 (UTC)
  • While cultural origin is sometimes very clear, at other times it is very fraught (see examples in my 02:40, 6 July 2026 remark, to which I would add things like polka in Mexico, Mexican vs. Colombian cumbia, etc.). - Jmabel ! talk 03:43, 7 July 2026 (UTC)

    I definitely take the point that defining cultural origins of a dance can be fraught. At the same time, it's often a more defining element of a dance media file than where it was performed (e.g. I care more that it's a dance of Chinese origin than I do that it was performed in France). Sdkb ^talk 05:42, 7 July 2026 (UTC)

    Then what happens with dance (or any other activity) that has no clear-cut national/ethnic/cultural reference (rave parties)? Or when the historic origins are too distant or uncertain (waltz)? IMO, 'by location' is just this, where it happened, regardless of any cultural/ethnic/national connection. Retired electrician (talk) 10:47, 8 July 2026 (UTC)

    Ultimately, I'm a little less concerned with what approach we take with the category than that we choose an approach, document it, and stick with it. The current status quo, in which different editors are using different approaches, makes these categories all but worthless because it's unclear which type of information they're conveying. Maybe we need an RfC? Sdkb ^talk 15:41, 8 July 2026 (UTC)

Creating category redirects at scale

I recently encountered a situation that I'm guessing will be familiar to others. I was trying to tag a traffic circle in Italy, so I searched for a relevant "Traffic circles in Italy" category. It didn't appear to exist, but I was able to tag the image with a broader "Traffic circles" category. Clicking through to that, I discovered that the category is actually located at "Roundabouts", with a suitable "Roundabouts in Italy" subcategory. Wanting to pave the path, I went ahead and created a category redirect from Category:Traffic circles in Italy to help out the next editor. But this same issue probably still exists for the roundabout subcategories of most other countries. What I really want to do is create a category redirect from every instance of "Traffic circles in [Country]" to the corresponding "Roundabouts in [Country]", ideally by specifying something programmatically so that future "Roundabouts in [Country]" categories will also have the incoming category redirect created as soon as they are created. Do we have any mechanism for this? Sdkb ^talk 22:26, 5 July 2026 (UTC)

If we have a mechanism for this m, it would also be really helpful for animal (and plant) categories because they often use the Latin name of the animal, but people really want to just categorize by writing Category:Foxes in the United States instead of Category:Vulpes in the United States, and somewhere down the line categories just switch to using the "common name" of the animal anyway without a category with the Latin name (for example Category:Foxes in art of the United States vs Category:Vulpes in art of the United States) and you never know at what point that switch happens. Would be great to just have redirects for all instances of Vulpes=Fox in category names. Nakonana (talk) 16:51, 7 July 2026 (UTC)

The problem is Vulpes and foxes are not synonyms. Most of what we call foxes are Vulpes, but the grey fox, for example, is no more closely related to true foxes than wolves. Making them synonyms just encourages people not to be correct about that.--Prosfilaes (talk) 02:59, 8 July 2026 (UTC)

I understand the reasoning. But we're really not very consequent about the accuracy in category names as my above example shows. And a lot of people would probably not know what fox (or non-fox) they actually photographed and just end up being confused that "Category:Foxes in the United States" doesn't exist when they try to add categories to their photo. Nakonana (talk) 15:57, 8 July 2026 (UTC)

i too often have trouble with such cats (spelling s vs z e.g. organisation organization; cat:2022 in Rome vs cat:Rome in 2022...).

i think there are two layers of solutions:

1. create all redirects as one-off operation
2. actively check for new targets for new redirects after the one-off operation

i dont think the solutions are difficult but just need someone to code them up.

using regex, make a redirect format and a target format, e.g.

target: /Organizations of (.+)/

redirect: Organisations of $1

for every target that is matched, create the redirect. RoyZuo (talk) 17:58, 9 July 2026 (UTC)

there's another problem plaguing any solution for redirects.

Category:Companies based in the United States is self explanatory.

many users are actively undermining the convenience which creating redirects brings to category exposure tools (upload, hotcat, catalot...). RoyZuo (talk) 19:58, 9 July 2026 (UTC)

Final reminder: Wikimedia Commons Pre-Conference at the Wikimania 2026

This is a final reminder about our Wikimedia Commons Pre-Conference at the Wikimania in Paris on July 21. If you want to join the pre-conference, please sign up on this page until July 7. Participation at the pre-conference is also possible without a ticket for the Wikimania. If you sign up before the deadline on July 7, you will get free access to the pre-conference day. Unfortunately, online participation will not be possible.

If you have something you want to present or you want to talk about at the pre-conference, please add it here, also until July 7. See you in Paris! GPSLeo (talk) 15:58, 6 July 2026 (UTC)

African American cosmetics

I'm surprised that we don't seem to have a category for cosmetics made for the African American market, nor can I readily find any significant number of such images. I'm wondering if I'm just missing something. I recently uploaded File:La Jac Face Powder.jpg and placed it in Category:Cosmetic industry in the United States and Category:African American culture for want of a better category along these lines. Thoughts? - Jmabel ! talk 01:50, 8 July 2026 (UTC)

Other countries than America have cosmetics for dark skins, like Africa or Germany, and people who are not African have "non-white" skin colour, so the "market" is poorly described this way. "Cosmetics for POC" might be a useful category? These categories do not exist yet.

Commons struggles with the use of English which is not Americanocentric, it's worth staying alert to that bias, especially where there is any relationship to American ideas about "race" - these are not universal. --Fæ (talk) 08:12, 8 July 2026 (UTC)

The market is perfectly described this way. There are a set of products, sold primarily in the US, that are targeted at the African American market. They probably have little overlap with products sold in Africa or Germany.

On the other hand POC and "non-white" skin color are terribly Western ways of looking at things, basically boiling down to lumping people as European and non-European. The Japanese don't see themselves as POC. Lumping things into white skin care and POC skin care is unlikely to reveal anything deep.--Prosfilaes (talk) 10:48, 8 July 2026 (UTC)

Yeah, we don't have specific categories for cosmetic products for the "Caucasian" or "Far Eastern market" either, so that having a category for POC cosmetics might be strange because it implies that non-POC is the norm, and POC cosmetics is the unicorn that requires a separate category.

Wouldn't it make more sense to just have categories for powder by color/tone or something? Because non-white-skinned people also exist outside the US, and why would Germany not have powders and foundations for them? And why would such products in Germany not come from the US brands Maybelline New York or NYX Professional Makeup or some other US brand? Nakonana (talk) 16:38, 8 July 2026 (UTC)

Beginning in roughly the early 20th century there were a small set of brands in the U.S. making cosmetic and hair care products specifically for the African American market.Into at least the 1960s most of these brands were made by distinct companies that targeted exactly that market, although increasingly since then the same cosmetic industry giants that sell to other ethnicities and other countries have entered this market. Wikipedia has articles on quite a few of these brands and companies, mostly with few or no images. Several of these brands were founded and owned by African Americans (e.g. the Overton Hygenic Manufacturing Company and probably most notably the Madam C.J. Walker Manufacturing Company, whose founder became the country's first African American woman millionaire). Interestingly (at least to me) most of the remainder were founded and owned by Ashkenazi Jews (e.g. Keystone Laboratories, Valmor Products Company).

Although a number of these companies also sold products in the Caribbean area, this industry was certainly distinct from cosmetics industries elsewhere in the world that marketed to people with similar skin colors. These companies and products were part of African American culture, for which we have a longstanding category Category:African American culture, which has had a subcat Category:African American hairstyles for over a decade, but which has lacked any subcats specific to cosmetic and hair care products. I'm guessing from the above that the relevant category(-ies) simply don't exist, rather than having the wrong parent categories. It also looks like we are very short on images of such products, even though we have plenty of photos of U.S. cosmetic and hair care products that marketed primarily to white people. I'll be creating a couple of relevant categories. - Jmabel ! talk 20:01, 8 July 2026 (UTC)

This still seems arbitrarily Americanocentric. Here's some counter examples that challenge the idea that "African American" is the way to describe these products or the culture. Pat McGrath Labs (UK) specializes in make up for black women, founded by Pat McGrath a British black woman made Dame of the British Empire for "services to the Fashion and Beauty industry and Diversity". UOMA Beauty, created by Nigerian Sharon Chuter, died last year, and remains black owned and retails in multiple countries. Black Up, based in Paris and specializing in make up products for black women. None of these are American, none describe themselves as founded for or by African Americans. Fæ (talk) 12:12, 9 July 2026 (UTC)

I'm sure there are similar products for Africans and for the African diaspora in quite a few countries (though I do actually wonder if there were any on an industrial scale outside the U.S. in the first half of the 20th Century (maybe in Brazil?), and I wonder if we have content on Commons relating to those). But, again, until the relatively recent consolidation and internationalization of the cosmetics industry, I'm pretty sure these would all have been distinct national or regional phenomena. African-American culture and (for example) Afro-Brazilian culture are obviously both African diasporic cultures, but for centuries they had little influence on one another, up to a time in living memory. - Jmabel ! talk 19:58, 9 July 2026 (UTC)

Say it in your language!

Hello everyone,

As part of Wiki Indaba 2026 (Abidjan, November 13–15), the organizing committee is launching a call to all Wikimedia communities across Africa and beyond.

Say it in your language!

We invite every community to record a short video (1 minute maximum) in which a member says the Wiki Indaba 2026 theme in their local language:

“Africa’s Future: Knowledge Equity and Innovation”

All submitted videos will be edited together into a collaborative pan-African video celebrating the linguistic and cultural diversity of the Wikimedia movement.

• Maximum 1 minute

Submit your video here

⏳ Deadline: July 20, 2026

Please share this call within your communities! 🙏

Wiki Indaba 2026 Organizing Team — Wikimedia Côte d’Ivoire x WisCom Abiba Pauline (talk) 13:06, 8 July 2026 (UTC)

Crosses: buildings or not?

Hello.

I'd like to know if Crosses (cemeteries, waysides, ...) are buildings. Some says they're not because building means something with walls, roof, ... and other says it is because they have been built.

For me they have been constructed so they may be in buildings' cats.

Hope you understand what I mean, English isn't my mother language.

Thanks for your advices. LW² \m/ ^{(Lie ² me...)} 21:33, 8 July 2026 (UTC)

@User:Llann Wé²: I moved your topic from the VP talk page, it was misplaced there. Regards, Grand-Duc (talk) 21:39, 8 July 2026 (UTC)

I would put them in structures categories, but not buildings categories. At least in American English, "building" means a structure specifically for humans to be inside. Pi.1415926535 (talk) 23:33, 8 July 2026 (UTC)

Agree with Pi.1415926535. There are some marginal cases: follies and mausoleums, for example. Our categorization calls both of these buildings, but I suspect there has never been a clear statute or a clear legal judgement of that in most countries where it would matter under copyright law. - Jmabel ! talk 01:37, 9 July 2026 (UTC)

Thank you @Grand-Duc, but I haven't been notified... LW² \m/ ^{(Lie ² me...)} 22:54, 9 July 2026 (UTC)

@Pi.1415926535, @Jmabel, thanks for your opinion. I think it'll take a very long time to correct thousand cats... LW² \m/ ^{(Lie ² me...)} 22:54, 9 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)

Ombudsman?

Out of curiosity, is there any wmf wiki that has a designated page for discussing/reporting users holding advanced permissions (sysop+) conduct? One that lets users speak generally freely?

On commons there's Commons:Administrators' noticeboard/User problems but that's for reporting any user about any problem. RoyZuo (talk) 21:26, 9 July 2026 (UTC)

Yes, DE-WP at least: de:WP:AP ("Administratoren/Probleme", literally "Problems with administrators") and maybe also de:WP:AWW (a page where, pending certain quora, admins can get a request to open a re-election process or lose their rights). EN-WP has a robust ArbCom. And most projects would allow free discussions as long as the tone conforms to the Wikimedia Foundation Universal Code of Conduct, won't they? Regards, Grand-Duc (talk) 23:27, 9 July 2026 (UTC)

Copyright violations

Hi, There are more than 1000 files without a license waiting for review (not counting the hundreds I have already deleted). Most of them are copyright violations, the rest is often out of scope. Honestly, I am a bit fed up by people endlessly arguing for deletion for very unlikely issues, while nobody seems to care about real issues. This must change. Yann (talk) 09:07, 10 July 2026 (UTC)

at a quick glance many in Category:Files with no machine-readable license are User:Dominic's dpla files that got into the category after all data transitioned to com:sdc.

probably something needs to be done on the template or on the way machine readability is tested.--RoyZuo (talk) 10:55, 10 July 2026 (UTC)

What a great example of how using SDC can screw things up. The page.text is blank, and standard Commons tools like VFC can't check basic stuff like the date of publication. So documents there published in the USA in the 19th century need manual intervention to fix. Sorry, this is what you get when SDC obsessives get free reign. There's no way we should waste volunteer time like this. It may seem harsh, but a mass deletion would not be out of the question. Fæ (talk) 13:14, 10 July 2026 (UTC)

@Dominic: , the DPLA bot made changes like this which stripped the page text off, deleting the Artwork template and the PD-US licence that was previously embedded and easily verifiable by loading the text. This appears out of policy for bot use, and has resulted in a pointless manual backlog.

Please revert blanking of text pages by the DPLA bot, unless there is a credible community consensus that pages on Commons can be blanked in this way, and consequently there is no requirement for license templates. Thanks Fæ (talk) 13:29, 10 July 2026 (UTC)

@Fæ: This is not about the "blanking"; all the copyright information is still there in the SDC, and there are over a million DPLA files with proper licensing rendered in this way. It appears that Module:License does not like when copyright has multiple values it sees as conflicting, so I am fixing it in Module:DPLA. To note, an image going in this maintenance category does not notify to the user, and this is the first I have been made aware. Any DPLA files should be fixed as soon as the bot finishes manually purging them, if not sooner. Dominic (talk) 14:15, 10 July 2026 (UTC)

Thanks for responding so quickly. There is no consensus to delete license templates from Commons collections in this way. The SDC FAQ does not say this should be done, and I have not found a policy with a consensus that basically says that text pages can be deleted and tools have to be rewritten to navigate SDC properties. Unless you or someone else can demonstrate that a community consensus supports removing license templates, all these changes should be reverted. Fæ (talk) 14:19, 10 July 2026 (UTC)

BTW, to clarify Module:License is in an "alpha" state. It is described as being ready for testing on a few pages, not millions.

Please establish a credible consensus before rolling out millions of changes in this way. Fæ (talk) 14:23, 10 July 2026 (UTC)

I found 700 files that had landed in this category, out of, as you say, about 1.5 million, which is a tiny proportion. I then fixed it by adding a fallback mechanism in template for this rare case, within an hour of being made aware. You have made claims about volunteer hours being wasted, and seem mad about SDC in general. I just want to clarify:

• We are only touching our own uploads, or uploads of our partner institutions' collections, not rolling something out across Commons generally. The "blanking" you are claiming is DPLA editing its own template parameters.
• Some of the data needs to be overwritten for a good reason. This project maintains some images uploaded across time, some as old as 10 years ago. We are very glad that SDC and Lua now allow us to keep the data in sync, because we are finding many cases where IDs, URLs, and other metadata has changed over the years, and this sync method, which is only realistiacally possible via SDC, allows us to ensure the accuracy of data and, in many cases, fix link rot and broken IDs. This is a net value, and is much better, in terms of volunteer resources, than attempting to maintain 10 million images' wikitext parameters by hand as they gradually drift out of sync from the source.
• License templates are not being deleted. They are just being emitted by code nested within another template. The general principle of relying on Lua-based templates to emit data not stored directly in the page wikitext is standard practice on Commons, not just limited to this use case, but others (like {{Artwork}}'s own extensive use of Wikidata. Moving a template parameter value to SDC and then using Lua to display the value is functionally not "deleting" anything.

At this point, I think this has taken over Yann's thread in a way that is no longer related to the original backlog concern, but I am happy to carry on the conversation elsewhere. Dominic (talk) 14:53, 10 July 2026 (UTC)

Checking with elastic search, there appear to be around 1.5 million files that use {{DPLA metadata}} in this way and may have no valid license template. A sample check shows that they can be reverted to earlier versions with the Artwork template correctly in use with license templates. Fæ (talk) 13:57, 10 July 2026 (UTC)

These have valid licenses. The template incorporates the pre-existing License module to emit the correct license from the structured data. Dominic (talk) 14:23, 10 July 2026 (UTC)

There is no consensus to blank text pages and remove valuable basic information like licenses, dates, source links and "hide" them in SDC fields which are effectively invisible for many Commons tools and maintenance tasks. Please revert these changes. SDC fields are supposed to be easy *additional* information, not replacements for everything useful on Commons.

Just to reiterate as you appear to be ignoring this fact, there is *no consensus* for these changes.

For others not getting what this means, a maintenance task writing in Pywikibot can grab information like categories or dates in the text by using a simple query like "page.text" and searching the text. What is proposed here would break all such tools, and in the example above the page literally just returns == {{int:filedesc}} ==\n\n{{DPLA metadata}}, which is equivalent to leaving Commons with blank image pages. Fæ (talk) 14:40, 10 July 2026 (UTC)

maybe the tools should learn to read sdc instead of the messy wikitext?

we need better sdc editing tools, but the lack of them should not hold users back from using sdc more widely. RoyZuo (talk) 15:16, 10 July 2026 (UTC)

You'll note that the basic issue of a lack of any consensus for this mass change. That's not sensible to ignore because a few SDC advocates like the system, even though it appears that it's not maintained and may not be in Commons' long term future. As a tool creator and very large collection uploader, my projects never will use or rely on SDC, though it's fine to use it to *add* information in this format, however it's damaging to delete perfectly valid information from the image pages, as is being done in these examples of a few million images. Fæ (talk) 16:38, 10 July 2026 (UTC)

Which browser (in which os) is most suited for editing and browsing wmf websites

including but not limited to commons, wikidata, wikipedia, wiktionary...

i'm curious if anyone has a preference for certain browsers and why. how does it make you more productive, your workflow smoother, etc.?--RoyZuo (talk) 10:55, 10 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)