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/03.
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: 1 month 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: 7 days 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
Help needed to close 6,323 Category for Discussion cases
Latest comment: 2 days ago11 comments7 people in discussion
There is a large and growing backlog of open CfDs. It would be great…
if more people would participate in these discussions to move them toward closability and
if more admins or CfD/backlog-experienced users would to go through CfDs to close closable discussions (if there is a way to filter these for discussions with 3+ participants, that would be useful)
CfDs over time – this chart was made possible by generative AI and uses data of scraped from Wayback Machine archives of Category:Categories for discussion via a new tool
The oldest open discussions are from 2015. If you have any ideas how to increase participation or more easily solve more CfDs, please comment. For example, maybe there is a way to see CfDs for subjects one is interested/knowledgable in or users could identify users relevant to CfDs and ping them from there to get these to participate (e.g. top authors of the linked Wikipedia articles identified via XTools).
CfDs shouldn't be closed for the sake of it prematurely though – the reason for why they have been started should really be solved before they're closed – sometimes this requires some restructuring, renaming or categorization work. For info about CfDs, see Commons:Categories for discussion. Prototyperspective (talk) 13:55, 6 March 2026 (UTC)Reply
Perhaps we can categorize CfDs like we categorize DRs, so people who are only interested in a specific subject can browse CfDs relating to that subject more easily. Thanks. Tvpuppy (talk) 15:19, 6 March 2026 (UTC)Reply
Good idea. Joshbaumgartner had already set up Category:Category discussions by topic in mid 2024. However, it can be difficult to categorize CfDs into these as these topic categories probably would need to be and are very broad where deepcategory fails. This probably is part of the reason for why the current subcategories are very incomplete and contain just few CfDs (which means that cat is currently not very useful and also doesn't seem to be used much so far). For example, when trying to find more than the 1 CfD currently in the Culture-related CfDs, this search does not show any CfDs and neither does this search. Prototyperspective (talk) 18:38, 9 March 2026 (UTC)Reply
Indeed, it was an attempt to do exactly that, but as a manual process it isn't going to be useful unless broadly adopted as part of the CfD process and probably needs some better gadgetry to make it user friendly for nominators to categorize their CfD from the start. Josh (talk) 01:11, 10 March 2026 (UTC)Reply
Agree. Adding some functionality to a widely-used gadget or a gadget in general may not be needed for this to be broadly adopted: one could have a bot auto-categorize the CfDs and then then better-populated by topic cat could maybe be made more visible in various ways so more people use these. Since the deepcat queries break, I don't know how that could be done theoretically – maybe via petscan or quarry or the Commons SPARQL query service. Prototyperspective (talk) 12:46, 10 March 2026 (UTC)Reply
I agree that categorizing CfDs could be useful, both for users to find them to comment, and for admins to find them to close. (That's especially true where the discussion hinges on specific knowledge bases, or is conducted in non-English languages.) I don't love the idea of canvassing users, even by neutral/automated criteria, unless it's strictly opt-in.
Like many other tasks, the CfD backlog is mostly due to a shortage of admin time. (Experienced non-admin users can also close discussions, and I think it's a great place to learn admin for those considering the mop, but obviously they are not able to delete categories when needed.) There's also a notable lack of tools to efficiently work with CfDs, which means that the workload for a given CfD is substantially higher than a DR. I can close DRs or process speedies on my phone in a few spare minutes on the bus, but closing CfDs requires my laptop and a longer block of time.
Tool to close CfDs - it should be one click to add {{Cfdh}}, {{Cfdf}}, etc, just like it is with DRs.
Tool to rename all categories in a category tree, and move associated files
Tool to add/remove CfD notices on all categories in a given category tree
There are some other less common but time-consuming CfD closure tasks that would benefit from tools. For example, sometimes we decide to merge two category trees with identical structures but different names, or to upmerge a large swath of categories. Having to work through these can make a single CfD close take hours.
Some of these may exist in some form on enwiki or other wikis, which could reduce the work required from "write from scratch" to "localize to Commons". Given the importance of the CfD process and the limited capacity of volunteer developers, I really think these should be developed and maintained by the WMF. Pi.1415926535 (talk) 20:31, 6 March 2026 (UTC)Reply
Opt-in notifications of CfDs aren't feasible I think – a related idea however would be to maybe post about categories of CfDs on WikiProject pages about that broad subject.
Regarding the shortage of admin time maybe an approach could be to get more sufficiently experienced users to help with closing CfDs. Only a fraction of CfDs involve cat deletion and one can also delete these by renaming the category without leaving a redirect in many of these cases.
More tools for CfDs would be great – or probably CfD-features in existing tools like Twinkle. To your useful list of missing features, I'd add a tool to modify many category pages at once similar to VisualFileChange. I've asked about it at Commons:Village pump/Technical#Editing many categories at once and this could also be used for the add/remove CfD notices on all categories in a given category tree functionality. I'd like to note though that afaik most CfDs are not held back by this but rather by a lack of user input or nobody closing the closable CfDs. Prototyperspective (talk) 14:27, 16 March 2026 (UTC)Reply
Uncategorized files over timeWith the increasingly large numbers of uncategorized files, I think there needs to be some thought and work on how to address this at scale / effectively without consuming so much volunteer time. One idea is to better aid and facilitate uploaders to categorize their files at upload as outlined in Commons talk:WMF support for Commons/Upload Wizard Improvements#Guidance/facilitation of categorization; another idea would be to have tools suggest categories based on file-title, description, metadata, and content, similar to User:Alaexis/Diffusor.
On a related note, ultimately all of this is largely a two-stage process where adding initial category/ies is stage 1 and diffusion into more specific categories is stage 2; categorization can be improved a lot if initial category/ies are set if the one/s set is/are about the main topic/usefulness/uniqueness of the file. Probably both stages need some development.
.
I've created the chart on the right a few days ago using some new tool that I coded with the help of AIs – does somebody know how to get data for between mid 2015 and early 2024 or why there is this quick rise from 2012 to 2015 but a decline by 2024? Prototyperspective (talk) 12:58, 10 March 2026 (UTC)Reply
The "two-stage process" that you describe is certainly helpful, e.g. by using Category:Unidentified by topic, but I am even more proud about files that I can categorize to their final location. In many cases, this might involve creating a new category for a person, of which a Wikipedia article exists in any language. This new category will, initially, most often contain only one file, but it can be inter-wiki-linked to the relevant Wikipedia articles via Wikidata. GLAMorous is a powerful tool, to find uncategorized photos of persons, of which a Wikipedia article exists. Until a suitable bot will be programmed, these photos have to be categorized manually one-by-one, please. NearEMPTiness (talk) 02:29, 11 March 2026 (UTC)Reply
Just my two cents... I think it is the job of the uploader to choose a suitable category/categories. The "penalty" for not doing so, is that an image will remain unnoticed, and is unlikely to be used in a Wikipedia article. Trying to think of a suitable category is a nice way to pass the time, certainly. But we're looking at about 1000 uncategorized images per day, and I consider myself lucky if I can find a category for more than a handful. Regards, MartinD (talk) 20:27, 12 March 2026 (UTC)Reply
If we find 200 volunteers, who will categorise at least 5 files per day, we will proceed faster than the uploaders of uncategorized files, especially if some of the volunteers will do more than 10 files a day. NearEMPTiness (talk) 20:31, 13 March 2026 (UTC)Reply
Good point but there's also good counterpoints to this. These include that 1) many of these files are copyvios or would be good to delete for other reasons (like being blurry) so going over them is useful 2) often, categorization is hard depending on the file so it may need some Commons contributor to cat it properly 3) many of these files were just transferred from Flickr or other sites – these aren't just original content of the uploads so it's not the file creator who failed at that and many of especially these files are quite useful but missing in the cats which is a disadvantage to Commons and in Commons' interest to address.
The aforementioned guidance in the UploadWizard could involve showing the info that the image is less likely / easy to be found and used if there is no proper category set. Prototyperspective (talk) 23:23, 16 March 2026 (UTC)Reply
March 11
Categories for exact dates
Latest comment: 59 minutes ago11 comments4 people in discussion
Yes, I am right now sorting clips of uncategorized weather maps into these by-day categories. Also, when I come across a newspaper file, I add the day category, but I am not aware of any systematic effort to sort newspapers into these categories. The last time I suggested to do so was in 2024, see the full discussion here. I would support this idea, but also suggest getting support from bots if possible. --Enyavar (talk) 17:26, 11 March 2026 (UTC)Reply
Yes, that would be it. I was trying the wrong date formatting, and I could not find an example. Should it be News articles published on 2026-03-11, or just Articles published on 2026-03-11 so it can contain magazine articles, or just Works published on 2026-03-11, to be as broad as possible? Or should news articles be categorized by the day of the event, not the day published? News travelled slower in the past. That way someone looking up a day during the American Civil War would see the events of the day, not a day or two later, when it was published. --RAN (talk) 18:50, 11 March 2026 (UTC)Reply
Should news articles be categorized by the day of the event, not the day published? News travelled slower in the past.
In this case, there should be a category for the day the article is published, and one for the subject the article is about. "Works published on..." would be a suitable parent category with "Articles published on..." being one of its subcats. ReneeWrites (talk) 21:58, 11 March 2026 (UTC)Reply
Re "Works": Here I don't think we need to consider other periodicals, or books. The exact date of publishing is not too relevant with a scientific journal, so I don't think they would need to be categorized by date. The same with monthly periodicals: these are not daily newspapers, and should be categorized by month of appearance, even if they do have a day-date. That means, "Works published on..." (date) is really superfluous in my opinion, and will just lead to more fractures in the category tree. For example, 1876-06-09 is the exact publishing date of Twain's Tom Sawyer, but we do not need a category for "Novels published on 1876-06-09". Rather, "1876 novels" is precise enough, and "1876 books from Chicago" for the 1st edition (year book location-scheme). Ergo: Publications/Works where the publication day really matters, are (daily+weekly) newspapers, but little else. That is, I'm looking at the matter with pre-internet publications in mind. Post-1990 and post-2000, things may be different.
Then, RAN might have mixed two slightly different subjects in the comment above, namely newspaper issues (the full publication, or whole pages) and newspaper clippings (singular news articles). I think these should be approached differently.
I'm strongly supporting the idea of just categorizing newspaper issues only by date of publishing. In the times when news travelled at the speed of horses or sails, the same newspaper issue would contain stories about events that happened weeks and days ago, along with the local news of yesterday and today. Our users just should expect on their own that an earthquake that happened in Chile at a certain date in mid-19th century, would not appear in a London newspaper on the same day. Also, a weekly newspaper would still be filed by date of publication.
That said, a newspaper clipping of just a single story, should instead be categorized by the date of the event that is described in it. For example, 1921-06-22, but not 1921-06-23, despite being taken from a publication of the latter day.
I think that country subcategories will come up sooner than later, so I want to consider them early. That doesn't mean we should create by-day categories single newspapers, of course. But it still means several different patterns could be established, here I'm going for an example: "Newspapers of the United States, 1899-09-14" or "United States newspapers published on 1899-09-14" or "1899-09-14 newspapers of the United States". All three suggestions fit the existing patterns, I would say. My favorite would be the third: "<date> newspapers" and possibly "<date> newspapers of <country>" --Enyavar (talk) 05:19, 12 March 2026 (UTC)Reply
Would you also prepend the country name, as also established with the photos? That would fit the second suggestion in my post above.
Another thing, would you also change the category names of the year? Right now, we have "Newspapers of the United States, 1826" but also 1826 newspapers of the United Kingdom. Once we take on the daily format, the year categories could be changed to "Newspapers of <country> published in 1826", which also has the advantage of more clarity. In that way we could harmonize the two rivalling category structures. (Just a suggestion to ask if someone else sees that need; needs further debate in a CfD.) --Enyavar (talk) 16:26, 12 March 2026 (UTC)Reply
I guess that photos of monuments/buildings that don't change daily don't need to have a visible by-date-category for the photos that depict them.
But newspapers? Hiding media by making the categories inaccessible is the best way for nobody being able to find them. I would think that these new-to-implement newspaper-by-day categories, however the name, should not be hidden. --Enyavar (talk) 14:39, 16 March 2026 (UTC)Reply
I suppose I can add in two date categories for some news articles. The day of the event and the day of publication, if there is no event category. Where there is an event category, just the day of publication. --RAN (talk) 16:50, 19 March 2026 (UTC)Reply
Commons:Upscaling
Latest comment: 6 days ago2 comments1 person in discussion
I started a draft guideline at Commons:Upscaling that could use input. To be clear this section is not a proposal to make this a guideline but an invitation for users to edit or provide feedback on a page I plan to eventually propose as a guideline. I started to detail procedures for how to describe/tag/categorize upscaled images, but that got me wondering: what are the valid use cases for upscaling on Commons? I'm having trouble thinking of them. In some cases, upscaling is actively harmful. In others, it's a simple task that we should really just leave to our reusers if they want to. The only thing I can think of is if a Wikimedia project wants to upscale an image for use in an article. So maybe INUSE is the only realistic exception? Thoughts? — Rhododendritestalk | 17:34, 11 March 2026 (UTC)Reply
I've made a bunch of edits since posting this message (and thanks, Jmabel for getting the exceptions started). Still hoping for additional comments or edits, even if to say "looks good". Planning to wait about a week and then start the proposal process at VPP. — Rhododendritestalk | 20:14, 12 March 2026 (UTC)Reply
Bot request: replace old username in file descriptions
Latest comment: 7 days ago2 comments2 people in discussion
My username was renamed from Christo to Random photos 1989, then I've renamed back to Christo.
Many of my uploaded files still contain the old username in the description
(for example in the Author field of the Information template).
Could a bot replace "Random photos 1989" with "Christo" on my files?
This is not true: The Republic of China had its first copyright law in 1928 (Wikisource), with modifications in 1944 (minor change in 1949), 1964 and finally 1985. (I know there are more copyright laws later, but 1928-1985 is the relevant timeline.
As you can check in the wikisource links provided, the copyright lenght did not change between 1928 and 1965 reforms, being the most relevant of all the texts 1944 because it included for the first time movies. This is the articles and terms:
Art. 4 General Works (Individual Author) Life of the author + 30 years (for heirs)
Art. 5 Joint Works (Multiple Authors) Life of all authors + 30 years (after the death of the last surviving author)
Art. 6 Posthumous Works 30 years from the first date of publication
Art. 7 Corporate or Official Works 30 years from the first date of publication
Art. 9 Photographs and Sound Recordings 10 years
Art. 9 Film Works 10 years (must be legally registered)
Art. 10 Translations 20 years (Note: This did not prevent others from translating the same original work)
So, there was a deletion request for some pictures (photographs) made by a folk who lived in the Mainland during ROC times and then fleed to Taiwan, and those pictures were deleted, even if, obviously, somebody linving in the ROC (both Mainland and Taiwan) between 1947 and 1966 was under the current ROC copyright laws (all 1944, 1944 and 1964 recognised 10 years post publication lenghth) and had its copyright expired by the time the 1985 copyright law was implemented, and far before URAA applied in 2002.
Just to clarify, by using for example Art. 7 and 30 years: does your statement mean that ROC government works up to 1954 would be considered public domain because they fell out of copyright before the laws changed in 1985? Or would that deadline rather be 1971, because the URAA date is 2002? Or does this work differently? Best, --Enyavar (talk) 19:05, 12 March 2026 (UTC)Reply
Not a lawyer, but my understanding is:
If a work was PD by July 10, 1985 (when the Taiwanese Copyright law changes), then it's PD. Answering your question (what was PD by July 10, 1985?):
Works by people dead by 1954 (+30 years: 1st January 1985)
Corporate works made in 1954 or before (+30 years: 1st January 1985)
Photos and videos made in 1974 or before (+10 years: 1st January 1985)
Translations made in 1964 or before (+20 years: 1st January 1985, very rare to have in Commons)
Then, 1985 changed again to
General Works Life of the author + 50 years
Cinematic (and Photo) Works 30 years from completion
And 1992 changed Cinematic (and Photo) Works to 50 years after public release; remaining the General Works unchanged.
This means anything in PD according to 1985-1992 law by 2002 was already PD in Taiwan because of 1928-1966 laws (and anything made in the Mainland under ROC rule was also PD by then). For Commons effects, anything falling in PD because of 1985 or 1992 (or 2002) law is not eligible because URAA, until 2047, when post-1996 fall into PD (The movement should ignore URAA in order to improve out projects, but it's a different debate).
Comment, regarding the DR you linked, it was not correct to say "some pictures (photographs) made by a folk who lived in the Mainland during ROC times and then fleed to Taiwan". Per my comment in the DR, the photographs depict that person, so clearly the person did not "make" the photos. It is unknown who has taken the photographs, so we can only assume for the photographs taken in mainland China, the works of the unknown author are subjected to PRC laws, while for the photographs taken in Taiwan, the works of the unknown author are subjected to ROC laws. Thanks. Tvpuppy (talk) 19:57, 12 March 2026 (UTC)Reply
That's a topic for The Undeletion requewst itself, and I can't see the pics (Where were those made?), but if the man moved to Taiwan in 1949 (mny guess: post-1949 are pics of Taiwan), then the whole rationale works.
And still: PRC had no copyright law at all, PRC did not have a Constitution (so, abolish all of the ROC laws) until 1954, and works made by people without PRC passport at the time (two pics, if made in the Mainland) fall into the copyright laws of the country who gives citizenship to the photographer, not the laws of the place where the pics are made. TaronjaSatsuma (talk) 21:52, 12 March 2026 (UTC)Reply
When a new law extends the length of the copyright term, there are two possibilities:
The new term applies only to works that were under copyright on the effective date of the change, or
The new term applies to all works, including those whose copyrights under the old law had expired.
The second is less common, but the combination of the dates in the existing guidance looks like that might be the case in Taiwan. I don't read the language and I'd rather not trust Google translation with something as subtle as this, so I think we need a Chinese reader to look at that issue. . Jim . . . (Jameslwoodward) (talk to me) 20:07, 12 March 2026 (UTC)Reply
I believe there is no combination in the existing guide, someone did 2002-50 = 1952, and followed up with the 2002 (1992) laws regardles of previous possible considerations.
About the possibilities you name, it's the first option, according to article 50 of the 1990 text, which I'll quote in Chinese (you can Google translate to get an idea while waiting for a subtile native translation which I can't provide because I'm not a native speaker).
I'm also not a lawyer, so below is just what I understood by reading the law:
I think the explanation can be found in the article 106-1 of 1998 law (for English translation, see "article106bis" in page 57 of this PDF, the PDF was for later versions of the law, but article 106 is the same).
From reading Article 106-1, I think it meant that for works completed before the WTO date (1 Jan 2002), if those works haven't obtain copyright under the previous versions of the law, and are still under the copyright terms of the current version of the law (e.g. death+50 years), the current law shall apply to those works (there are some exceptions for foreign works, but that's not the subject of discussion).
Article 117 also states Article 106-1 shall take effect on the WTO date (1 Jan 2002)
To me, this meant that most works created before 2002 shall be subjected to the current copyright terms, hence works that are not PD in 2002 will subject to URAA protection (with exceptions for some unpublished works, registered works and foreign works)
Article 106 has two clauses on it (quoting the English version you linked):
"this Act shall apply to works that were completed prior to the date on which the World Trade Organization Agreement took effect in the territory under the jurisdiction of the Republic of China":
where such works did not enjoy copyright under the provisions of the respective versions of this Act (condition 1, the works had copyright and expired under previous versions of the act)
but
where the term of protection for economic rights has not expired in accordance with this Act; (condition 2)
I'm not a lawyer, and I'm using now AI to help me navigate this but:
Once again, not a lawyer, but it seems like the works those whose copyright protection period expired before June 11, 1992, shall become public property because the copyright economic rights protection period has expired, and anyone may freely use them. TaronjaSatsuma (talk) 23:15, 12 March 2026 (UTC)Reply
This introduces a new nuance: 1944 ROC law (and following ups) did include a provision (apparently, only for films) in which in order to be protected they needed to be registered (simillar to US law). Apparently, the law is retroactive for those films failing to fulfill legal register. But only for those (because the need to register in order to have copyright was only for films under the 1944 version, not in the original 1928 law) and not retroactive for works already in PD according to the then valid law.--TaronjaSatsuma (talk) 23:35, 12 March 2026 (UTC)Reply
Indeed, this second TIPO documents seems to confirm what the "such works did not enjoy copyright under the provisions of the respective versions of this Act " in article 106 did mean: The law is retroactive but only for works not covered by the older versions of the copyright law (Movies not registered according to article 10 in 1944 law ( 電影片得由著作人享有著作權十年。但以依法令准演者為限). Indeed it's not exactly a US-like copyright registry, it seems every film was protected... unless they were censored films. For works which are not movies, the law was fully authomatic, so it will change nothing on the restoration proposal of deleted photos.--TaronjaSatsuma (talk) 23:53, 12 March 2026 (UTC)Reply
The first statement by TIPO is referring to registered works. Please note that prior to 1985, all works are required to be registered in order to have copyright protection, so not just for films.
You can see this in Article 1 of any versions prior to 1985, which states "works that are registered according to this law shall have copyright". This register system was abolished with the 1985 law, and it was changed to the current system of "automatic copyright upon creation".
The 1990 text clarified (in Article 50-1, as you quoted above) that the 1985 law will restore copyright for unregistered works published after 10 July 1965. These works subsequently have their copyright terms extended under Article 106 of the 1992 law.
To me, the 1990 text also meant that unregistered works published before 1965, still have not "enjoyed copyright" under any versions of the law, until the Article 106-1 came in effect in 2002, and restore copyright to them.
The fact the register system exist before 1985 is exactly the reason why I specified there are exceptions to registered works. It has a slightly different calculation for their copyright terms, hence it is more complicated (similar to the registered works in the U.S.)
However, to my understanding, currently there isn't a digital system to check for past registration records in Taiwan (unlike the U.S. Copyright Public Records System), so not sure how people here in Commons can check if a particular work was registered or not.
Thanks for the nuance. All works had to be registered
Same
Unregistered works [only those] had its copyright extended, as clarified in 智著字第09300006140號 and 智著字第0920008530-0號. Registered works with their original copyright term expired are considered PD.
Yes, the system is complicated, but the current guidance and explanation is wrong. Works properly registered under 1928-1965 copyright law whose term expired before 1992 (indeed, before 1954/64/74) are PD. This should be explained, and those files should be in Commons.
IDK if there is a registry, but we can assume, at least, for movies, that any film not censored by the government was indeed registered (same for magazines; otherwise, they would not be able to publish it in a military dictatorship with censorship such as Taiwan). For photographs, especially non-professional ones, it can be tricky.
The undeletion request is the undeletion request, we can talk about it in the specific pages. We have undeletion petition for works made in Taiwan, in the Mainland, for pictures, films and paitings. Each has a different case. TaronjaSatsuma (talk) 09:37, 13 March 2026 (UTC)Reply
As I stated before, the paragraph in 智著字第09300006140號 (the first TIPO statement you quoted) are specifically referring to registered works, so it doesn't contradicts with my statement about unregistered works. The paragraph is simply stating for registered works that entered PD before the 1992 law, they would remain in PD even if the 1992 law extended the copyrighted terms.
Please note that 智著字第89007299號 (the second TIPO statement you quoted) was made in 29 August 2000. The statement did use the term "Article 106-1", but the text TIPO quote is definitely Article 106, not Article 106-1. So, the statement was probably referring to Article 106 only.
This means when that statement was made in 2000, it was definitely true that unregistered works published before 1965 was still in PD, since they do not meet the requirements of Article 106, which previously came in effect in 1998.
Article 106-1 (the important part) only came in effect in 2 years later in 2002, as dictated by Article 117 which states Article 106-1 to 106-3 shall come in effect on the WTO date. Only then in 2002, unregistered works published before 1965 have their copyright restored retroactively.
Please see this TIPO statement from 17 September 2003, which states, "又我國自九十一年一月一日加入WTO後，之前未曾依我國歷次修正施行之著作權法受保護之電影著作，將依著作權法第一百零六條之一回溯保護著作公開發表後五十年，亦即原先在我國未曾受著作權法保護之本國及外國人著作，將因適用回溯保護之規定而受保護（即四十一年一月一日至七十四年七月十一日間發行而未註冊之影片將因本條文規定仍受著作權法保護）".
Note that they specifically used the term "回溯保護", which means "retroactive protection".
The sentence in bold roughly translates to "unregistered films released between 1 January 1952 and 11 July 1985 will still be protected by copyright law under the provisions of this article". The sentence is referring to films because TIPO was answering a question about films, but I think it would apply to any unregistered works from 1952 to 1985.
1) Ok, I understand now. Obviously, we should focus on analizing both the registered and unregistered works
7) Ok, good find. I must admit I'm starting to get lost on details, but I get the 2002 law did override some of the conclusions I had arrive.
Focusing on what we can agree (changing the wording in PD-Taiwan, even creating a new template if necessary):
What is PD in Taiwan (and compatible with URAA)?
Registered works by people dead by July 11, 1955 (+30 years: 11th July 1985)
Registered corporate works made in July 11, 1955 or before (+30 years: 11th July 1985)
Registered photos, sound works and audiovisual works made in July 11, 1975 or before (+10 years: 11th July 1985)
Registered translations made in July 11, 1965 or before (+20 years: 11th July 1985, very rare to have in Commons)
Any unregistered work made before July 11, 1965 Any unregistered work made before 1st January 1952 (+50 years after creation in the time URAA was effective)
Taking into consideration the current discovering only affect works registered, perhaps instead of changing the existing templates should we create a PD-ROC-Registered template? I believe using ROC as name is better because it covers both Mainland and Taiwan period, but it could be named PD-Taiwan-Registered too.
Also, I'm unsure if the right date should be July 11 or January 1 (although I believe de facto will always be January 1 because works fall into PD at the begining of the year). @Tvpuppy: What do you think about this? TaronjaSatsuma (talk) 20:00, 13 March 2026 (UTC)Reply
As I mentioned before, the copyright terms calculation for registered works is more complicated, so I cannot be sure if your calculation are accurate. However, I have some comments:
Registered works that entered PD before 11 June 1992 is in PD on the URAA date. This is because Article 106 of the 1992 law states the 1992 law only applies to registered works that are still in their copyright terms. This means the copyright terms of registered works whose copyright has expired in 1992 were not extended under the 1992 law, hence remained in the PD ever since.
For some registered works, there is a distinction between the creation date and publish date. This is because between 1985 and 1992, the copyright terms are calculated from the creation date. However, prior to 1985 and starting from 1992, copyright terms are calculated from the publish date. It is possible for works to be created and registered before 1985, but wasn't published until before 2002. This means the calculation might be different for those works.
I agree "PD-ROC-Registered" is more suitable than "PD-Taiwan-Registered", as some works might be registered to the ROC government when ROC still governed mainland China before 1949.
The concept of "works fall into PD at the beginning of the year" was only first introduced in Article 35 of the 1992 law. Prior to 11 June 1992, works fall into PD on the date it was created/published.
Latest comment: 1 hour ago39 comments16 people in discussion
Is there a feature on the Wikimedia Commons that allows people to hide/blur NSFW images (images depicting nudity, gore, etc.)? If not, should we implement such a feature? Some1 (talk) 16:44, 14 March 2026 (UTC)Reply
This is a perennial suggestion. Even if technically feasible, the very large amount of volunteer work needed to tag images, and the vastly cultural and personal ranges of what would be NSFW, make it unlikely to be effective. If there are images you personally do not want to see, the suggestions at en:Help:Options to hide an image should be easy to implement on Commons as well. Pi.1415926535 (talk) 21:56, 14 March 2026 (UTC)Reply
Tagging images would be as easy as adding them to a new 'NSFW' category or the like. And there should be an easier way for editors to hide/blur these images without to log in and mess with the common.js or .cs. Like how Google search has the 'SafeSearch' option that one could turn on to blur explicit images. With all the age verification laws cropping up around the world lately, there is a possibility that one day, the Commons will be affected. It's better to be prepared than to scramble when the time comes. Some1 (talk) 22:08, 14 March 2026 (UTC)Reply
We have 136 million files. Adding this proposed category would require checking every one of them - a workload equivalent to about 1/8 of all edits ever performed on Commons (and about 1/5 performed by humans) - with no actual benefit to Commons. The automated systems used by sites like social media platforms have significant false positive and false negative rates, as well as significant biases introduced by their training sets, and would not be suitable for use here.
Unlike social media sites, Commons users also understand that there is no universal definition of NSFW. It depends massively on cultural norms, personal views and comfort levels, context of individual files, and what those with power wish to designate as "inappropriate" to further their own aims. Things as diverse as nudity, interpersonal acts like sex or kissing, depictions of religious figures, depictions of people, speech and symbols representing certain views, medical imagery, and animal behaviors may be NSFW to some people and not to others. Many governments would wish to designate files showing protests of dissenting views, the existence of LGBTQ+ people, and the existence of disabled people as NSFW because they represent contradictions to their ideology.
As I've written before when this topic came up, there may be some subject areas where an opt-in filter might have definable criteria, a relatively low chance of use for censorship, and a feasible number of files to check. Nazi symbols is a likely example. But those represent a very small subset of anyone's NSFW definitions. There is plenty of Category:Content-control software out there for those who wish to control what they see. Pi.1415926535 (talk) 23:12, 14 March 2026 (UTC)Reply
I think you're letting the perfect become the enemy of the good. There are plenty of files on Commons which any reasonable person would consider NSFW - e.g. photos of human genitalia, images and videos specifically described as pornography, or those Panteleev photos (you know the ones). We don't need to review every single image; simply tagging images which are already in categories which identify it as likely to be objectionable could get us a lot of the way there. Omphalographer (talk) 02:16, 15 March 2026 (UTC)Reply
Your definition of what NSFW would be likely be different from what someone in Dubai would consider NSFW or someone in Singapore. Governments and organizations would want us to put everything related to LGBTQ+ behind a NSFW filter, Israel would consider pro-Palestinian protest images NSFW, etc. Nudity is also a cultural specific matter. Abzeronow (talk) 03:13, 15 March 2026 (UTC)Reply
Easy: The WMF can add an option that allows individual readers/editors to checkmark certain categories they themselves want included in NSFW filter. Some1 (talk) 03:26, 15 March 2026 (UTC)Reply
I think individual opt-in filters would be fine to have. The problem is how to implement this. The thumbnails on gallery pages are requested directly from the media server without a request on the file page content. GPSLeo (talk) 05:36, 15 March 2026 (UTC)Reply
It works with structured data statements but so far not all or most NSFW files have these set
It does not blur NSFL files such as images showing torn open dead human bodies
I'm not sure how it works – I think it would be best if it worked like on reddit where it blurs the file content and that one can see the individual file by clicking on a button on the image
Support improvements to this gadget and making it easily enable via the preferences and then some thoughtful discussion on whether and which additional things could be done (example: making the gadget usable to logged-out readers). Prototyperspective (talk) 16:39, 17 March 2026 (UTC)Reply
Comment This keeps coming up, but we never get a coherent, concrete proposal, or even a good list of the considerations for a system that would support this without imposing censorship on those who do not want it, or a set of options on what we might consider supporting. I'd be very open to a serious discussion on this front, but it is almost impossible to react intelligently to what is little more than a hand-wave. - Jmabel ! talk23:08, 15 March 2026 (UTC)Reply
Comment People often talk about this as if its a technical problem. It really isn't. The moment we start doing this we have to define what is and is not NSFW. Nobody wants to open that can of worms. The technical problems are trivial comparatively. Bawolff (talk) 23:09, 15 March 2026 (UTC)Reply
Comment I don't think anyone has suggested full-out censorship. Even the OP just requested hiding/blurring. But especially the "Search Media" function should be configurable to have personal settings that blur certain images that come up while searching. The image would then only be displayed, when actively clicking on it. Which images would be blurred? All images from the category that you as a user have determined to be nsfw for yourself, for example all media in Category:Human sexuality or category:Violence (if you consider war paintings and pictures of swords as too obscene). --Enyavar (talk) 11:43, 16 March 2026 (UTC)Reply
Makes sense. Currently, category:Violence would be way too broad to be usable for this. Moreover, it would need some sort of caching as the dynamic deepcategory search operator breaks on such large categories. Prototyperspective (talk) 14:00, 16 March 2026 (UTC)Reply
Just directly in those categories or also subcategories. If you include subcategories, to what depth? Like this isn't as simple as you are making it out to be. Bawolff (talk) 18:48, 16 March 2026 (UTC)Reply
This is the main problem: We would need to store huge index lists of these files to not slow down image loading when enabling such filters. GPSLeo (talk) 19:51, 16 March 2026 (UTC)Reply
Honestly, I don't even think that part is that big an issue (or at the very least there are solutions to that problem). The real challenge is coming up with the list in the first place. Bawolff (talk) 15:55, 19 March 2026 (UTC)Reply
Do you have a specific AI system in mind? AI isn't magic, it still requires making decisions about what type of content the AI thinks is gore or genitalia. On top of that AI adds complications by often focusing on the wrong things (e.g. There was a famous AI system to identify NSFW photos that turned out to just be identifying photos where the subject was wearing lipstick). Bawolff (talk) 16:20, 19 March 2026 (UTC)Reply
I will propose a system Media is requested from thumbnail media server sending an id 0 or 1 for safe search on or make it into a binary for selective Each image will be assigned a “rating” or classification as nsfw
a binary table
Gore
Violence
Non sexual depictions of genetailia
Sex
Etc
Etc
Etc
Etc
yes
1
1
1
1
1
1
1
1
no
0
0
0
0
0
0
0
0
Lets say i want to set my preferences as no gore. Violence no genetailia no sex That would become 01000 The server would let violence through like body cam footage Cyberwolf (talk) 16:03, 19 March 2026 (UTC)Reply
You would still have to agree on the scale then. There is no way to do any sort of collaborative rating without deciding on a rubric. Bawolff (talk) 16:48, 19 March 2026 (UTC)Reply
There are similar categories for places other than continents. There are also some categories that have been defined, like the first one listed here.
The issue is that our terminology "<year> maps" usually means maps produced in the indicated year, not maps showing data for that year. These categories were obviously not produced that 2028. Most of the content of these and similar categories I've looked at show demographic projections, so they don't represent actual data.
So these categories need to be named differently, but how? "Maps of Africa in 2028" wouldn't work, because the data doesn't represent a real situation. Maybe "Maps of Africa showing projected 2028 data"? Something else?
Since some of these have been created already, we might need to look at those to move maps of projected data into different categories.
An extensively populated cat of that type is Category:2050 maps of the world. For non-ancient maps, the year in the cat title refers to the year of the data shown. For ancient maps that's more or less the same as the year the map made. It would be best if the cats for future dates are renamed or if subcategories for these are created. Maps of projections for the future that is now the past or present also need to be considered. You can find many or most, possibly nearly all such files via Category:Future and Category:Prediction (I've added most of these data graphics to these two cats and their respective subcats for maps).
@Auntof6, there is a related discussion above at Commons:Village pump#Maps from Our World in Data. Not sure what is the best solution for future maps, but in the other discussion, they have created specific templates for OWID maps showing past data. Those templates will categorized these maps into a special OWID category under the "YYYY maps of each continent" category (e.g. see Category:1940 maps of Africa).
Perhaps we could try using this solution for these future OWID maps as well, or maybe the templates needs some adjustments for future maps. Thanks. Tvpuppy (talk) 19:44, 17 March 2026 (UTC)Reply
Latest comment: 4 hours ago9 comments4 people in discussion
I dont agree with the move. While 'Midi' can be translated to 'South'. In French it is more usual to use the word 'sud' for South, 'Midi' is more a general term for a region in the south, not a direction. Midi is not used in rail passenger communication. Smiley.toerist (talk) 13:03, 17 March 2026 (UTC)Reply
I simply harmonised the Wikimedia category with the Wikipedia article, where this discussion already took place back in 2010 (see Talk:Brussels-South railway station). Please check WP's naming conventions for Brussels, where it is clearly stated that if an English name exists or it can be easily anglicised, that name should be used. For Brussels' railway stations, the names "Brussels-South", "Brussels-North", "Brussels-Central", etc. were chosen for the sake of neutrality and consistency. All the other variants (e.g. Brussels-Midi, Brussels-Zuid, etc.) are mentioned in the Wikidata entry. Jason Lagos (talk) 13:37, 17 March 2026 (UTC)Reply
Midi is midday and at 12 oclock the sun is in the south. I think we can change the main category, but keep all subcategories. And certainly not change file-names. These refer massively to Midi or Zuid. Functionaly it is the main station. A lot passengera get confused and try to get of at Brussel Central for train connections. The German hauptbahnhof is much clearer.Smiley.toerist (talk) 14:28, 17 March 2026 (UTC)Reply
Thanks for your quick reply. I am well aware of the origin and meaning of "Gare du Midi", as I am myself Brusselian and francophone. ;-) It is true that the name causes some well-known confusion for international passengers, for the reason you mentioned. Again, the point of renaming the category was for consistency with the established conventions on Wikipedia.
Regarding your suggestions, I fully agree with you that we should not rename the files, as that would not make sense.
For the subcategories, I am more neutral, with a preference for moving them as well to match the head category. Would you see any reasons not to?
I would certainly give priority to first changing the station headcategories. The subcategories are less necessary and create a lot of churn. I have lots of images of the South station in my followlist.Smiley.toerist (talk) 10:38, 18 March 2026 (UTC)Reply
Thanks HyperGaruda - I agree. Right now, Category:Train stations in Brussels is a bit of a mess consistency-wise, with some entries named "xxx train station", others "xxx railway station", and others "xxx station", in contradiction to the principle you linked to. Some also use the (less common) Dutch name, instead of the (more common) French one, contrary to WP:NCBRUSSELS. Jason Lagos (talk) 13:24, 19 March 2026 (UTC)Reply
@Smiley.toerist: I am happy to continue the renaming process as I am familiar with these guidelines, as well as the specifics of Brussels' stations (i.e. regular railway stations vs. multimodal hubs requiring a more general "station" name). Ideally, they should match the corresponding WP categories to maintain a harmonised naming system across the project. In any case, creating a lot of "churn" should not hinder progress if the guidelines request it. Jason Lagos (talk) 13:26, 19 March 2026 (UTC)Reply
Neutrality and "Wiki loves Ramadan"
Latest comment: 2 hours ago24 comments15 people in discussion
Hi everyone, am i the only who wonders what presence is given to the competition "Wiki loves Ramadan" by advertising it on the main page and on banners. For our big three competitions, WLM, WLE and WLF i understand such a promotion since their topics are neutral, for WLR i do not understand it. In my mind, there should be a policy of neutrality for main page advertisements and banners. PS: My comment is not about the WLR itself, but about the question if it should be advertised on same level as WLM etc. --Arnd 🇺🇦 (talk) 15:44, 17 March 2026 (UTC)Reply
In fact, I did feel offended. Not exactly for reasons of Christian belief ... but where is "Wiki loves Lent (Fastenzeit, Carême, Quaresima)"? Where is "Wiki loves Easter"? ... or, on a more general scope, "Wiki loves Christianity"? -- Martinus KE (talk) 16:29, 17 March 2026 (UTC)Reply
I don't think there is any reason why we couldn't have a Wiki Loves Lent or Wiki Loves Easter or Wiki Loves Passover or Wiki Loves Holi for more examples. Abzeronow (talk) 03:25, 19 March 2026 (UTC)Reply
I think this is a good call and would suggest that instead the competition/campaign is made broader so as to be about religious practices or religious festivals. Additionally, I find many campaigns like this one slightly problematic since there already is good free media coverage of the subject but lots of other subjects without any such challenges are missing media files with lots of gaps. Prototyperspective (talk) 16:35, 17 March 2026 (UTC)Reply
While Commons is not bound by the RfC linked above, there are good points brought up there. I think one of the best points is that the standard naming "Wiki Loves [X]" implies more of a celebration/preference than the reality of such projects entail. It's really more like "Wiki Documents [X]" (although that wording is perhaps drier than it needs to be -- I don't have a good alternative). "Document Ramadan With Wiki" maybe better. I, too, am uneasy with explicitly religious events advertised to everyone across the project, but appreciate that it's not realistic to disentangle religion and culture, which overlaps in some places more than others. — Rhododendritestalk | 19:20, 17 March 2026 (UTC)Reply
I was aware of that when commenting and here is a RfC about that m:Requests for comment/Wiki Loves X. The (main) issue however is not with the naming but with the campaign topic where a suggested potential action could be to broaden it to religious practices or religious festivals or even religions overall. Prototyperspective (talk) 19:24, 17 March 2026 (UTC)Reply
This particular event is timed to coincide with the month of Ramadan (18 Feb - 19 March this year) - even if the name or description of the campaign were changed, it's still inherently focused on one cultural event. Omphalographer (talk) 22:54, 17 March 2026 (UTC)Reply
I agree that something like this is better language. It also irritates me to no end that it's "wiki loves x": there must be a better way to name that than anthropomorphizing wikis. —Justin (koavf)❤T☮C☺M☯23:17, 17 March 2026 (UTC)Reply
Comment, on a side note, I expect the main page will change to promote Wiki Loves Africa 2026 after Wiki Love Ramadan ends this month. Do you think promoting this event on the main page (which have been done for the last 4 years) have neutrality problems as well, since it only focus on a specific continent? Thanks. Tvpuppy (talk) 00:00, 18 March 2026 (UTC)Reply
I don't think so, other than Wiki Loves Africa, I don't know any other continent-specific campaigns. There are some country-specific campaigns in the past (e.g. Wiki Loves México, Wiki Loves Sudan), and given their smaller scale, it makes sense these have not been promoted in the main page before. Thanks. Tvpuppy (talk) 00:28, 18 March 2026 (UTC)Reply
They are sort of neutral, in a sense they at least pick different subjects. For example, there was Wiki Loves Pride, it was also criticised, but by different groups of users. If they equally represent concepts "loved" by different social groups or cultures, it might be not big issue. MSDN.WhiteKnight (talk) 04:54, 18 March 2026 (UTC)Reply
My vote is clearly against Wiki loves Africa. For Asia, the corresponding campaign is Asian Month, so I'd rather have the Africa campaign also named that way.
Just imagine it the other way round: What amount of protest would be triggered by a campaign called Wiki loves Europe, or even Wiki loves Catholicism? My guess is that the protesters would get quite vocal ...
Sounds like a good idea. I just think the issue is not with the name but with the focus on a narrow subject where the other equivalent subjects do not have such campaigns. One idea would be to have campaigns for these too and not unlikely contributors interested in that could somewhat-readily set them up; another idea would be to broaden the scope so those other subjects can participate too. I don't think a Wiki loves Europe campaign would get much protest and for continents or large territories/regions like that it may make more sense to also run campaigns for equivalent subjects instead of broadening scope so I'd suggest somebody sets sth like that up (eg Wiki loves Europe, Wiki loves European Union, Wiki loves Oceania etc). If there are concerns that we have lots of media about the subject already or that there are no/very few media gaps etc – that applies more to Ramadan where I doubt there's still important media gaps to close when there's a whole campaign about that particular religious practice. Prototyperspective (talk) 13:41, 18 March 2026 (UTC)Reply
This project supports European users very well. Nine out of the ten largest Wikipedias are European, with the exception having been threatened to get shut down because of the use of bots to make it larger. You speak Dutch, as 22 million people do? We have a Wikipedia with 2 million articles for you. You speak Welsh, as a half million do? We have a Wikipedia with a quarter million articles. You speak Hausa, as a 100 million people do? Have a Wikipedia with less than one hundred thousand articles. We have extremely good coverage of Europe, and pretty poor coverage of Africa. But, no, it would be unfair to support Africans in one way if we don't support Europeans in the very same way.--Prosfilaes (talk) 05:51, 19 March 2026 (UTC)Reply
The German chapter also had a campaign Wiki Loves Democracy. We should not make guidelines, who can use this slogan as long as they are within our project scope and values. The question how large and global a campaign has to be, to be featured on the main page, is a different topic. There I think we should have some kind of guideline. GPSLeo (talk) 06:37, 19 March 2026 (UTC)Reply
as a anti-islamist wikimedian, i believe this project is good for getting information from muslim communities. in year passed, muslim people getting more technology and know wikimedia better. we are the ones who bring information to them. i Support this project. yes, it is looking un-neutral, not secular... but in life everything has flaws. modern_primatඞඞඞ ----TALK20:04, 18 March 2026 (UTC)Reply
Latest comment: 38 minutes ago4 comments3 people in discussion
Has anyone found a way to download the highest resolution version of an image from Flickr, when the image is copyright-expired, but "The owner has disabled downloading of their photos"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits13:20, 19 March 2026 (UTC)Reply
You can try viewing the highest resolution version and find the source URL, hover over the image and hit Ctrl+Shift+C in Chrome. A docked window opens and the highlighted HTML block could reveal the URL. --PantheraLeo1359531 😺 (talk) 17:11, 19 March 2026 (UTC)Reply
{from YouTube} using archive.today links
Latest comment: 2 hours ago3 comments2 people in discussion
Archive today was using users ips to launch a ddos attack. It’s a security risk. The webmaster tried to generate ai porn of a blogger and extortion him with it from ars technica Archive.today maintainer sent threatsPatokallio told Ars today that he is pleased by the Wikipedia community’s decision. “I’m glad the Wikipedia community has come to a clear consensus, and I hope this inspires the Wikimedia Foundation to look into creating its own archival service,” he told us.In emails sent to Patokallio after the DDoS began, “Nora” from Archive.today threatened to create a public association between Patokallio’s name and AI porn and to create a gay dating app with Patokallio’s name. These threats were discussed by Wikipedia editors in their deliberations over whether to blacklist Archive.today, and then editors noticed that Patokallio’s name had been inserted into some Archive.today captures of webpages.“Honestly, I’m kind of in shock,” one editor wrote. “Just to make sure I’m understanding the implications of this: we have good reason to believe that the archive.today operator has tampered with the content of their archives, in a manner that suggests they were trying to further their position against the person they are in dispute with???” End quote. If this doesn’t justify a full cleansing of it here I don’t know what does Cyberwolf (talk) 15:28, 19 March 2026 (UTC)Reply
Dan Breen: wrongly identified
Latest comment: 1 hour ago1 comment1 person in discussion
The image File:Dan_Breen, circa 1920s.jpg refers. It appears on the en:Dan Breen article (a deceased Irish republican). The provenance is RTÉ, Ireland's national broadcaster, and I have asked them about it.
That Talk page has an item from a relative of Breen informing us that this image is not of Dan Breen but his younger brother Laurence "Lar" Breen, an Irish republican himself. I emailed this Mr O Riain as follows:
It came from RTÉ but the page in question is no longer available: https://www.rte.ie/news/2021/1129/1263845-the-treaty-debate-a-close-run-thing/
Can I ask how you know that this pic is of Laurence and not Dan? Fwiw, I suspect you are correct, for while there is a resemblance, it does not appear to be the same person.
While I'm not an administrator on Wikipedia, if there is any photographic evidence you can send me or point me to in order to prove that a mistake has been made, I will try and pass it on.
Reply: "I am delighted to hear from you, I've had to raise this issue with a number of people over recent years. The reason I am so sure about this that I happen to be a Grandnephew of both Dan and Laurence Breen. Their Brother Patrick Breen was my Grandfather and his daughter Josephine Breen was my Mother. I regret to say I don't have another photo of Laurence Breen(He died in the USA in 1940).
Paud Ó Riain"
What is the best way forward? I am happy to receive a message or messages about this.
_cases_over_time_on_Commons.png)
.svg/20px-Pictogram_voting_comment_(orange).svg.png)
Comment, regarding the DR you linked, it was not correct to say "
Oppose. We can't cater to everyone. What if my workplace was at the Taliban? See COM:CENSOR. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:53, 14 March 2026 (UTC)
Support improvements to this gadget and making it easily enable via the preferences and then some thoughtful discussion on whether and which additional things could be done (example: making the gadget usable to logged-out readers). Prototyperspective (talk) 16:39, 17 March 2026 (UTC)_Berlin_09.jpg/120px-(20260308)_Berlin_09.jpg)
_Berlin_09.jpg)
,_Ed._1_Thursday,_September_14,_1899_-_DPLA_-_776a4f1990f65cdded8fdb80e2d3f6ab_(page_1).jpg){kind=link}
_-_Google_Art_Project.jpg){kind=link}
