This page is used for discussions of the operations and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2026/05.
Please note:
If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.
Purposes which do not meet the scope of this page:
For questions about copyright, technical matters, or help that does not relate to the general Commons community as well as proposals, please see the other discussion boards linked in the blue panel at the top.
SpBotarchives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.
January 02
History maps of Europe
Latest comment: 3 months ago6 comments4 people in discussion
Hi, I would like to discuss the description in all categories of the scheme "Maps of <country> in the <x>th century" (see for example Italy, Belgium, Spain, Poland). There are three different points about the current system I would like to invite comments on:
the wording of the definition in the first paragraph of the hatnote
whether or not to include "you may also be looking for similar maps" (second and third paragraph) of the description
whether or not to re-include a distinction between history maps (in this category group) vs. old maps (not in this category group)
For the first point, there are two proposals, the first is the current "Maps showing all or most of the territory (geographic area) of modern-day <country> - as the lands were in the 8th century (701-800 CE)" which I would prefer to replace with a simple "This category is about maps of the history of <country> in the 8th century (701-800 CE)", given that "modern-day territories" are not always the same as they were in the respective century. Another critism of mine is that "all or most" excludes history maps that only cover smaller parts of the country in question.
For the second point, my argument is that these paragraphs are not necessary, since the links to the Atlas project should be included in the respective parent category (i.e. "Maps of the history of <country>"), which is also linked via template.
For the third point, I find it essential to point out that Commons has always distinguished "current", "history" and "old" maps, formulated in Template:TFOMC: "history" maps include this map of Poland in the 16th century (created recently, depicting the past) but "old" maps include this 16th-century map of Poland (created to depict the present, back then). There are certain grey areas where these categories DO overlap, especially "old history maps", but in quite many cases they don't. The respective category names are quite similar and can be confused, so I would suggest to mention this right in the category description.
I've put my own opinion in italics to explain why I think this requires debate, but I would like for people to check out the scheme examples for themselves, and judge on their own. Peace, --Enyavar (talk) 08:11, 2 January 2026 (UTC)Reply
@Enyavar: I'm trying to understand the first point. A couple of questions that may help me understand:
Would there be no such thing as "maps of Germany" for any date before 1866? Or would we take "Germany" before that date to mean the German-speaking world (and, if so, would that include areas where the rulers spoke German, but most of their subject did not)? or what? (Similarly for Italy.)
Similarly: would there be no such thing as maps of Poland or Lithuania between 1795 and 1918? If so, what would we call maps of that area in that period?
I could easily provide a dozen similar examples, but answers to those two will at least give me a clue where this proposes to head. - Jmabel ! talk18:49, 2 January 2026 (UTC)Reply
Thanks for that question, our categories about "history of" do not really care for nation states existing. Germany's history begins quite some time before it became a nation in the 19th century, and Polish history did not stop during the times of division: Poland in the 19th century is unquestionably a valid category. Our history categories generally imply that people know the limits of a subject without exact definitions.
Your question is getting to the reason why I am uncomfortable with the current hatnote/definition of these categories. I have not checked for all countries in Europe, but I'm quite confident: We do not define the subject of "Maps of the history of Poland" with a hatnote. We do not define "Poland in the 16th century" either. So why would we define the combination subcategory of the two so narrowly and rigidly, that only 6 out of 26 files currently in the category even match that (unreasonable) definition? (And of course, Poland/16th is just a stand-in here, I would argue the same for Spain/12th and Italy/8th and all others)
I would even be okay with no definition at all, besides a template notice (my third point) that "maps of <country> in Xth century" is about history maps, and old maps have to be found in "Xth-century maps of <country>". --Enyavar (talk) 04:53, 3 January 2026 (UTC)Reply
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.
In our Commons:WikiProject Postcards we have the similar problem. Is this a "old postcard of the German Empire" or a "Postcard of Germany". There we are mostly agree, that today people often search for postcards be the locations of today. So many former German towns are now Polnish towns and so we are categorized this postcards under the polnish name of the town. See also Commons:WikiProject_Postcards#Categories. Best regards --sk (talk) 12:29, 12 February 2026 (UTC)Reply
February 22
Maps from Our World in Data
Latest comment: 2 months ago30 comments7 people in discussion
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.
As with other files in these categories, that's the year of the data. This categorization has large usefulness to find and update outdated images used on Wikipedia. And the category title does not imply that's the year the map was made. Prototyperspective (talk) 20:13, 22 February 2026 (UTC)Reply
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.
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)Reply
Sure we can adjust the categories however folks wish. We have additionally build a tool to help with more fined toned mass categorization. See Help:Gadget-CategoryBatchManager.
With respect to numbers, yes have uploaded about 600K so far and it looks like I am maybe a third done, so maybe 1.2 million more to go. Will likely not finish until this fall. Doc James (talk · contribs · email) 06:03, 25 February 2026 (UTC)Reply
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)Reply
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)Reply
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.
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)Reply
[[: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)Reply
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)Reply
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)Reply
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.
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)Reply
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.
I fixed "the world" (ooh, it feels good to write this ;-))
It is generally true that the template works best when the categories are created top down (i.e. first the centuries, then the decades, then the years). Still the navigation ribbons should appear even if the parent category does not exist (yet), I will have to investigate why they don't. But for the addition of the correct parent categories for new categories, it is important anyway that the parents pre-exist.
I have (years ago) thought a lot about the question of logical sort keys, currently they are used very inconsistently across commons. I've even made a page summarizing my thoughts which you may or may not agree with. About this specific case, I think the space is widely used for meta categories (Blah blah by xyz) and should be reserved for that, and that the @ has the advantage of being sorted after all the other special characters, so if for example the category key "*" is before the alphanumeric subcategories, it is also before the numeric subcategories if the numeric are sorted as @. In the end I don't think in our case it makes much of a difference as long as all the subcategories use the same key so they are sorted correctly - which is taken care of by the template.
About the "Maps of Oceania in 1947", would you want to also create them right now? Should I create a {{Category description/Maps by continent and year}} (and decade and century), and adapt the OWiD templates to the new parents?
I don't use a bot, and I think that the CategoryBatchManager can add parent categories, but not a template. But since you don't have to change a single letter when copying the template from one category to a similar one, it can be done very fast. --Reinhard Müller (talk) 18:02, 8 March 2026 (UTC)Reply
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)Reply
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)Reply
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)Reply
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
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)Reply
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 ! talk20:53, 8 March 2026 (UTC)Reply
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)Reply
Latest comment: 2 days ago32 comments10 people in discussion
This proposal has been re-drafted endlessly. It's difficult. Before I actually put this up on COM:VPP I'm sharing it here in case it contains serious flaws.
As it would affect a longstanding policy I intend to request a project wide banner to make the user base aware of the proposal.
The current draft:
Misleading and misinforming content
Works where a reasonable person is likely to make incorrect assumptions about its provenance when only looking at the work (not the file page or file name) [Note 1] are not acceptable.
Visual works that were modified using AI tools (e.g. restoration) can not be acceptable unless:
It is ensured by an experienced user that the AI did not add artificial details outside of areas that had to be filled like creases or watermarks.
The unmodified original is uploaded alongside the modified file.
Details of any AI tool use are detailed on the file page.[Note 2]
Human-modified visual works that misrepresent the original are not acceptable.
Works where the educational value is in the misinformation and optical illusions are exempt.[Note 3] Files can be cured by superimposing information that declares the provenance[Note 4], provided that it is legible at the default thumbnail size.
Footnotes
↑Like mistaking an AI-generated image for an actual photograph or historical artwork. This does not affect generic drawings and paintings where a reasonable person would not attribute them to a particular author or studio.
↑For example in the upload comment, using {{Retouched picture}} or (if available for the tool/operation in question) categories.
↑Will Smith eating spaghetti is an example which was covered by multiple news outlets. Another example would be a well documented art forgery. This does not extend to AI-generated/modified works made by Commons users to demonstrate flaws of AI, those should be cured with superimposed provenance.
↑The language of choice should be appropriate for the intended audience of the file. For AI-generated works the initialism "AI" is always sufficient. For files uploaded before $proposal_acceptance_date there is a grace period until $proposal_acceptance_date+1_year to allow uploaders and projects to make their files compliant or upload them locally.
localized imperfections I'm not sure "localized" is the key. Maybe "specific identified"? For example, I could imagine a good AI based tool to deal with despeckling, half-toning, inadvertant moire, etc., certainly one at least as good as "conventional" tools for this in Photoshop or GIMP. - Jmabel ! talk21:56, 17 May 2026 (UTC)Reply
definitely better. Wondering about "which are detailed on the file page". Seems to me that things like removal of a watermark aren't usually noted on the file page when done by any other means, unless you count the upload comment for an overwrite as a "mention". I don't see why doing it with AI would require different handling. The two images are still there to compare, and if it had other side effects then it is a bad job and should be reverted. - Jmabel ! talk01:05, 18 May 2026 (UTC)Reply
Jmabel, when a human does it there are typically no severe side effects. With AI, unless it's tailored to that specific purpose, it's guaranteed to mess it up. If it's not detailed on the file page we wouldn't be aware that we should check. For anyone who's unaware: when you say "fix red eyes in the image", non-tailored AI doesn't desaturate a few pixels. Oversimplified: it converts the image to "George Clooney wearing a blue-brown vest with round buttons at sundown facing the camera dreamy look with red eyes and baseball cap yada yada yada", removes the "with red eyes" part as per your instructions and uses that prompt to render a new image. I once asked Bing to remove the black fat bike from File:Police bicycle in 2025 in the Netherlands side 1.jpg. And upon my request, Bing did pinky promise it wouldn't change any pixels that didn't belong to the fat bike. Then it mangled the police bike, turned all the signs into gibberish, converted the w:Albert Heijn logo to "a1" (if you squint the AH logo does look a little like "a1"..), made modern art out of the bike rack that passed through the shop window, moved the walls, changed the lighting, and so on. Bing has not been a good Bing and I gave it a good spanking. If everybody complied with all the rules, you'd be right. In practice it's more messy, and given AI's predisposition to messing up, redundancy is not a luxury. Some users will forego the review by an experienced user, some will skip the superimposed information, some will omit their prompt from the file page. Compare with gun safety: some rules will be broken, but you generally must break more than one to have an accident. For example, when you holster a handgun it's pointing at your feet, but you should never allow the muzzle to point at something you're not willing to destroy. If you follow the rule of not putting your finger on the trigger until you've made the decision to shoot, your feet will be fine. - Alexis Jazzping plz09:09, 18 May 2026 (UTC)Reply
@Jmabel: I've changed the second point per you and GPSLeo, but I don't see a way to differentiate between non-tailored AI and AI tailored to a specific purpose. Even when it is tailored, quality will vary. This would require maintaining a whitelist of acceptable AI tools. - Alexis Jazzping plz16:44, 19 May 2026 (UTC)Reply
This is not a review comment, but I would create a new section at Commons talk:Project scope to discuss this, or even a new RFC page, rather than VP and VPP. I think it's better to use a dedicated discussion space when you anticipate a big discussion than a discussion space for miscelleneous topics. (We can use VP and/or VPP to advertise it, though, but if you are planning a sitenotice, that alone might be enough.) whym (talk) 23:04, 17 May 2026 (UTC)Reply
@Whym: , there was one singular RfC in 2025 and it has 2 whole comments. RfCs aren't used much on Commons, it seems. But with a sitenotice and VP/VPP notices an RfC may indeed be better. A sitenotice would be appropriate in my opinion as this proposal would affect basically all Wikimedia projects. - Alexis Jazzping plz23:27, 17 May 2026 (UTC)Reply
A few comments:
What is the point about "human-modified visual works that misrepresent the original" meant to accomplish?
In footnote 1, can we add something to the effect of "an actual photograph or a piece of historical artwork"? I've seen the latter a number of times.
Footnotes 2 and 3 should be rolled into the text of the bullet point and made more clear.
In footnote 4, the "does not apply..." language seems unnecessary. Some projects legitimately use user-generated AI images to illustrate AI errors, like File:AI generated woman with extra legs.jpg; I don't see any compelling need to prohibit that.
Thank you for your suggestions! What is the point about "human-modified visual works that misrepresent the original" meant to accomplish?
Essentially codifies cases like Jan Arkesteijn's block into policy. He claimed until the very end he had no idea why he was being blocked.
Footnotes 1, 2 and 3: done.
I don't see any compelling need to prohibit that.
It wouldn't be. The draft has three bullet points, only the first applies to images generated out of thin air. No reasonable person would be confused about the provenance of File:AI generated woman with extra legs.jpg as her anatomy is really impossible. This also isn't meant to apply to AI-drawings, watercolor paintings and the like. For example this drawing (if it was in use) isn't meant to be targeted by this as a reasonable person wouldn't mistake it for a Vermeer, work from Studio Ghibli or a photograph. The language of footnote 4 (now footnote 2) would only apply to demonstrations of more subtle errors, like a hand with six fingers which is actually plausible. Such images would still not be prohibited, they would only have to be cured with superimposed information to avoid invalidating its COM:INUSE defense. - Alexis Jazzping plz10:04, 18 May 2026 (UTC)Reply
I would change the second point. The current formulation does not cover the core problem well. I would simply say: "Images modified using AI tools, if it is not ensured that they did not add artificial details." This makes clear that edits like de-noising with suitable tools are not a problem. GPSLeo (talk) 06:17, 19 May 2026 (UTC)Reply
@GPSLeo: when you remove watermarks/creases/etc you essentially always introduce artificial details, regardless of method. I've reworded it, is this better? I'm saying "visual works" instead of "images" because AI does video too. - Alexis Jazzping plz16:44, 19 May 2026 (UTC)Reply
I don't fully understand all implications of this proposal and of where the proposed insertion is going to be. Does this mean that provably misleading/false/forged files could be subject to deletion? If so, I could support this, I have long combatted fraudulent productions - not so much fake photos, but faked graphics. --Enyavar (talk) 21:06, 19 May 2026 (UTC)Reply
Example of superimposed provenance@Enyavar: Good point! As the intention is for these new rules to be able to override COM:INUSE I thought they should be added under that section, but that would have been a mistake. The draft has been adjusted accordingly. Some implications:
Examples at w:AI upscaling would require superimposed provenance.
Anything photorealistic that COM:AIP disapproves of would be automatically out of scope, even if INUSE, unless provenance is superimposed. (may still be deleted for other reasons, like being an unused non-notable artwork)
Nothing happens to w:Madame Tussauds. A reasonable person may make incorrect assumptions about the provenance, but that's also where the educational value lies.
Nothing happens to File:Jesus Trump.jpg as it was covered by various news outlets, and even it hadn't been, nobody would be confused about its provenance. Everybody knows Trump is not a doctor.
Your unmodified original is uploaded alongside requirement here differs from COM:AIIP which currently permits a milder or by linking to the external source option. I'm not sure on the figure, but a lot of images in Category:Upscaling (such as upscaled YouTube stills) do not include an unmodified copy on Commons. Belbury (talk) 15:28, 22 May 2026 (UTC)Reply
Belbury, considering the prevalence of linkrot that's a flaw of AIP that shouldn't be repeated in this proposal. a lot of images in Category:Upscaling (such as upscaled YouTube stills) do not include an unmodified copy on Commons. That's an absolute shame, but strictly for this proposal in its current form it wouldn't matter. AI-upscaling, unless cured with superimposed provenance, is not acceptable. No matter if the original is uploaded or not. Uploading the original only helps (in the sense of not needing superimposed provenance) if an AI-tool was used for something other than upscaling (for example watermark removal), checked by an experienced user, the AI-tool use is detailed on the file page, and the unmodified original is uploaded. Note that non-AI upscaling isn't affected in any way. - Alexis Jazzping plz16:20, 22 May 2026 (UTC)Reply
Oppose This is unrelated to COM:INUSE. If an image is in use in another project it's on scope. If the image is wrong on some account it should be marked as such in Commons or it even can be removed from categories, but it can't be deleted as out of scope without first it stopping being in use on the other project. This seems just another proposal aimed at making Wikipedias store locally the images they use instead of using Commons, as it was before Commons was created.--Pere prlpz (talk) 12:48, 21 May 2026 (UTC)Reply
Strong oppose Commons should not become an arbiter of what is "misinformation", "misleading" or sufficiently "factual". That is the role of the individual Wikimedia projects through their own content policies, sourcing standards and editorial processes. Commons should only concerns itself with copyright, licensing and basic project scope, and files that are legitimately in use on Wikimedia projects are, by longstanding principle, and should continue to be, in scope. --Jonatan Svensson Glad (talk) 16:51, 22 May 2026 (UTC)Reply
Josve05a, don't you think that ship had sailed when Ratify Commons:AI images of identifiable people as a guideline passed and COM:AIP became a guideline? Because several admins are now overruling COM:INUSE policy by referring to that guideline. In part, this proposal draft is damage control. One of its goals is to make COM:AIP partially redundant. The proposal draft above doesn't strictly ban any content as it allows anything to be cured with superimposed provenance. This way, projects can upload anything, no matter how abhorrent we think it is, as long as it's INUSE and (if it matches one of the bullet points above) has superimposed provenance. This relieves Commons from the burden of hosting the kind of misinformation that many users here object to. If another projects really wants to it could even use w:Template:CSS crop to get rid of the provenance in their local thumbnails! - Alexis Jazzping plz17:31, 22 May 2026 (UTC)Reply
@Alexis Jazz: COM:AIP is about legal and moral rights of subjects depicted. If admins were misusing it to delete images that don't affect legal or moral rights of subjects depicted, we would have a bigger problem.
@Alexis Jazz: No, I don't think that ship has sailed, and even if parts of it have, we should not accelerate it. The fundamental principle of Commons has long been that if a file is legitimately in use on another Wikimedia project, it is in scope. We are a media repository, not an editorial board or truth ministry for the movement. Individual projects (especially enwp) have their own policies on reliability, due weight, misinformation, and image use. That division of responsibility exists for good reason. COM:AIP was (controversially) passed specifically around legal/moral rights of identifiable living people in AI-generated images, i.e. a narrow carve-out. Using it (or this new proposal) as a general tool to delete or sideline files that are merely "misleading about provenance" or "potentially confusing" is a massive expansion. Many historical images, political cartoons, propaganda, satire, and restored works are in some sense "misleading about provenance" or altered. We have never required "superimposed provenance" labels before.
This proposal would put Commons admins in the position of constantly judging "does this look too much like a Studio Ghibli style?" or "is this upscaling good enough?", effectively encourage projects to host files locally again, and lead to endless deletion arguments about what constitutes sufficient "superimposed information".
If another project is using it, it should stay (barring legal requirements not to do so). If the content is misleading, the project using it should be responsible for context, captions, disclaimers, or removal. Not Commons playing upstream censor. If there are specific bad cases that are abusing COM:INUSE, let's address those narrowly rather than creating a broad new exception that weakens one of our core policies. (Please also note difference between a guideline approval and a policy change)--Jonatan Svensson Glad (talk) 18:05, 22 May 2026 (UTC)Reply
Many historical images, political cartoons, propaganda, satire, and restored works are in some sense "misleading about provenance" or altered. Those would generally be covered by the "educational value is in the misinformation" exemption. If you have specific examples that you worry wouldn't be covered by that, I could see if the draft needs to be refined further. Pere prlpz, Are admins using COM:AIP to delete images that don't affect legal or moral rights of the depicted subjects? Josve05a, passed specifically around legal/moral rights of identifiable living people in AI-generated images, i.e. a narrow carve-out.
@Alexis Jazz: You’re overwhelming the discussion with examples in what looks like bad faith. Yes, true legal requirements (copyright, privacy, personality rights of living people, etc.) override COM:INUSE. That’s not in dispute.
The problem is admins stretching COM:AIP — and now this proposal — to delete files that don’t actually break any law or moral rights, just because they dislike the “AI” label, “misleading” provenance, or “lack of education value”. Your pile of examples (Cleopatra, Napoleon, Tutankhamun, etc.) mostly fall into this category: pure editorial overreach on long-dead subjects.
Commons is a media repository, not the movement’s upstream “truth ministry” or provenance police. Individual projects are responsible for context, captions, and reliability. Forcing “superimposed provenance” on everything shifts us into content censorship.
This proposal guts a core policy (COM:INUSE), guarantees endless subjective fights (“Is this too photorealistic?” “Is the label big enough?”), and will drive projects back to local hosting. The “educational value is in the misinformation” carve-out is hopelessly vague.
If COM:AIP is being misused beyond actual legal requirements, fix that — don’t ram through an even broader exception for upscaling, historical reconstructions, satire and more.
Josve05a, you're calling it abuse (and I'm not gonna say you're wrong), but there doesn't seem to be anything that could realistically be done about it. A proposal to treat AIP as a guideline would be nonsense because that's what it is. Dragging admins to AN/U rarely ends with a lovely cup of tea. You voice concerns about this draft for a proposal while we're staring down the barrel of Special:PermanentLink/1220689243#Proposal: Promote Commons:Upscaling to guideline. Subjective fights aren't even the biggest concern, it'll flat out ban various perfectly acceptable practices, and this has been made clear, and users want it to become policy anyway because nobody has written anything better. Individual projects are responsible for context, captions, and reliability. Forcing “superimposed provenance” on everything shifts us into content censorship. Individual projects are not equipped to deal with this, especially the smaller ones. Any many, including enwiki, actually count on Commons to handle these kinds of things. They just assume that what we host is truthful. For text they require reliable sources, but they'll accept a photo taken by Joe Schmoe and documents he scanned and uploaded from his local library. If they have to question and review every single file, they might as well go back to hosting it all themselves. Some Wikipedians -especially on enwiki- are vehemently against transcluding information from Wikidata, specifically because according to them Wikidata can't get its vandalism and sourcing issues under control. Projects don't want to be belittled, you are right about that. But they don't want us to mindlessly host anything either. Maybe we should see what projects think about it all. Forcing “superimposed provenance” on everything shifts us into content censorship. I disagree. In this context, superimposed simply means in-image. That could also be achieved by adding a bar. Which a project technically could hide locally with CSS crop if they hated us. If you run an ad for a financial or medical product you generally have to include some sort of disclaimer. On food packaging you may be required to list the ingredients. To me, that's not really a restriction on freedom of speech. It's not prohibiting you from saying something. - Alexis Jazzping plz22:24, 26 May 2026 (UTC)Reply
@Alexis Jazz: Have you actually asked the wikis in question (like mgwiki or enwiki) what they want from us, or are you just making shit up? Drawings and AI images are made by us and not meant to be taken as real photos, but editors on projects like enwp can differentiate that themselves — we shouldn’t impose upstream ”superimposed provenance” censorship because smaller wikis might be lazy. I’ll abide by community consensus (of course), so I apologize if I come of as too strong, but this the only time I can express my deep dissatisfaction or highlight my interpretation of our policies and role. --Jonatan Svensson Glad (talk) 23:52, 26 May 2026 (UTC)Reply
Also, again. There’s a difference between a guideline and a policy. Policy is always “the highest authority” unless a guideline can shed light on a legal requirement. --Jonatan Svensson Glad (talk) 23:54, 26 May 2026 (UTC)Reply
Josve05a, Have you actually asked the wikis in question (like mgwiki or enwiki) what they want from us, or are you just making shit up? I remember this from a discussion that I probably had on enwiki. I don't know if I could find a link, it must have been years ago. If it would turn out I misremembered I would apologize, but I'm pretty sure. so I apologize if I come of as too strong, but this the only time I can express my deep dissatisfaction or highlight my interpretation of our policies and role. You accuse me of "making shit up". You're burning bridges. I was hoping you'd be willing to collaborate with me to write a better policy proposal, because the community is desperate for some kind of policy. But you disrespect me like this, for no real reason, I'd have expected better from you. Also, again. There’s a difference between a guideline and a policy. Policy is always “the highest authority” Yeah it is!! But if other admins are just going to ignore that and do what they want, guidelines are a higher authority than policy. - Alexis Jazzping plz03:05, 27 May 2026 (UTC)Reply
Josve05a, here's a very clear example of why we need this: Special:ListFiles/Thelezifor. This user uploaded dozens of AI-generated images and many are used on mgwiki, so eradicating all uses will be a considerable amount of work. Nobody on mgwiki looked at this and went "yeah that's totally fine and super educational!", they just didn't know. Which isn't too surprising on a wiki with 112 active users and two admins. When provenance is superimposed, at least those 112 active users have a better chance to spot the rubbish. If provenance isn't superimposed, CommonsDelinker will be doing them a favor. If we strictly follow our current policy we have to either host this crap or remove all uses from mgwiki (and potentially go to edit war with the uploader). - Alexis Jazzping plz14:02, 24 May 2026 (UTC)Reply
Commons is not there to editorialize mgwiki (nor enwiki or any other wiki, for that matter). If you think some user in mgwiki is abusing the system, go to admins there or to stewards, but don't delete images that are in use.
Oppose mostly per Jonatan Svensson Glad. Commons' primary purpose has always been to serve other Wikimedia projects, and we should be careful about restricting files that are COM:INUSE and legally unproblematic. @Alexis Jazz: I understand your point about COM:AIIP, but keeping the slippery slope fallacy in mind, I believe the line can be drawn there. The proposed language, especially at the policy level, is way too broad. I might support this if the language was softened a bit and proposed as a guideline instead, but we kind of already have a proposal for that. Phillipedison1891 (talk) 20:07, 26 May 2026 (UTC)Reply
May 18
LLM use in discussion
Latest comment: 2 days ago28 comments15 people in discussion
Support. The only time that someone should be posting a comment generated by some LLM or AI or ML tool is if that person is trying to communicate by translating. In that case, you should probably still post your actual material that you wrote alongside whatever an online translation tool posts to be safe. ―Justin (koavf)❤T☮C☺M☯22:46, 18 May 2026 (UTC)Reply
@Koavf: that presumes you are using the LLM-based tool for at least the bulk of your translation. I'll often use Google Translate in much subtler ways than that: e.g. to see if it can come up with a more apt word than I first chose for something where I'm less than confident, or to verify that my writing in a language where I am decent but short of fluent makes sense by translating back into English, etc. I could give other examples but the short of it is that often it would take two or three times as long to describe my process than it did to do the writing. - Jmabel ! talk02:18, 19 May 2026 (UTC)Reply
@Jmabel: Enwiki's policy says ...that are obviously generated (not merely refined) by a large language model or similar AI technology... Both of your comments here cover situations that would be clearly covered by "merely refined". Pi.1415926535 (talk) 03:29, 19 May 2026 (UTC)Reply
Support. I've seen a lot of LLM-generated comments in deletion discussions (typically by the uploader, opposing deletion), and not once have I seen one that coherently made a relevant argument. I have frequently seen them misstate (or outright fabricate) claims about project policy or copyright law. As Justin mentioned above, users who are not comfortable commenting in English should reply in their native language rather than using LLMs to construct messages for them. Omphalographer (talk) 02:30, 19 May 2026 (UTC)Reply
@Omphalographer: so should I stop attempting to help people on the help desk, etc., in their native language, and just write my replies in English or Spanish, the only languages in which I'm really comfortable? (N.B., I read several other languages well, including at the level of reading numerous books, but I don't express myself fluently, and more often than not need the assistance of translation tools for some word or phrasing.) I think that would be ridiculous. I've seen no signs I've gotten this wrong in any significant way in literally hundreds of times I have done this. - Jmabel ! talk02:37, 19 May 2026 (UTC)Reply
Perhaps I could clarify - users should not feel obligated to write comments in English, particularly if they must rely on a LLM to write a comment on their behalf. I would much rather read a user's own words - in any language, at any level of fluency - than some words an AI put into their mouth. Omphalographer (talk) 06:17, 19 May 2026 (UTC)Reply
@Omphalographer: absolutely, we are in agreement there. I'd much rather read good Spanish/German/Portuguese/French/Romanian (& a few others) than bad English, and for the rest I might as well run them through the translator myself. - Jmabel ! talk20:51, 19 May 2026 (UTC)Reply
Oh, I see. Well... too busy or preoccupied with Wikipedia and real-life stuff right now. I don't mind you going right ahead with page creation. George Ho (talk) 08:36, 19 May 2026 (UTC)Reply
Support LLM use should be banned in discussion. Google Translate is not concerned, but the original language should be included. Yann (talk) 08:38, 19 May 2026 (UTC)Reply
@RoyZuo: so now it cost you 20s, some water and electricity for ChatGPT, a bunch of investor money to fund the data center, insane DRAM prices for everyone, and then someone else has the misfortune of checking ChatGPT's work with a spreadsheet. This doesn't sound like a time saver. And ChatGPT got a failing grade because it can't do addition properly. - Alexis Jazzping plz15:53, 19 May 2026 (UTC)Reply
Summarizing the results of a discussion - especially a long and contentious one - is exactly the sort of task which I would never trust a language model to perform. They consistently perform poorly at this type of task; they frequently misattribute comments, focus on irrelevant asides, and reach "conclusions" which are irrelevant or based on (potentially loud) minority opinions. Omphalographer (talk) 18:34, 19 May 2026 (UTC)Reply
en:WP:LLMTALK leaves AI-refined comments alone, as pointed out above. Aren't the comments found in the section you linked too? Grandmaster Huon said this: "this was written with the help of AI, as it helps me articulate my statement". Or are you saying that they relied on LLM more than they said they did? I'm sure some don't like AI-refined, AI-assisted comments, too, and people can call it out on a case-by-case basis, but it seems that there is no consensus on enwiki to automatically invalidate them.[2]whym (talk) 11:26, 20 May 2026 (UTC)Reply
Oppose We should let people express themselves however they like, even if this includes using LLM. Then we judge on the basis of (and solely on) what they chose to post. Why wouldn't we? Why would we constrain how someone develops their post? Have we ever done such a thing before? Are we to police asking other editors for advice? For copying old posts about similar issues? Automatic translation tools? Why would we justify this new restriction on not only the thought they express, but how they got to that point? They make a post, they become responsible for what that post expresses, we react to that post.
Secondly, the ability to detect use of LLM is itself flawed. On a project where we already have a problem of calls for immediate deletion of 'AI' content, citing policies that don't even exist, it's a problem if we are to begin downgrading our opinion of anything, either content or talk: posts, simply because someone has decided that they're 'AI' and thus of implicitly less worth. Andy Dingley (talk) 21:22, 19 May 2026 (UTC)Reply
The proposal seeks to re-use the existing language from the en-WP guideline page. We're not talking about any suspected AI-use, but "obvious AI argument generation". If this addition to the guidelines gets misused to delete unwelcome voices in a debate, there are obvious remedies, like appealing to administrators. --Enyavar (talk) 22:36, 19 May 2026 (UTC)Reply
The problem is that purely AI generated comments tend to be unnecessary long and verbose and to top it off often miss the point (their contents are irrelevant and don't address the issue at hand). Nakonana (talk) 05:58, 20 May 2026 (UTC)Reply
Is that any more of a problem than human-written comments that are unnecessarily long and verbose and miss the point? I think that is covered by the user being responsible for their comments no matter how they are generated. - Jmabel ! talk13:48, 20 May 2026 (UTC)Reply
In the Wikipedia projects I'd say it is a problem because AI generates walls of text and the longer the thread the more reluctant are people to participate in a discussion. So, it kind of has a "chilling effect". But as for Commons, I've rarely encountered AI generated comments, probably that's because on Commons we don't have to seek consensus over article content etc. all the time. There are just not as many discussions here as elsewhere. Nakonana (talk) 11:41, 21 May 2026 (UTC)Reply
Support LLMs cannot communicate, period. The thread that Apocheir linked is a perfect example. The LLM hallucinated easily-falsifiable accusations, and there's no indication that the other editor was even bothering to read my responses before pasting them into the LLM. Pi.1415926535 (talk) 21:40, 19 May 2026 (UTC)Reply
Support - here, en-WP has the right idea. Post that obviously were generated by AI are typically taking a lot of space without any true argument to them. It should be possible/allowed to mark them as what they are, make these posts collapsible, or in very extreme cases strike them entirely - just like how we would strike other non-constructive contributions on talk pages, like for example fully repetitive walls of texts, or insults. However, there need to be safeguards so that we are not suppressing free speech: This is an international project where writers of all languages are allowed to participate, regularly in auto-translations. If users are flagged/reprimanded falsely for LLM misuse, there should be reasonable ways of recourse, like appealing on the admin noticeboard. And if users are systematically misusing such a new guideline themselves to suppress critics, that should also have consequences. --Enyavar (talk) 22:36, 19 May 2026 (UTC)Reply
If an LLM generates an objectively 'bad' post, e.g. one that is repetitive or hallucinatory, then we should critique it on that basis, i.e. that the results were repetitive or hallucinatory, rather than taking a subjective stance that LLMs and their use are themselves inherently inferior. Andy Dingley (talk) 14:41, 20 May 2026 (UTC)Reply
Support as someone who is neurodivergent and sometimes uses generative AI to get an idea of how to effectively communicate something that's in my head. But I don't copy and paste the response; I use it as a starting point to write my own text in my own words.
All Wikimedia projects are built more or less on consensus and good faith. LLMs are very effective at quickly generating authentic human-sounding communication with little to no effort. It's a perfect tool for trolls, agenda-driven individuals, and other bad actors to compromise our community. If someone is clearly and repetitively posting LLM-generated content in discussions, they absolutely should be blocked as disruptive.
Latest comment: 6 days ago4 comments3 people in discussion
Upon the recent death of Brazilian footballer Geovani Silva, I have came to notice that his main portrait available on Commons looks poorly AI upscaled:
Original image on Placar : After some investigation, it looks to me like the original picture is this one, in a poor quality but depicting a man with a different face than the upscaled one.
Since I'm not a regular Wikimedia Commons contributor, I don't really know the usual stance on this matter (I don't even know if this discussion should take place at the Village pump or somewhere else), but from my understanding the use of AI upscaling in Commons is controversial (Commons:Village_pump/Archive/2026/02#More_explicit_policy_against_upscaling_needed).
What actions should be taken in that case? Should we leave the AI upscaled portrait as it is, or replace it by the original? Or maybe leave both versions co-exist?
In another case of the WMF making decisions without the community, WMF has disbanded Community Tech, and laid off six people. This continues a trend in which community wishes and needs are ignored by WMF. Now the system pits Commons against other projects to get quality of life improvements or to improve our situation with needed tools. I doubt whatever WMF has in mind to replace CommTech will actually get us the kind of technical support we actually need. I agree with User:Novem_Linguae that wishlists need to go back to yearly and individually ranked so it can be shown to WMF what urgently needs to be improved upon. I am also concerned about WMF laying off longtime community members that actually understand the community. I don't like WMF removing that kind of expertise from their staff. I worry about the kind of work culture that the WMF might be fostering by firing well-qualified and well-liked people and by actively working against any kind of dissent. WMF seems to be responding in a familiar pattern as noted by User:Rutebegayou see the same recurring themes: The WMF makes a decision behind closed doors without consultation. They announce the decision late or not at all before implementation. When the community pushes back, they act like they're the ones being blindsided. They claim confidentiality and make general statements without addressing the community's core concerns. They say they are listening and request questions and feedback from the community, to which they have no intention of responding. They sometimes go as far as to issue a non-apology without accountability or any specific commitments. They claim to want to be more responsive and transparent, but it's just part of the charade. This is their strategy of crisis management: waiting it out, saying as little as possible, making empty promises, taking no direct action, and sequestering the last hardliners in some farce of a listening committee, where their complaints can be ignored more directly.
Incredibly alarming news, especially considering the possibility being discussed on enwiki that this was union-busting. Since there's already a long discussion on enwiki that we don't need to replicate here, I would suggest that Commons follow any community actions that enwiki takes, of which disabling fundraising banners seems to be the most likely. Pi.1415926535 (talk) 04:47, 25 May 2026 (UTC)Reply
WMF is a deal with the devil we can’t escape from because without it there’s literally no Wikimedia. They don’t care about their editor base and never will because they rake in gazillions of dollars by pretending the biggest educational website on the planet is struggling to keep the lights on and selling out to data-hungry tech giants. We are just free labor that is endlessly replaced with a neverending supply of naive idealists so it’s not like it would even matter if we all went on strike or something. What point is there in a “response”? Dronebogus (talk) 09:49, 25 May 2026 (UTC)Reply
WMF is full of well-intentioned people, from conversations I've had with current and former employees, they recognize that the lack of trust is a problem, which makes their actions even more frustrating. Yes, their fundraising is misleading, but they do fund people which is a necessary thing. The point of a response is to show that the community believes that they are wrong and should listen to us. I brought this up to both inform the community (since some may not have heard) and to ask the community what we want to do about this issue. I'm willing to follow through with what the community decides. If we decide to follow enwiki's lead, then I'll do what I can to see it through including relaying what the community says to WMF during Wikimania. If I need to start taking this matter to social media, I will do so. Abzeronow (talk) 03:17, 26 May 2026 (UTC)Reply
Doesn’t matter who it’s full of, they could all be saints and bodhisattvas for all I care. Whoever is really in charge clearly doesn’t give a shit. And why should they? What have they possibly got to lose if they piss off a bunch of us little people who are literally volunteering to work for them? It’s not like they are even responsible for our wellbeing. It’s not like we have rights. In all seriousness they have bigger concerns than this, namely protecting Wikimedia from censorship and other legal problems we simply cannot deal with as volunteers. It sucks, I’m not defending their actions or their treatment of the community as expendable, but they have no reason or incentive not to act this way. Because we’re contributors, we’re meant to be expendable. Dronebogus (talk) 09:55, 26 May 2026 (UTC)Reply
Individual editors may be expendable, but the editor base as a whole is not. If there are community decisions to start highly-visible protests like blocking fundraising banners, adding counter-banners, or blacking out wikis, that could generate a lot of bad press from the WMF at a time that it's very protective of its public image. (And if they try to overrule community decisions, that's liable to backfire on them.) I don't think the decision-makers at the WMF understand just how poorly the editor community regards them, nor what said community is willing to do. They think they can just wait for the storm to pass. Pi.1415926535 (talk) 20:16, 26 May 2026 (UTC)Reply
"Individual editors may be expendable" It really does depends on the project in question. On less active projects this absolutely does not apply Trade (talk) 20:46, 26 May 2026 (UTC)Reply
I was just stating that there are good people within WMF, who are making very poorly thought out decisions. Individually, we don't have much power, but collectively, a project can make decisions that WMF will be unable to ignore. As Pi says, I don't think WMF comprehends just how badly this could go for them. Abzeronow (talk) 03:20, 27 May 2026 (UTC)Reply
before people get all riled up, there's a simple question that i dont seem to find in the super long discussions elsewhere.
what is the actual impact of this restructuring by wmf? that means, what's the impact in terms of money and man-hours dedicated to "tech", immediately and in the long run?
I have reverted the AI image, and then replaced it with a 200% upscale using the bicubic algorithm which does not use AI. The Anome (talk) 12:39, 25 May 2026 (UTC)Reply
Latest comment: 3 days ago4 comments3 people in discussion
The file en:File:Logo of Restore Britain.png is marked as non-free content on the English-language Wikipedia. Surely this is free content, as it consists only of text and a map outline in which there cannot be any copyright, as the outline of the map is determined only by coastline (not a human work, therefore no copyright), and political boundaries, specifically the boundaries of counties of Ireland, made well over 100 years ago and thus out of copyright even if one had existed in the first place. The Anome (talk) 12:26, 25 May 2026 (UTC)Reply
Most UK party logos may only be used under fair use, which is not acceptable for Commons. Labour is just as unfree, for example.
Regarding THIS logo: A specific generalization (but not the landform itself!) may be copyrighted. As maps go, this one is on the very low end of intellectual property if any, but PCP shoud be applied. I would think that Restore Britain might have registered a trademark on this general color/map/text combination/arrangement. Unless there is a valid carveout that states why Copyright may not apply. --Enyavar (talk) 20:02, 25 May 2026 (UTC)Reply
The fact that it's a party logo is irrelevant, as is the status of other party logos. Either it's copyrightable, or it isn't.
@EthanL13: What exactly is the goal here? Complete suppression of the existence of the original upload, hiding the user name of the uploader, hiding the content? - Jmabel ! talk15:36, 27 May 2026 (UTC)Reply
Yeah, I think that is the one thing we can't hide with just a revdel, so we would need to delete (and, yes, COM:G5 would be the correct criterion), then undelete everything but that version (and possibly the original wikitext of the upload, though I think there we can hide the uploader name without suppressing entirely). But it seems like a lot of work for some admin to have to go through to try to hide something relatively harmless. Is this really needed on a frequent basis? - Jmabel ! talk16:03, 27 May 2026 (UTC)Reply
May 26
Invitation: Discussion on the proposed direction for the Wishlist
Latest comment: 2 days ago1 comment1 person in discussion
@Jmabel: I have renamed manually some files, but there are too many to rename all of them in this way. And the information provided in metadata is scarce. So I don't have a real meaningful answer. Yann (talk) 15:46, 27 May 2026 (UTC)Reply
It would seem that if there is pattern, we could get them into a category and then use MassRename on that category. But without a pattern, this is inherently one-by-one. - Jmabel ! talk16:04, 27 May 2026 (UTC)Reply
Semantic markup
Latest comment: 1 day ago3 comments3 people in discussion
I had a conversation with Andy Dingley, but they said it was "a waste of [their] time", so I'm asking here:
Could someone confirm that semantic markup is not used on Commons? E.g. <em>...</em> to indicate emphasis instead of plain italics.
... in almost every case when there is an adequate wikitext syntax to use, then that is used rather than HTML. ... This is our practice here on Commons (and Wikimedia projects).
However, regarding "Wikimedia projects", I know for a fact that <em> is preferred on Wikipedia for one; see en:MOS:ITALICS:
The most accessible way to indicate emphasis is with the HTML <em>...</em> element or by enclosing the emphasized text within an {{em|...}} template. Italics markup (''...'', or <i>...</i>) is often used in practice for emphasis, but this use is not semantically correct markup, so emphasis markup is preferred.
On Commons, I did a bit of research for any pages talking about "semantic markup", but I couldn't find any among a bunch of irrelevant pages in the search results. I don't know what would be the equivalent of Wikipedia's manual of style.
I did notice that {{Em}} exists on Commons, but its documentation was copied from Wikipedia and it doesn't seem to have been tailored for Commons.
In practical terms there's no distinction between ''italics'' and <em>. Both get rendered as italic text, and there's no compelling reason to use one over the other. (In particular, there's no real difference in accessibility; screenreaders and other tools are familiar with both tags.) Omphalographer (talk) 20:02, 26 May 2026 (UTC)Reply
I'm basically with Andy here. Unless a site is systematic about semantic markup, there is not much use to using it here and there. - Jmabel ! talk15:45, 27 May 2026 (UTC)Reply
Why is GoogleMaps on spam blacklist?
Latest comment: 2 days ago4 comments4 people in discussion
Can anyone elaborate, why are short-links of Google Maps or Google Streetview (links beginning with "goo.gl") prevented from posting on Commons? You can bypass it by using long links from the adress row of your browser, example.
A spam blacklist entry makes no sense if you can bypass it, but more important, what exactly is the point of blocking Google Maps or Google Streetview links from Commons? Please remove this nonsensical block a.s.a.p. Thanks. --A.Savin20:09, 26 May 2026 (UTC)Reply
I think that there's kind of a global rule that URL shorteners (and goo.gl is one of those) are generally forbidden. Of course, Goo.gl itself is mostly benign, but any shortener is liable to hide the original page destination. This is what is to be avoided, thus that policy of "No URL shorteners" is understandable (even if it makes citing Google Maps references bothersome, Google's system itself only shows shortened addresses when you're using the function of sharing a location). Regards, Grand-Duc (talk) 20:25, 26 May 2026 (UTC)Reply
It's only in the global SBL which reads \bgoo\.gl\b(?!/maps\b).*. Some projects like frwiki added goo.gl to their whitelist. --Achim55 (talk) 20:39, 26 May 2026 (UTC)Reply
Latest comment: 1 day ago5 comments4 people in discussion
I’m going to Wikimania this year (got a full scholarship, very grateful) and would love to meet up with other Commons users. Anyone else from Commons planning to attend? Feel free to reply here or on my talk page if you’re interested in grabbing a coffee or organizing something small. --Jonatan Svensson Glad (talk) 00:14, 27 May 2026 (UTC)Reply
There are discussions about having a fringe conference nearby for those who couldn't get in to Wikimania. (Per Wikimania organizers request, I'm not going to disclose where the venue is within Paris.) Abzeronow (talk) 03:25, 27 May 2026 (UTC)Reply
For anyone going and interested, the Commons Photographers User Group has a preconference on July 21 (will include sessions and likely a photo walk). WikiPortraits is tentatively planning to have a portrait booth, either at the fringe conference or conference proper (still have to check with conference organizers for the latter). ~Kevin Payravi (talk) 04:23, 27 May 2026 (UTC)Reply
Google Books
Latest comment: 3 hours ago4 comments4 people in discussion
Do we have tool for importing PD works from Google Books?
Hi, I have a project to setup a semi-automated tool to upload such files. Most websites now block bots, so it requires some magic. Yann (talk) 10:38, 28 May 2026 (UTC)Reply
I wonder of efforts might be better spent on Google-scanned documents hosted on HathiTrust. I've noticed Google Books often censors all photographs/illustrations from public domain books, even those published in the US well before 1931, while the same document at HathiTrust is uncensored. --Animalparty (talk) 21:38, 28 May 2026 (UTC)Reply
Here I have written this script which will output format that can be pasted in URL2Commons to upload it it can be ran in browser console or saved as bookmark
(This message was sent to Commons:Txokoa and is being posted here due to a redirect.)
Request for Nigeria pidgin and Pidgin Babel templates.
Latest comment: 1 day ago1 comment1 person in discussion
Hello, I would like to request for the creation of the Babel language templates for Nigerian pidgin since the current Babel system doesn't recognize it. Thank you. Wmbata (talk) 18:26, 27 May 2026 (UTC)Reply
Why are they not automobile parks
Latest comment: 1 day ago3 comments3 people in discussion
Because it's one of many possible and valid names.
OTOH, 'automobile parks' would be an invention that no-one uses. In the country where 'automobile' is in use, they're called 'parking lots' instead. Andy Dingley (talk) 19:10, 27 May 2026 (UTC)Reply
@Andy Dingley: In the US, we also have multilevel structures called 'parking garages', generally in areas with high costs for real estate like Manhattan in New York City and international airports, and charging parking fees by the hour or day. I have heard 'park' used by immigrants as a noun instead of 'parking space' for a single available parking space on a street (sometimes a place to put a vehicle that may not be on the other side of the street for much of that day due to street cleaning regulations that mimic New York City's 'alternate side of the street parking'). — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 20:42, 27 May 2026 (UTC)Reply
Notification of DMCA takedown demand — Laura Fraser At Premiere of The Boys Are Back
Latest comment: 1 day ago1 comment1 person in discussion
Oppose This is unrelated to COM:INUSE. If an image is in use in another project it's on scope. If the image is wrong on some account it should be marked as such in Commons or it even can be removed from categories, but it can't be deleted as out of scope without first it stopping being in use on the other project. This seems just another proposal aimed at making Wikipedias store locally the images they use instead of using Commons, as it was before Commons was created.--Pere prlpz (talk) 12:48, 21 May 2026 (UTC)
Strong oppose Commons should not become an arbiter of what is "misinformation", "misleading" or sufficiently "factual". That is the role of the individual Wikimedia projects through their own content policies, sourcing standards and editorial processes. Commons should only concerns itself with copyright, licensing and basic project scope, and files that are legitimately in use on Wikimedia projects are, by longstanding principle, and should continue to be, in scope. --Jonatan Svensson Glad (talk) 16:51, 22 May 2026 (UTC)
![[1]](https://commons.wikimedia.org/w/index.php?title=Commons:Undeletion_requests/Current_requests&oldid=1206588521#File:Unconscience_learning.png){kind=link}
Support. The only time that someone should be posting a comment generated by some LLM or AI or ML tool is if that person is trying to communicate by translating. In that case, you should probably still post your actual material that you wrote alongside whatever an online translation tool posts to be safe. ―Justin (koavf)❤T☮C☺M☯ 22:46, 18 May 2026 (UTC)
_logo.svg){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=edit){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=history){kind=link}
.jpg&limit=999){kind=link}
.jpg&action=watch){kind=link}