Commons: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/11. Please note:
Purposes which do not meet the scope of this page:
Search archives: |
| Legend |
|---|
|
|
|
|
|
| Manual settings |
| When exceptions occur, please check the setting first. |
Broadwick St, Soho, London: a water pump with its handle removed commemorates Dr. John Snow's tracing of an 1854 cholera epidemic to the pump. [add] | |||||||||||||||
| |||||||||||||||
| SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days. | |
November 02
On the new page Commons:Template requests, Commons users can request edits to templates, the addition of complex templates to pages, and the creation of new templates. Users experienced with templates can find tasks to work on.
So far, such requests could only be made on dispersed talk pages unlikely to be watched by users experienced with templates (and just very few if any users) and at Commons:Village pump/Technical which Template editors may not watch either and which is more broadly about any kind of technical problems. Moreover, on both of these pages, requests may have gotten archived without gotten implemented.
If you are skilled in editing templates, please help out there.
--Prototyperspective (talk) 14:44, 2 November 2025 (UTC)
- Is there a way to display stats like these (these current stats)?:
- 3 solved requests, 5 open requests (8 total)
- Prototyperspective (talk) 13:42, 5 November 2025 (UTC)
- 3 solved requests, 6 open requests (9 total)
- Current open requests:
- Parameter auto=yes for ArchiveBox to detect and link/transclude archive subpages
- Parameter for "review impossible" for LicenseReview template (in progress)
- Fix Topic in country template linking to the redlink Template:Byby
- Make template Shortcut show again
- Florida memory – Attribution-FLGov-PhotoColl should contain image number (likely not done)
- Making Template:Search link work with MediaSearch (likely solved)
- Prototyperspective (talk) 14:57, 11 November 2025 (UTC)
- Regarding making the template {{Shortcut}} show up again: really nobody wants to fix it? Currently, lots of policy pages don't display their shortcuts. I would check if I could fix it myself but I don't have permissions to edit that template. Considering how many pages use that template and how important policy & guideline pages are on Commons, I think this is not unimportant to look into. Prototyperspective (talk) 22:27, 18 November 2025 (UTC)
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)
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)
- 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)
- 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)
- 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)
- 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)
- We have deleted files long after 7 days several times Trade (talk) 14:30, 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)
- 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)
- @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)
- 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)
- 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)
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)
November 09
Criteria for setting Category:Videos by year categories? Set them by bot?
- Is there some rough criteria to which files videos-by-year categories should be added? (Category:Videos of 2024 etc)
- I've mostly only added it to videos that are either notable (such as videos of films or year-specific events) and/or
- where the year is important metadata such as videos extensively portraying cities (which look/ed quite different 50 years ago or 50 years in the future) or of events that occurred in that year.
- If there are (or should be), please add this as info. The criteria may be less relevant to items in subcategories.
- Is there some script/bot that automatically adds years cats to videos depending on the year in the Date field of the file description?
- This is tied to the question above – whether or not there is or should be criteria for which files should be in these cats (however, there could also be a subcategory that contain less notable/relevant files from a given year). If simply all videos of a year are supposed to be in there, I don't see why people waste their time manually categorizing files by year when this info is already there in the date field. However, it may be best to limit it somehow and/or require things to be in certain subcategories. In that case, a bot or multiple bots doing this categorization would still be useful.
- A small fraction of files have false date set but they'd either also be miscategorized when handled manually or could rather be identified later on, for example if they are underneath seemingly contradicting categories like 2022 events or 1980 works. Those are the exception.
- This is probably also related to thread the VP thread #Date Own work Author above, to Commons:Categorization requests#NASA videos from unidentified year, Template:Taken on discussion, and to VP/T: How to search fields of files' Information template?.
Prototyperspective (talk) 22:13, 9 November 2025 (UTC)
A small fraction of files have false date set
I would think nearly all videos of archival film/video materials would have a false date in the in-file metadata. Is that not the case? - Jmabel ! talk 23:08, 10 November 2025 (UTC)- I don't know and it would be new to me; good question. Checked some files in Category:Videos of films by year and some (example) had the correct year set while some had the date of publication on YouTube (example imported from video2commons with the default date unchanged).
- This category also makes clear how Commons categories could be used to check and change these ambiguous values in the date field. I think the date should consistently (expectably & standardized) be date of first publication where that is the key date (films) or date of recording where that is the key date (more or less any other videos; and these date values could be converted to use {{Taken on}}). Prototyperspective (talk) 14:34, 11 November 2025 (UTC)
- There are probably quite a few more cases of videos with wrong year in the date field due to importing the publication date but not the year of either first published or depicting like the second example. However, probably most of them are older videos that have a category that puts them somewhere underneath Category:Videos by year and if the year in the date field was read and written to the categories, a hypothetical bot could ignore those files that are already underneath that category. Maybe there's a way to scan for these in Category:Uploaded with video2commons where the date of the category does not match the date in the date field (see also section #Contradictions & ambiguity within Wikimedia projects).
- I think the by year category(ies) would be more useful if limited in a certain way like only including videos where the year is of substantial relevance. One could however solve this by creating a subcategory where that is populated by aforementioned bot-based method and/or separate such videos where it's of special relevance via subcategory/ies like Category:Videos of 2024 events, Category:Videos of software in 2024, etc. All of this would be too much work when done manually but again bots could add the videos and could maybe subcategorize based on other categories the videos have (or do it batchwise via scanning e.g. the whole Software category to populate the subcategories of Category:Videos of software by year). I'm not sure what the value of videos by year categories are if they're are super incomplete, meaning you can't search, statistically compare, browse, or filter by them. That's at the same time that this data is already there, in structured format, in the {{Information}}'s date field.
- -
- Also, files in there, including especially Category:Videos of 2024 by country, often don't really show anything of that year or of the respective country. For example, animated explainer videos (here the year is of relevance in terms of 1. techniques and technologies used for them and 2. the state of humans' knowledge which for subjects can change over the decades). All of these are very incomplete. Prototyperspective (talk) 22:59, 18 November 2025 (UTC)
November 11
The Commons brochure needs an update
File:Illustrating Wikipedia brochure.pdf is very outdated. Things look very different now. Maybe parts of the text need updates too but the images would be very confusing if anybody reads this.
That file is used on many pages, including en:Help:Pictures, en:Help:Files and meta:Commons brochure.
Alternatively, the document could be replaced by an entirely new up-to-date document. Note that in that case, most file-uses should probably also be changed.
See also Commons:Simple media reuse guide and Commons:Welcome. The file is of course relevant to the entire global Commons project.
Also posted this to Commons:File requests#Updated version of the Commons brochure and I suggest discussion continues there once this thread here is archived. Prototyperspective (talk) 23:25, 11 November 2025 (UTC)
- The file is outdated by over a decade – it was uploaded and last revised in 2014 which in 1 week is 11 years ago. Despite of this it is and remains heavily used across Wikimedia projects, including English Wikipedia and metawiki. Prototyperspective (talk) 11:50, 17 November 2025 (UTC)
November 14
Stopping MediaWiki message delivery from messaging me
Every few months, MediaWiki message delivery will leave a message on my talk page, informing me about picture of the year/month/day/hour/second votes, and honestly I couldn't care less. It's also very annoying whenever I get stressed about one of my files being deleted and I realize it's that. I would very much like t turn this off. Is there any way that would be possible?
I very much hope this signs me message automatically.
edit: it did not. Mohammad.darg (talk) 07:07, 14 November 2025 (UTC)
- In the notification preferences in the preferences (at Special:Preferences#mw-prefsection-echo) you can disable the notifications for Web and Mail. Please comment whether this solves your issues or not. I don't know if there is a way to unsubscribe from / disable notifications for just MediaWiki message delivery & DR notifications.
- If you press the Add topic button at the top as one is supposed to or alternatively the other large blue well-described button "Start new discussion", it will automatically sign your message. (And I agree talk page posts should be automatically signed instead of users having to worry about learning that they should do so and the wikitext syntax to do so.)
- Prototyperspective (talk) 14:48, 14 November 2025 (UTC)
- Thanks you for the response. Unfortunately, it doesn't allow me to disable notifications for one specific user. Thank you very much nonetheless. Mohammad.darg (talk) 17:51, 14 November 2025 (UTC)
- If you look at the MediaWiki message delivery user page, it says that you can opt-out of its messages by adding your user talk page to Category:Opted-out of message delivery. That would only stop messages sent through that specific process, but that might be what you're looking for. — PeterCooperJr (talk) 19:15, 20 November 2025 (UTC)
Best way to migrate from unclear but widespread category naming system?
The naming system of many categories related to frescoes in Pompeii does not seem to match the spirit of Commons' hierarchical naming system.
Specifically, the paintings generally have two hierarchies, one rooted at Category:Ancient Roman frescos in Pompeii then descending to house → room (and sometimes a subcategory for a specific painting) and another rooted at Category:Ancient Roman frescos of Pompeii by Irelli-Aoyagi-De Caro-Pappalardo number (with 561 subcategories for specific paintings, walls or rooms).
This second system is based on the figures in volume 2 of a book called La Peinture de Pompéi edited by Irelli, Aoyagi, De Caro and Pappalardo. Volume 1 also has other paintings with their own numbering but those are __not__ part of the Commons categorisation system. Volume1 numbers overlap with volume2 numbers but refer to different paintings, however the category names do not mention that they refer to volume2. The pictures in volume 2 are no where close to a complete catalogue of paintings at Pompeii.
Just about everyone who goes to Category:Red oecus q, north of the peristyle is going to have a hard time discovering the painting/subcategory they're looking for, whereas descriptive names (e.g. 'Cupids making wine') would help greatly. Another example of confusion is described here.
Improvement?
Shouldn't this situation be improved? Does anyone have an opinion on the best course of action?
The Aoyagi-Irelli.. categories refer to specific paintings (or sometimes whole walls with multiple paintings) so it doesn't make conceptual sense for a painting to have both this category and a hypothetical new category that describes the painting. It also doesn't seem right to rename the category because then it loses the numbering information.
Would the right way be to create a new category with a descriptive name and then "tag" that category with the Aoyagi-Irelli number? This makes sense to me but I don't know how to "tag" the new category. Also, this would be a very large change (over 500 categories) and I don't know if the rest of the community agrees?
- User:BeakheadIntrados — Preceding undated comment was added at 10:51, 14 November 2025 (UTC)
- I don't have any expertise here, but it sounds to me like your main problem here is with the naming of the categories based on Irelli-Aoyagi-De Caro-Pappalardo number. Is that correct? Is there another problem as well (in which case, please spell it out; if there is more than one other problem, a bullet list of issues at hand would be useful). At the very least, if those are drawn from two different volumes and the numbers overlap, it would seem that the volume should be part of the category name. As for the issue of whether the Irelli-Aoyagi-De Caro-Pappalardo number should be the primary way of naming individual paintings, I bet needs will vary wildly: as a rule, the more scholarly users will probably prefer those, the less scholarly will not. At the very least those should be preserved within the category pages, one way or another.
- One possible pattern for a solution is the way we handle ships, with a category for an IMO number and a subcategory for a ship name. In that case, this is partly because a ship can have more than one name over the course of it existence, but still something like that might be workable.
- Another possible pattern for a solution would be to pick a handful of languages and try to have descriptions for as many categories as possible be given in all of those languages. That would help greatly with the search problem.
- Another possible pattern would be to add another hierarchy under Category:Ancient Roman frescos of Pompeii: Category:Ancient Roman frescos of Pompeii by subject matter, leading down to the same "leaf" categories. - Jmabel ! talk 20:04, 14 November 2025 (UTC)
- Sorry for not being totally clear. Yes, my problem is that I don't think the Irelli-Aoyagi number should be the primary way of naming individual paintings, for the following reasons:
- It is not a standard way of referring to the paintings by scholars. Scholars use the title or subject matter along with the house, room and wall compass position (House, Room, north/east/.. wall). (There's no inventory numbers like in museums.) The Irelli-Aoyagi book is not 'canonical'. It would typically only be referenced by scholars indicating where a reproduction of the painting is to be found (but they could equally refer to another book or none at all).
- Further, the paintings in volume 1 (which has 200+ large colour plates, unlike volume 2 which has smaller black and white photographs) are mostly more "important" than those in volume 2. So it doesn't make any sense to arbitrarily pick volume 2 of this particular books.
- The way that the scholars refer to paintings seems much more intuitive for non-scholarly people too: it's common to read about (or see in real life) a painting and its location (particular house and room).
- If we really wanted to pick a book to number from Irelli-Aoyagi would not be the one but rather Pompei : pitture e mosaici in 11 volumes (1990-2003) which did try to be complete. However more paintings have been excavated since then so even this would not be adequate.
- I really don't understand why this particular book has been chosen and it greatly degrades the name- and location-based categorisation system that would be more understandable to both scholars and non-scholars.
- Adding 'volume 2' to the category names would not solve the problem, it would only entrench the situation.
- The ship-like subcategory idea could work! It would conceptually be a bit weird because the Irelli-Aoyagi category would refer to the files in the subcategory rather than any files in itself, but that would be a good trade-off to preserve automatic 'tagging' of paintings in the main category with this number. An alternative would be to remove the Irelli-Aoyagi categories from the location-based hierarchy and but maintain them as a parallel, but they would quickly become out of sync because few people are going to be thinking in terms of this particular book's numbers.
- Again though we're talking about 500+ categories and I would like to get some sort of consensus before making a change on that scale.
- BeakheadIntrados (talk) 07:30, 15 November 2025 (UTC)
- I agree with BeakheadIntrados that any system based on Irelli et al. is misguided, for all the reasons listed, and especially because this work is not a scholarly standard and is not normally cited by professionals in the field as a primary means of identifying a given painting. By far the best organizing principle for Pompeian wall paintings that are still in situ, or for which the original location is recorded, is the traditional numbering system by region, insula, and house numbers (e.g., VI.8.3), subdivided further by room and location within room as necessary. This has the advantage of being (a) universally intelligible to anyone interested in Pompeii, whether they are scholars or casual visitors, and (b) completely independent of any particular publication. It's the system adopted in Schefold's Die Wände Pompejis (available here for those with access to The Wikipedia Library), which, although it is three-quarters of a century old and lacks illustrations, is still the most convenient one-volume index of Pompeian wall paintings available, and is regularly cited in the scholarly literature. As the OP notes, the multivolume Pompei: Pitture e mosaici is more complete, because it includes the results of more recent excavations, but it's also much bulkier and more expensive, and most readers on both sides of the Atlantic will find it harder to locate a library that owns a copy. For wall paintings in the Naples museum (or, in a few cases, other museums) whose original location is unknown, citation by inventory number is universal. Cluttering up category names and hierarchies with identifiers other than these two widely recognized systems is not, in my opinion, helpful to anyone. Choliamb (talk) 19:31, 16 November 2025 (UTC)
- Given that others agree I then propose the following:
- For each category like 'Category:Irelli-Aoyagi-De Caro-Pappalardo <NUMBER>':
- Create a new category with a descriptive name using best practices. In some cases this may just be the subject matter title of the painting (following existing examples) though to disambiguate with other paintings the name of the house, room or wall may be included.
- Make this new category a subcategory of the Irelli category.
- Move all files in the Irelli category into this new category.
- Make the new category a subcategory of all the parent categories from the Irelli category except the Irelli-specific ones (I believe this is just Category:Ancient Roman frescos of Pompeii by Irelli-Aoyagi-De Caro-Pappalardo number).
- Remove the corresponding parent categories from the Irelli category.
- For each category like 'Category:Irelli-Aoyagi-De Caro-Pappalardo <NUMBER>':
- This should preserve the automatic 'tagging' of new paintings with the Irelli number while creating a more logical, scholarly and user-friendly location-based hierarchy.
- Please let me know any concerns before I start doing this.
- BeakheadIntrados (talk) 10:58, 18 November 2025 (UTC)
- Not sure I follow how this will "preserve the automatic 'tagging' of new paintings with the Irelli number…". Maybe I'm missing something. - Jmabel ! talk 23:26, 19 November 2025 (UTC)
- I mean that in the future, when an uploader/editor categorises a new photo, they're much more likely to find & use the location-based category rather than the Irelli category. In my suggestion, such new photos would be "automatically tagged" with the Irelli number in the sense that the user only needs to find the location-category and then their photo will be placed in the right Irelli number parent category. An alternative would be adding everything to both the location-based category and the Irelli category but I think this would quickly lead to the two categories getting out of sync (when in most cases they should be identical collections).
- I don't actually think this is the 100% best idea (I think this gallery page Pompeian Painting (1990) is probably enough rather than categories). I'd actually be most in favour of renaming the Irelli categories to be location-based but I don't know how to obtain consensus (does anyone else?). That's why I'm suggesting a solution that preserves the numbers, to avoid someone's categorisation work being lost without them explaining why the Irelli numbers are so important. BeakheadIntrados (talk) 08:01, 20 November 2025 (UTC)
- Not sure I follow how this will "preserve the automatic 'tagging' of new paintings with the Irelli number…". Maybe I'm missing something. - Jmabel ! talk 23:26, 19 November 2025 (UTC)
- Given that others agree I then propose the following:
- I agree with BeakheadIntrados that any system based on Irelli et al. is misguided, for all the reasons listed, and especially because this work is not a scholarly standard and is not normally cited by professionals in the field as a primary means of identifying a given painting. By far the best organizing principle for Pompeian wall paintings that are still in situ, or for which the original location is recorded, is the traditional numbering system by region, insula, and house numbers (e.g., VI.8.3), subdivided further by room and location within room as necessary. This has the advantage of being (a) universally intelligible to anyone interested in Pompeii, whether they are scholars or casual visitors, and (b) completely independent of any particular publication. It's the system adopted in Schefold's Die Wände Pompejis (available here for those with access to The Wikipedia Library), which, although it is three-quarters of a century old and lacks illustrations, is still the most convenient one-volume index of Pompeian wall paintings available, and is regularly cited in the scholarly literature. As the OP notes, the multivolume Pompei: Pitture e mosaici is more complete, because it includes the results of more recent excavations, but it's also much bulkier and more expensive, and most readers on both sides of the Atlantic will find it harder to locate a library that owns a copy. For wall paintings in the Naples museum (or, in a few cases, other museums) whose original location is unknown, citation by inventory number is universal. Cluttering up category names and hierarchies with identifiers other than these two widely recognized systems is not, in my opinion, helpful to anyone. Choliamb (talk) 19:31, 16 November 2025 (UTC)
- Sorry for not being totally clear. Yes, my problem is that I don't think the Irelli-Aoyagi number should be the primary way of naming individual paintings, for the following reasons:
link rot: digitallibrary.usc.edu
for example:
File:Spectators watching a bicyclist on Beacon Street, San Pedro, ca.1907 (CHS-4783).jpg
https://web.archive.org/web/20150928155242/http://digitallibrary.usc.edu/cdm/ref/collection/p15799coll65/id/17161 is broken because w:archive.org can fail archiving w:Ajax (programming) web pages, more than w:archive.today
http://digitallibrary.usc.edu/cdm/ref/collection/p15799coll65/id/17161 is now at:
https://digitallibrary.usc.edu/asset-management/2A3BF16PKMY
Piñanana (talk) 11:56, 14 November 2025 (UTC)
- Are you asking for these files to be corrected? Checking insource:http://digitallibrary.usc.edu/cdm/ref/collection/ (assuming that's the url part to search for) suggests over 36,000 files are affected.
- Since the identifier also seems to have changed I have no idea how this could be fixed – does somebody know? Maybe the organization can be asked to unbreak these links so they redirect?
- I also noticed link rot (404) for source links of files in Category:Videos by Terra X where I notified the creator account. Prototyperspective (talk) 14:54, 14 November 2025 (UTC)
- Will the links remain broken and if so is anybody doing anything regarding that or is there a dedicated page to report broken external links for set of files? Prototyperspective (talk) 15:29, 20 November 2025 (UTC)
COM:INUSE and outdated charts
When files with old data are in use and there is a file with newer data but otherwise the same, does COM:INUSE mean the file with the older data can't be redirected to the file that also shows the newer data which preserves the file uses?
If it does mean that, should that policy be changed to enable this method / kind of updating data graphics?
See also Category:Wikimedia updating and Category:Charts by year of latest data.
-
1971-2018
(closed DR) -
1970-2020
(the file I asked the two other ones to redirect to)
Prototyperspective (talk) 15:16, 14 November 2025 (UTC)
- Have you looked at some of the places these are used and seen whether such a substitution would be appropriate? (In this case, I would guess it would). Commons Delinker can do a global substitution even without us redirecting the older files, but (just as much as with your redirect proposal) you'd want to make sure global substitution is really desired. - Jmabel ! talk 20:08, 14 November 2025 (UTC)
- It's the same image except that the third one has more data. A substitution would be appropriate – the design and so on haven't significantly changed and the trend also hasn't. It would just mean data graphics aren't as outdated anymore in Wikipedia. This may not be a big problem in this case and more important for cases where the data shown for some disease is outdated by a decade but it's nevertheless appropriate and useful to do this here too.
Commons Delinker can do a global substitution
Interesting, didn't know that. How can it be used for that? On User:CommonsDelinker it saysIt aims to prevent image links from visibly breaking on local wikis after a Commons file is deleted.
. If it's nevertheless possible, I think just very few users know about it, and it's not as straightforward and known as a making DR (with a request to redirect the file). Moreover, the outdated files will still be on Commons instead of only having the up-to-date file which I think is very desirable unless the target file has a significantly worse/undescriptive file-title. Prototyperspective (talk) 18:28, 15 November 2025 (UTC)- Sorry but setting this as a general principle is a bad idea. The role of Commons is to act as a repository and not dictate which files other projects use. If one language version of Wikipedia chooses to present and discuss a set of data available in 2018 and another language version of Wikipedia chooses to present and discuss a set of data from 2020, what right do we have to enforce a substitution with a version containing 2025 data? Who is going to jump into those various language versions and update the narrative of the articles to align with the new data? If you want to investigate an individual case and make educated substitutions, then that is fine. Encouraging mass substitutions without proper consideration will create more problems than it solves. From Hill To Shore (talk) 19:18, 15 November 2025 (UTC)
- The file used is outdated not on purpose and one could just replace all of the files manually but that would currently be a lot of work and won't be done as often. You're right though,
- Sometimes the dataset changes instead of staying the same and just getting new data points.
- It may be rare but sometimes articles may deliberately choose an older time-span, probably because newer data is thought to be of lesser quality (haven't yet seen any of these but if these DRs would be done more often it could be that some charts are used deliberately with old data as the article is about an old time-period/event albeit I don't think it's likely such a chart would get a DR)
- Maybe the better approach would be to have for example a bot or a Commons script leave a notification on the article's talk page that one of the files has a newer version available so that users watching the Wikipedia article can manually edit. For a bot to do this one would have to mark a file as an older version of another chart with newer data somehow. Prototyperspective (talk) 20:11, 15 November 2025 (UTC)
- Another way would be to upload the latest version as a new revertable revision to EACH of those files and rename the file if they got the old year in the title, assuming none of these have the 'intentionally old data' template set. This would mean all the file uses are up-to date. However, then there would be three identical PNG images. Back when they got uploaded and added to Wikipedias, they were the most up-to-date versions; but not anymore. Prototyperspective (talk) 22:39, 17 November 2025 (UTC)
- The file used is outdated not on purpose and one could just replace all of the files manually but that would currently be a lot of work and won't be done as often. You're right though,
- Sorry but setting this as a general principle is a bad idea. The role of Commons is to act as a repository and not dictate which files other projects use. If one language version of Wikipedia chooses to present and discuss a set of data available in 2018 and another language version of Wikipedia chooses to present and discuss a set of data from 2020, what right do we have to enforce a substitution with a version containing 2025 data? Who is going to jump into those various language versions and update the narrative of the articles to align with the new data? If you want to investigate an individual case and make educated substitutions, then that is fine. Encouraging mass substitutions without proper consideration will create more problems than it solves. From Hill To Shore (talk) 19:18, 15 November 2025 (UTC)
Vyshyvanka/Вишиванка
Can someone who's familiar with this type of dress take a look at File:Альона Ігорівна Мовчан.jpg and see if this is in fact a Vyshyvanka and if I've added the right category? This is a really beautiful dress she's wearing and the portrait is high quality. Thanks for your time. Geoffroi 20:59, 14 November 2025 (UTC)
- Vyshyvanka basically just means embroidery. Вышивать (vyshyvat') = to embroider (literally).
- I'd say the outfit qualifies as vyshyvanka. Nakonana (talk) 21:04, 14 November 2025 (UTC)
- Thanks for the quick response. Can this be QI? Also, could it be VI for blue vyshyvankas? Geoffroi 21:13, 14 November 2025 (UTC)
- What do QI and VI stand for? Nakonana (talk) 21:14, 14 November 2025 (UTC)
- Com:Quality images and Com:Valued images. Geoffroi 21:16, 14 November 2025 (UTC)
- I see, thanks.
- If the image meets the quality criteria for QI / VI, then sure, why not.
- It features classical vyshyvanka motives like rhombuses and crosses. Nakonana (talk) 21:28, 14 November 2025 (UTC)
- I think File:День Вишиванки. Молода україночка у вишитій синій сукні серед квітів 14.jpg or one of the others in that series is probably better because they show the whole dress. Thanks for the help though. Geoffroi 21:47, 14 November 2025 (UTC)
- Both dresses are modern variations and factory made. Apron (and it was part of many other ethnic female costumes) is obviously missing on second photo. Please note that pendant on first photo may be variation of w:en:Black_Sun_(symbol). EugeneZelenko (talk) 15:47, 15 November 2025 (UTC)
- Looks more like a Svitovit (Свитовит), a pagan symbol. Nakonana (talk) 20:05, 15 November 2025 (UTC)
- Thank you for the research. I've added this to the file's description. From my own research, I see that the reverse swastika (in the middle of the pendant) was never used as a separate symbol by the nazis. They only used it as a background for their version. Geoffroi 23:41, 15 November 2025 (UTC)
- Looks more like a Svitovit (Свитовит), a pagan symbol. Nakonana (talk) 20:05, 15 November 2025 (UTC)
- Both dresses are modern variations and factory made. Apron (and it was part of many other ethnic female costumes) is obviously missing on second photo. Please note that pendant on first photo may be variation of w:en:Black_Sun_(symbol). EugeneZelenko (talk) 15:47, 15 November 2025 (UTC)
- I think File:День Вишиванки. Молода україночка у вишитій синій сукні серед квітів 14.jpg or one of the others in that series is probably better because they show the whole dress. Thanks for the help though. Geoffroi 21:47, 14 November 2025 (UTC)
- Com:Quality images and Com:Valued images. Geoffroi 21:16, 14 November 2025 (UTC)
- What do QI and VI stand for? Nakonana (talk) 21:14, 14 November 2025 (UTC)
- Also, the Ukrainian image caption which was added by the uploader says: "Красуня у вишиванці" (literally: Beauty in embroidered dress). Nakonana (talk) 21:13, 14 November 2025 (UTC)
- Thanks for the quick response. Can this be QI? Also, could it be VI for blue vyshyvankas? Geoffroi 21:13, 14 November 2025 (UTC)
November 15
Categorization question
File:Seattle Water Department worker driving ditch digging machine, 1927.jpg I don't think I've ever seen a machine quite like this. I did my best at categorization, but I suspect I didn't do well; I won't be surprised if we need some category we haven't got. - Jmabel ! talk 06:01, 15 November 2025 (UTC)
- Nice photograph. There is an enwiki article about something called a w:Ditch Witch (for which we also have a category here c:Category:Ditch Witch). This might be related. (I haven't dug into it in any detail.) -- Cl3phact0 (talk) 07:25, 15 November 2025 (UTC)
- Seeing that a cat about excavators was already set at the time of upload, would putting it in Category:Unidentified excavators or a new subcategory of it like Category:Excavators of unidentified types solve this? (Note: "Identify unknown objects" is already a task-type highlighted at Commons:Welcome and maybe it could get highlighted more if adding the file to the cat is seen as too unlikely to result in identification+categorization.) Prototyperspective (talk) 11:42, 16 November 2025 (UTC)
- I added Category:Barber-Greene, the manufacturer. You can see part of the name "Barber-" above the driver's head. Commons has a good photo of a similar B-G machine in action: File:Drainage, machine, graven, sleuven, barber greene, Bestanddeelnr 160-0317.jpg. Mrwojo (talk) 16:49, 16 November 2025 (UTC)
- I'd say it belongs to Category:Chain trenchers, although it is old, small and retractable - and that makes it look different -, and the chain has buckets instead of just teeth as most of the examples in the category. Pere prlpz (talk) 17:07, 16 November 2025 (UTC)
- This machine's chain of "buckets" is similar to the floating gold field dredges of the American West and Alaska. The buckets work best in wet soils and wetlands. Ooligan (talk) 19:46, 19 November 2025 (UTC)
- I'd say it belongs to Category:Chain trenchers, although it is old, small and retractable - and that makes it look different -, and the chain has buckets instead of just teeth as most of the examples in the category. Pere prlpz (talk) 17:07, 16 November 2025 (UTC)
Icons of Madonna and Child
Shakko seems to have taken it upon himself to unilaterally empty Category:Icons of Madonna and Child and soft-redirect it to Category:Icons of Virgin Mary. Surely this is not the sort of uncontroversial move that should be made without discussion. I see that for at least some of these (e.g. File:Bucharest - Biserica Schitul Darvari interior 02.jpg, one of my uploads) he has substituted Category:Hodegetria instead. Literally no ancestor category of that indicates the presence of Jesus as part of such an icon (that could, of course, be remedied), so there is a loss of information.
Also related: I see that Category:Eastern Orthodox icons of the Virgin Mary was emptied and redirected to Category:Icons of Virgin Mary.
Again: my main issue here is not whether this is right or wrong, but that this is the sort of change that certainly merits a CfD or other discussion. I would like to have at least an after-the-fact explanation of what other related changes may have been made to the category hierarchy, and a (belated) opportunity to discuss what is desirable here. - Jmabel ! talk 22:08, 15 November 2025 (UTC)
Also, on File:Muzeul Vasile Grigore 05 - Madonna and Child with Saints Ermolaos and Mina, prophets and apostles.jpg I see similar changes; at least Category:Panachranta has an ancestor category indicating that it is a Madonna and Child. - Jmabel ! talk 22:16, 15 November 2025 (UTC)
- Hello. I'm art historian and I've uploaded here circa 1000 my own photos of icons. I'll be glad to explain. First of all we will talk about definitions:
- Term Icon - is a Christian painting made, to generalize, in Byzantine style, usually tempera on the wood. As byzantine art, icons almost always are related to en:Eastern Orthodoxy, because it was the religion of the Byzantine Empire (exception is tiny national ancient churches such as the Coptic and Armenian). This is why Category:Eastern Orthodox icons of the Virgin Mary is unnecessary, it sounds like "photographic photographs of John Lennon". (Also there is such thing as Greek Catholic Churches and Slavic Uniate Church after Union of Brest, who combined Byzantine and Catholic styles. Proportionally the number of icons created in these narrow Churches is very small (maybe 5-10%), and they are taken out here in subcategory Category:Uniate and Catholic icons, they also immediately catch the eye because their non-typical iconic style and a Catholic themes prohibited by Orthodoxy.)
- We can find several cases when icons of Mary aren't Orthodox, mainly two: 1) Catholic icons of Poland (where they started up, probably because Poland is too close to the Orthodox lands and is also Slavic country); 2) several pieces of worshipped icons in Italy, in Catholic churches (which, if you look closely, were brought to Italy from Byzantium before the 15th century, and are basically Byzantine, also Orthodox, copies of them (+ sometimes early Italian paintings pre-Giotto, when Italian painters worked in Italo-Byzantine style, but they aren't icons but simply paintings, see Category:Early Italian paintings of Virgin Mary). You can find it here Category:Uniate and Catholic icons of Virgin Mary. If i'll find such I'll create also Category:Oriental Orthodox icons of Virgin Mary, but in analog about Jesus we have only 5 yet.
- Term Madonna is exclusively Catholic. Not Orthodox. Not Lutheran. Not Greek Catholic. Not Coptic. It should refer only to Catholic images of Virgin Mary with Child. The whole Category:Madonna and Child is wrong named, 'cos we see there the images of her from all the confessions. Now it is not neutral and it looks as if the Catholic point of view is the main one in the world. (However, feel the difference: "Madonna lactans" is a normal, worldwide scientific term for iconography.) But my area is the icons. "Icon" as I told below almost always is the synonim for "Orthodox religious painting", so it could't be used with "Madonna". It sounds like "Retablo of Buddah" or "Thangka of Zeus". Funny, illiterate. In Orthodoxy her title is Theotokos, but we'll not call the category Icons of Theotokos, the name sould be as neutral as possible and take into account other denominations from around the world, including, say, the Church of Ethiopia.
- "...and Child". Circa 85-90% icons of Mary are icons of Mary with Child. In Category:Types of icons of Virgin Mary by alphabet are now 140 types. No need to create separate "Icons of Virgin Mary with Child", it's like to create "Icons of Christ with beard". More logical would be create "Icons of Christ without beard" and put there these unusual cases (by the way it calls Category:Christ Emmanuel, + icons of Nativity and other vita icons from his childhood). So here is Category:Icons of Virgin Mary without the Child. Very few.
- Tree of categories. Don't worry, Hodegetria and Eleusa etc. (see the difference here) are in Category:Icons of Virgin Mary which is in Category:Madonna and child byzantine style which is in Category:Madonna and Child by type (and all this Madonnas' should be renamed!!!)
- Believe me, I've thought a lot about how to put this category in order from the point of view of scientific accuracy of icons' iconography. -- --Shakko (talk) 17:36, 17 November 2025 (UTC)
- @Shakko: I do believe you've "thought a lot". I also believe you have undertaken a major change with no discussion with any other participant in the project. - Jmabel ! talk 18:37, 17 November 2025 (UTC)
- Is this really the major change? Icons are very local hobby for very few users here. I'm sorry. I didn't mean to touch the real global problem with ubiquitous Madonna, only the thing that is clearly mistake in icons category. I have outlined my reasoning above and how the category tree should look like so that our Wikipedia does not look illiterate. I apologize if I don't understand all the nuances of intonation, I'm not a native English speaker. For example your File:Bucharest - Biserica Schitul Darvari interior 02.jpg was moved to Hodegetria, 'cos it is en:Hodegetria. Category:Madonna and child byzantine style now is the maternal. --Shakko (talk) 19:00, 17 November 2025 (UTC)
- @Shakko: have a look some time at Commons:Categories for discussion, and you will see how many much smaller changes are normally run through there to make sure we have consensus before proceeding. I'm not saying your changes are wrong, I'm saying they are large, and that they affect hierarchy and naming conventions that had been hashed out over a couple of decades. I'm definitely not used to seeing some of my own work recategorized to this degree with no advance indication anywhere.
- I've initiated similarly large reorganizations of material in the past. It's usually been my experience that even if I know the subject matter well, there are usually others with some useful thoughts. You didn't give anyone a chance to express those.
- In short, my main issue here is one of process, not substance. I'm not expert in the relevant area, but certainly you are not the only Commons contributor who is, and you should have given others a chance to weigh in.
- In particular, I understand your point about the word Madonna being a Roman Catholic term, but the flip side of that is that probably fewer than 5% of English-speakers have words like Hodegetria and Eleusa in their vocabulary, which is also a consideration for naming categories. (FWIW, I'm a secular Jew, and my only stake in the outcome of this is usefulness to end users.) - Jmabel ! talk 22:32, 17 November 2025 (UTC)
- Is this really the major change? Icons are very local hobby for very few users here. I'm sorry. I didn't mean to touch the real global problem with ubiquitous Madonna, only the thing that is clearly mistake in icons category. I have outlined my reasoning above and how the category tree should look like so that our Wikipedia does not look illiterate. I apologize if I don't understand all the nuances of intonation, I'm not a native English speaker. For example your File:Bucharest - Biserica Schitul Darvari interior 02.jpg was moved to Hodegetria, 'cos it is en:Hodegetria. Category:Madonna and child byzantine style now is the maternal. --Shakko (talk) 19:00, 17 November 2025 (UTC)
- @Shakko: I do believe you've "thought a lot". I also believe you have undertaken a major change with no discussion with any other participant in the project. - Jmabel ! talk 18:37, 17 November 2025 (UTC)
November 16
Moving categories without leaving redirect causes broken links at Wikipedia
I noticed when moving categories without leaving a redirect – as one may want to for titles with typos or flaws or that are just the plural/singular form etc (pollutes the autocomplete) – links to the category in Wikipedia can become broken.
The move page doesn't inform the user much about this potential issue – it says The old title will become a redirect page to the new title. Be sure to check for double or broken redirects. You are responsible for making sure that links continue to point where they are supposed to go.
but the user may not be aware that the category is linked from a Wikipedia page. One also can't see which Wikipedia pages do – Special:WhatLinksHere doesn't show them and the they're also not listed on the move page. Many Wikipedia articles just link dynamically to whatever Commons category is linked on the/a Wikidata item but apparently many(?) also specify the exact category title.
This is especially problematic when one wants to move a set of categories all named by the same schema. Usually, Wieralee moves files in the moved category to the target category but that's not the case for moves when no redirect is left. When moving multiple categories, one would have to check for each where it's linked on Wikipedia and also correct that(?)
See also Commons:Village pump/Technical#How to move (rename) many categories?
I think there may be quite a few moved categories where the links have not been updated on Wikipedia – is there any way to find them (if possible just the ones with broken links) so these can be corrected? Is there maybe a tool for category moves that would also change these similar to "Move & Replace" for files? Prototyperspective (talk) 00:16, 16 November 2025 (UTC)
- Another benefit for those wiki's to just rely on Wikidata for this. Sjoerd de Bruin (talk) 22:45, 16 November 2025 (UTC)
- Is there any tool / query (probably quarry) that could check
- all redirect pages and
- all pages that were moved without leaving a redirect
- whether they contain files so that one could for example create a regularly bot-updated report page that lists these categories for editors to fix these? Prototyperspective (talk) 12:19, 19 November 2025 (UTC)
A non-registered user is empying the categoies "World War II ships of the Netherlands]] the previous days. Is that a correct move? Stunteltje (talk) 12:22, 16 November 2025 (UTC)
- Examples? Functional wikilink: Category:World War II ships of the Netherlands. Prototyperspective (talk) 13:15, 16 November 2025 (UTC)
- Category:Hr.Ms. Sumatra (ship, 1926) from Category:World War II cruisers of the NetherlandsStunteltje (talk) 19:42, 16 November 2025 (UTC)
- I undid some of the edits of this anonymous user, as I don't see why this category is removed. Thanks. Tvpuppy (talk) 15:20, 17 November 2025 (UTC)
- Category:Hr.Ms. Sumatra (ship, 1926) from Category:World War II cruisers of the NetherlandsStunteltje (talk) 19:42, 16 November 2025 (UTC)
- @~2025-34477-45: Please use the edit summary field to explain why you made certain changes. Why did you empty these categories? Also please don't edit war but discuss with the user.
- @Stunteltje: Have all the edits been reverted by now? Prototyperspective (talk) 21:18, 19 November 2025 (UTC)
- Forgot to mention here, I made a report at AN/U regarding this unregistered user (see COM:AN/U#User:~2025-32925-15), since they were causing multiple problems other than this one here. The user did not respond there, so it is unlikely they will respond here. Thanks. Tvpuppy (talk) 22:44, 19 November 2025 (UTC)
- I will try to find te deleted categories.Stunteltje (talk) 09:36, 20 November 2025 (UTC)
- Forgot to mention here, I made a report at AN/U regarding this unregistered user (see COM:AN/U#User:~2025-32925-15), since they were causing multiple problems other than this one here. The user did not respond there, so it is unlikely they will respond here. Thanks. Tvpuppy (talk) 22:44, 19 November 2025 (UTC)
Big PNG and small JPG dupes
User:Killboy010 uploaded:
File:Γκάντατζ.png 2,560 × 1,920 (9.98 MB)
File:Γκάντατζ1.jpg 640 × 480 (188 KB)
what to do in this situation? RoyZuo (talk) 15:29, 16 November 2025 (UTC)
- Convert the large PNG into a JPEG and delete the other two? Nosferattus (talk) 15:53, 16 November 2025 (UTC)
- Keep both, but add the higher resolution image as "other versions" to the smaller image. Wouter (talk) 16:42, 16 November 2025 (UTC)
- Convert the large PNG into a JPG and overwrite the small JPG with the large one. Keep both files, but have them link to each other in the "other versions" field. ReneeWrites (talk) 16:58, 16 November 2025 (UTC)
- Keep both versions or delete low-quality JPEG. Юрий Д.К. 18:50, 16 November 2025 (UTC)
- Delete the jpg per F8
The file is an exact or scaled-down duplicate of an older existing file.
but I haven't checked which of the two files was uploaded first and thinkan older
would be good to change toanother
in that policy. Prototyperspective (talk) 22:37, 16 November 2025 (UTC)- We can retain different file types of the same image. See Commons:File types#PNG for details of a bug affecting thumbnails of PNG images. It is normally a good idea to retain a JPG version of a PNG file, where available. The PNG file is a lossless file type that is a good starting point for any crops or file conversions, while JPG is a lower quality compressed file that avoids the thumbnail bug. In this case, ReneeWrites' solution provides us with the best of both worlds; retaining high quality PNG and JPG files that serve both roles. From Hill To Shore (talk) 23:40, 16 November 2025 (UTC)
It is normally a good idea to retain a JPG version of a PNG file, where available
Strongly disagree and a JPG is available for all files because they can/could all just be converted to jpg. It clutters search results and category pages and comes with lots of other problems without any benefit if the file-title isn't significantly better. Transcoding a jpg version at upload of PNG files could be something to consider. The bug needs fixing (and/or a workaround) instead of images being uploaded twice. Prototyperspective (talk) 23:46, 16 November 2025 (UTC)- Please read Commons:File types. There are plenty of advantages and disadvantages between file types, so saying this is "without any benefit" is incorrect. Instead, you see the increased categorisation burden as outweighing the problems with the different file types. Your preference does not negate the existence of other benefits. If you wish to change this, push to get the bug fixed (if it can be fixed) and gain consensus that the other issues explained in Commons:File types are secondary to categorisation issues. From Hill To Shore (talk) 00:01, 17 November 2025 (UTC)
- No, I don't. There are lots of downsides and I named more than just that one. Another examples is bloating up feeds that people patrol or watch by up to twice the size. The file with the highest quality is best and can be converted to other file types if needed or alternatively be transcoded by the Commons software so that e.g. all PNG files have a jpg file version available in the file description page. Moreover, that bug doesn't even affect the file this thread is about or does it? Prototyperspective (talk) 01:01, 17 November 2025 (UTC)
- Agree with User:Prototyperspective. The PNG is inherently a better, lossless format. It's only drawback used to be the demand for larger file sizes, but the internet has moved on since then. The thumbnail problem seems to manifest itself mostly in two-tone graphics and drawings. It is not particularly important and should be solvable. For those of us who do a fair bit of categorization, needless doubles are indeed a nuisance. Cheers Rsteen (talk) 02:58, 17 November 2025 (UTC)
- Allowing users to override what type of scaling is used on an image might be a worthwhile feature request. Omphalographer (talk) 20:44, 17 November 2025 (UTC)
- Agree with User:Prototyperspective. The PNG is inherently a better, lossless format. It's only drawback used to be the demand for larger file sizes, but the internet has moved on since then. The thumbnail problem seems to manifest itself mostly in two-tone graphics and drawings. It is not particularly important and should be solvable. For those of us who do a fair bit of categorization, needless doubles are indeed a nuisance. Cheers Rsteen (talk) 02:58, 17 November 2025 (UTC)
- No, I don't. There are lots of downsides and I named more than just that one. Another examples is bloating up feeds that people patrol or watch by up to twice the size. The file with the highest quality is best and can be converted to other file types if needed or alternatively be transcoded by the Commons software so that e.g. all PNG files have a jpg file version available in the file description page. Moreover, that bug doesn't even affect the file this thread is about or does it? Prototyperspective (talk) 01:01, 17 November 2025 (UTC)
- Please read Commons:File types. There are plenty of advantages and disadvantages between file types, so saying this is "without any benefit" is incorrect. Instead, you see the increased categorisation burden as outweighing the problems with the different file types. Your preference does not negate the existence of other benefits. If you wish to change this, push to get the bug fixed (if it can be fixed) and gain consensus that the other issues explained in Commons:File types are secondary to categorisation issues. From Hill To Shore (talk) 00:01, 17 November 2025 (UTC)
- We can retain different file types of the same image. See Commons:File types#PNG for details of a bug affecting thumbnails of PNG images. It is normally a good idea to retain a JPG version of a PNG file, where available. The PNG file is a lossless file type that is a good starting point for any crops or file conversions, while JPG is a lower quality compressed file that avoids the thumbnail bug. In this case, ReneeWrites' solution provides us with the best of both worlds; retaining high quality PNG and JPG files that serve both roles. From Hill To Shore (talk) 23:40, 16 November 2025 (UTC)
November 17
- The category is about a quite important subject
- It could contain some of the most educational most useful files
- It could be very useful as a way to find specific files, explore interesting content, filter search results, and organize files
However, it's very incomplete. Could people here help populating it? Does anybody have any ideas for search queries and tool-uses to find lots of files that belong into it?
For example, I imagine one could somehow show all files that are in more than one subcategory of Category:Life expectancy charts by country to put them into Category:Life expectancy charts comparing countries which is a new subcat of Charts comparing countries.
Then there's some categories that likely contain many relevant categories like Category:Statistics of Europe.
Iirc, I added Charts comparing countries as a redcat to some files and didn't yet create it because it's neither close to complete – and I currently didn't want / have the time to work on making it – nor even just containing many files. Iketsi apparently went ahead and created that cat apparently without worrying much or at all about putting files in it.
I know that lots of nonmap/chart files in Category:Our World in Data show data of multiple countries but don't know how one could filter for these to put them all into the cat.
Lastly, please comment if you have an idea how to make this category better findable to places where it's useful and people who may be interested in these, for example from Wikipedia. E.g. there are Wikipedia articles about statistics like Solar power by country and there doesn't seem to be an article for statistics comparing countries but there could be some section somewhere and things like that. Prototyperspective (talk) 12:15, 17 November 2025 (UTC)
- Should we categorize after the countries that are being compared and which years they are comparing? Trade (talk) 16:55, 17 November 2025 (UTC)
- That would be difficult and also probably not very useful for files that compare 5+ countries (such charts are quite common) to be subcategorized by all the included countries.
- Subcategorizing by content / region for charts that compare only countries of a world region makes a lot of sense – Examples: Africa, South Asia, EU, G7
- It would be best I think to have all the files subcategorized first of all by subject area
- Often nearly all countries are being compared and either all of the compared ones or the top/bottom fraction thereof shown in the cart. It's more useful to navigate by subject and much more feasible to categorize by it. Prototyperspective (talk) 17:24, 17 November 2025 (UTC)
- Why cant we compare by year? There are only one or two of those in each chart Trade (talk) 02:39, 19 November 2025 (UTC)
- What do you mean (and how does it relate to the prior comment)? Did you ask whether Category:Charts comparing countries by year would make sense? I think it would also make sense to subcategorize by decade and year there. Only some charts compare just the state of things in one year for multiple countries, there's many that span several years – see Category:Charts by year of latest data. Nevertheless, it may be difficult to subcategorize into these and make the decade/year cats fairly complete so it would still be better to subcategorize by subject and worry about other ways to subcategorize later imo. Prototyperspective (talk) 16:04, 19 November 2025 (UTC)
- Why cant we compare by year? There are only one or two of those in each chart Trade (talk) 02:39, 19 November 2025 (UTC)
- That would be difficult and also probably not very useful for files that compare 5+ countries (such charts are quite common) to be subcategorized by all the included countries.
Contradictions & ambiguity within Wikimedia projects
Created this new category: Category:Contradictions within Wikimedia projects
Looking for some more files to add to it and, why I'm creating this thread, also some examples and ideas how to visualize the concept(s) and its subtypes:
- Contradiction between the categories of two language versions of a Wikipedia article: e.g. German Wikipedia has category 1980 deaths while English Wikipedia has 1982 deaths – how to best visualize this concept / is there file(s) that show this?
- Contradiction between text contents of two language versions of a Wikipedia article: I heard about the idea of, basically, having LLMs read the language versions of Wikipedia articles and showing which things in the article may contradict with other language versions – is there any media on this?
- On English Wikipedia there is a template for contradictions between ENWP articles which puts articles into en:Category:Articles contradicting other articles – maybe somebody could create a diagram to explain this. There also is this new research project do detect such: m:Research:Wikipedia Inconsistency Detection
- There is this preprint study about a tool that identifies articles contradicting themselves in the text
- There are sometimes contradictions between the data in Wikidata and Wikipedia, specifically the data in Wikipedia's infoboxes and/or categories – there doesn't seem to be a tool to list these so users can correct either / sync them; maybe somebody knows of an example to screenshot to explain this assuming there's no better way to explain this
- Here on Commons categories of a file or a category can contradict each other
-
- Is there maybe a meta page about all this? Maybe a WikiProject, or task force, or tool(s), or media coverage?
- Especially if there is none, I may create a new page about this on metawiki but I don't know much about it, it would be quite short, it would barely be found by people, and it would need or greatly benefit from explanatory & statistical media about this. I've been thinking a while about this, basically in the context of it being as a specific class of Wikimedia contribution types. (And a class where tools could be especially useful, e.g. via creating reports like Commons:Database reports/Category cycles.)
I also created Category:Ambiguity within Wikimedia projects. Both of these categories are fairly empty and it would be great if more files could be added or uploaded to them. For a brief example of ambiguity and an example of how it can be dealt with: the Wikidata property spoken text audio (P989) can have an audio file that is the audio version of the Wikipedia article of the item but if the Wikipedia article is about a poem or novel for example, it could also be a spoken version (e.g. audiobook) of the poem or novel, not the Wikipedia article. This means the property is ambiguous and a solution could be to create a new Wikidata property for either kind of spoken text audio.
I think there is no overview or page systematically integrating and describing this, just a few loose files and categories few people are aware of. Neither does there seem to be any organized effort or comprehensive tool that works at scale. So far, the cat has just few files and barely anyone knows about this broad concept in the context of tasks.
Also Category:Wikimedia projects would benefit from being diffused more – it now has so many direct subcategories that visitors of that page will be put off and are rather unlikely to explore further with so many subcategories. Prototyperspective (talk) 18:12, 17 November 2025 (UTC)
- @Prototyperspective: as you mentioned this is really more appropriate for meta. I am not certain what files you expect for the Commons category since we are limited to media. Some screenshots, graphs, help pictures? I will also note that some of your examples are not correct: en:Category:1982 deaths has an equivalent de:Kategorie:Gestorben 1982 and they are both linked to each other in wikidata. However there is absolutely no expectation that the category systems of different wikipedias would be equivalent - in practice they are for large parts, but each wikipedia is allowed to create their own custom categorization systems.
- Article texts are by necessity created by different people using different sources so they will be very much different from each other. The ideal would be that articles are reasonably comprehensive and correct, but they are not translations of each other. Some language articles will be outdated or stubs, others are well maintained.
- I suggest you ask about this in meta:Wikimedia Forum. MKFI (talk) 15:46, 18 November 2025 (UTC)
- However, one can't well ask about media files on metawiki.
I am not certain what files you expect for the Commons category
I'm asking about what files people would expect for the one part. E.g. ideas how these things could be visualized. For the other part, yes also screenshots (see "maybe somebody knows an example to screenshot"), graphs, and more. Don't know what you mean by help pictures (diagrams?) but these too probably. I will also note that some of your examples are not correct: en:Category:1982 deaths has an equivalent de:Kategorie:Gestorben 1982 and they are both linked to each other in wikidata.
The example is correct. There are also inconsistencies between linked and unlinked categories but here I was talking about a Wikipedia article about a person where in one language version it has "1982 deaths" and in the other "1980 deaths" which can be identified by a tool – or a human if things are inefficient – to be inconsistent or likely inconsistent.each wikipedia is allowed to create their own custom categorization systems
again, this all comes from a misunderstanding what I was saying. And categories about fundamentally different things shouldn't and aren't linked to each other on Wikidata and vice versa.The ideal would be that articles are reasonably comprehensive and correct
of these two things, this thread is only about the latter / contradictions between them.Some language articles will be outdated […] others are well maintained
I don't know what repeating this part of my comment is supposed to mean/say.- Thanks, will ask there (albeit the place seems fairly inactive) but this thread here is about 1. specific also to contradictions and ambiguity on Commons, e.g. as it comes to categories of files and 2. (main point of the thread) about adding existing and creating new media and ideas for new media for these two categories. Prototyperspective (talk) 16:08, 18 November 2025 (UTC)
- However, one can't well ask about media files on metawiki.
- @Prototyperspective: have you checked existing methods of tracking the differences, such as en:Category:Wikipedia categories tracking Wikidata differences, how they are created and who maintains them? You might find help and interested people that way. MKFI (talk) 17:43, 18 November 2025 (UTC)
- Thank you for this categorylink! I didn't know about it. I'm interested in the existing methods, e.g. to raise awareness of the big potential there so this is scaled this up and specifically via media that explains this. However, media about it seems missing and there's seemingly just a loose pages with no associated info page or organized efforts or large awareness about them. In the case of that category, is there any diagram or other media file that explains how this category works like it's populated and how it's being used? Maybe somebody here knows some media files or alternatively more about these existing methods plus ideas how it could be visualized... At least I found 2 PDF files by searching for "Wikipedia categories tracking Wikidata differences" that I'll probably add to the cat. Prototyperspective (talk) 23:07, 18 November 2025 (UTC)
- @Prototyperspective: have you checked existing methods of tracking the differences, such as en:Category:Wikipedia categories tracking Wikidata differences, how they are created and who maintains them? You might find help and interested people that way. MKFI (talk) 17:43, 18 November 2025 (UTC)
November 18
Flag of Nevada and an inconsistency
Recently, it has come to my attention that the Flag of Nevada uploaded here contain the incorrect colors in its field, scroll, sagebrush, flowers, and most importantly: the star. Per the NRS Chapter 235, the design of the flag "must be of solid cobalt blue." It also specifies the color of the star to be silver (per the state's official nickname, "The Silver State"). In addition to how the colors should be interpreted (even though there's no official enforcement, however I believe it was always wrong), The design of "The scroll and the word “Nevada” must be golden-yellow. The lettering on the scroll must be black-colored sans serif gothic capital letters." According to various different versions, those scrolls have the font "Samdan", per this page on DaFont. However, according to the current version hosted here, it uses "Helvetica Neue" (which is also what the first iteration of the Clark County flag used, per a low quality image found on the CRW flags website.)
Now, my question I'd like to ask is: Should we replace the long, outstanding file with the iteration I uploaded, or do a delete move instance for moving my said file to the "Flag of Nevada" destination and move that file to a different name? This is something that had been recently bothering me, and as a Nevadan, it upsets me that the flag uploaded on here was never really the actual state flag. It was always wrong in color. ₘₒd cᵣₑₐₜₒᵣ ✰ ʜᴀʙʟᴀ ⍟ コントリビューション 00:21, 18 November 2025 (UTC)
- Update: The Samdan font style is actually not considered to be part of the flag code, it's just how some flag manufacturers interpret that. It's always Helvetica Neue for both "BATTLE BORN" and "NEVADA", as that typeface does meet the "Gothic sans-serif" design. ₘₒd cᵣₑₐₜₒᵣ ✰ ʜᴀʙʟᴀ ⍟ コントリビューション 03:00, 18 November 2025 (UTC)
- Just an aside: I can't readily find the flag as such anywhere on the state's own site; I expect the image on page 10 of https://dhcfp.nv.gov/uploadedFiles/dhcfpnvgov/content/Providers/Informational%20Medicaid%20Managed%20Care%20Expansion%20Webinar%20Presentation.pdf has the same lineage as our old file.
- I'm sure you are correct about the star; less certain about the particular yellow, where did you get that?
- No opinion on how we should handle the file move. This sort of thing can be tricky, because if we do it by a pair of moves, we have to be careful not to do a "move and replace." - Jmabel ! talk 03:59, 18 November 2025 (UTC)
- The yellow actually comes from the second version of the Flag of Nevada file: [1], and while the CRW website does have the yellow on the flag, it's not that exact yellow. I hope that is clarified. ₘₒd cᵣₑₐₜₒᵣ ✰ ʜᴀʙʟᴀ ⍟ コントリビューション 23:40, 18 November 2025 (UTC)
What are these typographer codes called?
What are these typographer codes called that appear in the lower left hand corner of public notices and ads in newspapers? They appear to be telling the typesetter how long the ad runs, so they do not break up the type. --RAN (talk) 03:42, 18 November 2025 (UTC)
- @Richard Arthur Norton (1958- ): Can you link an example or two of what you are talking about? - Jmabel ! talk 03:53, 18 November 2025 (UTC)
- Ooops! File:William Naughton (1809-1891) probate in The Berkshire County Eagle of Pittsfield, Massachusetts on May 28, 1891.jpg and there are more in the Category:Probate records. One of the numbers must be how long to run the ad. --RAN (talk) 04:02, 18 November 2025 (UTC)
- Probably for typesetters rather than typographers, but I don't have an answer to the question of what they are called. - Jmabel ! talk 06:25, 18 November 2025 (UTC)
- It may be a good idea to put info requests like this into Commons:Expert identification or categorization requests and then having a thread where these are bundled. It seems not very important or relevant to the entire global Commons community – if you knew how these are called would this have any impact on the file? I don't think files should be categorized by some tiny textcode in the corner. The respective categories would be very incomplete, distract, and not used/useful. Could be wrong of course but then it would be good to explain why you need to know what these are / what you'd like to do with the info. Prototyperspective (talk) 15:59, 18 November 2025 (UTC)
Author of Vietnam famous picture
Hi, It seems the author of a famous photo of the Vietnam War is not the one usually credited: ["Petite Fille au napalm" : un analyste français remet à son tour en cause la paternité de la photo https://www.franceinfo.fr/culture/arts-expos/photographie/petite-fille-au-napalm-un-analyste-francais-remet-a-son-tour-en-cause-la-paternite-de-la-photo_7614215.html]. Yann (talk) 11:08, 18 November 2025 (UTC)
- The category about it is Category:The Terror of War. Seems like there is just one file whose description would need to be adjusted.
The Netflix movie The Stringer wants to determine that whoever actually holds the camera when taking this photo is not Nick Ut, but a freelancer from the same agency, Nguyen Thanh Nghe. Hence the name of the documentary because "stringer" means "pigist" in English, unlike a person under contract.
(machine translation) has this been determined yet? If not, the Commons community probably can't determine it but maybe this info should be added to the file's author info. If it is, the file page would need to be changed. It doesn't seem like it would have implications for the licensing. The Wikidata infobox hasCreator: Nick Ut (attribution, The Stringer, disputed)
. Prototyperspective (talk) 15:45, 18 November 2025 (UTC)- Edited the file description page. This should solve it, or not? One curious thing is that the file, a quite famous photo, is not used anywhere so far. Prototyperspective (talk) 21:23, 19 November 2025 (UTC)
Street parts in US cities
Hello, some cities in USA have streets with 'east' and 'west' parts, which is sometimes reflected in the name of those segments (e.g. Broadway and West Broadway in San Diego - see https://www.openstreetmap.org/#map=17/32.715874/-117.163117) When putting files into categories, what is the common practice - use separate categories for ther east/west/no parts, or just one category (e.g. Broadway, without further division)? Thank you. --JiriMatejicek (talk) 15:21, 18 November 2025 (UTC)
- From what I have seen, only one category. Ymblanter (talk) 15:54, 18 November 2025 (UTC)
- Ymblanter is right for most cases, but there are exceptions like Category:First Avenue South, Seattle: it is rather different in character from the (unmodified) First Avenue, and once upon a time even had a different name. Also, Seattle has an entirely unrelated First Avenue NW, First Avenue NE, etc. (not along the same line) that happen not to merit categories; the same must happen in some other cities. - Jmabel ! talk 23:34, 19 November 2025 (UTC)
The category is strangely empty. It doesn't contain a subcat about the ancient Americas. Shouldn't e.g. Category:Maps of the Mayas be in a cat like that?
Moreover, none of the subcats of Category:Maps by year shown or their parent cats are in this category – shouldn't this be changed and if so, how? Also pinging @Enyavar: .
Lastly – and this fits well into a CfD – is the title of this cat and other cats in Category:Maps showing history really appropriate? It sounds as if these maps would show historical developments such as from where to where some people moved (how things developed over a certain period). But the maps each show a situation at a certain ancient time such as population centers on a map. The category is linked to Wikidata historical map (Q459798) described as "map displaying a past event or other historical situation". These maps mostly don't show historical events or historical situations but simply the past of any kind (specifically the ancient past). Prototyperspective (talk) 17:44, 18 November 2025 (UTC)
- Categories referring to history are generally not useful. There is no agreement about when history starts. Better to use categories with actual dates. Rathfelder (talk) 19:48, 18 November 2025 (UTC)
- Hi @Prototyperspective: , "Maps of the Mayas" are a subcategory of "Maps of ancient peoples". I do agree that the "maps showing history" category tree feels pretty raw. The history map section on Commons is not fully fleshed out, and I suppose we need a concept on how it should be best structured. I even had arguments with a fellow editor recently on how explicitly regionalized the tree ought to be. (i.e. Maps of Belgium in the 8th century vs. Maps of Luxembourg in the 8th century vs. Maps of the Netherlands in the 8th century: Aren't these just the same? (CfD here, be warned, we are both wall-texters, but the initial proposal is quite brief.)
- Maps by year shown (or maps by century shown) should in my opinion not necessarily be part of the "ancient" category, because timespans in history are so hard to define. "Antiquity" was traditionally subdivided into Stone/Bronze/Iron age, which then was succeeded by classical and late antiquity... in Europe and the Near East. The 5th century, when the European middle ages began, was still prehistoric in North America (the Mesoamerican cultures excluded). Right now, I added a disclaimer to the "maps of history by period" category, because I fear that some nitpickers will try and apply the distinction of prehistory and recorded history onto the category to further confuse matters. Aside from that, I have placed a link to "maps showing history by millenium BC" in the OP category. It is a parallel structure though, not a sub/parent cat.
- Re "usefulness" of the "history" categories: "History" in our category tree is anything that is about the past. A lot of people are categorizing everything by year and months, and then locate these categories under "history of...". Even the stuff from the 2020s is usually found under "history". That whole practice is often not particularly useful, sure. --Enyavar (talk) 21:59, 18 November 2025 (UTC)
- By the way it would be better to click Reply underneath the post to which you're replying to or if editing wikitext set the indentation accordingly.
- I saw "Maps of the Mayas" is already a subcategory of that. I doubt that all maps of the ancient Americas are of Maya and even if adding a subcat for the Americas seems missing considering the other subcats of that cat and how it can be found starting from other categories.
and I suppose we need a concept on how it should be best structured
Let's discuss it here then, specifically for Category:Maps showing ancient history and secondarily also for the broader Category:Maps showing history cats regarding the "showing history" part in terms of whether maps just showing a long-ago state of things are "showing history" as opposed to just maps where historical events or developments are illustrated.Maps by year shown (or maps by century shown) should in my opinion not necessarily be part of the "ancient" category,
The proposal is to a fraction of these to the category, not the entire category. The time period included can then be easily changed and be oriented toward some academic consensus of which period(s per location) can be classed as Ancient history, where the gray area category/ies is/are e.g. only linked as see also instead of being subcategories. This would benefit from and incorporate the existing finely-set (down to by year not just broad historical era) categories rather than for example copying the files into this cat. This isn't clear and easy to do so this thread could be used to flesh out how a solution.The 5th century, when the European middle ages began, was still prehistoric in North America
Indeed that's part of the problem: periods vary per region. So maybe things can only be done once the Category:Maps by century shown cats are subcategorized into by-region subcategories(?) (or only those subcategories get added).added a disclaimer to the "maps of history by period" category
Thanks. Category:Maps showing history by period definitely should inform that "prehistory [is grouped] into history categories" despite that many main definitions of "history" distinguish it from prehistory (btw many also it as the study of / information about and field about the past from the past itself).Aside from that, I have placed a link to "maps showing history by millenium BC" in the OP category
Thanks, good call.It is a parallel structure though, not a sub/parent cat.
Yes that's how things currently are but I suggested here for this to be changed somehow in an adequate way.Even the stuff from the 2020s is usually found under "history" […]
This is not relating to the primary subject of the 'ancient history' cats where this isn't the case. It does relate to the secondary topic of Category:Maps showing history which brings me back to my question of whether that title is (/ these titles are) adequate. Prototyperspective (talk) 17:38, 19 November 2025 (UTC)
Categories referring to history are generally not useful.
Strongly disagree.Better to use categories with actual dates
Agree that it would be better but that's not an either or question: both can be done where the year category is arguably more important. We shouldn't delete Category:History and do away with history cats. The full term here is "ancient history", not just history btw. And it makes sense to have categories for ancient history, middle ages etc because that's making it a lot easier to find things. Organizing also gets better and lots of sources and articles and topics are about such or things by such delineations. Just because it's not perfectly clear-cut doesn't make it useless. There's a lot of other things we organize by that also aren't clear cut.- At Category:Maps by year shown the question or challenge I was asking about is also about how to subcategorize a fraction of these into the cat – if this is done by putting these cats in there instead of e.g. just a fraction of the files – which of course brings the issues of it not being clear cut to the forefront.
- I can't now explain you in length why the concept of ancient history is of value but it is and there's good reasons the Wikipedia article about it, Ancient history, exists in 117 language versions and has lots of big sources about exactly that scope, high readership, many articles in its cat, and much info; etc. Prototyperspective (talk) 23:17, 18 November 2025 (UTC)
- Oh yes, of course, history categories per se are eminently useful.
- My critique was mostly on the praxis that detailed ("dated") history like Rathfelder preferred above my comment, usually just spans the last fifteen years, as can be seen for example in this random history category: We have files explictly dated by year and month about the "history" shown in random photographs dated between 2010 to 2024: flowers in parks, sunsets, memorials, road and building infrastructure. I firmly believe that in most cases, it matters little whether those photos were taken in the 1990s or this year, unless you can hold them next to each other and point out the changes.
- It is good and important to date our photos, but these examples do not show "history" in my opinion. This would be different with media about unique events (festivals, demonstrations, catastrophes).
- The linked example shows how one can group content in a better way instead of by-year breakdowns: photos of history markers/placques/monuments get their own category. Old maps get their own category. Registered historical buildings and sites get their own categories. That should be the focus of "history of" categories in my opinion.
- I see more or less the same pattern with History of Chongqing, History of Kanchipuram, History of Caen, i.e. all over the place: Detailed and sometimes meaningless by-year subcategorization, while broader subcategories by theme are more helpful in finding things.
- Back to the "maps by year shown", those are helpful when the map content can be clearly dated to a year. I also would like to locate these maps as well, like Maps of North America in the 17th century: First collect enough maps for an area and a century, and subdividing into decades or years on a much later stage. --Enyavar (talk) 16:30, 19 November 2025 (UTC)
- --Enyavar (talk) 16:30, 19 November 2025 (UTC)
- My comment was a reply to Rathfelder, not to your comment.
but these examples do not show "history" in my opinion. This would be different with media about unique events
that's also what I argued in my opening post (if I understood you correctly).that detailed ("dated") history […] usually just spans the last fifteen years, as can be seen for example in this random history category
off-topic to this thread, sorry, but you could make a separate thread about this subject.Detailed and sometimes meaningless by-year subcategorization, while broader subcategories by theme are more helpful in finding things.
I think I agree but I think that by-year categories are often useful, just usually for such cases shouldn't be the main or only or first criteria to subcategorize by. Also off-topic to this thread.Back to the "maps by year shown", those are helpful when…
as is, also off-topic to this thread. Clearly those are useful. But let's please discuss the topic of the thread and open a separate one about other or tangentially related topics. Prototyperspective (talk) 17:13, 19 November 2025 (UTC)- I am not against categories of history of any kind, but I dont think there is widespread understanding of when ancient or medieval history began or ended, so I think they should, where possible, be populated by categories by century or millenium. Rathfelder (talk) 17:16, 20 November 2025 (UTC)
- When exactly each era started/ended is not important to most use-cases / users that use these categories that adopt a widely-used concept and distinction. Yes, they should be also categorized by century or millenium or year. Prototyperspective (talk) 15:28, 21 November 2025 (UTC)
- I am not against categories of history of any kind, but I dont think there is widespread understanding of when ancient or medieval history began or ended, so I think they should, where possible, be populated by categories by century or millenium. Rathfelder (talk) 17:16, 20 November 2025 (UTC)
- My comment was a reply to Rathfelder, not to your comment.
November 20
It is not normal to name all the files using own nickname?
I've found one user who names all the files with their own name. Something like <subject>_<name>.<ext> Name space is already very polluted and this thing pollutes it even more. At the same time I understand that looking for new name is a bit hard task. So...
1. Is it normal to do use such namings? 2. If it is not desirable naming scheme, what should I do? I should go to users talk page, politely explain and hope they will understand? DustDFG (talk) 11:25, 20 November 2025 (UTC)
- It's not 'normal', it's not encouraged, but nor is it forbidden. This isn't helped by a couple of prominent and very active editors here (inc. at least one admin) who do this, and will angrily defend against any renaming.
- BTW, the same policy of 'free choice' that makes this possible also means that it's nearly as easy to rename them otherwise, should one of the other general conditions for renaming be met. Andy Dingley (talk) 12:32, 20 November 2025 (UTC)
- To be clear. Ppl have no RIGHT to demand this name is preserved, similar to how they have no right to retain metadata in the exif, or a specific mark inside a photograph. These are not rights that the license provides them, literally the opposite, the license explicitly permits others to make such changes.
- They get their name somewhere, the license somewhere and often the share alike provision and thats it. The rest is a courtesy, and the more people abuse a courtesy (for instance by plastering their names over each and every wiki page that uses an image) the more likely they are to eventually cause every person to loose that courtesy. (Aka. Why we cant have nice things) —TheDJ (talk • contribs) 16:32, 20 November 2025 (UTC)
- The topic of rights is irrelevant here. Commons instead has policies, including a naming policy that outlines which files should and shouldn't be renamed, and if a filename meets the naming guidelines otherwise, there are no grounds for renaming files just to remove the author's name from it. ReneeWrites (talk) 17:45, 20 November 2025 (UTC)
- @ReneeWrites I was just saying that that is a choice. If people start misusing policy because they figured out it is a good way to insert their name everywhere without other people being allowed to complain about it, then we can amend the naming policy (and in my opinion should [but I haven't looked into how much of a problem this actually is right now, so no opinion on that]). This is somewhat alike to the whole GFDL debate. —TheDJ (talk • contribs) 09:12, 21 November 2025 (UTC)
- The topic of rights is irrelevant here. Commons instead has policies, including a naming policy that outlines which files should and shouldn't be renamed, and if a filename meets the naming guidelines otherwise, there are no grounds for renaming files just to remove the author's name from it. ReneeWrites (talk) 17:45, 20 November 2025 (UTC)
Reminder: Help us decide the name of the new Abstract Wikipedia project
Hello. Reminder: Please help to choose name for the new Abstract Wikipedia wiki project. The finalist vote starts today. The finalists for the name are: Abstract Wikipedia, Multilingual Wikipedia, Wikiabstracts, Wikigenerator, Proto-Wiki. If you would like to participate, then please learn more and vote now at meta-wiki. Thank you!
-- User:Sannita (WMF) (talk) 14:21, 20 November 2025 (UTC)
(This message was sent to Commons:Txokoa and is being posted here due to a redirect.)
Paintings "in" vs. paintings "from" categories
I'm a bit confused by the fact we simultaneously have categories like Category:1930 paintings from Mexico and Category:1930 paintings in Mexico. What is the distinction between them? Sdkb talk 18:34, 20 November 2025 (UTC)
- Just a guess but it seems like the former is paintings made in Mexico in 1930, while the latter is paintings made in 1930 which are currently housed/located in a public collection in Mexico. 19h00s (talk) 18:41, 20 November 2025 (UTC)
- That makes sense. As a meta thing, I wish we'd do a better job of building out descriptions as we build out categories. The proper domain of a category is always obvious to the editor who creates it, but not always to others. Sdkb talk 18:58, 20 November 2025 (UTC)
- Also a meta thing: we could really use some better guidelines on how to use prepositions in category names - right now it feels like we pick randomly between "in", "of", and "from", and a nontrivial number of categories end up duplicated and/or with inconsistent names as a result. Omphalographer (talk) 20:20, 20 November 2025 (UTC)
- cc @MarbleGarden because of your edit to Category:Prometeo (Orozco), which is a mural done in the U.S. by a Mexican painter. Sdkb talk 20:21, 20 November 2025 (UTC)
- My understanding based on the guidance for the country categories for "portrait paintings from", was that the "from" category is based on the nationality of the painter. MarbleGarden (talk) 20:56, 20 November 2025 (UTC)
- That doesn't make sense as guidance, though, imo. A Mexican portrait painter working in, say, France, is by definition not making "portrait paintings from Mexico". 19h00s (talk) 21:12, 20 November 2025 (UTC)
- Its not just paintings. There are many categories where it is clear many editors dont understand the intended differences between in, of, from, and the like - stuff that doesnt translate easily. No easy answer, but I think we should at least have some explanations. Rathfelder (talk) 16:47, 21 November 2025 (UTC)
- That doesn't make sense as guidance, though, imo. A Mexican portrait painter working in, say, France, is by definition not making "portrait paintings from Mexico". 19h00s (talk) 21:12, 20 November 2025 (UTC)
- My understanding based on the guidance for the country categories for "portrait paintings from", was that the "from" category is based on the nationality of the painter. MarbleGarden (talk) 20:56, 20 November 2025 (UTC)
- That makes sense. As a meta thing, I wish we'd do a better job of building out descriptions as we build out categories. The proper domain of a category is always obvious to the editor who creates it, but not always to others. Sdkb talk 18:58, 20 November 2025 (UTC)
Issues with requesting permission information of File:Voice of Korea English Service Logo.png
I have no idea how to request permission from the Voice of Korea. I know they have an E-mail address (vok@star-co.net.kp), but I do not think they will actually respond to my requests to permission information.
Melissza’s page Have a talk! See my contributions 19:20, 20 November 2025 (UTC) – uploader of this image and File:Voice of Korea Korean Service Logo.png
- Best practice is, to first make sure your permission is in order, and only then upload the file...
- I'm sorry they're not responding to your emails. Ciell (talk) 19:35, 20 November 2025 (UTC)
- It’s not that they aren’t, it’s that I don’t think they will. After all, it’s North Korea. That or I’m not looking at the right way. Melissza’s page Have a talk! See my contributions 19:51, 20 November 2025 (UTC)
- Then simply don't upload the files. Maybe you could file a Commons:Permission requests. There probably isn't anything that could be done here so this could probably be closed. You could of course look for other contact information but it seems unlikely the chances of a reply are higher than with the email. Prototyperspective (talk) 15:34, 21 November 2025 (UTC)
- It’s not that they aren’t, it’s that I don’t think they will. After all, it’s North Korea. That or I’m not looking at the right way. Melissza’s page Have a talk! See my contributions 19:51, 20 November 2025 (UTC)
Hand typed text

We have handwritten categories, but I dont see any handtyped categories. This example is clearly typed with a classic typewriter, not even an electric one, where the impact is constant. Nowadays this type of text is not made anymore, but (laser)printed. The most handy solution to make the handwritten text in Category:Lettre posthume de Bernard à Estelle is of course to write out the text in the French Wikisource, but in the meantime... Smiley.toerist (talk) 22:28, 20 November 2025 (UTC)
- @Smiley.toerist: I've recently been wanting to categorise typewritten documents by equipment as well. I've not thought to distinguish between electric and manual typewriters, but that totally makes sense if it's determinable. We have categories for Handwriting and Writing by medium and Writing equipment, so maybe Writing by equipment used would make sense? With Written with electric typewriters, Written with manual typewriters, Written with fountain pen etc. as subcats? Sam Wilson 03:21, 21 November 2025 (UTC)
- There is Category:Typed texts from Gallica, so as a first step I created Category:Typed texts. There are many categories under Category:Writing systems. Also interesting are the typefaces. Smiley.toerist (talk) 10:39, 21 November 2025 (UTC)
- @Smiley.toerist, should that new Category:Typed texts, include the category "typewriters?" -- Ooligan (talk) 00:45, 22 November 2025 (UTC)
- There is Category:Typed texts from Gallica, so as a first step I created Category:Typed texts. There are many categories under Category:Writing systems. Also interesting are the typefaces. Smiley.toerist (talk) 10:39, 21 November 2025 (UTC)
November 21
Where to challenge undeletion
To say I'm surprised by the undeletion (a supervote?) at Commons:Undeletion requests/Current requests#File:Nintendo Advanced Video System cartridge console, data recorder and keyboard all together-February 1985 Computer Entertainer.jpg is an understatement - but I'm not clear where such an action should be challenged. Is here a suitable place for discussion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 21 November 2025 (UTC)
- As the uploader, I'd have been fine with it remaining deleted. Abzeronow (talk) 00:28, 22 November 2025 (UTC)


