Shortcut : COM:VP Community portal introduction Village pump copyright proposals technical Administrators' noticeboard vandalism user problems blocks and protections blocks and protections Commons Help desk Village pump (general discussion) Copyright Proposals Technical Graphics and photography discussion Photography critiques Image improvement Illustration workshop Map workshop Photography workshop Video and sound workshop Photography critiques Image improvement Illustration workshop Map workshop Photography workshop Video and sound workshop Illustration workshop Photography workshop Video and sound workshop Categories for discussion Undeletion requests Deletion requests Volunteer Response Team/Noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems ( Dispute resolution ) Blocks and protections User problems ( Dispute resolution ) Blocks and protections Bureaucrats' noticeboard CheckUser requests Oversight requests Commons mailing list ( archive ) Commons' bugs on Phabricator 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/09 . 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. Have you read our FAQ ? For changing the name of a file, see Commons:File renaming . 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: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump . To ask for image improvement , see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement , see Commons:Graphic Lab/Video and sound workshop . For translation requests , please post at Commons:Requests for translation . For media requests , please post at Commons:File requests . 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. Search archives: Start a new discussion In the last hour In the last day In the last week In the last month More than one month Policy update for AI content (23 June 2026) Policy update for Renaming of Pdf and DjVu files (14 August 2026) History maps of Europe Hi, I would like to discuss the description in all categories of the scheme "Maps of <country> in the <x>th century" (see for example Italy , Belgium , Spain , Poland ). There are three different points about the current system I would like to invite comments on: the wording of the definition in the first paragraph of the hatnote whether or not to include "you may also be looking for similar maps" (second and third paragraph) of the description whether or not to re-include a distinction between history maps (in this category group) vs. old maps ( not in this category group) 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 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? 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 Maps from Our World in Data A suggestion in regards with the maps from Our World in Data: remove from each map the category <year> maps of the world . These maps weren't published in the years referenced. In addition, it could make the categories of <year> maps of the world more easy to browse. Thanks in advance. -- Universalis ( talk ) 19:15, 22 February 2026 (UTC) Reply The template would be used for categories like Our World in Data maps of Oceania showing 1947 data , right? Would we also have Our World in Data maps of Oceania showing 1940s data (decade) and Our World in Data maps of Oceania showing 19th-century data (century) as parent and grandparent of the year category? I have now created: {{Category description/Our World in Data maps by continent and century}} {{Category description/Our World in Data maps by continent and decade}} {{Category description/Our World in Data maps by continent and year}} Category:Our World in Data maps of Oceania showing 20th-century data Category:Our World in Data maps of Oceania showing 1940s data Category:Our World in Data maps of Oceania showing 1947 data Category:Our World in Data maps of the world showing 1947 data The usage of the templates is super easy, no need for any parameters specifying the continent or the year, they take everything they need to know from the name of the category they are used in. The names of the continents are automatically translated using Wikidata labels. The first part of the title and the text above and below the navigation blocks are just examples. These can be used as an explanation for the category which is centrally maintained and must only be changed once if something should be changed, and if the texts are final, we can also make them translatable. Please let me know what you think. -- Reinhard Müller ( talk ) 09:52, 6 March 2026 (UTC) Reply 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 {{Category description/Maps by continent and century shown}} {{Category description/Maps by continent and decade shown}} {{Category description/Maps by continent and year shown}} for all files in [[Category:Our World in Data maps of Asia]] if " {{Map showing old data|year=YYYY}} " occurs in the file: take the YYYY as a variable to insert " [[Category:Our World in Data maps of Asia showing YYYY data]] " //** a single category for the location and year of the map **// if that inserted category does not yet exist: create it with " {{Category description/Our World in Data maps by continent and year}} " //** (as helpfully provided by Reinhard)**// take the file name as the variable topicname and strip File: and , Asia, YYYY.svg (or ,Asia,YYYY.svg ) from that variable insert " [[Category:Our World in Data maps showing ||topicname]] " //** for example Category:Our World in Data maps showing Absolute change co2 , neatly collecting ~1800 files like this one or ~200 files like this one : a single category for the topic of the map, to have them all easily assembled **// if that inserted category does not yet exist: create it with " [[Category:Our World in Data maps by topic]] " //** in many cases, better names might be found, but that cleanup can be handled afterwards manually where needed **// remove all occurences of " {{Map showing old data|year=YYYY}} ", "" [[Category:YYYY maps of Asia]] " and " [[Category:Our World in Data maps of Asia]] " ( else leave the file alone) if " {{Map showing old data|year=YYYY}} " occurs in the file: take the YYYY as a variable to insert " [[Category:Our World in Data maps of Asia showing YYYY data]] " //** a single category for the location and year of the map **// if that inserted category does not yet exist: create it with " {{Category description/Our World in Data maps by continent and year}} " //** (as helpfully provided by Reinhard)**// take the file name as the variable topicname and strip File: and , Asia, YYYY.svg (or ,Asia,YYYY.svg ) from that variable insert " [[Category:Our World in Data maps showing ||topicname]] " //** for example Category:Our World in Data maps showing Absolute change co2 , neatly collecting ~1800 files like this one or ~200 files like this one : a single category for the topic of the map, to have them all easily assembled **// if that inserted category does not yet exist: create it with " [[Category:Our World in Data maps by topic]] " //** in many cases, better names might be found, but that cleanup can be handled afterwards manually where needed **// remove all occurences of " {{Map showing old data|year=YYYY}} ", "" [[Category:YYYY maps of Asia]] " and " [[Category:Our World in Data maps of Asia]] " 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)**// if that inserted category does not yet exist: create it with " {{Category description/Our World in Data maps by continent and year}} " //** (as helpfully provided by Reinhard)**// take the file name as the variable topicname and strip File: and , Asia, YYYY.svg (or ,Asia,YYYY.svg ) from that variable insert " [[Category:Our World in Data maps showing ||topicname]] " //** for example Category:Our World in Data maps showing Absolute change co2 , neatly collecting ~1800 files like this one or ~200 files like this one : a single category for the topic of the map, to have them all easily assembled **// if that inserted category does not yet exist: create it with " [[Category:Our World in Data maps by topic]] " //** in many cases, better names might be found, but that cleanup can be handled afterwards manually where needed **// 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. Removing women from categories Hello, I noticed that Mary Louisa Gow was moved from Category:Painters from England to Category:Female painters from England. https://commons.wikimedia.org/w/index.php?title=Category:Mary_Louisa_Gow&diff=prev&oldid=420189141 Is this correct? There have been some other women moved the same way, at least one a politician. I am seeing that https://commons.wikimedia.org/wiki/Category:Zohran_Mamdani_in_2025 is in a "politicians" type category and not in a "male politicians" category or "Asian politicians" category. I don't see any help files about this. Thank you. Caffeinated Chihuahua ( talk ) 02:10, 13 August 2026 (UTC) Reply Category:Zohran Mamdani is under Category:21st-century male politicians of New York City which is somewhere under Category:Male politicians of the United States . Category:Politicians of the United States in 2025 has no male or female subcats, and contains women like Category:Pam Bondi in 2025 Category:Kristi Noem in 2025 . [This could either be an addition to COM:OVERCAT or a separate project page; either way, it effectively modifies OVERCAT.] Nutshell: As a general rule, categories that intersect individuals' gender, ethnicity, religion, or sexuality with some other category should be non-diffusing categories. There are some exceptions to this, which are addressed below. Rationale: Regardless of intentions, the introduction of categories such as Category:Female guitarists or Category:Jewish classical musicians can lead to ghettoization. Fundamentally, a female guitarist or a Jewish cellist does exactly the same thing as a male guitarist or Russian Orthodox cellist, but when they are sectioned out like this they are separated from their peers based on a characteristic that is irrelevant to the matter at hand. Some of the unwelcome results are: One ethnicity is singled out this way, separating them from basically everyone else in their field. Because they are somewhat separated out, they are overlooked for other diffusions of the main category, so they are never categorized by nationality, genre of music, etc. In an overwhelmingly male (or overwhelmingly female) field women (or men) are ghettoized with similar effect. Diffusing a category by sexual orientation can be particularly pernicious, because it requires you to know something not necessarily obvious about a person to find them in the categorization system, and because there are likely to be very large numbers of people of no publicly declared sexuality. There are valid reasons to have categories such as Category:Female guitarists or Category:Jewish classical musicians , but they should be implemented as non-diffusing categories. What does non-diffusing mean? We will need a paraphrase of text from en:WP:Categorization#Non-diffusing subcategories , including our policy on tagging these. Note that we already have {{Non-diffusing subcategory}} , but it is not heavily used. The following may be diffused by gender: The following may be diffused by religion: saints or other venerated individuals, diffused to the religion or religions that venerate them other exceptions? Jmabel ! talk 04:10, 15 August 2026 (UTC) Reply there's no "overloading". it's perfectly fine if a cat contains millions of files. there's no "more general cats". all should be "general cats" that deal with exactly only 1 aspect. categorise files to answer five Ws (Q368722) : questions whose answers are considered basic in information-gathering , but dont combine those answers to create cats like Category:France photographs taken on 2026-05-01 . this one mixes where, what, when. problems of this specific one have been raised in 2016 Commons:Categories for discussion/2016/10/Category:September 2007 Finland photographs . On the exchange above between User:Gone_Postal and GPSLeo : I don't really think this particular discussion is the place to make an entirely different proposal that would completely redefine how Commons uses categories. Feel more than free to make a distinct proposal of your own, but it seems you are arguing "don't refine the current approach because I'd like to do everything almost completely differently," and that just really isn't fair, it's a derailing. In case you do plan to make a proposal along those lines, though, I want to point out a use case you may not be considering, where I think the current category approach performs particularly well: when a user starts, not from a rationally formed query, but from one of our files, and thinks "this isn't exactly what I want, but it's close." Right now, they can navigate from the file to a category that seems like it might be promising, and possibly from that to parent and child categories. I would hope that any proposed replacement for the current approach to categories takes that use case into consideration. @ RoyZuo : yes, there are some small number of cases where even for these types of performers, their gender is irrelevant, but I hope you would agree that these are relatively rare cases. Even some of your examples could as easily be seen as counterexamples: the Takarazuka Revue is an all-female troupe, which is pretty much a defining factor for it. Yes, many of their performers play male roles, but that doesn't change the fact that the members of the troupe actually being women is a defining factor in these performances. Imbalance in gender ratio may be a reason to have a gender-specific subcat for those who are the exception to the rule, but it is absolutely not a reason to make that a diffusing subcat, quite the opposite. The latter is precisely the "ghettoization" problem this proposal is intended to address. It is possible that the now mostly historical role of a governess might be another case that would call for an exception. Category:Waitresses , however, is simply a gendered subcat of Category:Waiters (with no corresponding specifically male subcat) and with possibly a few edge-case exceptions, waiters and waitresses do the same work. We could arbitrarily make it an exception here, but it would only be because in this case the English language is not our friend. - Jmabel ! talk 23:31, 15 August 2026 (UTC) Reply In general, this is a very good proposal, but I do not agree with any of the "exceptions". If you are going to say that male vocalists are not vocalists because they are hired for a particular vocal range, you might as well go straight to "bass, tenor, soprano" etc. categories. Likewise they say that Ginger Rogers did everything Fred Astaire did, but backwards and in heels, so how could you say that Ginger Rogers was not a legitimate dancer. And how could you categorize someone like Augustine by denomination, or some of the missionaries who were primarily notable as linguists. Categories help editors find images. Removing already marginalized groups from broad categories will make them even less discoverable. I would support implementing the "non-diffusing" parts now. It seems like the "exceptions" need more work before they can be agreed on. Caffeinated Chihuahua ( talk ) 05:37, 16 August 2026 (UTC) Reply Support Jmabel 's draft proposal. I don't see any reason why w:wp:ALLINCLUDED shouldn't also apply to Commons. Currently, subcategories based on gender etc are incredibly inconsistent and sometimes confusing. Better to keep things simple: its harder to miscategorise with this proposal, and less likely to lead to othering . LetmeEditit ( talk ) 18:45, 22 August 2026 (UTC) Reply I Support the adoption of w:en:WP:ALLINCLUDED on Commons. I Oppose trying to explicitly list all the exceptions (see my comments further up). Nosferattus ( talk ) 10:34, 23 August 2026 (UTC) Reply @ Nosferattus : I'm fine with not attempting to explicitly list exceptions, but I would at least like to include examples: that diffusing by gender makes sense for vocalists, but not instrumentalists, and for actors, but not for directors; that diffusing by religion make sense for clergy, but not for politicians? - Jmabel ! talk 04:51, 25 August 2026 (UTC) Reply Sure, listing some examples is fine, IMO. Nosferattus ( talk ) 05:41, 25 August 2026 (UTC) Reply Support proposal by Jmabel to include the given examples as well as per Nosferattus and if possible, adopt or adapt https://en.wikipedia.org/wiki/en:WP:ALLINCLUDED to avoid othering per LetmeEditit -- Ooligan ( talk ) 02:06, 8 September 2026 (UTC) Reply If I want to see images of vocalists, why should I have to choose between looking at male vocalists or female vocalists? It does not make any sense to make the person looking for images jump through more hoops and more layers of subcategories. If they want to refine their search, let them do it themselves instead of creating artificial barriers and hiding them in layers of subcategories. Likewise with religion, it does not make any sense to me that, say missionaries, are hired on the basis of appearance so should be hidden under more categories. This opens up a can of worms for other occupations as well, and does not help with discoverability. I would rather encourage people to add more categories, than take them away. Caffeinated Chihuahua ( talk ) 06:59, 1 September 2026 (UTC) Reply Commons:Categories for discussion/2025/02/Category:SVG by subject trying to log in from a new device It was just now forced to request an e-mail to be sent to me, which read: it looks like you are trying to log in from a new device on Wikimedia Commons which is correct. It is also true that I will connect from whichever device I want or need and that’s nobody else’s business. If my username and password combo checks, that should be quite enough. Kindly advice on how to turn off this unnaceptably meddling feature in my Wikimedia account preferences. I’m well aware some people opt to outsource the management of their passwords to disparate parties, but I have been the sole custodian of my own passwords since 1984 and I plan to go on doing so. -- Tuválkin ✉ ✇ 14:08, 23 August 2026 (UTC) Reply A script for renaming and describing files from Special:ListFiles Special:ListFiles shows a hundred of your files at once, which is where you notice that several still carry camera names, that a description is in the wrong language, or that a whole shoot never got its category. Fixing any of it meant opening each file page and coming back. I wrote a user script that moves the editing into the list. Every row gets a pencil that opens a small form with the file's name, description and categories, read from the file page itself. Above the table there is a bar that adds or removes one category across the ticked files, and one Save that writes every row you edited. Renaming goes through action=move and leaves a redirect unless you untick it, so it needs the file mover right. The page edits are deliberately narrow: only the description parameter and the category lines change, sort keys are kept, and a save is refused if someone edited the page while the form was open. Code and documentation: User:Wilfredor/commons-listfiles-editor . It is new, so I would rather hear now about anything that breaks. Wilfredor ( talk ) 12:34, 25 August 2026 (UTC) Reply Colombian judicial decisions: Article 41 of Law 23/1982 and JEP court rulings I would appreciate some guidance regarding the copyright status on Commons of official judicial decisions issued in Colombia. The specific case concerns judicial rulings ( autos and potentially judgments) issued by the Special Jurisdiction for Peace (JEP) , Colombia's transitional justice jurisdiction. These are official judicial decisions issued by its judicial chambers and Tribunal for Peace and published by the JEP itself.

We are exploring the long-term preservation of this corpus and would like to determine whether faithful copies of the official PDFs may be hosted on Wikimedia Commons. — Preceding unsigned comment added by AmiGueko ( talk • contribs ) 22:47, 26 August 2026 (UTC) Reply Article 41 of Colombia's Law 23 of 1982 states: In English, approximately: The Colombian National Copyright Directorate (Dirección Nacional de Derecho de Autor) describes Article 41 as a limitation allowing any person to reproduce these materials. This seems different from the general regime for works created by Colombian public employees. Government works in Colombia are not automatically in the public domain; Article 41 creates a specific rule for legislation, administrative acts and judicial decisions. The Andean Community's Decision 351 does not appear to contain an identical exemption for judicial decisions, although Article 21 permits Member States to establish copyright limitations and exceptions subject to the three-step test. Article 22 also contains specific permitted uses. Article 2(4) of the Berne Convention additionally provides that it is a matter for national legislation to determine the protection granted to official texts of a legislative, administrative and legal nature. — Preceding unsigned comment added by AmiGueko ( talk • contribs ) 22:47, 26 August 2026 (UTC) Reply The U.S. side appears clearer. Section 313.6(C)(2) of the Compendium of U.S. Copyright Office Practices states that government edicts include judicial decisions and further states that the Copyright Office will not register a government edict issued by a foreign government. Commons already reflects this in {{PD-EdictGov}} , which states that an edict of a local or foreign government is in the public domain in the United States and explicitly includes judicial decisions. Therefore, it appears that {{PD-EdictGov}} could cover the U.S. copyright status of an official JEP judicial decision. — Preceding unsigned comment added by AmiGueko ( talk • contribs ) 22:47, 26 August 2026 (UTC) Reply Question about Colombia / Commons policy The point on which I would particularly appreciate community input is the Colombian side. Article 41 gives everyone an express statutory right to reproduce judicial decisions, but it also requires the reproduction to conform exactly to the official edition. Would this statutory status be sufficient for an official Colombian judicial decision to meet Commons' requirement that a work be free in its country of origin? More specifically: Should Article 41 be interpreted for Commons purposes as making official Colombian judicial decisions sufficiently free for hosting on Commons, when combined with {{PD-EdictGov}} for the United States? Or is Article 41 only a copyright exception permitting faithful reproduction, while leaving other exclusive rights — particularly adaptation/derivative works — intact, making the documents incompatible with Commons unless the relevant rights holder provides an additional free licence? If Article 41 is sufficient, would it make sense to create a specific template such as a Colombian government-edict / judicial-decision tag rather than using {{PD-Colombia}} , which appears to concern expiration of copyright terms? Would the answer differ between the judicial text itself and additional material embedded in a PDF (for example photographs, maps, illustrations, or other third-party material)? Our intention would initially be to upload only faithful copies of the official judicial decisions published by the JEP, together with their original source URLs and provenance information. Before uploading anything at scale, we would like to establish the correct copyright analysis and template combination. Relevant legal provisions: Colombia, Law 23 of 1982, Article 41. Andean Community, Decision 351 of 1993, Articles 21–22. Berne Convention, Article 2(4). U.S. Copyright Office, Compendium , §313.6(C)(2), Government Edicts. Commons: {{PD-EdictGov}} . Thank you for any guidance, particularly from editors familiar with Colombian/Andean copyright law or the treatment of foreign judicial decisions on Commons. — Preceding unsigned comment added by AmiGueko ( talk • contribs ) 22:47, 26 August 2026 (UTC) Reply Proposal of a tool to detect over-categorized files I am considering creating a small tool or gadget to help identify possible cases of over-categorization. The idea is simple, on a category page, a button such as Check for over-categorization would compare the files directly contained in that category with the files found in its subcategories. If a file is already included in a more specific subcategory, the tool would show it as a possible redundant categorization. For example, if File:Example.jpg is directly in Category:A, but is also in Category:A1, which is a subcategory of Category:A, the tool would flag it and show the category path.This would initially be read-only, since there are valid exceptions to over-categorization and the final decision should remain with the editor. Later, it could possibly integrate actions similar to Cat-a-lot for removing the parent category after review. There are already related tools such as DeepcatSearch, PetScan, Cat-a-lot and catpath.js, but as far as I know there is no simple tool focused specifically on answering: which files directly in this category are already categorized somewhere below it? For large category trees, the search depth could be limited or configurable to avoid performance problems. Would this be useful for category maintenance on Commons? Is there already a tool that provides this exact functionality, or a preferred way to implement it? Wilfredor ( talk ) 21:39, 27 August 2026 (UTC) Reply flat categories: if there is a deliberate flat category (e.g. Category:Ships by name (flat list) ) anywhere in the descent, then unless you have somehow accounted for that you will almost certainly get false positives. Street and building: we often make all of the streets a building is on be parent categories of a category for that building. However, any photo that clearly shows both the building and the street will typically be in both categories. E.g. File:2nd Ave looking north from Yesler Way, Seattle, Washington, ca1895 (LAROCHE 317).jpeg has both Category:Second Avenue, Seattle (its chief subject) and categories for a fair number of the visible buildings, most or all of which have Category:Second Avenue, Seattle as parents. 2 different people: you can have a category for a specific person in a photo, and also a category related to a different person in the photo that would also be a parent category for that specific person. E.g. in File:2015 State of the City Address (16519383817).jpg , if someone were to add categories for one or two of the members of the Seattle City Council who are visible here, it probably would sitll be correct to keep Category:Members of the Seattle City Council for the many others who are also there. A parallel issue can apply for buildings in a photograph where one building is specifically identified, and doubtless there are other parallel cases. A parallel issue can apply for buildings in a photograph where one building is specifically identified, and doubtless there are other parallel cases. Cycles: The traversal handles them explicitly. The crawl keeps a set of visited categories and never expands the same category twice, with a hard depth limit on top, so loops terminate and not recursing indefinitely. The result also shows the category path used to reach each file, making unusual parent relationships visible. Read-only: There would be no edits, maintenance category, public backlog page, or queue for other editors to work through. The output exists only in the browser of the person who ran the tool and disappears when the tab is closed. There is no persistent "flagged" state for editors to dispute and nobody inherits a list to process mechanically. Naming: I will drop "over-categorization" from the button. What the tool actually answers is: Which files in this category are also present in one of its subcategories, and through which path? Presenting the result as a violation would invite unnecessary disputes, so the interface should remain descriptive rather than prescriptive. Structural false positives: Streets and buildings, a named person inside a group category, or one identified building among many are all cases where the issue comes from the category relationship rather than the individual file. The opt-out should therefore be defined at that level, in an on-wiki list anyone can edit, with two kinds of entries: categories whose files should never be considered for this check, such as Category:Members of the Seattle City Council or Category:Ships by name (flat list) , and specific parent and child relationships that should never be reported, such as a street category and the categories for buildings on that street. One entry can then cover thousands of files instead of requiring file-by-file exclusions, and the list belongs to the community rather than to me. Flat lists and meta categories: The crawl stops at categories explicitly marked as deliberately flat or as meta categories and does not descend beyond them. If the existing templates are not applied consistently enough for reliable automatic detection, that argues for the explicit exception list above rather than trying to infer intent. Depth: The default would be one level, meaning direct subcategories only, configurable up to a small hard cap. Most genuine duplicates are likely to appear one level below the parent, while deeper traversal increasingly encounters the structural cases described above. Action mode: I am not proposing Cat-a-lot-style removal or any other editing action as part of this tool. If such functionality is ever considered, it should come back here as a separate proposal, and the exception mechanism should already exist and be populated first. Cycles: good, sounds like you've got that one. Read-only: glad to hear any actions will be by humans. The one problem with that (and it looks like you've given this some thought) is the danger that a false positive may be reported to a lot of different users if there is no way to head it off, and (in the worst case) that someone eventually "does what the bot seems to want" rather than thinking for themself. Naming: agreed. Structural false positives: I don't think we are yet on the same page here. I'm not certain what you mean by saying they are "the issue comes from the category relationship rather than the individual file." Could you expand on that instead of my responding to one or more of my several interpretations of what you could mean? Category:Members of the Seattle City Council and Category:Ships by name (flat list) are very different from one another. For "members of", ideally we would diffuse this completely, if we had enough content (so that we didn't have just one or two pictures of some council members) and enough knowledge (so that, for example, we could say who each individual is in a picture of the City Council visiting a dam site in the 1930s). The problem comes when we can identify (and have subcats for) some, but not all, of the people depicted. (The street/building situation is analogous: in both cases you have to actually examine what the file depicts to see whether it is OVERCAT or not.) Now that I look more closely, Category:Ships by name (flat list) any other truly flat list doesn't present a problem at all. The only issue (and it won't be detected by a tool like the one you are proposing) is that its subcats all need to be the correct type of categories: categories for individual named ships. The problem would come if it has a subcat like the nonexistent Category:Tugboats by name (flat list) , where tugboats would belong in both. I'm not certain what you mean by saying they are "the issue comes from the category relationship rather than the individual file." Could you expand on that instead of my responding to one or more of my several interpretations of what you could mean? Category:Members of the Seattle City Council and Category:Ships by name (flat list) are very different from one another. For "members of", ideally we would diffuse this completely, if we had enough content (so that we didn't have just one or two pictures of some council members) and enough knowledge (so that, for example, we could say who each individual is in a picture of the City Council visiting a dam site in the 1930s). The problem comes when we can identify (and have subcats for) some, but not all, of the people depicted. (The street/building situation is analogous: in both cases you have to actually examine what the file depicts to see whether it is OVERCAT or not.) Now that I look more closely, Category:Ships by name (flat list) any other truly flat list doesn't present a problem at all. The only issue (and it won't be detected by a tool like the one you are proposing) is that its subcats all need to be the correct type of categories: categories for individual named ships. The problem would come if it has a subcat like the nonexistent Category:Tugboats by name (flat list) , where tugboats would belong in both. For "members of", ideally we would diffuse this completely, if we had enough content (so that we didn't have just one or two pictures of some council members) and enough knowledge (so that, for example, we could say who each individual is in a picture of the City Council visiting a dam site in the 1930s). The problem comes when we can identify (and have subcats for) some, but not all, of the people depicted. (The street/building situation is analogous: in both cases you have to actually examine what the file depicts to see whether it is OVERCAT or not.) Now that I look more closely, Category:Ships by name (flat list) any other truly flat list doesn't present a problem at all. The only issue (and it won't be detected by a tool like the one you are proposing) is that its subcats all need to be the correct type of categories: categories for individual named ships. The problem would come if it has a subcat like the nonexistent Category:Tugboats by name (flat list) , where tugboats would belong in both. Flat lists and meta categories (some of the issues her cross over with Structural false positives ): I'm not at all sure that meta categories actually require special handling at all: I'd be interested in seeing why you think they do. Similarly, as I remarked above, for flat lists. But there are two things I think are trickier: Categories that are intended as non-diffusing. For example, we have a discussion going on right now that possibly (with some relatively few exceptions) subcategories for gender should be non-diffusing. If we went that way, it would be appropriate for a category for a person to be in both Category:Guitarists and Category:Female guitarists , but probably we still would not want to have that person category in both Category:Guitarists and Category:Folk guitarists . Categories like Category:Neighborhoods in Seattle which are "sort of flat" lists. For example, Category:Admiral District, Seattle, Washington is a child of Category:West Seattle, Seattle, Washington , and both of the latter are directly children of Category:Neighborhoods in Seattle . Why? Because the Admiral District is part of West Seattle, so it certainly belongs in Category:West Seattle, Seattle, Washington , but anyone who doesn't know the city well would probably not try to look it up there, so they should be able to find it directly in Category:Neighborhoods in Seattle ; it is, after all, a neighborhood in its own right. This is an example of something that I suspect comes up more widely than we might at first think, because almost by definition, most of us are not subject matter experts in a large number of subjects, and it takes a subject matter expert to set it up right so it is easily used by the non-expert. Categories that are intended as non-diffusing. For example, we have a discussion going on right now that possibly (with some relatively few exceptions) subcategories for gender should be non-diffusing. If we went that way, it would be appropriate for a category for a person to be in both Category:Guitarists and Category:Female guitarists , but probably we still would not want to have that person category in both Category:Guitarists and Category:Folk guitarists . Categories like Category:Neighborhoods in Seattle which are "sort of flat" lists. For example, Category:Admiral District, Seattle, Washington is a child of Category:West Seattle, Seattle, Washington , and both of the latter are directly children of Category:Neighborhoods in Seattle . Why? Because the Admiral District is part of West Seattle, so it certainly belongs in Category:West Seattle, Seattle, Washington , but anyone who doesn't know the city well would probably not try to look it up there, so they should be able to find it directly in Category:Neighborhoods in Seattle ; it is, after all, a neighborhood in its own right. This is an example of something that I suspect comes up more widely than we might at first think, because almost by definition, most of us are not subject matter experts in a large number of subjects, and it takes a subject matter expert to set it up right so it is easily used by the non-expert. Depth: interesting thoughts, certainly a reasonable hypothesis, it will be interesting to see what we find when applying this to actual data. Action mode: glad to hear there won't be one! I assume "the tool only compares files" means "the tool only compares categories for a file, not parent categories for a category," correct? "Excluding files one by one doesn't work here": why not? I wouldn't suggest completely excluding the file, just having a way for the user to note--in a template on the file page--that a particular apparent OVERCAT had been noted and signed off. Template probably should also add a maintenance category so people can readily find these. I agree that this would not lend itself to a centralized list. "the tree structure does not allow for distinguishing between the two cases": I don't see anything more difficult in marking this sort of relationship in an exception list than the other. I agree with the importance of a prototype and actual data. A better term would be removing "redundant" categories. People use overcategorization to mean a few different things, like adding a category of each person mentioned in a pdf book (indexing), or creating categories that are the intersection of two existing categories (left handed female writers). -- RAN ( talk ) 03:44, 1 September 2026 (UTC) Reply I would like to see the process automated. It seems a clean up process that automation would be perfect for. We could also use a tool for looking for and making flat lists, where they are currently absent. -- RAN ( talk ) 20:04, 2 September 2026 (UTC) -- RAN ( talk ) 20:04, 2 September 2026 (UTC) Reply @ Jmabel : , Yes, exactly. When I say the tool only compares files, I mean it checks whether a file located directly in category A is also found at some level below A. It doesn't attempt to detect redundant relationships between the categories themselves. Therefore, cases like flat lists or "Neighborhoods in Seattle" fall outside the scope of this tool's checks. Regarding the tagging of individual files, I think you're right. I was trying to avoid adding permanent maintenance templates before knowing how frequently these cases actually occur. However, there are likely two distinct situations: a category relationship that is intentionally non-diffusing, and a specific file where both categories make sense based on what the image shows. A category-level exception might resolve the first case, but not always the second. For the prototype, I prefer not to address this just yet. I want to see the actual figures first. If the same false positives keep appearing, we can determine whether it's better to set exceptions at the category level, the file level, or perhaps both. @ Richard Arthur Norton (1958- ) : , I agree regarding automating detection; that is the tool's goal. I am more cautious about automatically removing categories. The category tree indicates that the same file appears in both a parent category and a subcategory, but it doesn't tell us the reason. For example, a photograph might actually show a building and the street, or several people, even if only some of them have their own category. In these cases, automatically removing the parent category could make the categorization worse. That’s why I think the first version should be limited to locating the cases, grouping them based on the parent/subcategory relationship, and displaying them to the user. It can also recognize known cases of non-diffusing categories when they are explicitly marked. This way, I can test it with real categories and manually review a sample. That should give us a clearer idea of ​​how many results are truly redundant and how many are intentional. If the results show that some cases can be handled automatically without risk, I think the automation of removal as a separate step could be discussed later. And yes, I agree that "redundant parent category" is likely a more suitable term than "over-categorization," since the latter can have several different meanings. The flat list tool also seems useful, but I believe it addresses a different issue, as it focuses on relationships between categories rather than on files appearing at different levels. Wilfredor ( talk ) 15:31, 3 September 2026 (UTC) Reply Severe bug in the frontend file cache servers (not serving the effective last version of any original file) There's a severe scheduling bug in the Wikimedia file server cache (for the "original source" files), which does NOT reflect the LAST version of ANY updated file, but ALWAYS serves some previous version BEFORE the last update. I think that when a file is updated, the file server cache incorrectly receives an update event much too early, and then updates itself before the file has been actually stored and made available on the file storage server. This bug does NOT affect the thumbnail generator which correctly uses the last version and updates the PNG thumbnail correctly, because it receives the update event correctly after the file was actually stored on the file server. You can wait for hours or days, there's no way to have the "original source" file made available via its standard (undated) link (e.g. https://upload.wikimedia.org/wikipedia/commons/f/ff/U1CC43.svg , instead of https://upload.wikimedia.org/wikipedia/commons/archive/f/ff/20260902082205%21U1CC43.svg which is supposed to be the link for the version dated 2026-09-02 08:22:05 in the history, but is in fact a link to the version immediately before it!) This is NOT specific to this file, in fact I've seen this bug in many other files whose updates were NEVER reflected in their original versions (i.e. not the generated thumbnail which are correct), many days (or months!) after their updates. Attempts to fix this by uploading the exact same content has no effect (the frontend considers this is a duplicate upload, and discards the upload). If you upload again the "original file" that you've downloaded from the top of the file history, you are in fact uploading an older version! Attempts to fix this by editing the file description page has no effect on this bug. Always, the history shows links to the incorrect (non-thumbnail) dated versions. This means that we can NEVER correctly update the original files (with the exception of their thumbnails), as we are always serving original files one (or several) versions before! The only workaround for now is to upload an additional "nulledit" file (with some "invisible" change, e.g. a non-significant space in SVG files, or in some internal file metadata): this works sometimes, but not always as in the previous example where a nulledit upload was made in an attempt but still used the 2nd version, then a revert which is still served with the 2nd version (but the dated version with the nulledit is correct...). In summary the content of the Wikimedia file cache is completely inconsistant with the effective file versions. I found no way to force the frontend file cache servers to download again the effective file version from the backend storage servers (e.g. by appending some dummy query string such as "?action=purge" to the "upload.wikimedia.org" link); the frontend continues to maintain its own old local version (for extremely long time which is constantly extended as long as the file is demanded because the frontend is never informed that there was an update was available, even days, weeks, or months before). The bug also affects the "file preview" (e.g. when you click any file in Commons to display the file in "full screen" mode, it also shows an old version). I consider this synchronization bug (between the inconstant frontend file cache servers, and the backend storage servers which superficially seem correct, as these latter servers are used by thumbnail generators) being severe everywhere in Wikimedia for three major reasons: It affects countless files that need to be legitimately updated on Wikimedia Commons, but also files stored in other Wikimedia wikis (e.g. in any localized edition of Wikipedia when these files are not accepted in Commons due to licencing exceptions). The displayed file histories are completely inconsistant! The bug is independant of the file content type (not specific to SVG): this same bug occurs as well for PNG, GIF, JPEG images, as well as PDF or DejaVu documents, or audio and video files! Reverting any file to a previous version does not work (except for their generated PNG thumbnails), and files that must be reverted, because of an unexpected error (e.g. from any user that used the wrong filename and unepectedly overwrote the incorrect file), or because of some users voluntarily damaging file contents with abusive uploads (the revert from the file history also does not work, except for the served thumbnails). This creates severe maintenance problems against user abuses or errors, or for any legitimate fixes that may be desirable and needed. Transfering any file from Wikipedia to Commons may in fact transfer an old version that was updated on Wikipedia, where the correct last version will be permanently deleted just after the transfer (an no more history available in Commons or in Wikipedia to find the correct last version). This bug is reproducible everywhere (you can try with your own file, upload it, make a correct file description page with the required licences, date, your author name, and relevant categories, then update the file content several times with successive visible edits, look at the file description page and find a logic to the displayed file history, but don't look just at the displayed list of thumbnails: click each version thumbnail to see the full version and you'll see that they don't match...). -- verdy_p ( talk ) 08:39, 2 September 2026 (UTC) Reply Help in Category:Falcon 9 by flight I want to kindly request everyone interested to help in categorising the images present on Category:Falcon 9 Starlink by flights and Category:Launches of Falcon 9 . Abdullah1099 ( talk ) Template:Countries of Asia Hello everyone, In the template {{Countries of Asia}} , the entry for Israel has been removed and replaced with Palestine. I wasn’t able to find the edit that caused this change. Could someone help locate the source of this edit? -- Geagea ( talk ) 07:06, 3 September 2026 (UTC) Reply The recognition of Israel is limited too. I certainly do not want to open the can of worms of defining what is limited and what not, but if someone says the template "Countries of Asia" is taking a political stance they may have a point. See: Regards. Strakhov ( talk ) 16:40, 7 September 2026 (UTC) Reply PIP removal requests on "embarrassment" Recently, I have seen several instances of individuals nominating photos of themselves (no explicit evidence they actually are the person in question) for deletion on the allegation that it causes embarrassment. Commons:Photographs_of_identifiable_people#Removal_requests does state that embarrassment may be a reason for deletion, but does not guarantee this. Now, the claim that a photo causes embarrassment is difficult to assess when looking at these photos, as it is somewhat subjective. However, many such requests concern photos in which there is basically no element of degrading or insulting content. This includes many neutral portrait photos or screenshots taken from videos. We should obviously not cave to every allegation that a photo is embarrassing, as this could quickly become a tool of censorship for individuals wishing to promote a particular image of themselves. Since COM:PIP does not elaborate on what constitutes embarrassment, can we come up with some guidelines for future deletion discussions? – Howardcorn33 ( 💬 ) 09:57, 3 September 2026 (UTC) Reply Just a few recent ones: Commons:Deletion requests/File:Silvia Leal.jpg Commons:Deletion requests/File:Shana Pearson dehors Casa Del Popolo.png (BullDoser !) Commons:Deletion requests/File:Fa-مجتبی عیسی پور.ogg Commons:Deletion requests/File:Anne C, Agungsn, Aesthetic of Me 5-5-2026.png Commons:Deletion requests/File:Abendrot Rittersgrün.jpg Copyright status about currency of Bulgaria When Bulgaria replaced to euro , it is still protected by copyright after replaced to euro? However, what is the current situation about Bulgaria and the euro. like Ireland , the currency is copyrighted; But it not mentioned in the section mentioned here , any questions that currency has copyright that should not allowed to upload here due to restrictions from Bulgarian National Bank ? TentingZones1 ( talk ) 12:21, 3 September 2026 (UTC) Reply Server side error Some of my recent edits on Wikimedia Commons did not register due to " Server returned error: HTTP 503. " In one instance of using VisualFileChange , I had to manually add the request I made because of Error: -- NO TASK DESCR. FOR mdUploaderNotified PLEASE ADD IT -- ##### Server status: 503 - Error: . This server-side problem also extends to editing some pages using source editing, needing a few "TRY AGAIN" clicks. I suspect much of the issues concern uploading of edits, because it seems fine whenever I "download" data like loading any of the pages here (file pages, Commons policy pages, categories, watchlist, galleries etc.). (Very likely, I experienced another " Server returned error: HTTP 503. " while saving this topic.) JWilz12345 ( Talk | Contributions ) 03:06, 4 September 2026 (UTC) Reply 1970 Yugoslav film poster with locally redrawn Disney characters I would appreciate opinions on the copyright status of a 1970 Yugoslav theatrical poster before uploading it. The poster was issued by Kinema Sarajevo for Remek djela Volt Diznija ("Walt Disney Masterpieces"), a theatrical compilation of eleven Academy Award-winning Disney shorts. Contemporary Yugoslav newspaper listings document the compilation's theatrical release in December 1970. The poster appears to be a locally produced Yugoslav design rather than a reproduction of a French, American or other Disney campaign poster. Its composition and lettering are original, and the characters appear to have been independently redrawn by a local illustrator in a noticeably simplified, non-professional style rather than reproduced from film frames, model sheets, or existing Disney promotional artwork. Under the former Yugoslav copyright rules applicable in Bosnia and Herzegovina, works of applied art published before 1 January 1977 had a 25-year term. For works published before 1 January 1971, Commons' Bosnia and Herzegovina copyright guidance indicates that the copyright had already expired before the URAA restoration date. The issue I am uncertain about is the treatment of the characters depicted in the poster. It includes locally redrawn representations of Mickey Mouse, Pluto, the Three Little Pigs / Big Bad Wolf, Ferdinand the Bull and other characters associated with the films in the compilation. I am not arguing that the underlying Disney films are public domain. The narrower question is whether an independently drawn 1970 Yugoslav poster, whose own copyright has expired, remains non-free merely because its local illustrator depicted recognizable characters from the advertised films. the drawings do not appear to reproduce identifiable film frames; I have not found evidence that they reproduce Disney model sheets or existing poster artwork; the Yugoslav poster has a different composition from the known French/Belgian campaign material for the same compilation; the characters appear to have been redrawn locally rather than mechanically copied. Would Commons treat the surviving character copyrights as preventing upload of the entire poster, or can the poster be considered a public-domain work of applied art where the particular drawings themselves are independently created? If useful, I can provide a high-resolution scan and side-by-side comparisons with the known foreign campaign posters and film imagery. Relevant copyright guidance: Commons:Copyright rules by territory/Bosnia and Herzegovina Commons:Derivative works Commons:Character copyrights Commons:Fan art Thank you. User:Baronmilone , 18:41, 4 September 2026 (UTC) Reply Streetcar image I found an image I want to use of a streetcar here (full image here ) and I did some research and I found it in a magazine article from 1964 stating the image was from a former resident of Martinsburg. This was the earliest mention of it. The street railway operated form 1891 to 1893. I don't know if this is copyrighted, it is on Flickr , but I doubt he is the original owner. Wobs100 ( talk ) 02:41, 5 September 2026 (UTC) Reply Photo challenge July 2026 results Congratulations to @ Krigore , @ Sindugab and @ Gorillo.Chimpo . Sekidoki (aka Taiwania Justo) is speaking ( Reception Room ) 06:35, 5 September 2026 (UTC) Reply Wikimedia Commons turned 22 Some ice-cream for the Occasion! EugeneZelenko ( talk ) 12:35, 7 September 2026 (UTC) Reply commons-nominator, nominations without leaving the page you are in I comment here a script I maintain since some time, commons-nominator , because I just added a thing that maybe is useful for more people. In a file page it puts a row of links that nominate the file to FP , QI and VI , each one with its dialog and one single edit per click, and next to them it also schedules a featured picture as Picture of the day in the next free date, sets the picture as the image of its Wikidata item when that item still has none, and searches which English Wikipedia articles the picture could illustrate, which is what a Commons FP needs before it can be a featured picture over there. What I added now is that all this arrives to the category pages too, written over the thumbnails themselves, so you can go through a whole category deciding while you look at the pictures instead of opening them one by one. Every picture that is still not a Quality Image gets a small QI button, in green when the file is already a Featured Picture, because a FP without QI is almost always an oversight and not a decision, on my own files 84 of my 212 featured pictures were missing it. Pressing it opens the normal dialog with the short description already filled from the file, and when you finish you stay in the category. In the FP nomination pages it also adds rename buttons and it warns you about the two open nominations rule before you edit instead of after. It only offers what each process could accept, so it stays quiet on videos, on small images or when your five QI nominations of the day are already used, and it never writes anything without a click. Documentation and installation in User:Wilfredor/commons-nominator , and I read everything that you tell me is wrong with it. Wilfredor ( talk ) 17:58, 7 September 2026 (UTC) Reply Images and files not loading properly on Commons Hi, I have noticed that when I am uploading pictures and PDFs to Commons recently, they are sometimes not rendering properly when I open the file page. Examples: https://commons.wikimedia.org/wiki/File:Phylloscopus_forresti_-_James_Eaton_-_338161400.jpeg https://commons.wikimedia.org/wiki/File:Pelargopsis_melanorhyncha_-_James_Eaton_-_435252346.jpeg https://commons.wikimedia.org/wiki/File:Photo_Guide_to_the_Lycaenidae_of_Bolivia.pdf Mitsingh ( talk ) 08:28, 8 September 2026 (UTC) Reply A script for the wikitext and structured data coordinates that disagree A file can carry its position twice, as {{Location}} in the wikitext and as P1259 in structured data, and nothing keeps the two honest. Category:Pages with local camera coordinates and mismatching SDC coordinates has about 19,000 files where they do not match. User:Wilfredor/commons-sdc-coords shows both sides on a file page with the distance between them and a button to fix whichever one is wrong. On a category page it reads the whole category and lists only the files where the camera EXIF settles which side is right, and then writes them in one run with pause and stop. It carries on from where the last run stopped, or you can ask it for a random sample instead, because a category that size never gets read in one sitting. In a batch it only ever writes structured data, never wikitext, because the structured data was often copied from the EXIF by a bot and rewriting somebody's corrected wikitext on that evidence would undo human work at scale. And it will not touch a file where the camera is as far from one side as from the other. I ran it over 670 files and 654 were written. It also purges the pages it corrects so they leave the tracking category, which does not happen on its own because the statement lives in a different slot from the wikitext. Source and documentation at User:Wilfredor/commons-sdc-coords . Reports and complaints welcome. Wilfredor ( talk ) 13:01, 8 September 2026 (UTC) Reply Commons community Commons maintenance