Commons:Village pump

Shortcut: COM:VP

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓

COMMONS DISCUSSION PAGES 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 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 Bureaucrats' noticeboard CheckUser requests Oversight requests Telegram IRC webchat Commons mailing list (archive) Commons' bugs on Phabricator Welcome to the Village pump 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/2025/12. 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. 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. 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

#	💭 Title	💬	👥	🙋 Last editor	🕒 (UTC)
1	Data graphic resources?	6	1	Prototyperspective	2025-12-08 22:04
2	Warning for users	40	16	RoyZuo	2025-12-02 21:32
3	Category:Line art without P180	20	5	ReneeWrites	2025-12-02 18:43
4	Video and audio plays	5	2	Doc James	2025-12-03 20:51
5	Is there a bot that adds old style interwikis to wikidata?	3	1	Immanuelle	2025-12-04 09:58
6	MP3s are allowed.	8	6	TheDJ	2025-12-08 13:06
7	DEMO.MID	1	1	DanielParoliere	2025-12-04 12:32
8	Files with no machine-readable source	4	3	Prototyperspective	2025-12-08 20:39
9	Community Wishlist – Voting open for Commons-related Wishes!	5	3	TheDJ	2025-12-08 12:55
10	favicon.ico too dark at night	2	2	Mod creator	2025-12-05 23:17
11	Do we have a category for text files that need OCR run on them?	3	3	Prototyperspective	2025-12-08 20:38
12	Lat/Lon: DD vs. DMS	2	2	TheDJ	2025-12-08 12:57
13	Hatnotes in History maps of Europe	5	3	Enyavar	2025-12-08 04:11
14	Uploading cubemap projections of 360 degree panoramas	8	6	SimmeD	2025-12-09 00:02
15	Why is Category:Mute (toki pona) not connecting to tok:nimi:mute as per the interwikis	4	3	Immanuelle	2025-12-09 05:08
16	Scans of papyri	7	5	Prototyperspective	2025-12-09 12:08
17	Otto Warmbier is missing	7	5	SimmeD	2025-12-09 04:32
18	Near-empty Category:Statistics about communication	3	2	Prototyperspective	2025-12-09 12:06
19	Does en:WP:NBZ apply for Commons? (in regards to South Tyrol/Südtirol/Alto Adige)	3	3	Nakonana	2025-12-09 16:33
20	Government agencies and acronyms	4	4	Ooligan	2025-12-09 20:13
21	Formatting Wikidata query	1	1	Yann	2025-12-09 16:42
22	Attention filemovers	1	1	Geoffroi	2025-12-09 21:21

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

Village pump in Sabah, Malaysia. [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Commons:Village pump/Proposals#Temporary account IP viewer policy (6 September 2025) User talk:CommonsDelinker/commands#Replace images with .svg version (5 August 2025) Category talk:Heroes' Cemetery in the Philippines#RfC: Cemetery name (18 July 2025) Discussion on Copyright law of North Korea (16 March 2025) Hosting of free fonts in Commons (18 July 2024) Template: View   ■ Discuss    ■ Edit   ■ Watch

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

November 06

Data graphic resources?

Commons:Free media resources/Datagraphics is a relatively new page for databases with free data graphics like charts that could be uploaded to Commons.

It still only has few sites – do you know of any further ones?
-
Recently added this resource but it's mostly just German-language data graphics. It would be great if somebody could upload the graphics from there that aren't yet on Commons. Until now, doing so was just in my private todos but I may never get to uploading more of these. For an example, see Category:Meat Atlas which contains charts and maps about meat consumption (not just in Germany but also worldwide; translatable).

--Prototyperspective (talk) 23:22, 6 November 2025 (UTC)

Seems like Eurostat could be added: according to this page The copyright for the editorial content of this website, which is owned by the EU, is licensed under the Creative Commons Attribution 4.0 International licence. There probably are more sites like it and maybe somebody here knows of or can find more.

There also are a few files in Category:Data visualization by Statista – is there a way to search for the subset of files in Statista that are CCBY/CCBYSA?

May be good to create a Commons:Batch uploading request for these if that's anyhow possible (and it's probably possible to scrape the sites in structured ways even if they don't have APIs). For Our World in Data, the batch uploading is done semi-manually/automatically via the OWIDImporter which is linked on that page. Prototyperspective (talk) 12:03, 13 November 2025 (UTC)

I've heard NOAA is another resource for charts but I could not find a page on their site for finding and/or searching these – does somebody know? There probably are quite a few more government agencies with lots of data graphics. Prototyperspective (talk) 21:25, 19 November 2025 (UTC)

• I just added CDC Data Dashboards, Visualizations, and Query Systems – it contains lots of useful visualizations not yet on Commons; maybe somebody can upload some of them
• See also Commons:Village pump/Copyright#Are World Inequality Database data graphics in the public domain? I think it has to be removed again.
• I'm sure there must be at least some more pages of US agencies who publish data visualizations and probably also some of other countries.

Prototyperspective (talk) 15:52, 26 November 2025 (UTC)

Well, I can't find and don't know of all the major resources myself. So far the page only has resources I found myself. Is there maybe a tool to scan top sources/websites of files in Category:Data graphics (especially of used files in it)? And I removed the World Inequality Database for the list and made it a permission request to ask for their data graphics to be put under a free license. Prototyperspective (talk) 00:22, 2 December 2025 (UTC)

• Added a few more: Klimadashboard (German-language data graphics about climate change & GHG emissions; as a result of a request at Commons:Permission requests), US-specific government resources (United States Census Bureau visualizations, U.S. Cancer Cases and Death Statistics, U.S. Mortality Data Dashboards, U.S. Bureau of Labor Statistics)
• Are there CCBY data graphics on https://observablehq.com and if so how to find/link them? There are many user-made charts I think and I don't know if there's a way to see CCBY-licensed ones. Same for Tableau Public except that I have more doubts there's CCBY ones there.
• Are there any data visualizations in https://data.worldbank.org/ that aren't also in OWID or in a more complete/up-to-date version in OWID? For example, if I try to upload this data visualization about prevalence of anemia in pregnant females as SVG I get this error in the UploadWizard (and also can't edit the svg in a text editor): This SVG file contains an illegal namespace "http://www.w3.org/1999/xhtml" and when I download it as PNG just a corner of the image is visible and for JPG it's entirely blanks. However, OWID has a map that I just uploaded for the year 2023 while this is for 2019. Since many OWID visualizations are based on WB data, I wonder if there's any WB visualizations that aren't also visualized via OWID software. For example, I've noticed that OWID maps are always at most at the country level but never at higher resolution than that so maybe this or another site has also such choropleth maps.

Prototyperspective (talk) 22:04, 8 December 2025 (UTC)

November 08

Warning for users

Time and time again we see users trying to delete their own uploads, only to find out that they cannot do that themselves, and they can rarely convince sysops to delete for them (as the current practices show).

But this reality, the lack of utility to delete one's own content, is not communicated to the users at all. If you go through registration and every step in Special:UploadWizard, this rule is not mentioned at any point. This is a very different rule from what people can expect on any other major file hosting sites such as flickr, youtube... where users can always delete their own uploads anytime for any reason or no reason at all.

So I suggest, that this rule be clearly communicated to the users, and that there should be a write-up documenting this rule as well as its origin and rationale.--RoyZuo (talk) 20:50, 8 November 2025 (UTC)

written as i am fed up with mistreatment of fellow users as recently as Commons:Administrators'_noticeboard#c-Olga_Rithme-20251107145500-Appealing_decisions_that_contravene_a_set_of_rules.--RoyZuo (talk) 20:50, 8 November 2025 (UTC)

It is hidden in the license conditions shown on the "Learn" page at the UploadWizard and at the linked license texts. And of course it is also in the Terms of Use. We could make this more clear if we would have a definitely needed rework of this info graphic. GPSLeo (talk) 21:13, 8 November 2025 (UTC)

it is not explicitly spelled out that "you cannot delete your user-generated content" in https://foundation.wikimedia.org/wiki/Policy:Terms_of_Use .

when all other major websites, which also support certain "free licences" fit under wikimedia commons definitions, allow users delete their uploads, most users dont realise they cannot do the same on wikimedia commons until they want to delete something, and that this surprise is because wikimedia commons prioritises irrevocability of the licence over user experience. RoyZuo (talk) 21:34, 8 November 2025 (UTC)

I find this very clear: "e. No revocation of license: Except as consistent with your license, you agree that you will not unilaterally revoke or seek invalidation of any license that you have granted under these Terms of Use for text content or non-text media contributed to the Projects or features, even if you terminate use of our services." This in theory event forbids making a deletion request. GPSLeo (talk) 22:24, 8 November 2025 (UTC)

Something this vital shouldnt be hidden in the first place at all Trade (talk) 20:23, 9 November 2025 (UTC)

This rule was clearly communicated to this user multiple times. Maybe not at the upload stage but certainly once they started filing deletion requests and had those requests denied. ReneeWrites (talk) 10:12, 9 November 2025 (UTC)

I actually broadly agree with RoyZuo on this. I've always found it weird that there is no warning in plain language in the upload process about the lack of simple deletion procedures for users uploading their own works to Commons. "License irrevocability" is quite a niche topic if you don't spend a lot of time on this and other Wiki project or work professionally in the realm of IP; many if not most people have no idea what that means or just assume it's a technical requirement akin to allowing cookies on a website. I think that's evidenced by the steady stream of users over the years who have tried at the help desk, village pump, and other forums to get their content deleted and were baffled by the idea that they had no recourse to delete their own work. There should be clear, plain language in the upload process that explains how, barring copyright questions or another legal issue and following a 7-day courtesy window, works uploaded to Commons will not be deleted at the uploader's/author's request.

And to be clear, I'm not saying it's good that so many people don't understand free licensing or the preexisting written warnings/caveats in the upload process; it just seems to be a fact. I believe we could avoid a lot of headaches by adding plainer language. But that would also probably lower the rate at which users complete the upload process, as a warning like that might scare some people off, which, if I were being cynical, I would assume is why the language has never been added (after all, who wants to be responsible for on average less content being added to Commons?). But the ethical choice appears to be better informing uploaders about the long-term deletion policies in the clearest, most non-technical language possible. 19h00s (talk) 13:26, 9 November 2025 (UTC)

I agree with this. Ymblanter (talk) 16:50, 9 November 2025 (UTC)

"works uploaded to Commons will not be deleted at the uploader's/author's request." But we already do delete works uploaded to Commons at the uploader's request. It's just not consistently Trade (talk) 20:30, 9 November 2025 (UTC)

Provided the deletion is requested within 7 days after upload and the work is not currently in use on a Wikimedia-project. --Túrelio (talk) 20:53, 9 November 2025 (UTC)

We have deleted files long after 7 days several times Trade (talk) 14:30, 10 November 2025 (UTC)

Sure, but that is not the rule. In such cases often the file is also out of scope and there may be further aspects. But the uploader should be communicated the valid rule, because they have a right to it. --Túrelio (talk) 15:43, 10 November 2025 (UTC)

I disagree. A lot of the files i see deleted after a week would not have survived a typical "out of scope" deletion request Trade (talk) 22:23, 10 November 2025 (UTC)

@Trade: We are allowed, but not required, to extend a courtesy. Lying to us and/or threatening legal action certainly both decrease the chance of us extending a courtesy. - Jmabel ! talk 23:03, 10 November 2025 (UTC)

Can you expand on this? I believe you're hinting at a perceived double standard or deference on the part of Commons or WMF to certain users or rightsholders (or types of users/rightsholders) when they request their content be deleted, but I don't want to incorrectly assume. I think that's an important separate conversation in that we shouldn't, for example, allow large corporations to remove validly licensed content while not allowing individual authors/uploaders to do the same simply because one has more structural and financial power. But this conversation seems to be specifically about the average, or very new, user, who does not fully grasp the ramifications of their choices when freely licensing and uploading their work to Commons. Again though, I could be misinterpreting you. 19h00s (talk) 16:50, 10 November 2025 (UTC)

Where do we allow large corporations to revoke their licenses? We hand mass deletions because an employee published something without the corporation having the permission from the rights holders to do so. But this is something totally different. GPSLeo (talk) 19:06, 10 November 2025 (UTC)

I was responding to Trade, asking about what they were implying with their comment about policy not being applied "consistently". I gave theoretical examples of what I believed they were implying (e.g., that there may have been deference or double standard in the way certain rightsholders' requests were handled). I never said Commons in fact does these things. 19h00s (talk) 19:32, 10 November 2025 (UTC)

I am moreso implying that some users lean heavily towards courtesy and others towards keep. Whether or not the deletion goes through is mostly dependent on which group of users decided to stumble upon the DR at the given time

At this point dealing with courtesy deletion requests is little different than using a random number generator to determine the outcome Trade (talk) 22:27, 10 November 2025 (UTC)

@19h00s while i dont know what User:Trade might actually mean, here's a separate answer to your question:

Commons:Village pump/Archive/2025/03#March 2025 update from WMF Legal on "Vogue Taiwan and possible Copyright Washing" discussion, not that long ago.

the unfortunate thing here, is that these good hearted contributors dont have money to lawyer up.

Conde Nast can get away by merely saying they made an error.

meanwhile, the absolutists here and there (Commons:Administrators'_noticeboard#c-Olga_Rithme-20251107145500-Appealing_decisions_that_contravene_a_set_of_rules) dont realise that commons users are at the most only given t&c in "browsewrap manner via hyperlinks alone" which is void as per Nguyen v. Barnes & Noble, Inc.

also, when users are never displayed the full t&c, it's probably invalid as per Specht v. Netscape Communications Corp.

and clearly, the t&c linked in the uploadwizard doesnt refer to the file uploaded, because in a single sentence it says "By clicking "publish", you agree to the terms of use, and you irrevocably agree to release your contribution under the Creative Commons CC0 License." even if you are releasing your photo in any licence other than cc0. the only logical understanding is this only explicit mention of "terms of use" here covers "your contribution" related to "captions and other additional information such as main subjects and location (NOT the file)".

so if they have a lot of money, they could quite possibly do something to have the same treatment as corporations.--RoyZuo (talk) 22:30, 11 November 2025 (UTC)

I'm not a very sympathetic ear on the Vogue Taiwan case, as I vocally approved of deletion and still agree it was the correct decision; corporate structures are opaque for a reason, they give companies plausible deniability and legal/ownership "air-gaps" for situations just like that one, meaning our obligation to protect the project and reusers from possible (and possibly valid) litigation or damages must necessarily trump our desire to retain the content. Indeed though, Vogue Taiwan is what I thought Trade was referring to (clearly I was wrong), and I do believe we generally shouldn't let corporations with capital or power dictate our decision-making purely because they have the means to fight a legal battle. But that is a complex calculation that involves different levels of risk for WMF, Commons, and the Wiki community broadly.

On the whole though, I still completely agree that clearer language in the upload process about the slim prospects of courtesy deletion and lack of long-term deletion procedures would solve a lot of issues and prevent a lot of stress for both uploaders and Commons. 19h00s (talk) 23:34, 11 November 2025 (UTC)

and i'll end off my comments by this. what disgusts me the most, is certain users' hostility against other users and indifference to other users' needs. they choose to needlessly antagonise and bash other users instead of seeing and understanding people's needs and working kindly and gently with them.

i see this problem, i come up with this solution of a warning. those users see this problem, they bully the users in need and drive them away. technical solutions cant solve attitude problems. RoyZuo (talk) 22:30, 11 November 2025 (UTC)

 Support for the proposal to very clearly explain/state our current rules for the deletion of own uploads in the basic tutorial for new users and also during the upload-procedure. --Túrelio (talk) 20:58, 9 November 2025 (UTC)

The Commons:Upload page does have a warning (in bold even!) that licenses cannot be revoked. If people overread that part of the formular, it is their own loss.

However, I am surprised that the much-advertised Upload Wizard does not have a warning (I could find): The licensing part says currently: All media uploaded to Wikimedia Commons are free for anyone to use and share anywhere on internet or off internet. To ensure the work you upload is copyright-free, please provide the following information. (...)
That means I  Support the suggestion: Between these two sentences in the Wizard, we should add another sentence, that could read like this: "Please note that you can usually not revoke your permission later."(en), "Bitte beachte, dass du die hier gegebene Einwilligung später nur in Ausnahmefällen wiederrufen kannst." (de), "Veuillez noter que vous ne pouvez pas révoquer votre autorisation ultérieurement, que dans des cas exceptionnels." (fr) and so on. In the spirit of making the sentence less legalese, I exchanged "licence" with "permission", and kept it short. If someone is alarmed by this statement, they should stop uploading and find the relevant rules. --Enyavar (talk) 14:35, 14 November 2025 (UTC)

Concur, though "usually can not" is better English than "can usually not". - Jmabel ! talk 19:44, 14 November 2025 (UTC)

Support.✅️

I'm not sure if this is still under discussion, but I agree with @RoyZuo and others who say that this should be stated clearly in plain English on the upload page (prior to uploading). Also, deleting from the website doesn't unilaterally equate to revoking the license, contrary to what someone suggested earlier. BetsyRogers (talk) 07:53, 15 November 2025 (UTC)

Very important point. Deleting a file here does in no way whatsoever "revoke" the licence granted by the author. It simply means that the file/the work is no longer publicly available on this website - the "deleted" work itself is still under the licence originally given. ~TheImaCow (talk) 20:31, 19 November 2025 (UTC)

 Support -- Ooligan (talk) 08:55, 22 November 2025 (UTC)

I share the same view, that a user's deletion of his/her files on a website doesnt mean that s/he is revoking the licence granted to any other user re-using that file.

Suppose I upload the same photo here and on flickr under the same licence. I then want to delete only one of them, but the current situation is such that I can only delete the flickr one and keep the one here, but not the other way around. RoyZuo (talk) 08:34, 28 November 2025 (UTC)

• Haven't read all the above, sorry, but what I would like to see is a facility for contributors to be able to delete their own content for a short window (exact duration TBD) after upload. Surely this is reasonable so that mistakes can be quickly corrected. ITookSomePhotos (talk) 19:29, 29 November 2025 (UTC)
  • In practice, something quite like that that exists with {{SD|G7}}, but requiring an admin to have a chance to look at the file; I'm a bit skeptical about a feature that would make it easier for someone to pass below notice if they were doing this excessively; also, in particular, it would provide a way for someone to sneak CSAM onto our servers and possibly not get spotted doing so (not that the CSAM would be publicly visible, but that it could imaginably get WMF or others in trouble).

If it could be done with good safeguards, then I'm not opposed. - Jmabel ! talk 06:41, 30 November 2025 (UTC)

Isn't this the kind of situation that Section 230 protects the foundation from? Trade (talk) 07:05, 30 November 2025 (UTC)

Section 230 might or might not protect them, depending on whether it was determined that they were doing due diligence. This is exactly why we currently have a different reporting mechanism for CSAM material, and it actually gets hard-deleted, unlike other deleted content. It looks to me like the proposal would bypass that. - Jmabel ! talk 00:21, 1 December 2025 (UTC)

If this is an issue then "soft" user deletions could be reviewed by admins for hard deletion. ITookSomePhotos (talk) 10:15, 1 December 2025 (UTC)

•  Strong support: I agree that Commons' general limitation on deletion, different than any other media sharing site, is in no way sufficiently explained in the Upload Wizard or in our policies in general. But walking through the Upload Wizard today, I don't even think the CC licenses are explained sufficiently. Our license tags like {{Cc-by-sa-4.0}} have very high-level summaries of the license that are as clear and succinct as possible. The Upload Wizard seems to summarize this even further, all the way to requires the person using this media to give appropriate credit, which in no way explains to the user what they're getting into, including irrevocability. IMO the Upload Wizard should display the full text from our license tags while the user selects their license, so that they can make a fully informed decision. Consigned (talk) 13:49, 30 November 2025 (UTC)
• I  Support a clearer warning that 1. most users cannot delete their own uploads; 2. barring the first week, we do not accept deletion of files with a clear educational use and a proper license. Yann (talk) 14:10, 30 November 2025 (UTC)
  • +1 to that. - Jmabel ! talk 00:22, 1 December 2025 (UTC)
•  Support also to including a clearer warning regarding the limits/barring on deletion of uploads in the uploading process itself. - Theriocephalus ! talk 10:35, 1 December 2025 (UTC)
• I chimed in earlier but just to formalize it:  Support for a clearer/less technical warning in the upload process explicitly spelling out that most users do not have the power to delete their own uploads and that user-authored uploads will not be deleted after seven days barring copyright or scope concerns. --19h00s (talk) 22:57, 1 December 2025 (UTC)

i wrote a draft for a brief guide for newbies: Commons:Must-read for uploaders. feel free to improve. RoyZuo (talk) 21:32, 2 December 2025 (UTC)

November 22

Category:Line art without P180

What is the purpose of this category? And why is this category full of art that is not line art? --EncycloPetey (talk) 16:10, 22 November 2025 (UTC)

@Jerimee: this appears to be your handiwork. What's going on here? And why are thousands of images categorized as lineart that aren't? ReneeWrites (talk) 16:33, 22 November 2025 (UTC)

Hello @ReneeWrites! I appreciate your help. This hidden category houses some of the images that have SDC with instance of (P31)→line art (Q365552) and lack depicts (P180)

The category has documentation on the talk page and I'm happy to improve that documentation.

One would need a narrow definition of "line" to access hundreds of images as miscategorized in this category. I find a more broad definition to be useful, considering that there 79,327,945 files without any P31 value. Broad categories are useful; categories are as unique and numerous as the items themselves have limited utility.

That said, I did immediately find one image that was miscategorized, and I'm sure there are others. The documentation on the category talk page has a few saved queries to help in that endeavor. -- Jerimee (talk) 18:09, 22 November 2025 (UTC)

@Jerimee: it looks to me like you have also applied instance of (P31) -> line art (Q365552) very arbitrarily to etchings, few of which are line art. - Jmabel ! talk 23:42, 22 November 2025 (UTC)

@Jerimee: "I find a more broad definition to be useful". It's not about applying a broad or narrow definition, but one that is accurate. Categories exist to catalogue specific types of images so that other people have an easier time finding what they're looking for. Categories that are bloated with content that doesn't belong in them are not more useful as a result, that's why they're not used in this manner. What definition of lineart have you been applying? ReneeWrites (talk) 11:19, 23 November 2025 (UTC)

You can turn off the visibility of hidden categories. And, yes, the goal is to make the images easier to find Jerimee (talk) 15:03, 23 November 2025 (UTC)

The question was "What definition of lineart have you been applying?". I, too, would like your answer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:04, 23 November 2025 (UTC)

Do you all not remember the conversation about this nearly a year ago? Each person on this thread was also on that thread.

The category itself can't be the problem, right? There are tons of this sort of maintenance category, typically without any sort of documentation at all.

I'm at a loss as to how to help. Can you tell me what problem you're trying to solve?

As far as what I consider line art:

• Art with distinct lines
  • Typically I try to consider what the specific digital representation looks like in and of itself, and not put too much emphasis on intent or the original. The file Jmabel mentioned is a useful example because it is of low enough resolution that the lines are hopelessly blurred. So I agree it is a poor example of line work.
  • Color washes applied over line art do not typically detract from line work
  • I'm happy to explain further if it would genuinely be useful - just let me know how much detail you actually want
  • I'm not wedded to the label; I'd be happy to use anything else sufficiently broad
• Here are a number of examples: Category:Line_art_without_P180
• I've bookmarked queries here, which I consider documentation: Category_talk:Line_art_without_P180
• My motivation is to make it easier to find images, especially via SDC.
  • Commons:Structured_data
  • Commons:Structured_data/Modeling/Depiction#Level_of_detail
  • ...structured data makes it possible to use Commons' media in new ways, and makes the files on Commons much easier to view, search, edit, curate or organize, use and reuse... Commons:Structured_data/About
  • {{Search instances|Q365552}} → find instances of line art (Q365552)
• A taxonomy only works by approximating; if it were perfectly accurate it would tell you nothing. A useful system of organization requires some degree of generalization.
  • w:On_Exactitude_in_Science
  • Which, to answer User:Jmabel, is why I tend to categorize etchings as line art. Applying both values to P31 would be even better IMHO, but of course this is debated. And I'm sure there are people that would say "this is not an etching, it is an Aquatint, Sugar Lift, Spit Bite, Mezzotint, intaglio etc"
    • find instances of etching print (Q18218093) returns 14 results
    • Etchings are typically considered coincident with line art.

I don't claim the authority to define these things with perfect certainty - I'm glad we have a variety of viewpoints. Jerimee (talk) 03:47, 24 November 2025 (UTC)

I remember User talk:Jerimee#Line art, where I objected to your categorisations (I still do), and Commons:Village pump/Archive/2025/01#Line art, where you did not contribute, and which remains unresolved.

User:EncycloPetey was the only other person to comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:24, 24 November 2025 (UTC)

@Jerimee: I noticed that you're still adding metadata and categories to non-lineart images despite this conversation being ongoing, could you please pause your activity until this issue is resolved? ReneeWrites (talk) 14:44, 24 November 2025 (UTC)

It should have stopped in January. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:58, 24 November 2025 (UTC)

While I appreciate the thoughtful and generous nature of this proposal, I have some reservations. Rather than list all my questions out here, perhaps you could point me to some past issues you have successfully resolved? Jerimee (talk) 17:43, 24 November 2025 (UTC)

Feel free to list any questions you have, that's what discussions like these are for. ReneeWrites (talk) 18:13, 24 November 2025 (UTC)

1. Can you tell me what problem you're trying to solve?
2. Perhaps you could point me to some past issues you have successfully resolved, so I can better understand how and if to participate
3. Are you speaking for yourself, or do you represent a group of editors, or do you have a special role that I should know about?
4. Am I interfering with your work in some way? I value your contributions

Jerimee (talk) 19:04, 28 November 2025 (UTC)

1: Categories exist to catalogue specific types of images so that other people have an easier time finding what they're looking for. Categories that are bloated with content that doesn't belong in them are not more useful as a result, that's why they're not used in this manner.

2: I'm a bit unsure why you're asking me specifically, since a Commons admin with long-standing experience in this area is also participating in this discussion.

3: Several other editors in this thread have also expressed frustration with your work, so it isn't just a one-to-one disagreement.

4: Does it matter? ReneeWrites (talk) 10:58, 29 November 2025 (UTC)

So should we just delete the category then? I don't really mind doing that. Jerimee (talk) 17:06, 29 November 2025 (UTC)

@Jerimee: The problem is the too-broad application of the term line art, the category is only a byproduct of that. I don't understand why "line art" became such a fixation when you yourself admit to not really knowing what it is. I saw that you're also applying other kinds of metadata where their contents are not as ambiguous, such as subject matter or the number of people it depicts. Why not continue in that area instead? Your efforts are more likely to be appreciated there. ReneeWrites (talk) 18:43, 2 December 2025 (UTC)

You don't appear to be taking this seriously.

If you don't stop voluntarily, until consensus is demonstrated, the next step will be to ask for administrative action to prevent you from continuing until it is. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 24 November 2025 (UTC)

Re: "I tend to categorize etchings as line art". Is there a reason for this tend? You've made assertions with no reason or authority or citations. I've looked at the relevant article on English Wikipedia, which, as a general article, is devoid of references and most of the gallery examples were added by a single individual last year without documentation. Most Wikipedias do not even have an article on "line art", and I own no good authoritative book on the taxonomies of art, but it the above reply I see no source for the taxonomy being applied, merely an appeal to inexactitude. --EncycloPetey (talk) 15:49, 24 November 2025 (UTC)

Certainly "line art" is a common enough term in graphics especially and in art more generally. Certainly the category makes sense in principle; the problem is that, at a quick assay, it looks to me like roughly half of what is here isn't line art. If these all have instance of (P31)→line art (Q365552), then that assertion is being made incorrectly as often as not. And while an etching can be line art, most etchings are not; they have solid areas, areas that have been etched with a wire brush where the individual lines are not under the artist's conscious control, etc. - Jmabel ! talk 16:26, 24 November 2025 (UTC)

November 28

Video and audio plays

Hey All, we at Wiki Med funded software to record how many times a video or audio file has been played and how much of the file gets played. It is live for all users on EU WP currently.[1] Is this something the Commons community would be interested in?

To activate one needs to add to this MediaWiki:Common.js this script[2]. The code itself being here User:Yaron Koren/tmh-engagement.js

Doc James (talk · contribs · email) 03:15, 29 November 2025 (UTC)

Interesting! How does this compare to the mediaviews tool? Example

Also see the wishes Analytics missing on Wikimedia Commons and Add view count to videos in the Community Wishlist. Which stats MVC displays seems to be a topic on the talk pages. m:Wiki Loves Broadcast about Category:Videos by Terra X for example claims Over 90% of [the more than 350 videos] have found their way into Wikipedia articles, raking in more than 3 million views a month – is this statement false? Prototyperspective (talk) 00:17, 2 December 2025 (UTC)

User:Prototyperspective So the mediaviewer tool is simply listing the number of times the page with the video on it has been loaded. Please note that with lazy load this can be lower than the actual views of the page as on mobile the entire page may not be loaded and thus the video may not be loaded. It is not the number of times the video has had the play button hit. What we have built is the ACTUAL plays and than how much of the video is watched. Doc James (talk · contribs · email) 01:59, 2 December 2025 (UTC)

I suspected this and also user(s) claimed this was the case, if I remember correctly, on the talk pages of the two linked wishes. However, I could never find any confirmation of this.

It would be better if the media views tool explained this and I wonder why it doesn't. On the information page of file pages, it's linked to as "Mediaviews Analysis on Toolforge" and that title and the tool name suggest it's plays when it comes to audio & video files. Maybe the subheader at the tools page is supposed to explain it – it says "Comparison of media requests across multiple files".

Thanks a lot for your involvement in getting this tool developed; I think the two wishes should get the status changed to 'In progress' and then once the tool shows play from all the projects and can be accessed from the info page from all or all big projects to 'Delivered'. I was slightly alienated by seeing various claims about x number of views of the public broadcast videos I mentioned (such as in the Q&A in this video and the WLB pages) as I suspected these numbers are inaccurate and would soon edit the pages to clarify that these are just the views of the articles and that we don't know the number of plays.

If the tool only shows the plays originating from a few Wikipedias, it's not yet very useful – it really needs to show all or nearly all plays regardless of where the play originated.

By the way, I hope that low view-counts for high-quality and educationally useful videos and audios (an example for the latter are spoken Wikipedia audios) will hopefully raise understanding of the importance of good indexing in Web search engines (e.g. until recently Google, didn't show videos in the Videos tab even when searching for the exact title of a video on Commons) as well as having a good modern audio player, better visibility of audio files like audio versions of Wikipedia articles, better linking to Commons on Wikipedia (category link and further media and direct linking to Commons file page), and other things like that. Seeing media playcounts can be motivating to contributors (note: I doubt many contributors and visitors will find the link if it will again only be on the Tools page). Prototyperspective (talk) 18:43, 3 December 2025 (UTC)

Yup the tool is still under development. Activating it here on Commons would be useful. Will start an RFC eventually. Doc James (talk · contribs · email) 20:51, 3 December 2025 (UTC)

November 29

Is there a bot that adds old style interwikis to wikidata?

I made a lot of categories with interwikis with the intention of them being linked on wikidata. However I am concerned this might not actually work this way. Is there a bot like EmausBot that does the thing? Immanuelle ❤️💚💙 (please tag me) 10:00, 29 November 2025 (UTC)

Specifically it is subcategories of Category:Toki Pona logograms by word which all have interwikis to toki pona wikipedia. Immanuelle ❤️💚💙 (please tag me) 11:06, 29 November 2025 (UTC)

It is not working if it does exist Immanuelle ❤️💚💙 (please tag me) 09:58, 4 December 2025 (UTC)

December 03

MP3s are allowed.

https://commons.wikimedia.org/w/index.php?title=Template_talk%3AAbusefilter-warning-mp3#mp3_format_is_allowed.

Please turn off the warning. Jidanni (talk) 11:50, 3 December 2025 (UTC)

@Jidanni: It's apparently restricted to users with autopatrol. -- Asclepias (talk) 12:45, 3 December 2025 (UTC)

Maybe someone from the Mediawiki Foundation could turn it off? Jidanni (talk) 01:45, 4 December 2025 (UTC)

@Jidanni Per Commons:File types#MP3, MP3 are only allowed to be uploaded by users with the autopatrol (or higher) right. This restriction was introduced by a RFC on Commons, so this isn't something we can just "turn it off". So, please use another acceptable file type, such as ogg, or consider applying for autopatrol right at COM:RFR. Thanks. Tvpuppy (talk) 02:12, 4 December 2025 (UTC)

@Jidanni: Can you discuss what kind of mp3s you wish to upload? Sound recordings can be tricky copyright-wise. Abzeronow (talk) 02:28, 4 December 2025 (UTC)

At least someone should fix the tiny box in Phab:T411579 so people can read the message! Jidanni (talk) 06:45, 4 December 2025 (UTC)

I guess the issue is that MediaWiki:Abusefilter-warning-mp3 is using table based layout Bawolff (talk) 22:53, 4 December 2025 (UTC)

I opposed it when it was introduced and still oppose it, most definitely for this user level. It would be different if it was auto confirmed (or extended confirmed like on some wikis). I do think this is a thing we should look at. We have very little between auto confirmed and image reviewer. We are missing something like extended confirmed, or better, established community member, based on contributions on other wikis. It would be good to have something that identifies experienced community members from experienced Commons users... —TheDJ (talk • contribs) 13:06, 8 December 2025 (UTC)

December 04

DEMO.MID

Good afternoon! I found this file titled DEMO.MID on the Olidata Recovery Disk for Windows ME, which I actually don't know what famous 90s MIDI software it came from... Could you help me? Thank you! DanielParoliere (talk) 12:32, 4 December 2025 (UTC)

Files with no machine-readable source

I cannot see a difference in the source data between File:David Ogilvie 23.jpg and File:David Ogilvie 24.jpg. Yet, the #24 file pulls through a source in the information template, whilst the #23 file does not. Hence, the #23 file gets put into the Files with no machine-readable source category. Can anyone work out what's going on, please? Schwede66 22:57, 4 December 2025 (UTC)

@Schwede66: The one that works uses described at URL (P973) where the one that does not uses work available at URL (P953). - Jmabel ! talk 00:25, 5 December 2025 (UTC)

Thanks for spotting the difference, Jmabel. I thought I was going mad. Schwede66 00:35, 5 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 20:39, 8 December 2025 (UTC)

Community Wishlist – Voting open for Commons-related Wishes!

Recently, voting was enabled in the Community Wishlist. It's the successor to the prior Wishlist Surveys and unlike these runs indefinitely. It's a place for the global Wikimedia community/ies to submit feature proposals, ideas for innovations, and requests to get important bugs fixed.

There are many Commons-related wishes in the Wishlist so I'd like to call on you all to browse the wishes, read the ones you find interesting and vote on the ones you find important. Better to not postpone it. Here's some I'd like to highlight after having read all of the 410+ wishes:

• Show categories on mobile – categories on files are very useful but if you use a smartphone to access Commons like around half of users, you can't see them
• Open the Wikimedia Commons file page directly – when opening an image on Wikipedia, it doesn't open a Commons page (the file page) but shows a intermediary Wikipedia page that does not have the categories; this means we get far fewer visits and far fewer people learn about Commons
• A proper audio player – e.g. up-to-date audio versions of Wikipedia articles can be provided now for many articles and could probably double Wikipedia reads but only with a modern player & well-visible audio
• Do something about Google & DuckDuckGo search not indexing media files and categories on Commons – after some work on this videos on Commons are showing in Google's Videos tab but there's more

.

• Add machine translated category titles on WMC – titles are short and by translating them people searching the Web in their own language can also find the Commons cats
• Add a date range filter to Special:MediaSearch
• Suggest media set in Wikidata items for their Wikipedia articles – if you find good media on Commons, just add it once to the WD item and it can trickle down into the Wikipedias
• Video & audio chapters (jump to timestamp)
• When searching Commons, if there is a category with same or very similar title, show a hint/link
• In Commons category deepcategory view mode (wall of images), allow easily filtering offtopic subcats – basically what is needed for a wall-of-images view for categories including subcategory contents
• A way to see why a file is somewhere underneath a specific category (tool to show cat-path)
• Support full colour 3D models on Wikimedia projects – currently it's only STL files without textures
• When searching Commons, under "Categories and Pages" show the category for the search term – basically search results are bad if you look for category/ies, not galleries
• …

• 
  How the audio player could look (bottom panel) after clicking play (desktop)
• 
  audio player for a Spoken Wikipedia audio via audio-chapters (mobile)
• 
  Video on Commons now showing in Google (success)
• 
  Opening an image on Wikipedia in a new tab or with this button does not show the Commons page

If you have questions about any wishes there, ask on the wish talk pages or check if things have already been clarified there. Currently, software development by the WMF is rather low but maybe that changes in the future so voting can still have an impact. You could also name some wishes you find important but weren't mentioned here.

There also is a tag for wishes called 'Multimedia and Commons' by which you can filter the table. Alternatively, you could enable this script and use the category page. However, note that some wishes relevant to Commons don't have the tag because they relate to basically all projects.

The wishlist is based on a new MediaWiki extension. In this Wishlist, there are 'focus areas' which used to be the only things you could vote on until recently. You could additionally vote on these, especially the focus area most related to Commons:

• Focus area 8: Media formats, editing, and display

Prototyperspective (talk) 23:32, 4 December 2025 (UTC)

I think people underestimate how many of these are political wishes not technical ones. Sometimes I feel like people feel they are powerless due to lack of technical know how, but so many of these are stuck on either getting everyone to agree or hammering out ambigious details, which is something anyone can in theory do. e.g. Show category on mobile - would take 10 seconds to change, the real issue is the mobile team came to the unfathomable conclusion that it would be a bad thing. Open image pages on commons. Also pretty easy, i think that one is stuck on most people not caring one way or another, of course the real question is how does this play with media viewer. Machine translation of titles sounds pretty spicy (My personal view is that this is the wrong solution to a real problem). Anyways, 90% of the battle is figuring out what you want and convincing everyone else to agree. Bawolff (talk) 06:53, 5 December 2025 (UTC)

how many of these are political wishes not technical ones. I don't know if you're referring to the wishes in this Wishlist in general or the wishes I linked or a mix – if the second, wishes that aren't about technical changes but about policy-changes get archived there. Some haven't yet been archived but I think by now all of these have comments on the talk page basically asking for it to be archived. It's relatively few that haven't yet been archived. political wishes not technical ones when you say that, you claim they're only "political" – but they rather have political/policy/group-decision-making aspects. Often, these aspects are already elaborated in the wish or on its talk page. If not, I suggest you add the info there. Ultimately, wishes are about getting certain things done / problems solved. If there's also political things that need addressing or be done, then wish creators and supporters are certainly interested in discussing these there and getting them done as well.

• so many of these are stuck on either getting everyone to agree or source? I think they're stuck because there's very little software development and apparently relatively little interest to do any of the many things that could be done to increase it. Only some are stuck on these as well but obviously things like that don't get solved by themselves but need the political aspects to be clarified and then addressed. If 30% of wishes were implemented, one finds another 40% to be infeasible or quite unimportant, then it would be much easier and flow naturally to narrow in on the remaining 30% to find which of these are stuck on political issues and then work on addressing these. This is how I'd imagine the impact of more software development: as WMF would solve more critical bugs, boring but important issues, and more issues in general, people get freed up to and can dive more into suggested innovations and extend Wikimedia. The first step is more development.
• …or hammering out ambigious details That's why I always tried to include potential solution(s) in the wishes and add ideas on how to solve it to the talk pages of wishes that don't have such technical info despite that the wishlist is/was intended to be problem-focused. More details can be hashed out on the talk pages in regards to how things could be done in practice. I also had one user mail me, saying they're developing a script that aims to solve one of the wishes. Details don't get hammered out by themselves, it needs people to think about them and discuss them – this is what the wishes and their talk pages are for too.
• would take 10 seconds to change, the real issue is the mobile team came to the unfathomable conclusion that it would be a bad thing Exactly! So they should do it. It has been asked for many times, the community certainly wants it – it has been the top #1 wish of the Commons Technical survey, is a heavily-followed code issue, and was the top #3 supported wish in the 2023 global Wikimedia Community Wishlist survey. The WMF just ignores it and doesn't even feel the need to give any explanation why they are doing so (they didn't even say that they concluded this). Afaik, they only said Unfortunately, our key partner, the Web team, will not tackle this wish now. The importance of categories to readers must be researched further to prioritize this wish instead of other pending wishes. I strongly disagree with that. Moreover, if they want to do further research before implementing this, then do it.
• Also pretty easy, All the better. So it should rank high on feasibility and ease of implementing. on most people not caring one way or another Hence the wish and the ability to support it. Wikimedia community often shoots itself in the foot. Here we're keeping Commons down for no reason. If you like Commons to be better known and used more + wikilink in file descriptions to not be redlinks + categories to show on file pages at least when on desktop, then I strongly suggest users support this wish. However, most users aren't much aware of this and haven't thought about it. I don't know why you say this as if it was a caveat or downside of the wish: that it may be easy to implement is an advantage and that people in your mind don't care about it, is basically the point of the wish. the real question is how does this play with media viewer No, that's not the real question. Why would it? If you think things like that, I always suggest you (also) raise it on the wish talk page where it potential issues can be addressed. The MediaViewer actually does link to the Commons file page directly – it works how it should. One clicks the "More details" button and it takes you to the Commons file page. It's just that the other file links haven't been adjusted.
• Anyways, 90% of the battle is figuring out what you want and convincing everyone else to agree If this hypothesis was true, then nearly all top 15 wishes of the past years' wishlists would have been implemented. It's far from that. Either way, the wishes – including the voting and the talk page discussions – are one part of that.

Thanks for your feedback; basically maybe the political aspects are underestimated (which imo would suggest that the impact of votes & discussions are also underestimated). Prototyperspective (talk) 13:12, 5 December 2025 (UTC)

Perhaps I'm just sad how it feels like things have devolved to the community begging WMF for tidbits. I guess that is the natural consequence of more and more development happening by WMF instead of being more community oriented. I do think (with the exception of the mobile category one) that the higher you get on the wishlist the more technical and less political things become, because to make it to the top of the vote list, you need more universal agreement to get everyone to vote for it. Bawolff (talk) 17:28, 5 December 2025 (UTC)

@Prototyperspective I do think you underestimate some of the social bits of this. There is not simple 'just doing it'. Just doing things affects hundreds of other people. "if this hypothesis was true, then nearly all top 15 wishes of the past years' wishlists", those people represent just a fragment of the userbase and generally none of the other stakeholders affected by the change. Please vote, please show your interest, all of that is sorely needed, and it DOES influence things. —TheDJ (talk • contribs) 12:55, 8 December 2025 (UTC)

December 05

favicon.ico too dark at night

https://commons.wikimedia.org/favicon.ico is too dark on dark themed browsers. Possibly due to transparency. Jidanni (talk) 03:23, 5 December 2025 (UTC)

it just depends on which type of browser, like Opera, Brave, Firefox, Edge, etc. Because I use chrome, I have no problem with it. ₘₒd cᵣₑₐₜₒᵣ ✰ ʜᴀʙʟᴀ ⍟ コントリビューション 23:17, 5 December 2025 (UTC)

Do we have a category for text files that need OCR run on them?

Do we have a category for text files that need OCR run on them? RAN (talk) 23:17, 5 December 2025 (UTC)

@Richard Arthur Norton (1958- ): Yes, Category:Needing transcription is that, I think. It's added with {{Transcribe here}}. Sam Wilson 23:27, 5 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 20:38, 8 December 2025 (UTC)

December 06

Lat/Lon: DD vs. DMS

Maybe there should be a preference setting, that shows every coordinate pair, in the format preferred by the user.

So if I write {{Location|24.17|120.72}} it will show up in DD, not DMS. Not just for Template:Location, but everywhere, and for all Wikimedia wikis too. Jidanni (talk) 01:32, 6 December 2025 (UTC)

We have this on en.wp and like 6 people make use of it. I don't really think it is worth it. —TheDJ (talk • contribs) 12:57, 8 December 2025 (UTC)

December 07

Hatnotes in History maps of Europe

Since September, Ty and me are increasingly stuck in several arguments (essentially this entire page: User talk:Ty's Commons), one of them about the proper definition of history maps.

I will readily admit that Ty is the person who established a uniformed definition of European history maps by century, please compare Italy, Belgium, Spain, Poland, and so on. That level of standardization was in itself an achievement, where I had just created a patchwork-in-progress before. However, I get stomach issues when reading the elaborate hatnotes:

• Territorial definition: Ty has chosen this rigid definition: "map showing all or substantially all of the territory of modern-day <country> - as the lands were in the 16th century (1501-1600 CE)" (example here). This definition has two major problems: relevant history maps of subregions are not "all of <country>", and would by that logic be excluded. The second problem is word "modern-day", indicating that our current borders of today are the only acceptable definition of what may be included in Polish history. So my counter-suggestion has been: This category is about maps of the history of <country> in the 16th century (1501-1600 CE) - no "territory", "all" and "modern-day" involved. Ty refused this in several text walls.
• Atlas links: The second paragraph is the link to the Atlas project. Ty claims that it is important to guide interested users to other curated pages of related content; while I think that the Atlas does not need to be linked in every sub-subcategry. The "Atlas of France" may be linked in "Category:Maps of France", and the history subsection may be linked in Category:Maps of the history of France. However, links to the Atlas are superfluous for each by-century subcategory.
• Even more user guidance: Like the Atlas, so the following Additional maps related to... paragraph. The link is already included in the navigation bar just below, and is self-explanatory there.
• Missing differentiation: An important part that I think needs to be distinguished and explained, is that "old maps" are not "history maps" (in short: this is a "16th-century map of...", but this is a "map of ... in the 16th century"). The similarity of the category names make it important in my opinion to clarify the matter in each category. Ty has for some principled reason removed this part of the hatnote and just places it in the see-also-box.

Ty and me are apparently both frustrated by this matter, so I am hoping for intervention and some comments by other users: What would be the best wording in the hatnotes/definitions for these categories? --Enyavar (talk) 12:55, 7 December 2025 (UTC)

Thanks for your note and apologies for the delay in follow up since I've been involved in another project. I believe we've made progress on a number of issues (as challenging as they've been at times). But I think the matters have warranted considerable attention because we've been addressing overall frameworks that involve a large number of maps related to the histories of our European countries - which are no doubt complex. I'm also especially concerned, as you know, that our categorizations of maps line up as well as they can with both our overall categorization policies (which empahasize a uniform and systematic approach to the handling of our current countries and their histories) - as well as to other parts of Wikimedia Commons categorizations for the histories of our countries (to which maps should be linked).

• Regarding the key remaining issues of territorial definition etc., I will respond shortly regarding these since I haven't had a chance to address your recent proposal. Some of the confusion has been caused by your use of the term territory in a way that is different than what is actually being referred to in the category definitions. From your most recent comments, I appreciate that what you're actually getting at is the handling of regions within the territory - and I will address the proposal regarding these.
• Going forward, I do intend to address the issue of numerous maps being categorized and effectively separated from each other (and from related subject matter) - not based on their subject matter (i.e. the particular region and time they are portraying) - but rather on each map's year of publication. The most important subject matter for maps showing history is the country or territory with which it is associated and the time period of its history being reflected in the map. Indeed no map is particularly valuable if the time period being shown is not clear. It's publication date, licensing status, etc. are properly part of secondary attributes. I think that is consistent with both our file descriptions (which effectively separate subject matter from publication date and licensing), and our overall categorization principles based on subject matter.

The issue is especially true for maps showing history - because these maps generally reflect the contributions of historians who have been focused on aspects of the prior events, which necessarily occurred years or even centuries earlier. In my view (as both a user and contributor of such maps), I believe that for the benefit of users, maps showing France in the 16th century (which is their subject matter) should be categorized together. In particular, users have a need for maps of a particular era or period in a country's history for a variety of purposes - both research as well as articles etc. - and they should be able to readily see the corresponding set of maps with that subject matter together.

Conversely, sequestering maps of related subject matter into completely separate and essentially unpredictable hidden "drawers" - based on they're having been published in 1956 versus 1955, or in 1843 versus 1833 - clearly makes maps much harder to find. And finding some leads users to naturally assume they represent all that's available - even though maps of greater interest (for detail, size, etc,) might be available. Unfortunately, they didn't know in advance that the map of France in the 16th century was actual sequestered away into a category such as "old maps" of France published in 1922. Indeed, related categorization systems based on ambiguous terms such as "old," "old contemporary," "historic," etc. are not considered generally helpful. I see that concerns with these have been raised by other users in the past - but not really addressed - and they do need to be.

• A related but very important issue is accuracy. Relatively new maps may contain better information (or be smaller etc,) - but since they're often not from publications it is often unclear where the overall information used to generate it has been obtained. And even for cases in which a citation has been provided, the actual map and other information from the cited source are often not - making it difficult to know whether the creator accurately reflected what was earlier reflected and published. Conversely, older maps are often quite detailed, but it's possible that later historical information has led to corrections. Seeing maps showing what should be the same basic territory and historical status (including names, borders, internal regions etc.) side-by-side is the best way to determine whether there are inconsistencies. Categorizing these maps together by subject matter then allows users to quickly compare the group, assess their accuracy and relevance, and then select the map or maps that best match their remaining interests (including such additional attributes as publication date and licensing status, level of detail, size, cities included, regional borders, neighboring countries, coloration, etc.).
• Finally, regarding Wikimedia Commons extensive and ongoing atlases of our country's histories (such as Wikimedia Commons: Atlas of Spain ) - which not only reflect contributions from many members of our community but are quite closely related to categories of maps showing the territories and histories of these same countries - I was certainly very surprised by Enyavar's suggestion that cross-references to the Wikimedia Atlases (a project he's made clear he has no interest in despite his frequent involvement with related maps) should actually be effectively suppressed from corresponding categories.

I was even more surprised by his suggested reason for this being that the "Category tree is not primarily supposed to guide Users to potentially useful files."

If the category tree and categorization in general is not primarily supposed to guide (and help) users to find potentially useful files, then I think there are even more signficant conversations to be had. Among them, our overall Wikimedia categorization principles, which are in large part directed to that very goal of helping users to find what they're looking for, would need to be substantially reconsidered and rewritten.

In closing, I will plan to continue these discussions with Enyavar - focusing on our official categorization policy and its agreed principles, consistency across our categorization framework for the histories of countries, and last but most important, enabling users to find what they're looking for even, if they're not familiar with all of the intricacies of European countries and their complex histories. Hopefully the eventual outcome will be improved categorizations of maps, especially for maps reflecting the histories of each of our current countries. Ty's Commons (talk) 15:40, 7 December 2025 (UTC)

This topic was strictly and only about the category hatnotes. On the topic of user guidance, Ty misquoted me in that reply. I hope that you all see why I am hoping for an intervention. --Enyavar (talk) 19:21, 7 December 2025 (UTC)

Enyavar initial post here raised a large number of largely orthogonal issues whose only two common threads are (1) that they have to do with [hatnotes of] maps of Europe and (2) which two people have been disagreeing about them. If I read correctly, Ty's Commons then widened that even further. It is almost unimaginable to me that we can have a coherent discussion about this on a single thread.

At the very least: could we start separate threads to discuss each issue whose answer is independent of the others (or almost entirely so)? Better yet, could we prioritize two or three issues to discuss first (each in a separate thread) so we do not have 8 or 10 simultaneous discussions about maps of Europe? Alternatively (though I guess the two could be combined) could we spin out a project page to discuss these issues, rather than the Village pump? - Jmabel ! talk 03:07, 8 December 2025 (UTC)

Gladly, I see three threads from my own original post. The idea to split them into three distinct threads is fine with me, maybe that can create coherence?

• the wording of the definition in the first paragraph of the hatnote (i.e. the subject definition, currently in all these categories)
• whether or not to include the proposed "user guidance" of the second and third paragraph of the hatnote (currently in all these categories)
• whether or not to re-include the proposed clarification on the distinction between old/history maps into the hatnote (currently absent in all these categories)

"These categories" means all categories in the scheme "Maps of <European country> in the <x>th century", which was a scheme we introduced together last year to create meaningful subcategories for "Maps of the history of <European country>". On background: There was an earlier by-century-scheme ("Maps of <x>th-century <European country>") which we fully converted to the above new scheme. That old scheme was fragmentary and unsuitable to be used together with templates. Another earlier scheme is still partial existent and groups history maps by-periods-by-country, i.e. "ancient period", "medieval period", "modern period", and in some cases additional periods. The period-scheme has obvious definition flaws.

I would like to not discuss the fourth+final issue here, because that topic is already dealt with by a CfD: whether or not history maps according to the above scheme must be made available for each century and each country of Europe, or if neighboring countries (e.g. ancient/medieval Low Countries, Scandinavia, Baltics, Balkans...) can be grouped together by region for practical reasons, and then be connected via redirect. Again, that is part of that linked CfD.

Aside from those four topical issues, I am not aware of more (praxis-related) disagreements between Ty and myself. Ty might disgree? --Enyavar (talk) 04:11, 8 December 2025 (UTC)

Uploading cubemap projections of 360 degree panoramas

User:Sdkb recently requested I seek further discussion on this.

Recently I've been uploading cube map projections of 360 panorama images (phptospheres) as alternative versions of the image. Most of these images are currently in equirectangular format, which projects the entire 360 degree view into a single rectangle. This causes distortions similar to how a map of the earth is distorted as you cannot project a sphere on to a 2D rectangle without distortion, thus you can't really use the images directly unless you are doing so for artistic effect. Mostly they are used with {{Pano360}} to link to a viewer on toolforge. I've been uploading an alternative version of these images, where instead of one image they become 6, one for each direction - up, down, left, right, front, back (or up, down, north, south, west, east if you prefer).

The reason for doing this, is that the projected images are easier to work with on wiki without special software support. I view it somewhat similar to cropping an image for better use in an article. Like any derrivitave image, if the original changes the derrivatives would also need to be reuploaded. The six views can be used independently if applicable since they don't have distortion, however the main reason is that they can be joined together with templates to give an immersive view directly on wiki. Sometimes this is called cubeapping, because its as if your camera is inside a cube and these would be the faces of a cube.

As an example, consider, File:Panorama 360 of Basilique Saint-Patrick, Montreal, Quebec, Canada.jpg. In equirectangular projection it looks like

Splitting it up into a cube we get six images like so:

We can then combine them in to a unified view

Note, enwiki has a more complex viewer template that is better.

On english Wikipedia there is a gadget that provides a more interactive viewer. It does have some limitations though in that it doesn't support pinch to zoom or dynamic level of detail loading, but is quite a bit better than the pure wikitext commons template i used above. You can see it at w:Template:cubemap viewer. So far its been used on 34 articles. Its also been copied to fawiki and kowiki

Previously 360 panoramas were used on articles by having an external link to the panoviewer tool, but i think there is benefit to having a viewer directly in the article. It still links to the toolforge tool for a full screen view.

Thoughts? Bawolff (talk) 19:45, 7 December 2025 (UTC)

I'm very impressed with the cubemap viewer template you linked to, great job! I wonder though what's the reason the 360 panoviewer can't be placed directly in an article like the cubemap viewer? ReneeWrites (talk) 20:23, 7 December 2025 (UTC)

The basic answer is that I took this approach because all it involved was creating a template which i could do all by myself with no permissions or approvals, which is pretty freeing. The enwiki template does use a gadget, however that gadget was already approved to power w:template:Calculator, so it already existed and was live. There's something to be said about the Wiki-way of just being bold, is very motivating.

To integrate pannellum (That's the library panoviewer uses) there is basically two approaches. The first is proper integration with MediaWiki, which in the ideal world would be the best option. User:TheDJ has been on and off working on this for years (See mw:User:TheDJ/panoviewer for his work). I'm a bit unclear how much he is still working on it in the present. Getting custom MediaWiki extensions deployed on Wikimedia is often very politically difficult as a volunteer contributor. Its possible, and people have done it, but its an exhausting, uncertain process, and WMF seems to be even more reluctant these days about that sort of thing than it was in the past. Anyways, I wish anyone pursuing that the best of luck, it is definitely the ideal outcome, but I also think its unlikely to happen any time soon, and I don't really want to be involved with the politics of getting something deployed, as that's not really the sort of thing I like to do. Maybe if it wins the community wishlist that would get some momentum behind it.

The second approach would be a gadget for specifically embedding pannellum. It would probably be a large gadget, historically that would have been less than ideal, but with the advent of category gadgets, maybe that's less of a concern now. Of course someone would have to make such a gadget which might be a non-trivial effort, but at the same time not super hard (There are some previous attempts at just iframing toolforge like d:MediaWiki:Gadget-Panoviewer.js however that is not really what i mean. I think a proper tool would embed the viewer directly in the page and not just iframe toolforge). I think panellum has a native "pyrimid" image format, which is what it considers ideal and the panoviewer toolforge tool converts images to that in the background. In gadget form that wouldn't be viable, but it seems like panellum also supports normal equirectangular images, just without as much support for zooming in. Bawolff (talk) 03:33, 8 December 2025 (UTC)

Just to give an update on the other route that Bawolff was talking about. The basic status is at: User:TheDJ/panoviewer. The tool works, but there are some downsides. Primarily... it's still an issue to deal with large resolution images. That really needs tiling (like the Panoviewer toolforge tool does), but adding a tiling service to Wikimedia is ... PAIN. Secondly, you need some support to override angles etc for when that is not correctly provided by the metadata of the image (pretty common) and ideally serve those up via some sort of private API or something. Either magic words or Wikidata properties are an option for that, but I haven't been able to work on that for a while. Lastly.. the quality of tools in this space is... very low. A lot of the libraries are more suited for special dedicated websites and not so much for bigger websites, that have higher demands on quality and maturity. However, the extension does work, I updated it and verified this two months ago. —TheDJ (talk • contribs) 13:18, 8 December 2025 (UTC)

Overall, {{Pano360}} has some very significant limitations, and I'd love to see us using more photospheres overall in Wikimedia projects, so I share the praise for the technical work improving the viewer.

That said, we also currently have very poor infrastructure in place for relating files to one another, which is already a concern with cropped versions, and creating a cubemap results in even more files than a crop (a six-fold increase rather than just a doubling). This has the potential to add substantially to Commons' maintenance burden, especially as the use of photospheres increases over time, since with a cubemap e.g. each additional category has to be added in six places rather than just one.

Trying to think in a future-facing way, I wonder whether adding cubemaps to all 20,000 photospheres on Commons would really make them more accessible to Commons users (in which case it's more justified), or whether we ought to stick to the seemingly more common equirectangular projection format, and focus on technical improvements to the panoviewer rather than the stopgap solution of a cubemap viewer. I don't have a strong enough view about that to !support or !oppose the creation of future cubemaps. But given the number of files affected I do think it's a topic that could use some discussion/attention from interested editors, so I appreciate Bawolff following up from the discussion on their talk page to bring this here.

Cheers, Sdkb ^talk 23:51, 7 December 2025 (UTC)

To clarify, i support making new ones on an as needed basis, when a file is being used. I don't necessilary think doing this for every photosphere file makes sense. As you say its a ton of files and if its not being used in an article i don't think there is much benefit. Bawolff (talk) 00:32, 8 December 2025 (UTC)

I love it --PantheraLeo1359531 😺 (talk) 19:04, 8 December 2025 (UTC)

That looks quite interesting. -- SimmeD (talk) 00:02, 9 December 2025 (UTC)

December 08

Why is Category:Mute (toki pona) not connecting to tok:nimi:mute as per the interwikis

I thought a bot was supposed to run this and create a wikidata item that links the article and category. Why is the connection not happening? Has this just not been a part of wikimedia commons for a long time? Immanuelle ❤️💚💙 (please tag me) 11:43, 8 December 2025 (UTC)

Neither of these two items seem connected to a Wikidata item but both are connected to each other, I didn't even know that was possible. But if this isn't done automatically, couldn't it still be done manually? ReneeWrites (talk) 20:07, 8 December 2025 (UTC)

It's the old way of connecting, predating Wikidata. Yes, it would be better to create a Wikidata item for this and link them in the normal present-day manner. - Jmabel ! talk 00:44, 9 December 2025 (UTC)

@Jmabel @ReneeWrites yeah it is the old way. Originally sites were all linked like this, and a bot connected them all to wikidata and removed the links. But for almost ten years the bots still ran. The reason I didn't create the wikidata items is that it will be very difficult to create all the items manually. Quickstatements does not work for it. Immanuelle ❤️💚💙 (please tag me) 05:08, 9 December 2025 (UTC)

Scans of papyri

In continuation of a previous similar discussion: are scans of papyri (which are completely two-dimensional) I find online free to upload to Commons? for example this one.

Tagging Jmabel who helped me a lot in the previous discussion. פעמי-עליון (talk) 16:52, 8 December 2025 (UTC)

Looks like a simple technical reproduction to me --PantheraLeo1359531 😺 (talk) 19:08, 8 December 2025 (UTC)

Fyi, Morgan Library and Museum terms and conditions states, "The Morgan will not grant permission for the reproduction or commercial use of these low resolution downloadable images." -- Ooligan (talk) 03:28, 9 December 2025 (UTC)

That last sounds to me like an unenforceable non-copyright restriction. That same terms and conditions page also claims the images are all coyrighted, which this image clearly is not. It would apply to anything copyrightable on their site, but cannot apply to public-domain images. This is exactly what {{PD-Art}} is about. - Jmabel ! talk 03:52, 9 December 2025 (UTC)

Thank you for those details @Jmabel.

Great discovery @פעמי-עליון. -- Ooligan (talk) 04:35, 9 December 2025 (UTC)

If there are follow-up questions, please ask at Commons:Village pump/Copyright. Prototyperspective (talk) 12:08, 9 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:08, 9 December 2025 (UTC)

Otto Warmbier is missing

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 01:12, 9 December 2025 (UTC)

Category:Arrest and death of Otto Warmbier is empty. I assume, it contained one or more now deleted files. But if empty, it cannot fulfull its purpose --PantheraLeo1359531 😺 (talk) 19:05, 8 December 2025 (UTC)

see Commons:Deletion requests/Files in Arrest and death of Otto Warmbier. So the cat should be deleted, IMO --PantheraLeo1359531 😺 (talk) 19:07, 8 December 2025 (UTC)

Why did you make a thread about this? Prototyperspective (talk) 20:37, 8 December 2025 (UTC)

Hi @PantheraLeo1359531, in that case it would be best to create a deletion request for it at Commons:Deletion requests Commons:Categories for discussion :-) --SimmeD (talk) 00:00, 9 December 2025 (UTC)

No, empty categories can just be speedied. - Jmabel ! talk 00:47, 9 December 2025 (UTC)

Ah, Well, there you got it :-) —SimmeD (talk) 04:32, 9 December 2025 (UTC)

Near-empty Category:Statistics about communication

Adoption of communication technologies, World

This cat has a problem that only a small fraction of categories has and it's not really a subject for a CfD: the category scope and title seems fine; it's just that there's many files on Commons that would belong into it but the cat is nearly empty.

Assuming there is indeed no better solution such as merging the cat somehow: could some other user(s) help populating it?

A difficulty and also sth where input here would help is that probably not all of Category:Internet statistics should go into it but only a fraction that is actually about the communication and not e.g. the share of Web browsers used. Prototyperspective (talk) 23:06, 8 December 2025 (UTC)

Don't forget {{See also cat}} for categories that are related, but neither exactly belongs as a child of the other. - Jmabel ! talk 00:49, 9 December 2025 (UTC)

Yes; in this case of Internet statistics I think soon a subcat of that cat should become the subcat of the Statistics about communication and this is why I didn't link that cat as see also.

There's of course also other categories relevant to it where it needs some thought how they relate to each other (make it a subcat, add one of its subcats, create a new subcat and add it, or add files from there and only link cat as see also) such as Category:Media statistics.
Prototyperspective (talk) 12:06, 9 December 2025 (UTC)

December 09

Does en:WP:NBZ apply for Commons? (in regards to South Tyrol/Südtirol/Alto Adige)

I just reverted a category renaming from Category:Gerichtsplatz Bozen to Category:Piazza del Tribunale (Bolzano) because it changed the language name from German to Italian, and I knew this would likely be a controversial change in South Tyrol. I talked to User:Yeagvr about it and they said they applied en:WP:NBZ to rename the category. So I'm wondering if that is a policy on Commons and what should be our general principle on category names in South Tyrol/Südtirol/Alto Adige? Abzeronow (talk) 00:35, 9 December 2025 (UTC)

Comment: I reverted some of User:Yeagvr's changes of German language categories to Italian language and informed him that (at least on the English wiki) we adhere to en:WP:NBZ. Example: I moved the category to Category:Hydroelectric power station Töll (Algund) after he had moved it to Category:Hydroelectric power station Tel (Lagundo). I did not revert his moves related to the city of Bolzano, as per WP:NBZ that city has a Italian majority and hence uses Italian language (e.g. he moved Category:Oswaldpromenade (Bozen) to Category:Passeggiata di Sant'Osvaldo (Bolzano)). I would also like to know what the policy on commons is for names in South Tyrol. So far I have applied WP:NBZ and upheld that, e.g. when I requested (still pending) that Yeagvr's move of Category:Tschögglberg to Category:Monzoccolo be reverted as per WP:NBZ the four municipalities on the Tschögglberg are 95% to 98% German speaking, hence on the English wiki everything associated with them is in the German language. Thank you, Noclador (talk) 10:53, 9 December 2025 (UTC)

But we could have category redirects in the minority languages, I think. Nakonana (talk) 16:33, 9 December 2025 (UTC)

Government agencies and acronyms

When titling files, descriptions and categories related to US government agencies is it preferred that we use the full name or acronyms?

Examples being:

• FBI/Federal Bureau of Investigation
• ICE/Immigration and Customs Enforcement
• DoJ/Department of Defense

etc Trade (talk) 13:40, 9 December 2025 (UTC)

Per Commons:File naming#Clear, ...it is allowed to use well-known acronyms and initialisms such as NATO, so long as other parts of the name provide sufficient information to identify the subject.... I think acronym FBI is well-known enough, but ICE and DoJ may mean different things other than the US agencies, so you may want to use the full name if the rest of the file name doesn't have enough context. Thanks. Tvpuppy (talk) 14:34, 9 December 2025 (UTC)

Seconding Tvpuppy. When I see "ICE", I'm thinking of German bullet trains (aka InterCity Express, see File:ICE-Logo.svg, Category:ICE train services, Category:ICE network maps etc.). So, keep the international community of Commons in mind. People around the world might know what NATO is, and they probably have heard of the FBI / CIA / NSA in the news or in American movies, but... ICEs are German trains and I wouldn't have a clue what DoJ is if you hadn't written it out (and even after you wrote it out I might still question whether I deciphered the acronym correctly, because, why is it DoJ instead of DoD?). Nakonana (talk) 16:18, 9 December 2025 (UTC)

Yes, @Nakonana that is an error. Department of Defense = DoD or DOD, and DoJ or DOJ = Department of Justice. -- Ooligan (talk) 20:13, 9 December 2025 (UTC)

Formatting Wikidata query

Hi, In the table of Paintings by Wassily Kandinsky, how to format the result of the WD query so that it looks like this instead of the current one. The external links should be within [ ] avoiding to create an oversize column. Also is the description really useful? It is always "painting by Kandinsky". Yann (talk) 16:42, 9 December 2025 (UTC)

Attention filemovers

Please see Commons:Administrators' noticeboard#Mass rename requests with Criterion #4. Posting here so other filemovers have a chance to weigh in on use and scope of filemoving criterion #4 (harmonizing). Geoffroi 21:21, 9 December 2025 (UTC)