Commons:Village pump
Jump to navigation
Jump to search
|
This page is used for discussions of the operations, technical issues, 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/2024/06. 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. |
 People of Ngadisan (Java, Indonesia) are filling their cans at the village pump. The old well is defunct and replaced by a water tap. [add] | |||||||||||||||
| |||||||||||||||
 |
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days. |
May 28
Most of these categories contain no media of their own, but subcategories of characters (that are often played by multiple actors), and the structure is often circular in nature (e.g. the category "Whoopi Goldberg" has the subcategory "Whoopi Goldberg characters", which has the subcategory "Shenzi", which has the subcategory "Whoopi Goldberg"). Most if not all of these were made by the same IP user who created a huge amount of category spam in Category:Space Jam, Category:Mickey Mouse and a bunch of others.
I don't think this category tree structure is inherently invalid, but I feel it's mis-applied and excessive in most of these cases. I'd like to hear more people's thoughts on this before I take this to CfD though. ReneeWrites (talk) 19:19, 28 May 2024 (UTC)
- The whole thing seems rather ambiguous and pointless. Like the parent is called "Film characters" but then the subcategories aren't even characters. Or maybe they are. Is a category like that suppose to be for "characters of Chris Rock" or "Characters played by Chris Rock"? It's not really clear. Then on top of it a lot of the sub-categories only contain one child category but no files, which I'm not really a fan of. --Adamant1 (talk) 19:49, 28 May 2024 (UTC)
- I think this category structure is invalid, and these categories should be deleted. The purpose of categories on Commons is fundamentally to categorize media files. These categories don't organize media; instead, they attempt to represent abstract relationships between subjects. But that's what we have Wikidata for! We don't need to create a clumsy imitation of it on this site.
- The same probably goes for the following categories, at a minimum:
- Category:Actors by role - the inverse relationship of "film characters by actors"
- Category:Films by actor - same concept, organized by films instead of characters
- Category:Films by shooting location - encoding minor facts about films into categories
- Omphalographer (talk) 17:58, 29 May 2024 (UTC)
- Most of the categories in Category:Actors by role were made by the same guy who filled Category:Film characters by actors and made the over 500 categories for Space Jam, Mickey Mouse, Scooby Doo etc. I took to CfD earlier. ReneeWrites (talk) 10:19, 30 May 2024 (UTC)
- CfD plz Trade (talk) 15:59, 30 May 2024 (UTC)
- @Trade: Created a CfD for Film characters by actors and Actors by role. ReneeWrites (talk) 19:29, 30 May 2024 (UTC)
- CfD plz Trade (talk) 15:59, 30 May 2024 (UTC)
- Most of the categories in Category:Actors by role were made by the same guy who filled Category:Film characters by actors and made the over 500 categories for Space Jam, Mickey Mouse, Scooby Doo etc. I took to CfD earlier. ReneeWrites (talk) 10:19, 30 May 2024 (UTC)
Commons is not the place for this. Al Capone is not defined by Alec Baldwin and neither is Alec Baldwin defined by Al Capone. All of these categories should be deleted. The only place this data should be presented is in Wikipedia. Wikidata, might hold the names of movies and their casts, however that again is held in Wikipedia. We are not a repository of facts; we hold files, last time I looked. Only recently we had to go through this nonsense with film locations. Broichmore (talk) 12:20, 4 June 2024 (UTC)
- @Broichmore: Could you link me to the discussion about film locations? Was there a consensus? ReneeWrites (talk) 20:31, 4 June 2024 (UTC)
- Commons:Categories for discussion/2021/03/Category:Film locations by film (and the discussion which led into that, Commons:Categories for discussion/2020/11/Category:Film locations of Sonic the Hedgehog). Omphalographer (talk) 21:58, 4 June 2024 (UTC)
- Thank you 🙂 ReneeWrites (talk) 22:05, 4 June 2024 (UTC)
- Why is the category blue if consensus were to delete? Trade (talk) 02:42, 9 June 2024 (UTC)
- Pinging @Pi.1415926535 as closing Admin. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:54, 25 June 2024 (UTC)
- Because categories have to be tagged for deletion (and preferably emptied before you do). Having a consensus doesn't inherently lead to action being taken. ReneeWrites (talk) 17:43, 25 June 2024 (UTC)
- @Trade: This is about a current discussion, not one that his been concluded. - Jmabel ! talk 15:27, 9 June 2024 (UTC)
- Why is the category blue if consensus were to delete? Trade (talk) 02:42, 9 June 2024 (UTC)
- Thank you 🙂 ReneeWrites (talk) 22:05, 4 June 2024 (UTC)
- Commons:Categories for discussion/2021/03/Category:Film locations by film (and the discussion which led into that, Commons:Categories for discussion/2020/11/Category:Film locations of Sonic the Hedgehog). Omphalographer (talk) 21:58, 4 June 2024 (UTC)
- Agree about the general problem, as mentioned above, the problem with Category:Films by actor from the United States (or Category:Films by actor) in general is similar.
- The main question to solve is: where to place a picture of actor x playing the character y in the film z? In the three categories for each of these. Enhancing999 (talk) 17:27, 9 June 2024 (UTC)
- Under the actor, the character (if we have such a category), and (if that character is not a subcat of the film) the film. If we have more than a handful of such images for the same actor in the same film, then we can make a subcat bringing the three together. - Jmabel ! talk 23:56, 9 June 2024 (UTC)
- Laughingly Liam Neeson apparently played Hitler in a mini series. If we had a picture of him dressed up as Hitler, I certainly don’t want to see him filed under Hitler. Yes, under category Liam Neeson, and if we had one, for the TV series The latter should only have pix of the actual production, and in 121 years time, stills from the show, and the film itself. Broichmore (talk) 17:02, 16 June 2024 (UTC)
- I think something specifically about actors playing Hitler, used only for images in that role, would be a lot better than the current Category:Adolf Hitler interpreters which consists entirely of categories about people, by name. - Jmabel ! talk 23:29, 16 June 2024 (UTC)
- Every single "[Character] interpreters" category is like that. You can find them all compiled in Category:Actors by role and a CfD I opened for it last month at Discussion: Category:Actors by role where I made a similar argument about how to subcategorize actors playing specific characters. I also argued for all the "[Character] interpreters" categories to be deleted. ReneeWrites (talk) 08:03, 17 June 2024 (UTC)
- I think something specifically about actors playing Hitler, used only for images in that role, would be a lot better than the current Category:Adolf Hitler interpreters which consists entirely of categories about people, by name. - Jmabel ! talk 23:29, 16 June 2024 (UTC)
- Laughingly Liam Neeson apparently played Hitler in a mini series. If we had a picture of him dressed up as Hitler, I certainly don’t want to see him filed under Hitler. Yes, under category Liam Neeson, and if we had one, for the TV series The latter should only have pix of the actual production, and in 121 years time, stills from the show, and the film itself. Broichmore (talk) 17:02, 16 June 2024 (UTC)
- Still another approach at Commons:Categories for discussion/2024/06/Category:Madras (film), where the category for an actor is a subcategory of the film, but we don't have any media related to the film itself. Possibly the same problem applies to any film category that only has subcategories. Enhancing999 (talk) 09:40, 20 June 2024 (UTC)
- This is not that different from actors being subcategorized with characters they've played in films (see Category:Actors by role). It's actually the same problem. Broichmore put it really well in a comment he made earlier. To borrow his Al Capone example, Al Capone's not an appropriate subcategory of Alec Baldwin, nor is Alec Baldwin an appropriate subcategory of Al Capone. But once we have media on Commons of Alec Baldwin as Al Capone it can be added to both those categories. If we have enough media to justify creating a category for it on its own it can be named something like "Category:Alec Baldwin as Al Capone" and be made a subcategory for both of them. ReneeWrites (talk) 18:22, 20 June 2024 (UTC)
- I don't think it's anything to do with Al Capone as such, your promoting clutter here. Al Capone in this context is a fictional character. This sort of thing is as pointless, as linking New York as a film location to 1000s of movies. When at core it's a member of only a very few cats, which define it. AC and AB do not define each other and never will. I suppose if, those against cats like this were to lose, then we would have to create a buffer cat to protect the principal cat, something like Portrayals of Al Capone in media. - Broichmore (talk) 14:33, 25 June 2024 (UTC)
- Perhaps, we need to elaborate further in the rule book on what cats define a person. If we were to ask Al Capone on how he would define himself, he would volunteer the core set of cats we currently employ, Alec Baldwin would be a complete unknown to him. -Broichmore (talk) 11:50, 26 June 2024 (UTC)
- Totally agree. I ran into a similar situation with artwork recently where images of windows are being put in categories for artists that just did minor restoration on the window. Which at least IMO clearly isn't correct. I'd say the same here. Images and categories for artists (which I'd consider actors as) shouldn't be associated with categories or images of works/people that they either had minimal to do with or aren't mainly known for. --Adamant1 (talk) 22:15, 26 June 2024 (UTC)
- The hypothetical I put forward is of images being uploaded of Alec Baldwin playing Al Capone, assuming for a moment those images are alright to keep here. And if there's a lot of those images it's fine to make a subcat of that that can be both a subcat of Baldwin and Al Capone. I'm not talking about the movies as a whole, but specifically media that portray specific people. ReneeWrites (talk) 11:02, 27 June 2024 (UTC)
It's all related though. This whole thing is one big Markov chain lmao.--Adamant1 (talk) 12:37, 27 June 2024 (UTC)
- The hypothetical I put forward is of images being uploaded of Alec Baldwin playing Al Capone, assuming for a moment those images are alright to keep here. And if there's a lot of those images it's fine to make a subcat of that that can be both a subcat of Baldwin and Al Capone. I'm not talking about the movies as a whole, but specifically media that portray specific people. ReneeWrites (talk) 11:02, 27 June 2024 (UTC)
- Totally agree. I ran into a similar situation with artwork recently where images of windows are being put in categories for artists that just did minor restoration on the window. Which at least IMO clearly isn't correct. I'd say the same here. Images and categories for artists (which I'd consider actors as) shouldn't be associated with categories or images of works/people that they either had minimal to do with or aren't mainly known for. --Adamant1 (talk) 22:15, 26 June 2024 (UTC)
- Perhaps, we need to elaborate further in the rule book on what cats define a person. If we were to ask Al Capone on how he would define himself, he would volunteer the core set of cats we currently employ, Alec Baldwin would be a complete unknown to him. -Broichmore (talk) 11:50, 26 June 2024 (UTC)
- I don't think it's anything to do with Al Capone as such, your promoting clutter here. Al Capone in this context is a fictional character. This sort of thing is as pointless, as linking New York as a film location to 1000s of movies. When at core it's a member of only a very few cats, which define it. AC and AB do not define each other and never will. I suppose if, those against cats like this were to lose, then we would have to create a buffer cat to protect the principal cat, something like Portrayals of Al Capone in media. - Broichmore (talk) 14:33, 25 June 2024 (UTC)
- This is not that different from actors being subcategorized with characters they've played in films (see Category:Actors by role). It's actually the same problem. Broichmore put it really well in a comment he made earlier. To borrow his Al Capone example, Al Capone's not an appropriate subcategory of Alec Baldwin, nor is Alec Baldwin an appropriate subcategory of Al Capone. But once we have media on Commons of Alec Baldwin as Al Capone it can be added to both those categories. If we have enough media to justify creating a category for it on its own it can be named something like "Category:Alec Baldwin as Al Capone" and be made a subcategory for both of them. ReneeWrites (talk) 18:22, 20 June 2024 (UTC)
- Under the actor, the character (if we have such a category), and (if that character is not a subcat of the film) the film. If we have more than a handful of such images for the same actor in the same film, then we can make a subcat bringing the three together. - Jmabel ! talk 23:56, 9 June 2024 (UTC)
May 31
I'm unable to use the image I just uploaded.
Hi I don't seem to be able to use the file https://commons.wikimedia.org/wiki/File:M_F_Gervais_Holy_Roman_Empire.pdf It show up in Commons but in Wikipedia I'm not able to use it. Why? It happened for my last file and someone 'did' something... I don't know what was done but it worked. What should I do to fix it? — Preceding unsigned comment added by M F Gervais (talk • contribs) 18:45, 31 May 2024 (UTC)
- @M F Gervais: It is there and it functional however due to how big and unwieldy it is as a pdf it takes a while to render, especially whern it has to develop the image cache first:
- Now because PDFs are typically multipage document it can need extra formatting if you are trying to do it through standard wiki formatting. mw:help:images. PDFs should not be used if you want to display an image, please upload an image file per Com:File types — Preceding unsigned comment added by Billinghurst (talk • contribs) 07:59, 1 June 2024 (UTC)
June 05
Special:UncategorizedCategories is back over 1000 categories. If you can add appropriate parent categories to any of the many that have otherwise reasonable content, that would be very helpful. If you're not a admin, don't worry about the empty ones, one or another admin will eventually find those and delete them. - Jmabel ! talk 06:05, 5 June 2024 (UTC)
- Now up to 1165 categories. I have the feeling almost no one is addressing this. I've done literally thousands, probably over 5000, and while I still try to do 50 or so per week, that is not enough to keep up. - Jmabel ! talk 17:53, 10 June 2024 (UTC)
- @Jmabel: I did a few today and about once a month a small portion.
Question Is it a good idea to have the numbers next to the categories, like in other pages? Then you can see at a glance which are empty and not bother about them (for none admins like me) or to be able to remove them in quick succession (for admins). JopkeB (talk) 07:50, 15 June 2024 (UTC)
- Wouldn't that be nice? As it is, in case you haven't noticed, you can hover over the link and see whether there are files in the category. - Jmabel ! talk 14:56, 15 June 2024 (UTC)
- No I did not notice and I still do not see it. When I hover over a link, I see only the category name, for instance Category:Activité supplémentaire bibliothéquaire, but nothing else. JopkeB (talk) 07:31, 18 June 2024 (UTC)
- Weird that you get a different behavior than I do. So you don't get a thing like this in the popup?
- Wouldn't that be nice? As it is, in case you haven't noticed, you can hover over the link and see whether there are files in the category. - Jmabel ! talk 14:56, 15 June 2024 (UTC)
Category:Queensferry Parish Church, South Queensferry ⋅ actions ⋅ popups 44 bytes, 0 wikiLinks, 0 images, 0 categories, 1 week 4 days old ---- Queensferry Parish Church, South Queensferry Category members (5 shown) File:Queensferry Parish Church 01.jpg, File:Queensferry Parish Church 02.jpg, File:Queensferry Parish Church 03.jpg, File:Queensferry Parish Church 04.jpg, File:South Queensferry Townscape , Queensferry Parish Church - geograph.org.uk - 3034870.jpg
- Jmabel ! talk 18:25, 18 June 2024 (UTC)
- No Jmabel, in the pop-up I only get the name of the category again, nothing else. Is it something in my preferences? JopkeB (talk) 04:01, 21 June 2024 (UTC)
- @JopkeB: Yes, please search Special:Preferences#mw-prefsection-gadgets for "Popups". — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:30, 21 June 2024 (UTC)
- @Jmabel: Thanks! That was easy, and it works. JopkeB (talk) 14:46, 21 June 2024 (UTC)
- @JopkeB: you really should thank Jeff G., who gave the useful answer! - Jmabel ! talk 19:21, 21 June 2024 (UTC)
- @Jeff G.: Sorry, indeed, my thanks are for you. JopkeB (talk) 04:08, 22 June 2024 (UTC)
- @JopkeB: You're welcome. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:23, 22 June 2024 (UTC)
- @Jeff G.: Sorry, indeed, my thanks are for you. JopkeB (talk) 04:08, 22 June 2024 (UTC)
- @JopkeB: you really should thank Jeff G., who gave the useful answer! - Jmabel ! talk 19:21, 21 June 2024 (UTC)
- @Jmabel: Thanks! That was easy, and it works. JopkeB (talk) 14:46, 21 June 2024 (UTC)
- @JopkeB: Yes, please search Special:Preferences#mw-prefsection-gadgets for "Popups". — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:30, 21 June 2024 (UTC)
- No Jmabel, in the pop-up I only get the name of the category again, nothing else. Is it something in my preferences? JopkeB (talk) 04:01, 21 June 2024 (UTC)
- Jmabel ! talk 18:25, 18 June 2024 (UTC)
June 11
New designs for logo detection tool
Hello all! We're happy to share that we will work on logo detection in the following months and that we defined an initial approach for this.
You can read more at the project page and you can have your say in the project's talk.
We want your feedback on it, and we need your insights on how to further tune the detection tool.
Thanks for your attention! Sannita (WMF) (talk) 13:54, 11 June 2024 (UTC)
- I'm rather confused. The general feed back seemed to me to amount to "logo detection isn't very useful." I was told by a couple of people when I asked informally, "Don't worry, it isn't like logo detection isn't the goal, this was just a side effect of work on something else that someone thought might be useful." And now you say that further work is proceeding on this front? What, exactly, put this on the front burner, especially given that we are constantly being reminded that dev has very limited resources for Commons? What is the problem we are trying to solve? - Jmabel ! talk 22:25, 11 June 2024 (UTC)
- @Jmabel Our impression, to be fair, was quite the opposite: that it was something that could be useful in dealing with the third-most frequent rationale for requests for deletions (the first two being copyvios and FoP, which we found it was impossible to tackle in an automated way). There was more difficulty in defining how this could be implemented, but not on its usefulness. This is why we are re-opening the feedback period, to understand how it could be implemented. Sannita (WMF) (talk) 10:36, 13 June 2024 (UTC)
- @Sannita (WMF) "third-most frequent rationale for requests for deletions (the first two being copyvios" - This doesn't make sense at all. The only reason we would delete a logo is because it's a copyvio, not because its a logo. There are scores of logos which are in the public domain, either by age or by lack of creativity, while others get licensed under free licenses. I'm not sure why we should discourage people of uploading that specific content with such a warning, when those exact same rules apply to everything else. As it is, I tend to not support that implementation. And as JMabel mentioned, it's disheartening to see that resources were wasted developing such an apparently useless tool, when there are clearly established priorities (see the old wish lists, for instance). Darwin Ahoy! 16:16, 13 June 2024 (UTC)
- @Sannita (WMF), Jmabel, and DarwIn: I'll leave others to decide on the best or most suited UI for the logo detection. As for the feature, I am supportive of this, but conditionally. Suggest this feature should be mandatory for users who do not have the appropriate user rights; I suggest users who are not admins/sysops, license reviewers, and/or autopatrolled. Users who are under these three tiers of user groups are free to upload logos and should not be slapped with this filter, since they are already aware of copyright issues and TOO considerations for logos. If possible, the feature should effectively block uses of "FileExporter" and other cross-wiki file transfer tools. And one more thing, I suggest the filter can prohibit new users (those who are not autoconfirmed) from uploading or importing logos (even photos showing logos that are non-de minimis/non-incidental). Hopefully, this will trim down at least a third or less (my guess) of deletion requests that contribute to the perennial backlogs. There are many more areas in Commons that also need attentions and resolutions, like Commons:Categories for discussion/Older (some open discussions were from before the lockdown era of 2020). JWilz12345 (Talk|Contrib's.) 08:30, 14 June 2024 (UTC)
- @JWilz12345: I think the plan is for this to become a secret feature. It has no effect on the upload itself and nobody but the uploader will know about the warning. Possibly, the same effect could have been achieved by merely editing the current interface and noting "if it's a logo, follow logo guidelines". Enhancing999 (talk) 08:43, 14 June 2024 (UTC)
- Just my opinion, but having a specific warning to the uploader saying the image might be a logo seems rather pointless. If not borderline condensing towards users. People generally know what they are uploading images of. The less clear thing is what license to use in any specific instance and I don't really how this deals with that. A better thing would probably just be a specific checkbox for logos that automatically adds a license and puts the image in a specific category for images that need reviewing on upload. Otherwise people are just going to just ignore the warning just like they are already ignoring guidelines by uploading the image to begin with. What we really need is better ways to review and deal with problematic images on our end though. Not try to unload that on uploaders by over complicating the UploadWizard with a bunch of warnings, extra boxes, and the like. --Adamant1 (talk) 20:52, 15 June 2024 (UTC)
- @Adamant1: anything related to copyright is already complicated enough. That's perhaps a price to pay for establishing/creating a free media repository site like Commons, or more so, Wikipedia itself way back more than 20 years ago. Something that founders Wales and Sanger likely did not forseen or anticipate. (Note: just a part of my thoughts, and not a representative of my general perspective on Wikimedia movement, which I still support in the context of mandating global FoP). JWilz12345 (Talk|Contrib's.) 21:12, 15 June 2024 (UTC)
- Thanks everyone for your comments! @Adamant1 about the checkbox, we thought of that option too, but ultimately decided against, because we didn't want to clutter too much the UploadWizard and make it more complicated for legitimate uploaders to upload a legitimate logo or fall into the "I'll just ignore that" kind of case. Anyway, our scope is to get to a better and more seamless way of uploading medias, but this will take more designing, prototyping, and testing, so it won't happen overnight.
- To everyone, we're open to ideas for eventual moderation of logos in general, given that we don't want to unload a new bunch of work on volunteers without there being consensus. Sannita (WMF) (talk) 14:08, 20 June 2024 (UTC)
- @Adamant1: anything related to copyright is already complicated enough. That's perhaps a price to pay for establishing/creating a free media repository site like Commons, or more so, Wikipedia itself way back more than 20 years ago. Something that founders Wales and Sanger likely did not forseen or anticipate. (Note: just a part of my thoughts, and not a representative of my general perspective on Wikimedia movement, which I still support in the context of mandating global FoP). JWilz12345 (Talk|Contrib's.) 21:12, 15 June 2024 (UTC)
- @Sannita (WMF), Jmabel, and DarwIn: I'll leave others to decide on the best or most suited UI for the logo detection. As for the feature, I am supportive of this, but conditionally. Suggest this feature should be mandatory for users who do not have the appropriate user rights; I suggest users who are not admins/sysops, license reviewers, and/or autopatrolled. Users who are under these three tiers of user groups are free to upload logos and should not be slapped with this filter, since they are already aware of copyright issues and TOO considerations for logos. If possible, the feature should effectively block uses of "FileExporter" and other cross-wiki file transfer tools. And one more thing, I suggest the filter can prohibit new users (those who are not autoconfirmed) from uploading or importing logos (even photos showing logos that are non-de minimis/non-incidental). Hopefully, this will trim down at least a third or less (my guess) of deletion requests that contribute to the perennial backlogs. There are many more areas in Commons that also need attentions and resolutions, like Commons:Categories for discussion/Older (some open discussions were from before the lockdown era of 2020). JWilz12345 (Talk|Contrib's.) 08:30, 14 June 2024 (UTC)
- @Sannita (WMF) "third-most frequent rationale for requests for deletions (the first two being copyvios" - This doesn't make sense at all. The only reason we would delete a logo is because it's a copyvio, not because its a logo. There are scores of logos which are in the public domain, either by age or by lack of creativity, while others get licensed under free licenses. I'm not sure why we should discourage people of uploading that specific content with such a warning, when those exact same rules apply to everything else. As it is, I tend to not support that implementation. And as JMabel mentioned, it's disheartening to see that resources were wasted developing such an apparently useless tool, when there are clearly established priorities (see the old wish lists, for instance). Darwin Ahoy! 16:16, 13 June 2024 (UTC)
- @Jmabel Our impression, to be fair, was quite the opposite: that it was something that could be useful in dealing with the third-most frequent rationale for requests for deletions (the first two being copyvios and FoP, which we found it was impossible to tackle in an automated way). There was more difficulty in defining how this could be implemented, but not on its usefulness. This is why we are re-opening the feedback period, to understand how it could be implemented. Sannita (WMF) (talk) 10:36, 13 June 2024 (UTC)
- I just want to provide some context on @Sannita (WMF)'s post above ... what we're working towards here is an automatic process by which we reliably estimate the likelihood that an uploaded image will be deleted for any reason
- If we had that process we'd be able to inform users that their upload is likely to be deleted (and why) during the upload process, which would be a better (and more educational) user experience than we have now. Also moderators would be able to find (and deal with) potentially problematic uploads much more easily
- Our initial experiments with machine learning showed we can detect logos reliably, and they're a pretty common reason for DRs, so logo detection seemed like a promising place to start CParle (WMF) (talk) 14:36, 20 June 2024 (UTC)
- There may be a misunderstanding here: being a logo is not a reason to delete. We have tens of thousands of logos legitimately on Commons. Laying aside logos that are PD because they are very old, or created by certain governments that don't claim copyrights, etc., an enormous number of logos are below the threshold of originality for copyright, especially in countries like the U.S. where that threshold is quite high. False positives -- discouraging or (worse) preventing upload of content that could legitimately be hosted on Commons -- is at least as bad, and arguably worse than false negatives, letting a "bad" file through. We can always delete a bad file; we cannot conjure a file we don't get to see. - Jmabel ! talk 19:36, 20 June 2024 (UTC)
- > being a logo is not a reason to delete
- Absolutely, but being a logo is a signal that the upload is more likely to get deleted. We're not proposing to prevent logo uploads, just to alert the user if what they've uploaded looks like a logo, and attempt to educate them about the copyright implications (and also flag possible logos so that patrollers can check them) CParle (WMF) (talk) 10:56, 21 June 2024 (UTC)
- I'm not sure logos are actually among the things where the highest percentage get deleted. But maybe they are. Do we have any available statistics on this? - Jmabel ! talk 19:24, 21 June 2024 (UTC)
- @Jmabel Sure, the most recent statistics we have are available at phab:T340546. Sannita (WMF) (talk) 16:15, 24 June 2024 (UTC)
- @Sannita (WMF): I may be missing something, but I don't readily see anything there that even suggests what percentage of logos are deleted, compared to what percentage of uploads in general. Is it there and I'm missing it, or is it just not there? - Jmabel ! talk 18:22, 24 June 2024 (UTC)
- @Jmabel In this comment there is a direct quote of the last part of the analysis that breaks down reasons for deletion. Sannita (WMF) (talk) 09:14, 25 June 2024 (UTC)
- @Sannita (WMF): yes, I saw that. It says, in effect, "lots of logos are deleted" but with no indication of how many are kept, and how that ratio compares to other categories of files. - Jmabel ! talk 21:42, 26 June 2024 (UTC)
- To use an old joke, I'm pretty sure that roughly 90% of bad uploads are by right-handed people... - Jmabel ! talk 21:43, 26 June 2024 (UTC)
- I see, this could be in fact an improvement in data collecting, that I will be sure to share with the team. Sannita (WMF) (talk) 13:34, 27 June 2024 (UTC)
- @Jmabel In this comment there is a direct quote of the last part of the analysis that breaks down reasons for deletion. Sannita (WMF) (talk) 09:14, 25 June 2024 (UTC)
- @Sannita (WMF): I may be missing something, but I don't readily see anything there that even suggests what percentage of logos are deleted, compared to what percentage of uploads in general. Is it there and I'm missing it, or is it just not there? - Jmabel ! talk 18:22, 24 June 2024 (UTC)
- @Jmabel Sure, the most recent statistics we have are available at phab:T340546. Sannita (WMF) (talk) 16:15, 24 June 2024 (UTC)
- I'm not sure logos are actually among the things where the highest percentage get deleted. But maybe they are. Do we have any available statistics on this? - Jmabel ! talk 19:24, 21 June 2024 (UTC)
- There may be a misunderstanding here: being a logo is not a reason to delete. We have tens of thousands of logos legitimately on Commons. Laying aside logos that are PD because they are very old, or created by certain governments that don't claim copyrights, etc., an enormous number of logos are below the threshold of originality for copyright, especially in countries like the U.S. where that threshold is quite high. False positives -- discouraging or (worse) preventing upload of content that could legitimately be hosted on Commons -- is at least as bad, and arguably worse than false negatives, letting a "bad" file through. We can always delete a bad file; we cannot conjure a file we don't get to see. - Jmabel ! talk 19:36, 20 June 2024 (UTC)
June 16
Wikidata sufficient for scope?
Hi, It seems unclear if creating a Wikidata item is sufficient for being in scope. Files were recently deleted when a WD item was created by the same user who uploaded the files. Here it concerns Commons:Deletion requests/Files in Category:Insane Ashraf. Yann (talk) 12:46, 16 June 2024 (UTC)
- Wouldn't this better be asked at the Scope talk page? In COM:SCOPE it does say "legitimately" in use. That would mean it depends on the legitimacy of the Wikidata item itself and the legitimacy of the use there (does it actually show what the Wikidata item is about? is there a much better file available that should be used instead?). Prototyperspective (talk) 12:53, 16 June 2024 (UTC)
- Actually these files and category were created by a sockpuppet farm, so I would delete for this reason alone. But the general question remains for future cases. Yann (talk) 14:49, 16 June 2024 (UTC)
- It could be used to artificially cause a scope loop between Commons and Wikidata. AFAIK, Wikidata is the only Wikimedia website where an item can be in scope for no other reason than because it links to a page on Commons. A file about a person can be in scope on Commons if the file can be potentially useful to someone somewhere in a very broad educational sense, even if there is no page about that person on any other Wikimedia website. But that doesn't go so far as to include photos of non-notable persons in non-relevant contexts. Of course, a file about a person can be more easily assumed to be in scope on Commons if another Wikimedia website has a page about that person. (N.B.: that question is different and independent of the question of whether a file is in use or not on another Wikimedia website.) That makes sense based on the assumption that the other website has independent notability criteria. But that does not make sense when the only inclusion criterion being met on Wikidata by a person is that the Wikidata page links to a page on Commons. -- Asclepias (talk) 15:16, 16 June 2024 (UTC)
- 'Wikidata, has nothing to do with defining scope for Wikipedia or commons. Look to the policies for both projects separately to ascertain what is scope. There are differences, minor ones perhaps. Generally speaking, if it passes the scope test for Wikipedia. it will be okay for commons too, as the latter is marginally more liberal. As far as we are concerned, Wikidata is a tool, and nothing more. Broichmore (talk) 16:35, 16 June 2024 (UTC)
- I'd think yes. I noticed in a recent cleanup exercice some stuff got tossed that was in use there, but that seemed relatively marginal. Enhancing999 (talk) 22:29, 16 June 2024 (UTC)
- It seems to me that the only times an image that is used to illustrate a Wikidata item would be appropriate to delete on a "scope" basis would be (1) the Wikidata item shouldn't exist, which should first be dealt with on Wikidata or (2) the image does not meet Wikidata's criteria for images illustrating an item, which should first be dealt with on Wikidata. And, no, I wouldn't defend the case where the only justification for the Wikidata item is that the Commons image exists and vice versa.
- @Broichmore: are you saying (above) that it would be appropriate do delete an image that is legitimately in use on Wikidata, or just that the presence of a Wikidata item is insufficient to justify having other images of the subject in question? I'd agree with the latter: I believe there are cases where there are Wikidata items for every name on a war memorial or every person buried in a particular graveyard. That would merit hosting a single image of any of these people to support Wikidata, but would not mean that we would want an open-ended number of images of each such person. - Jmabel ! talk 23:44, 16 June 2024 (UTC)
- @Jmabel: Not to speak for Broichmore, but read through Wikidata:Requests_for_deletions#Q125118469. Especially the last 4 or 5 comments. I assume it's similar to what Broichmore is talking about. --Adamant1 (talk) 23:59, 16 June 2024 (UTC)
- As your all too aware, criteria for uploading images on commons centres on copyright (we want only PD), modified by notability, the emphasis on the former.
- In Wikipedia, it's possible to upload a non-PD item (using, the fair use parameter), if there's no other image (of even dubious suitability) available. Even so, the item then needs to be degraded so it's worthless commercially. Only items, most representative, are entertained. A pix of the ship. The person's face. an LP cover. An actual passport style portrait of the item.
- Wikidata says it wants an image of (the) relevant illustration of the subject; if available, use more specific properties (sample: coat of arms image, locator map, flag image, signature image, logo image, collage image); only images which exist on Wikimedia Commons are acceptable. In other words only PD and no fair use.
- Briefly, again, wanted images for the Wikipedia infobox and wikidata are passport only portraits, in that spirit I've been known to crop out portraits for that purpose. This example was used for both projects. That portrait will be replaced, only when better surfaces.
- Wikipedia carries only one pix in its infobox, and so should Wikidata, however the latter can carry more. Perhaps a persons facial image, representative from different stages of their life. There's no real limit. I don’t think this has actually been tested, by abuse yet, the tacit acceptance is, use only one image, perhaps two, following Wikipedia guidelines.
- Wikidata’s scope for inclusion is immense in comparison to WP and commons. Briefly an item should be represented by at least one valid sitelink to a page on Wikipedia, Wikivoyage, Wikisource, Wikiquote, Wikinews, Wikibooks, Wikidata, Wikispecies, Wikiversity, or Wikimedia Commons. ’’Note it refers to itself, it’s a bit woolly. But it wants to tag everything useful in the world. Read the policy here.
- As I see it, Wikidata has three uses for us, first our infobox, containing the variables that dictate licensing, secondly (for an artist, if there's no WP article); locations of work by time period, useful for correct attribution, and third, disambiguation of artists or place names. Broichmore (talk) 11:07, 17 June 2024 (UTC)
- It doesn't help there that the user whose contributions are largely at issue keeps cycling back and forth between reasonably serious arguments, ad hominem remarks, and remarks that seem entirely intended to derail the discussion. But I stand by what I wrote above: circular justification doesn't cut it; a Wikidata item can justify keeping one photo on Commons that would otherwise be deleted, to function as an image for that item; and it isn't up to us on Commons to decide whether the item meets Wikidata's (generally lower) threshold of notability. - Jmabel 01:09, 17 June 2024 (UTC)
- @Jmabel: Not to speak for Broichmore, but read through Wikidata:Requests_for_deletions#Q125118469. Especially the last 4 or 5 comments. I assume it's similar to what Broichmore is talking about. --Adamant1 (talk) 23:59, 16 June 2024 (UTC)
- The "scope loop" breaks on the Wikidata side. Per d:Wikidata:Notability, "Category items with a sitelink only to Wikimedia Commons are not permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as category for pictures taken with equipment (P2033)". Commons can expedite the cleanup of objects involved in these loops by ignoring media uses on Wikidata which only refer back to Commons. Omphalographer (talk) 23:56, 16 June 2024 (UTC)
- Concur. WD item creation that is involved with the uploader/creator in sequence within the same timeframe, and otherwise fails their notability (articles or independent linkage) is not "in use" (image or category). If it is borderline, or where I am in doubt, I will nominate there for deletion with appropriate commentary, and then nominate the image here with a DR, so we can do some follow-up (our DR review takes longer than theirs). That is pretty much what I will do for a draft article where it is dodgy and reeking of COI at the WPs. — billinghurst sDrewth 04:38, 17 June 2024 (UTC)
- @Omphalographer: that seems more of a technicality about WD than something germane here. It's specifically about Category items. That just means that if you are making up (for example) an item about Person FOO and the only Category:Person FOO is on Commons, you can make an item about "Person FOO", but not about "Category:Person FOO". - Jmabel ! talk 06:38, 17 June 2024 (UTC)
- @Jmabel, actually, you could, if "Person FOO" is sustainable itself. The item for "Category:Person FOO" is allowed per criteria #3 as structurally required as the topic's main category (P910) for the former item. What is not allowed is if "Person FOO" does not exist on Wikidata, and you solely wanted to create an item for "Category:Person FOO" with the only sitelink being to the Commons category. That would fail all three of the criteria for notability there. Of course, as you stated, this is all applicable to Wikidata alone and has no real relevance to Commons, except that you probably shouldn't add {{Wikidata infobox}} to "Category:Person FOO" without a valid corresponding Wikidata item. If that category is a valid Commons category, we certainly should not delete it just because it does not support a Wikidata link. Josh (talk) 17:08, 17 June 2024 (UTC)
- @Joshbaumgartner: No. I have no idea of your level of experience on Wikidata (and feel free to correct me if that experience is extensive, and you can provide examples of something I've never seen), but in my experience no one goes around creating a "category" item just to use it within Wikidata for a topic's main category (P910). Otherwise, every item would get a corresponding "category" item. Hell, every category item could get a corresponding, totally useless "Category:Category" item, etc. ad infinitum. Until a "category" item is justified by the existence of categories on some sister project other than Commons or Wikidata itself, it should not be created. - Jmabel ! talk 19:29, 17 June 2024 (UTC)
- Why in the world would anything require a "Category:Category" item? That doesn't make any sense. I honestly have no idea what tangent you are off on here. Wikidata supports an item for the Topic (with sitelinks to articles and galleries) and an item for Category:Topic (with sitelinks to category pages). The Category:Topic item doesn't need any more than the sitelink to its Commons category to be valid according to WD:Notability. By the way, I wouldn't make any personal claim of being especially experienced at Wikidata, I only have 750,000+ edits there and have been a property creator since they were still in double-digits, but my lack of experience is moot, WD's notability guidelines don't require an experienced editor to understand. Josh (talk) 01:41, 28 June 2024 (UTC)
- @Joshbaumgartner: Please don't take my reductio ad absurdum for a serious proposal! Quoting the very page you mentioned, wikidata:WD:Notability: "Category items with a sitelink only to Wikimedia Commons are not [emphasis mine] permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as category for pictures taken with equipment (P2033)." - Jmabel ! talk 02:29, 28 June 2024 (UTC)
- @Jmabel Fair enough, but I'm curious why you are intentionally re-quoting that section out of context. Why are you not indicating honestly that the section you quoted is only a sub-section of criteria #1 in the notability test and additionally that an item only needs to pass 1 of the 3 notability criteria to pass Wikidata's notability guidelines? Re-quoting this section without that context as if it were some overarching rule that applied to all notability tests is misleading in the extreme. I was a bit disappointed at seeing this from you, as I expect a higher standard from you, Jmabel. I'm assuming good faith in that you did not intend to be misleading, but hopefully you are willing to correct this oversight? Josh (talk) 02:41, 28 June 2024 (UTC)
- @Joshbaumgartner: I don't believe that was out of context; I certainly wasn't going to quote the entire page. I normally respect your work, but I honestly cannot work out what you mean here. Are you saying that every Wikidata item A should have a corresponding Wikidata "category" item B just so B can be linked from A with topic's main category (P910), when B serves no other use? If so, then we are back to the absurd infinite regress I laid out: by that same logic B can also have a topic's main category (P910) linking a (ridiculous) "Category:Category" item C, etc., etc., etc. If you were saying neither that nor that the Commons category is enough on its own for Wikidata notability, I honestly cannot see what else you could have meant, but please feel free to elucidate. - Jmabel ! talk 03:27, 28 June 2024 (UTC)
- @Jmabel You do seem fond of trying to reduce things to absurdity instead of dealing with what is actually being said. No one asked you to quote the whole page, and no one has proposed or done creation of "Category:Category:Cate..." items. Do you really think that no "category item(s) with a sitelink only to Wikimedia Commons" can ever pass notability, or do you agree that clause only applies in some circumstances, and that in many instances, "category item(s) with a sitelink only to Wikimedia Commons" are perfectly valid per WD:Notability? You quoted the clause as if you believe the first case, that it is an absolute rule, as you intentionally (per your admission) omitted providing any context to the quote. Which is it? Josh (talk) 03:54, 28 June 2024 (UTC)
- @Joshbaumgartner: Here's my understanding. Again, I may be wrong, but I haven't seen a counterexample. As noted within what I quoted there are two cases where there can be a valid category item where the only corresponding category is on Commons. (1) There is a corresponding Commons gallery (in addition to the category). (2) There is a structural need for the category for a Commons-related statement (but the example you gave of topic's main category (P910) does not constitute such a structural need). But that's it. Other than that, a "category" item is justified only by having a category on a sister project other than Commons. Or to put it another way, there are exactly three cases that justify creation of a "category" item:
- There is a corresponding category on a WMF sister project other than Commons.
- There is a corresponding category and a corresponding gallery on Commons.
- There is a structural need for the category for a Commons-related statement.
- If there is a valid "category" item that does not meet one of those three criteria, I'm not aware of it. Can you give an example? - Jmabel ! talk 04:15, 28 June 2024 (UTC)
- @Joshbaumgartner: Here's my understanding. Again, I may be wrong, but I haven't seen a counterexample. As noted within what I quoted there are two cases where there can be a valid category item where the only corresponding category is on Commons. (1) There is a corresponding Commons gallery (in addition to the category). (2) There is a structural need for the category for a Commons-related statement (but the example you gave of topic's main category (P910) does not constitute such a structural need). But that's it. Other than that, a "category" item is justified only by having a category on a sister project other than Commons. Or to put it another way, there are exactly three cases that justify creation of a "category" item:
- Or are you just talking about things like the item for the separate category for the name of a ship? Yes, of course those are OK, because the Wikidata modeling approach requires them. - Jmabel ! talk 05:09, 28 June 2024 (UTC)
- So yes, you can have a Category item where the only sitelink is to a Commons category. Thank you for agreeing on that point. Your assertion that somehow topic's main category (P910) doesn't count as a structural need is rather silly and made up, but whatever, it doesn't matter for this conversation. All we care about on this side of the fence is that yes, sometimes a Wikidata category item will exist with the only sitelink being to a Commons category and so if we are going to base our scope policy in any part on the existence of such an item (I disagree with doing so, for the record), then we have to keep that in mind. Josh (talk) 05:14, 28 June 2024 (UTC)
- @Jmabel You do seem fond of trying to reduce things to absurdity instead of dealing with what is actually being said. No one asked you to quote the whole page, and no one has proposed or done creation of "Category:Category:Cate..." items. Do you really think that no "category item(s) with a sitelink only to Wikimedia Commons" can ever pass notability, or do you agree that clause only applies in some circumstances, and that in many instances, "category item(s) with a sitelink only to Wikimedia Commons" are perfectly valid per WD:Notability? You quoted the clause as if you believe the first case, that it is an absolute rule, as you intentionally (per your admission) omitted providing any context to the quote. Which is it? Josh (talk) 03:54, 28 June 2024 (UTC)
- @Joshbaumgartner: I don't believe that was out of context; I certainly wasn't going to quote the entire page. I normally respect your work, but I honestly cannot work out what you mean here. Are you saying that every Wikidata item A should have a corresponding Wikidata "category" item B just so B can be linked from A with topic's main category (P910), when B serves no other use? If so, then we are back to the absurd infinite regress I laid out: by that same logic B can also have a topic's main category (P910) linking a (ridiculous) "Category:Category" item C, etc., etc., etc. If you were saying neither that nor that the Commons category is enough on its own for Wikidata notability, I honestly cannot see what else you could have meant, but please feel free to elucidate. - Jmabel ! talk 03:27, 28 June 2024 (UTC)
- @Jmabel Fair enough, but I'm curious why you are intentionally re-quoting that section out of context. Why are you not indicating honestly that the section you quoted is only a sub-section of criteria #1 in the notability test and additionally that an item only needs to pass 1 of the 3 notability criteria to pass Wikidata's notability guidelines? Re-quoting this section without that context as if it were some overarching rule that applied to all notability tests is misleading in the extreme. I was a bit disappointed at seeing this from you, as I expect a higher standard from you, Jmabel. I'm assuming good faith in that you did not intend to be misleading, but hopefully you are willing to correct this oversight? Josh (talk) 02:41, 28 June 2024 (UTC)
- @Joshbaumgartner: Please don't take my reductio ad absurdum for a serious proposal! Quoting the very page you mentioned, wikidata:WD:Notability: "Category items with a sitelink only to Wikimedia Commons are not [emphasis mine] permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as category for pictures taken with equipment (P2033)." - Jmabel ! talk 02:29, 28 June 2024 (UTC)
- Why in the world would anything require a "Category:Category" item? That doesn't make any sense. I honestly have no idea what tangent you are off on here. Wikidata supports an item for the Topic (with sitelinks to articles and galleries) and an item for Category:Topic (with sitelinks to category pages). The Category:Topic item doesn't need any more than the sitelink to its Commons category to be valid according to WD:Notability. By the way, I wouldn't make any personal claim of being especially experienced at Wikidata, I only have 750,000+ edits there and have been a property creator since they were still in double-digits, but my lack of experience is moot, WD's notability guidelines don't require an experienced editor to understand. Josh (talk) 01:41, 28 June 2024 (UTC)
- @Joshbaumgartner: No. I have no idea of your level of experience on Wikidata (and feel free to correct me if that experience is extensive, and you can provide examples of something I've never seen), but in my experience no one goes around creating a "category" item just to use it within Wikidata for a topic's main category (P910). Otherwise, every item would get a corresponding "category" item. Hell, every category item could get a corresponding, totally useless "Category:Category" item, etc. ad infinitum. Until a "category" item is justified by the existence of categories on some sister project other than Commons or Wikidata itself, it should not be created. - Jmabel ! talk 19:29, 17 June 2024 (UTC)
- @Jmabel, actually, you could, if "Person FOO" is sustainable itself. The item for "Category:Person FOO" is allowed per criteria #3 as structurally required as the topic's main category (P910) for the former item. What is not allowed is if "Person FOO" does not exist on Wikidata, and you solely wanted to create an item for "Category:Person FOO" with the only sitelink being to the Commons category. That would fail all three of the criteria for notability there. Of course, as you stated, this is all applicable to Wikidata alone and has no real relevance to Commons, except that you probably shouldn't add {{Wikidata infobox}} to "Category:Person FOO" without a valid corresponding Wikidata item. If that category is a valid Commons category, we certainly should not delete it just because it does not support a Wikidata link. Josh (talk) 17:08, 17 June 2024 (UTC)
- @Omphalographer: that seems more of a technicality about WD than something germane here. It's specifically about Category items. That just means that if you are making up (for example) an item about Person FOO and the only Category:Person FOO is on Commons, you can make an item about "Person FOO", but not about "Category:Person FOO". - Jmabel ! talk 06:38, 17 June 2024 (UTC)
- @Omphalographer, note that only applies if attempting to sustain notability under criteria 1 (i.e. solely on the basis of a sitelink). If an item qualifies under criteria 2 or 3 (i.e. is a "clearly identifiable conceptual or material entity that can be described using serious and publicly available references" or "fulfills a structural need"), the exclusion of 'items with a sitelink only to Wikimedia Commons' is not applicable. Josh (talk) 16:58, 17 June 2024 (UTC)
- For people, I think it'd be acceptable to declare as in scope those items with an identifier that may presume the subject is notable or relevant, such as those of National Libraries. Bedivere (talk) 20:41, 20 June 2024 (UTC)
- @Bedivere That's an issue for WD to decide. I am pretty sure anyone with an ID from a recognized authority (i.e. one with a relevant ID property) is going to be considered in scope on WD. Josh (talk) 01:44, 28 June 2024 (UTC)
- For people, I think it'd be acceptable to declare as in scope those items with an identifier that may presume the subject is notable or relevant, such as those of National Libraries. Bedivere (talk) 20:41, 20 June 2024 (UTC)
- @Omphalographer The "scope loop" ought to be broken in Commons policy too so that we can achieve the right result on a file here without having to wait for an action in another project. Consigned (talk) 23:21, 21 June 2024 (UTC)
- @Consigned: strongly disagree. Legitimate use on a sister project should be sufficient reason to consider an image to be in Commons' scope, and we should not be in a position to dictate to other projects what we consider legitimate for them. Commons is, as much as anything else, a repository for images required by other projects. Wikidata, for example, does not host images itself, and completely relies on Commons to be its image host. - Jmabel ! talk 02:03, 22 June 2024 (UTC)
- You could argue that images are tangential, if not completely at odds, with the purposes of Wikidata as a project though. I don't think the same could be said for Wikipedia since encyclopedias historically included images, but there's nothing about tabled or linked data that has anything to do with media. In most cases it has absolutely nothing to do with Wikidata being a "knowledge base of structured data" or whatever. I don't think we are obligated to host an image of something, let alone specific types of media, just because someone creates a Wikidata property or item for it either. --Adamant1 (talk) 02:26, 22 June 2024 (UTC)
- @Jmabel: If item on WD is within their scope and the notability, then yes, any image is reasonable. That said, there are many who upload an image, then create an item there as self-promotion, so in those cases it is not reasonable to retain. Solely having an item there, and having an image here used there, should NOT be the sole criteria, we need to have a little investigation. We cannot have each site be a blocker to the other resolving spam and self-importance. — billinghurst sDrewth 12:38, 22 June 2024 (UTC)
- @Billinghurst: agreed on the problem, but Wikidata, not Commons, is where you have to fight to say something on Wikidata is not valid use. Yes, every sister project is in this sense a "blocker" because we are here, among other things, to serve those projects. Again, we can consider something spammy, but it is up to Wikidata to make their own determination about their notability threshold, which is a low threshold. Having an item exist on Wikidata isn't an argument to keep 14 photos of that subject; it isn't an argument to create a category for that subject; but it is an argument for keeping the photo Wikidata is using. If Wikidata decides that the subject is above their threshold of inclusion, then the are entitled to have one photo of it, and Commons is the only place that can be hosted. - Jmabel ! talk 16:54, 22 June 2024 (UTC)
- @Jmabel: Please do not make this into a Gordian knot or an ouroboros; WD is also here with a level of serve the projects, hence their first point in d:Wikidata:Notability. NOTABILITY 1a) For an item to be notable at Wikidata there are numbers of hoops, and the main one for that is that a SITELINK exists. NO files at Commons are sitelinks at WD, that is only to galleries and categories, and that is the zone that we control. [Note that having an image is not a notability criteria.] 1b) The item has to have a range of other criteria including links to other items, and links to the item. 2) We are all editors at Commons and Wikidata, so I am more than comfortable identifying an abuse of process of the two, and ask for the file to be deleted, and for the WD item to be deleted. At this end, I have more investment in the deletion process and involve myself from both sides, and both methods DR and Speedy; whereas I leave things up to them for their processing. 3) If there is a level of wait for their processes to flow, then I nom there, and DR here with comment about awaiting resolution at WD and we have enough lag that it will resolve one way or the other. Imperfect, though it gets rid of most dross. At that point, if they make the decision to keep, then so do we. It doesn't prevent us having some rigour and challenge the dross. — billinghurst sDrewth 23:43, 22 June 2024 (UTC)
- This is (or at least started out being) a discussion about deletion of files, not about categories. Of course we can get rid of a category even if it corresponds to a Wikidata item. Similarly, in theory, we can get rid of a category even if it corresponds to an article in the English-language Wikipedia, or in any number of Wikipedias, though we seldom do, even for categories with only one photo. But (barring copyright issues) we should not be the ones to get rid of a file that is being used by a sister project without first resolving that use on the project in question. And, yes (give or take a few people who are blocked) people here on Commons may participate in whichever of these sister projects they choose, but these projects are distinct overlapping communities that do not always reach the same consensus on everything. - Jmabel ! talk 00:16, 23 June 2024 (UTC)
- Wikidata has what they concurred to be a "common sense" conflict of editing policy. They are regularly deleting conflicts of interest, and components of self-importance. An image uploaded here and an item created at WD by the same person and neither has an editing history at Commons or WD, clearly aligns with the F10 criteria here, and there should be a deletion process. There is no 100% purity, so applying good sense to interpreting our clear principles here and there, and let the community manage attempts to abuse us. The UDR process is here to be used by anyone who thinks that there is a mistake, so we can have resolution as required. We are never going to be perfect, and we have a resolution process. — billinghurst sDrewth 01:47, 23 June 2024 (UTC)
- This is (or at least started out being) a discussion about deletion of files, not about categories. Of course we can get rid of a category even if it corresponds to a Wikidata item. Similarly, in theory, we can get rid of a category even if it corresponds to an article in the English-language Wikipedia, or in any number of Wikipedias, though we seldom do, even for categories with only one photo. But (barring copyright issues) we should not be the ones to get rid of a file that is being used by a sister project without first resolving that use on the project in question. And, yes (give or take a few people who are blocked) people here on Commons may participate in whichever of these sister projects they choose, but these projects are distinct overlapping communities that do not always reach the same consensus on everything. - Jmabel ! talk 00:16, 23 June 2024 (UTC)
- @Jmabel: Please do not make this into a Gordian knot or an ouroboros; WD is also here with a level of serve the projects, hence their first point in d:Wikidata:Notability. NOTABILITY 1a) For an item to be notable at Wikidata there are numbers of hoops, and the main one for that is that a SITELINK exists. NO files at Commons are sitelinks at WD, that is only to galleries and categories, and that is the zone that we control. [Note that having an image is not a notability criteria.] 1b) The item has to have a range of other criteria including links to other items, and links to the item. 2) We are all editors at Commons and Wikidata, so I am more than comfortable identifying an abuse of process of the two, and ask for the file to be deleted, and for the WD item to be deleted. At this end, I have more investment in the deletion process and involve myself from both sides, and both methods DR and Speedy; whereas I leave things up to them for their processing. 3) If there is a level of wait for their processes to flow, then I nom there, and DR here with comment about awaiting resolution at WD and we have enough lag that it will resolve one way or the other. Imperfect, though it gets rid of most dross. At that point, if they make the decision to keep, then so do we. It doesn't prevent us having some rigour and challenge the dross. — billinghurst sDrewth 23:43, 22 June 2024 (UTC)
- @Billinghurst: agreed on the problem, but Wikidata, not Commons, is where you have to fight to say something on Wikidata is not valid use. Yes, every sister project is in this sense a "blocker" because we are here, among other things, to serve those projects. Again, we can consider something spammy, but it is up to Wikidata to make their own determination about their notability threshold, which is a low threshold. Having an item exist on Wikidata isn't an argument to keep 14 photos of that subject; it isn't an argument to create a category for that subject; but it is an argument for keeping the photo Wikidata is using. If Wikidata decides that the subject is above their threshold of inclusion, then the are entitled to have one photo of it, and Commons is the only place that can be hosted. - Jmabel ! talk 16:54, 22 June 2024 (UTC)
- @Jmabel: If item on WD is within their scope and the notability, then yes, any image is reasonable. That said, there are many who upload an image, then create an item there as self-promotion, so in those cases it is not reasonable to retain. Solely having an item there, and having an image here used there, should NOT be the sole criteria, we need to have a little investigation. We cannot have each site be a blocker to the other resolving spam and self-importance. — billinghurst sDrewth 12:38, 22 June 2024 (UTC)
- You could argue that images are tangential, if not completely at odds, with the purposes of Wikidata as a project though. I don't think the same could be said for Wikipedia since encyclopedias historically included images, but there's nothing about tabled or linked data that has anything to do with media. In most cases it has absolutely nothing to do with Wikidata being a "knowledge base of structured data" or whatever. I don't think we are obligated to host an image of something, let alone specific types of media, just because someone creates a Wikidata property or item for it either. --Adamant1 (talk) 02:26, 22 June 2024 (UTC)
- @Consigned: strongly disagree. Legitimate use on a sister project should be sufficient reason to consider an image to be in Commons' scope, and we should not be in a position to dictate to other projects what we consider legitimate for them. Commons is, as much as anything else, a repository for images required by other projects. Wikidata, for example, does not host images itself, and completely relies on Commons to be its image host. - Jmabel ! talk 02:03, 22 June 2024 (UTC)
- Concur. WD item creation that is involved with the uploader/creator in sequence within the same timeframe, and otherwise fails their notability (articles or independent linkage) is not "in use" (image or category). If it is borderline, or where I am in doubt, I will nominate there for deletion with appropriate commentary, and then nominate the image here with a DR, so we can do some follow-up (our DR review takes longer than theirs). That is pretty much what I will do for a draft article where it is dodgy and reeking of COI at the WPs. — billinghurst sDrewth 04:38, 17 June 2024 (UTC)
June 17
Intersection categories
I would appreciate additional opinions on a disagreement I am having with User:AnRo0002 (see User talk:AnRo0002#Intersection categories for the discussion so far). They have been creating a number of very specific time-based intersection categories such as Category:Snow in Massachusetts in February 2012, Category:October 2016 in bus transport in Massachusetts, and Category:April 2014 in rail transport in Massachusetts. I believe these categories are not useful - they provide no benefit to users, while making them sort through more subcategories to find files, and require additional editor work to categorize files. From what I have seen, the consensus at noticeboards and CfDs has generally been against the creation of highly specific intersection categories. Pi.1415926535 (talk) 02:55, 17 June 2024 (UTC)
- Those seem painfully narrow. - Jmabel ! talk 06:40, 17 June 2024 (UTC)
- Reminds me of the Steamboat Willie deletions. Enhancing999 (talk) 07:43, 17 June 2024 (UTC)
- @Pi.1415926535: How about Category:September 11, 2001 in New York or Category:September 2001 in Manhattan as a subcat of Category:September 2001 in New York? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:12, 17 June 2024 (UTC)
- See Category:New York City photographs taken on 2001-09-11 and Category:September 2001 in Manhattan, New York City, which are both two years old. Breaking out New York City photographs by day is two years old according to {{New York City photographs taken on navbox}}. Category:September 2001 in New York (state) is seven years old. I believe the effort to subcategorize Manhattan (and other borough) media by month began before the pandemic. One Wikimedia Foundation trustee uploads New York City images by the hundreds when he attends a board meeting every year--see Category:March 2023 in Manhattan, New York City and Category:March 2024 in Manhattan, New York City, for example. Some NYC subway and bus fans upload images by the score each month as well. -- DanielPenfield (talk) 15:53, 17 June 2024 (UTC)
- Those seem like a bit of a special case. Those categories are less of an intersection by date, more photos of an event which is known primarily by its date. I would hesitate to generalize from there. Omphalographer (talk) 19:43, 17 June 2024 (UTC)
- You're ignoring Category:March 2023 in Manhattan, New York City and Category:March 2024 in Manhattan, New York City, the latter of which contain photographs of quite possibly every last meteorite in the American Museum of Natural History as well as every nook and cranny in Riverside Park (Manhattan). Then there's the hundreds-to-thousands of photographs taken each year by an obsessive contributor in Category:New York City Subway photographs by Tdorante10--each one of those is categorized a month-specific "New York City Subway in MMM YYYY" category. You can pretend that the problem is one of overly-specific categorization, but really the root cause is an increasing number of contributors who like to upload images by the hundreds or thousands that depict the same subject over and over and over and over. That is what drives the quantity and therefore specificity of categories. Want an image of a bus in Midtown Manhattan? Well, then select one of the 754 in Category:Buses in Midtown Manhattan or one of scores more in any of its 10 subcategories. -- DanielPenfield (talk) 04:06, 18 June 2024 (UTC)
- Having complete coverage of useful subjects is generally a good thing - that's why we have GLAM collaborations. While there is a need to avoid actual duplicates (and yes, a few uploaders need to be reminded of that fact), I don't think that's the main factor behind the increasing number of questionable categories. A great many subjects are extremely complex and will rightfully have a large number of files; our category system should be designed to allow users to navigate those files efficiently.
- The key issues to me are:
- How do we decide which intersection categories are useful and which are not (the reason I started this discussion)
- What tools need to be created to enhance the category system and have it adequately serve the 100+ million files on Commons, and
- For tools that are beyond the resources of Commons volunteers to create and maintain, how do we get the WMF to prioritize making them?
- Without steering the discussion too far away from that first point, there seems to be general agreement that we need the ability to arbitrarily subdivide a category by certain parameters. In particular, we need a tool that can allow you to find all files in a category (or category tree) within a selected date range - and have it be available on the category pages as well as in the search function. This would eliminate a large swath of intersection categories - in particular, the ones that require the most labor to populate and provide the least benefit. Division by date, file type, resolution, and license could all be done with existing structured data; it would provide a great deal of functionality without getting into any areas likely to be controversial. Pi.1415926535 (talk) 06:08, 18 June 2024 (UTC)
- @Pi.1415926535 As to your 3 questions:
- The question of intersection categories is a constant one on COM:CFD. Essentially, nearly every topic category is an intersection category. Thus I don't think how we treat discussions on intersection categories is really that different from how we approach topic categories in general. There are sometimes calls to arbitrarily limit the amount of sub-categorization of a topic (essentially a process of intersecting categories), but these rarely gain consensus as it usually involves unintended consequences and lots of exceptions. Essentially, the basics are that there ought to be enough media to support an intersection category, that the intersection be sufficiently distinguishable to make a distinct category, and there it offer some meaningful sub-division of its parent categories. If any of these are in question, the issue is raised and discussed at COM:CFD (or other appropriate forum) and consensus for that particular use case is implemented. Basically, if a user creates a category, so long as it does not violate Commons category policies
, until there is a consensus that it is not useful, it is presumed useful and kept. - As for tools we need, better and more accessible search tools that obviate the need to use categories as search criteria would be high on my wish list. There are some good SPARQL query tools and gadgets that are helpful for those users with the initiative to learn and apply them, but they are not available to the mainstream and most users I would presume are not interested in learning to code just to view the media they are looking for. User-friendly interfaces built directly into the Commons interface (not requiring opt-in gadgets or third-party sites) are a must to make these useful for more than a small group of users.
- Clearly, involvement beyond volunteer contributors will be needed for at least some of these tools, and I have absolutely no clue how to push that cart. I'm not politically minded, nor am I steeped in the inner circle workings of the project, so I wouldn't even know how to start such a drive, but I'll gladly sign on to voice support for valuable tools. I added my name to several items on the wishlist a while ago...not sure if that did anything.
- The question of intersection categories is a constant one on COM:CFD. Essentially, nearly every topic category is an intersection category. Thus I don't think how we treat discussions on intersection categories is really that different from how we approach topic categories in general. There are sometimes calls to arbitrarily limit the amount of sub-categorization of a topic (essentially a process of intersecting categories), but these rarely gain consensus as it usually involves unintended consequences and lots of exceptions. Essentially, the basics are that there ought to be enough media to support an intersection category, that the intersection be sufficiently distinguishable to make a distinct category, and there it offer some meaningful sub-division of its parent categories. If any of these are in question, the issue is raised and discussed at COM:CFD (or other appropriate forum) and consensus for that particular use case is implemented. Basically, if a user creates a category, so long as it does not violate Commons category policies
- While I continue to look forward to better tools and development in the future and am eager to see how we can use them to best effect, I have been doing Wiki projects since 2005 and the idea that we shouldn't worry about making current systems work since there is a new tool just around the corner that will solve all problems is a song I have heard for going on 20 years now and one that all too rarely fails to deliver on the promises. Thus, my approach is to make the system we have now work as well as possible, and here that means making sure the categorization system provides the most robust and accessible system possible for finding media. I'll be pleased the day search tools obviate the need for it, but until that is shown to be true, I will be opposed to any attempt to limit categorization on the promise that search tools are the answer. Josh (talk) 17:03, 18 June 2024 (UTC)
- @Pi.1415926535 As to your 3 questions:
- You're ignoring Category:March 2023 in Manhattan, New York City and Category:March 2024 in Manhattan, New York City, the latter of which contain photographs of quite possibly every last meteorite in the American Museum of Natural History as well as every nook and cranny in Riverside Park (Manhattan). Then there's the hundreds-to-thousands of photographs taken each year by an obsessive contributor in Category:New York City Subway photographs by Tdorante10--each one of those is categorized a month-specific "New York City Subway in MMM YYYY" category. You can pretend that the problem is one of overly-specific categorization, but really the root cause is an increasing number of contributors who like to upload images by the hundreds or thousands that depict the same subject over and over and over and over. That is what drives the quantity and therefore specificity of categories. Want an image of a bus in Midtown Manhattan? Well, then select one of the 754 in Category:Buses in Midtown Manhattan or one of scores more in any of its 10 subcategories. -- DanielPenfield (talk) 04:06, 18 June 2024 (UTC)
- Those seem like a bit of a special case. Those categories are less of an intersection by date, more photos of an event which is known primarily by its date. I would hesitate to generalize from there. Omphalographer (talk) 19:43, 17 June 2024 (UTC)
- See Category:New York City photographs taken on 2001-09-11 and Category:September 2001 in Manhattan, New York City, which are both two years old. Breaking out New York City photographs by day is two years old according to {{New York City photographs taken on navbox}}. Category:September 2001 in New York (state) is seven years old. I believe the effort to subcategorize Manhattan (and other borough) media by month began before the pandemic. One Wikimedia Foundation trustee uploads New York City images by the hundreds when he attends a board meeting every year--see Category:March 2023 in Manhattan, New York City and Category:March 2024 in Manhattan, New York City, for example. Some NYC subway and bus fans upload images by the score each month as well. -- DanielPenfield (talk) 15:53, 17 June 2024 (UTC)
- Subcategories shouldn't be created simply because a category had a large number of files in it. If there are a lot of images related to something, that is what it is; we don't need to introduce artificial distinctions just to make categories smaller. Time-based category intersections in particular seem to have little value unless they're categorizing something which changes over time in a way that's significant to the topic. Photos of a person, perhaps (although breaking it down by month would still be excessive); photos of generic topics like weather, not so much. Omphalographer (talk) 15:01, 17 June 2024 (UTC)
- Those categories definitely need to be deleted. I'm not sure there's much point in having a discussion here. Please nominate them for deletion at Commons:Categories for discussion. Nosferattus (talk) 15:28, 17 June 2024 (UTC)
- @Nosferattus: I will take them to CfD, but there's little point in doing so until AnRo stops creating them. Pi.1415926535 (talk) 18:05, 17 June 2024 (UTC)
- Those categories definitely need to be deleted. I'm not sure there's much point in having a discussion here. Please nominate them for deletion at Commons:Categories for discussion. Nosferattus (talk) 15:28, 17 June 2024 (UTC)
- Chronological categorization seems to be coming under increased scrutiny lately. As the number of hosted files continues to grow and topical categories get larger, there seems to be increasing efforts to diffuse topics by date, and by increasingly precise dates at that. Beside appearing to be a benign effort to diffuse bloated topic categories, there can be specific technical value to categorization by specific date for maintenance, curation, and some specific research efforts. However, the unintended consequence is that topic files become buried in layers of date-based categorization, frustrating most users looking for images of that topic who are not concerned with exactly when the image is of. I think it is fair to conclude that the vast majority of users looking for images of snow in Massachusetts do not care if happens to be January or February of 2012, or if it is February of 2012 or 2013. Maybe one might want to focus on more recent times vs. pictures of yore, and some may indeed be interested in January vs. February for seasonal differences (not caring which exact year), but most don't probably care about the exact year even, much less month or day. Requiring them to select one particular moment in time to see images is very frustrating for most. This also makes normal diffusion more difficult, as files moved to specific dates are less likely to correctly get diffused to more appropriate sub-categories (e.g. a pic already moved to Snow in Massachusetts in February 2012 is less likely to ever be correctly be put into Snow in Boston as it no longer appears directly under Snow in Massachusetts).
- The solution to this dilemma would be one where the files are available in the main topic category for users to look through without requiring they select a specific date to be limited to, while also permitting the images to be collated by date to whatever level of specificity is meaningful for the topic. We have the same issue with categorization by media type. Most users are not looking for images of a precise type to limit their browsing to, but such categorization does have a lot of technical value to specific users. What we have done is make the Category:Media types tree separate from the Category:Topics tree. Files can be added to the Category:Media types tree and be diffused to whatever exact media type specification they fit, however, they are not to be removed from the Category:Topics tree (i.e. the main topic categories for the file). The Category:Media types categories are to be "__HIDDEN__" which puts them in a separate list of categories (only visible to users who elect to see non-topical categories).
- We could adopt this approach for date-based categorization, creating Category:Chronological categories as a separate non-topical tree. This would allow continued categorization by specific date without diffusing topical categories. For example, in the case of Massachusetts snow, all files regardless of date would be present under Category:Snow in Massachusetts, a topical (visible) category. The files themselves can be additionally categorized by date under Chronological categories to whatever level of precision those involved feel is warranted. They could be accessed from the main category via Snow in Massachusetts by period which would still appear under the main category for all users. Josh (talk) 17:44, 17 June 2024 (UTC)
- Is there a reason specific dates can't be off loaded to structured data? I think that would be a better way to do things since we are already having issues with the amount of needless categories in general. Really most categories could, and probably should, be off loaded to structured data at this point. --Adamant1 (talk) 19:54, 17 June 2024 (UTC)
- To query for images from a certain date, just use inception date (wdt:P571) in a structured data query at https://commons-query.wikimedia.org/. We need to stop treating categories like a query language. They are ill-suited for that purpose. And if using structured data queries is too difficult, we should get the WMF to add more capabilities to Special:MediaSearch, for example, filtering by date. Nosferattus (talk) 20:48, 17 June 2024 (UTC)
- @Nosferattus, structured queries are great, and you are right that categories are not queries! Unfortunately, requiring users to have SPARQL knowledge in order to search for files is, I fear, a bridge too far. We need tools to bridge that gap and bring query functionality to a broader user base before we can point to that as the answer to the problem. Josh (talk) 16:08, 18 June 2024 (UTC)
- @Adamant1 That is absolutely the way it should be done, but right now the structured data just isn't there yet to make this an accessible option for a lot of users and use cases. I'm all for moving that forward. In the meantime, this issue will persist. Josh (talk) 16:05, 18 June 2024 (UTC)
- To query for images from a certain date, just use inception date (wdt:P571) in a structured data query at https://commons-query.wikimedia.org/. We need to stop treating categories like a query language. They are ill-suited for that purpose. And if using structured data queries is too difficult, we should get the WMF to add more capabilities to Special:MediaSearch, for example, filtering by date. Nosferattus (talk) 20:48, 17 June 2024 (UTC)
- Is there a reason specific dates can't be off loaded to structured data? I think that would be a better way to do things since we are already having issues with the amount of needless categories in general. Really most categories could, and probably should, be off loaded to structured data at this point. --Adamant1 (talk) 19:54, 17 June 2024 (UTC)
- My general opinion: If there are enough files to create a new category: do so. Otherwise it is only annoying. For this specific case: I think that it is OK to have subcategories with more than ± 10 files, like Category:May 2014 in rail transport in Massachusetts (23 files), but not for Category:Snow in Massachusetts in February 2012 (1 file).
- I do think date categories are useful, especially when you are looking for other photographs taken on a certain date or month of the same subject and either harmonize their categories or create a new category, or to check whether a photo can indeed be taken on a certain day (if there is snow on the other photos instead of rain or blue sky, you know that something is wrong).
- I disagree with Omphalographer that subcategories shouldn't be created simply because a category has a large number of files in it. If a topic category has more than 200 files, it should be broken down into subcategories to keep a good overview. Those new subcategories should preferably be topic categories, not date categories. Exceptions might be longlists and subjects like all the pages of a book.
- I agree with Josh that files in date categories should also be available/stay in topic categories, for the reasons he mentions.
- I agree with Pi.1415926535 that we need a tool that can allow you to find all files in a category (or category tree) within a selected date range.
- See also Commons:Requests for comment/Categories of photographs by country by date, where (among other things) is discussed to which level of a country the diffusion would be allowed.
- --JopkeB (talk) 09:24, 18 June 2024 (UTC)
- @JopkeB: We have a tool that allows you to find whatever you want without abusing catagories. Want to see all the photographs of snow taken on January 1, 2009? Here you go: https://w.wiki/ARP$. Just click the Run button. Frankly though, I think the use case of needing to find images of a certain subject at a certain location on a certain date is entirely made up. Who has ever actually needed this? I certainly haven't. And if we're going to diffuse by location and date, why stop there? We could also diffuse by file type, license, aspect ratio, color vs. black and white, photographer, etc. The point is, categories are a poor substitute for search queries and are not what they were designed for. But when all you have is a hammer, everything looks like a nail. Fortunately, we now have other tools, so we don't have to keep abusing categories. And if writing queries is intimidating, just ask Magnus or the WMF to create whatever type of search interface you want. The data is there. We don't need categories to redundantly encode it. Nosferattus (talk) 14:39, 18 June 2024 (UTC)
- @Nosferattus, we do diffuse by many of the things you list, such as photographer, color, file type, and a hundred other criteria, depending on the topic. Scoffing at those who aren't prepared to create SPARQL queries to view what they need is not the answer. Also, no, the structured data is not all there yet, so queries are rarely complete. In theory you are not wrong...in fact a good enough database with a good enough search interface may make categories completely obsolete. We aren't there on either the data or the interface yet. If it is as easy as you claim it is, then go forward, get WMF to create the interface and demonstrate how the average user can easily use it in lieu of category browsing and maybe then you will have a valid argument to not use categories. Until then, we need categories to work for the broad user base that continues to need them. Josh (talk) 16:25, 18 June 2024 (UTC)
- You do have a good point that the data and interface are not complete. However, in my opinion, they are a lot more usable than our terrible category system which is only getting less and less useful by the day, mainly due to over-diffusion. Nosferattus (talk) 17:02, 18 June 2024 (UTC)
- @Nosferattus And I agree that over-diffusion is a serious issue. This is why I've floated the idea, at least in the case of the date diffusion, to remove that from the topic category tree and make it a separate tree, leaving the files undiffused in the original topic category. I see search tools as a valuable adjunct to this, in fact. I am not personally well versed in our third-party interfaces, but I would like to build a template (or bit to include in existing templates) that invokes a search to identify any files in a non-topical category that are not still present in the related topic category. This would permit easier maintenance reversing incorrect removals from the topic category. Josh (talk) 17:09, 18 June 2024 (UTC)
- You do have a good point that the data and interface are not complete. However, in my opinion, they are a lot more usable than our terrible category system which is only getting less and less useful by the day, mainly due to over-diffusion. Nosferattus (talk) 17:02, 18 June 2024 (UTC)
- Thanks, @Nosferattus: for the link. But I am one of those for who aquiring "SPARQL knowledge in order to search for files is ... a bridge too far." as Josh says. And I agree with him that this tool only show files with the correct structured data, what is not good enough for me. JopkeB (talk) 09:44, 19 June 2024 (UTC)
- @Nosferattus, we do diffuse by many of the things you list, such as photographer, color, file type, and a hundred other criteria, depending on the topic. Scoffing at those who aren't prepared to create SPARQL queries to view what they need is not the answer. Also, no, the structured data is not all there yet, so queries are rarely complete. In theory you are not wrong...in fact a good enough database with a good enough search interface may make categories completely obsolete. We aren't there on either the data or the interface yet. If it is as easy as you claim it is, then go forward, get WMF to create the interface and demonstrate how the average user can easily use it in lieu of category browsing and maybe then you will have a valid argument to not use categories. Until then, we need categories to work for the broad user base that continues to need them. Josh (talk) 16:25, 18 June 2024 (UTC)
- @JopkeB, as you can probably guess, I'm in agreement of most of what you've written here as many of these ideas are things that have come op in CfDs and other forums we've participated in. I am not a fan of placing hard arbitrary lower or upper limits on category size because I find topics and structures where very large or small categories do make sense within the scope of the topic and the available media. Of course, truly bloated categories do need to be diffused into meaningful sub-categorization, preferably by multiple different criteria. They don't even necessarily need to get to 200 files to warrant this in many cases. I do see you accept some exceptions though, which is good. One issue is stating 'subcategories should preferably be topic categories, not date categories.' I think I get what you are trying to say and I agree, but the root of this discussion is based on the fact that 'date categories' are 'topic categories' at the moment, at least structurally. The main effect of this is that, per COM:OVERCAT it is in fact required to remove a file from the main topic category when adding it to a date category. This is why I'm floating the idea of breaking date cats away from the topic tree and making them their own tree, akin to media type cats, thus reversing that requirement and making it a requirement to keep the media in the topic cat when adding it to a date cat. Josh (talk) 16:38, 18 June 2024 (UTC)
- I support the idea of making date categories non-diffusing, although my first choice would be to just delete them all. Nosferattus (talk) 17:09, 18 June 2024 (UTC)
- I'm not a big user of date categories, though I've had to work on several of them as part of being a broad-based maintainer. Commons doesn't have an exact analogue to Enwiki's non-diffusing categories, but we do have major category trees (see major category policy ) which are similar in effect, in that categories under one major category do not diffuse categories in another major category (e.g. a file in a Media types category does not diffuse from the related Topics category; the file should exist separately in both). This is why I presented the idea of creating Category:Chronological categories as a major category and making all 'by date' categories fall under this, prohibiting diffusion of the original topic category. I understand that nuking date categories would be your first choice, but appreciate your understanding that at least making them non-diffusing is an improvement that should be made if they are to be retained. Josh (talk) 17:21, 18 June 2024 (UTC)
- I'm not a big user of date categories, though I've had to work on several of them as part of being a broad-based maintainer. Commons doesn't have an exact analogue to Enwiki's non-diffusing categories, but we do have major category trees (see major category policy
- I also support this idea. Whether we ultimately keep these date-based subcategories or not, infusing their contents back into parent categories is a clear step in the right direction. Omphalographer (talk) 17:21, 18 June 2024 (UTC)
- Support the idea in absence of a better option like moving dates to structured data. The whole thing just seems circular though. We don't fully embrace SDC. So it's not properly implemented, naturally leading to lower adoption rates Etc. Etc. I'd like to at least see a realistic plan with some implementable steps to move in that direction. Along better guidelines and enforcement around these kinds of things. Although admittedly both are tangential to the current problem and I have no issue with Josh's idea in the midterm. --Adamant1 (talk) 21:20, 18 June 2024 (UTC)
- @Joshbaumgartner: The numbers I gave were not meant as hard lower or upper limits on category size, just indications that might be workable. JopkeB (talk) 09:59, 19 June 2024 (UTC)
- Understood and I agree. Josh (talk) 22:41, 19 June 2024 (UTC)
- I absolutely agree with the suggestion of always keeping/ automatically adding some other category (by default, the parent one, in no better one is available) besides date categories. COM:OVERCAT has been misused and abused a lot here, unfortunately, either by lack of good sense either by some obsession with pigeonholing everything people see in a cat - and pushing files into data cats while removing the parent cat is only one of those situations. Darwin Ahoy! 17:50, 19 June 2024 (UTC)
- I remember complaining about it years ago at Commons:Village_pump/Archive/2013/10#Category_madness_in_Hong_Kong, but there didn't seem to be much agreement that it was a problem. It's also a long-time obsession in the Australian categories, so you end up with the likes of Category:January 2012 at Launceston Airport. I ignore it. --ghouston (talk) 02:36, 20 June 2024 (UTC)
- @Ghouston You were more visionary I guess. It is indeed a problem that isn't always apparent until it has grown into a real monster. Regardless, I've seen it really come to a head in a lot of different topics over the last year or two and while we can't go back to 2013 and fix it then, we can do something now. I've created Category:Chronological categories as a base and a corresponding CfD to get input over there, but it sounds like a lot of support for not allowing diffusion by date to remove the files from non-date topical categories. Josh (talk) 17:42, 21 June 2024 (UTC)
- I remember complaining about it years ago at Commons:Village_pump/Archive/2013/10#Category_madness_in_Hong_Kong, but there didn't seem to be much agreement that it was a problem. It's also a long-time obsession in the Australian categories, so you end up with the likes of Category:January 2012 at Launceston Airport. I ignore it. --ghouston (talk) 02:36, 20 June 2024 (UTC)
- I support the idea of making date categories non-diffusing, although my first choice would be to just delete them all. Nosferattus (talk) 17:09, 18 June 2024 (UTC)
- @JopkeB: We have a tool that allows you to find whatever you want without abusing catagories. Want to see all the photographs of snow taken on January 1, 2009? Here you go: https://w.wiki/ARP$. Just click the Run button. Frankly though, I think the use case of needing to find images of a certain subject at a certain location on a certain date is entirely made up. Who has ever actually needed this? I certainly haven't. And if we're going to diffuse by location and date, why stop there? We could also diffuse by file type, license, aspect ratio, color vs. black and white, photographer, etc. The point is, categories are a poor substitute for search queries and are not what they were designed for. But when all you have is a hammer, everything looks like a nail. Fortunately, we now have other tools, so we don't have to keep abusing categories. And if writing queries is intimidating, just ask Magnus or the WMF to create whatever type of search interface you want. The data is there. We don't need categories to redundantly encode it. Nosferattus (talk) 14:39, 18 June 2024 (UTC)
What to do in this case
While we continue to discuss broader issues, I'd like to get some consensus as to what should be done in this specific case. AnRo continues to create hyperspecific categories such as Category:Spring 1951 in Boston, many of which have very few files, and they have not responded here nor at their talk page since this discussion began. To my mind, this is now an administrative matter - disruptive editing and a refusal to communicate - that needs action. Pi.1415926535 (talk) 18:03, 18 June 2024 (UTC)
- Yes, I just noticed that they created Category:Forests in Saxony in autumn 2019 and several others despite your polite request that they stop while discussion is ongoing. I've also asked them to stop. Nosferattus (talk) 20:42, 18 June 2024 (UTC)
- They should have at least held off until there was some agreement in the discussion about it. --Adamant1 (talk) 21:03, 18 June 2024 (UTC)
- This is just exacerbating the situation. There is some good discussion going on about how we can improve the system, but no matter what systemic changes we make, a disruptive effort by someone seemingly unwilling to participate in discussion is always going to be a problem. Unfortunately, some specific further action on that front might be needed. They don't even seem to be employing a consistent naming structure to these categories. Josh (talk) 22:59, 19 June 2024 (UTC)
- They should have at least held off until there was some agreement in the discussion about it. --Adamant1 (talk) 21:03, 18 June 2024 (UTC)
June 18
June 19
New changes to the "Depicts" step in UploadWizard available on Beta Commons
Hi all! I wanted to announce that on Beta Commons a new version of the "depicts" step of UploadWizard is available for testing.
A brief note about the changes:
- basic "depicts" annotations (and other statements set up in campaigns) without qualifiers or references can now be added on the same page where the user is entering captions, locations, etc
- the separate extra page for adding structured data is removed from UploadWizard
- qualifiers and references can still be added on individual File pages as before (and that will take only one extra click)
The reason for us doing this is that we're hoping that by simplifying depicts annotations we'll make it easier to spot copyvios (and in particular FoP violations). The drawback from a user perspective that we already know of is mostly for users who might be uploading multiple images at once with non-depicts statements and/or qualifiers and references, and copying those from the first image to all other images in the upload. This functionality is no longer available - as far as we can tell it's not used much, but if there are people using it then we'd like to hear from those users who use it.
This new version will be available on Beta Commons until Monday afternoon. We're waiting for your feedback on it! --Sannita (WMF) (talk) 10:23, 19 June 2024 (UTC)
- Two minor questions so far:
- Why does the
Main subjects visible in this work (optional)
label have a “pointer” cursor? Clicking it doesn’t seem to do anything (it doesn’t focus the input field). - Why will this only be available until Monday afternoon?
- Why does the
- Lucas Werkmeister (talk) 11:44, 19 June 2024 (UTC)
- The "pointer" cursor is unintentional - raised a ticket for it https://phabricator.wikimedia.org/T367976
- It'll be available until Monday afternoon because we have to revert it by Monday evening, otherwise it automatically goes to production. If there's demand for more testing we can re-enable it on beta on Tuesday (until the following Monday) CParle (WMF) (talk) 14:09, 19 June 2024 (UTC)
- I think this change has a lot of potential!
- Regarding adding more structured data with "one extra click", I think there should be a button for that on the last page of the wizard (next to each uploaded photo).
- Why do you call it "Main subjects visible in this work" when the values are used in a depicts statement? I think inconsistent terminology creates confusion.
- I think the created depicts statements could be automatically marked as prominent ("The most prominent subject(s) depicted in this work").
- Do you (or do you plan to) suggest categories based on the chosen Wikidata items?
- It would be nice to read about the plans for this kind of changes. TuukkaH (talk) 14:32, 19 June 2024 (UTC)
- Glad you think it has potential @TuukkaH!
- There's a link to the File page for each image on the last page, and that's where you can click the "structured data" tab and add extra structured data. We actually talked on the team about adding another link directly to the structured data tab, but weren't convinced that the extra clutter on the page was worth it
- We're calling it "Main subjects visible in this work" because we weren't sure if new uploaders would understand "depicts" (we had a lot of discussion about the exact wording). Open to other suggestions if you have them
- I'm not sure this is really necessary, but if there's community demand for it we can certainly do it
- It's an interesting idea, but likely to be a lot of work to figure out how to do that (and it's not on our roadmap atm)
- FYI the plans for all these kinds of changes are covered on the project page and the phab tickets linked from there CParle (WMF) (talk) 14:55, 20 June 2024 (UTC)
- Glad you think it has potential @TuukkaH!
- @Sannita (WMF) I tried to upload an image, but it doesn't appear (the file appears, but without the image itself). Is this expected? Darwin Ahoy! 17:30, 19 June 2024 (UTC)
- Beta can be a bit flaky, but an upload worked for me right now. Worth trying again maybe? CParle (WMF) (talk) 14:58, 20 June 2024 (UTC)
- @Sannita (WMF) I usually upload dozens of photos at once, and I used to upload them in batches so that it was very easy to put the "depicts" with the "apply to all" or "copy to all" function. If this is no longer available, and we'll have to pick depicts for every single file, I believe I'll stop adding them entirely. The extra field will be only additional, useless clutter, and I would frankly prefer if it wasn't there at all, or was hidden in another tab, as before. So, to me, in such a workflow, it's an unwanted change, and one for the worst. But I really don't get how do you think this change will help spotting copyvios, to start with. Darwin Ahoy! 17:37, 19 June 2024 (UTC)
- @DarwIn you actually can still copy "depicts", just not other statements (or qualifiers/references)
- Freedom of panorama copyvios are the most common reason for deletion requests on commons (see here https://phabricator.wikimedia.org/T340546). What we're hoping is If someone uploads a picture of, for example, Burj Khalifa then they'll add
depicts:Burj Khalifa, and we'll be able to spot the FoP violation automatically - Note that we don't propose to take any automatic action right now, but we're working towards better automatic detection of files that are likely to get deleted CParle (WMF) (talk) 13:58, 20 June 2024 (UTC)
- @Sannita (WMF): I tested out the changes and it seems like an improvement. Two tangential issues though:
- Why is UploadWizard only setting the depicts statement? Why not also set inception, media type, and copyright status? You can get those for free from the existing fields.
- Phabricator bug T261764 makes using the depicts interface error-prone and confusing, especially for newbies. Is there any chance that the Wikidata folks could help fix that?
- Nosferattus (talk) 02:12, 24 June 2024 (UTC)
- @Nosferattus Hi, thanks for your messages. Sorry it took me so long to answer, but I was caught in other urgent stuff, my bad.
- We're working on adding inception (phab:T362328) and coordinates of the point of view (phab:T368381) to the properties that users can add, it's going to need some time but it will be done. Other properties are already added automatically via bot, so they could be added, but since this is already taken care of by a bot we're not considering them a priority -- that is, unless there is consensus from the community to make them available.
- I don't know, I'll try to contact them and ask them about it, but I can't promise you anything about this. I know for a fact that scientific articles will be split from the main graph when doing queries, but I don't know if this will affect Structured Data too.
- Sannita (WMF) (talk) 16:38, 25 June 2024 (UTC)
- Thanks for the update! I'm glad you will be setting inception automatically soon! Nosferattus (talk) 17:32, 26 June 2024 (UTC)
- @Nosferattus Hi, thanks for your messages. Sorry it took me so long to answer, but I was caught in other urgent stuff, my bad.
June 20
June 21
Geogroup icon
Manjiro5 recently requested an edit to {{Geogroup}} at Template talk:Geogroup#Icon proposal. They are proposing a new icon to be used by the template:
| Current icon: | 
|
in template -> | |
|---|---|---|---|
| Proposed icon: | 
|
in template -> |
The comment in support of this proposal was: "I would like to replace it with this icon being more modern and slightly more accessible" by Manjiro5
As the template talk page is unlikely to get much traffic to comment on this, but the template is widely used, I am putting it out here on the VP for comment before we move forward with the edit request. Josh (talk) 17:33, 21 June 2024 (UTC)
- Would fit in the flat design trend of the recent years --PantheraLeo1359531 😺 (talk) 19:29, 21 June 2024 (UTC)
- Np. Atlantic or Pacific, I don't mind. Enhancing999 (talk) 19:55, 21 June 2024 (UTC)
- +3. Seems fine. --Adamant1 (talk) 00:28, 22 June 2024 (UTC)
- Np. Atlantic or Pacific, I don't mind. Enhancing999 (talk) 19:55, 21 June 2024 (UTC)
- Would fit in the flat design trend of the recent years --PantheraLeo1359531 😺 (talk) 19:29, 21 June 2024 (UTC)
June 22
Photo challenge April results
| Rank | 1 | 2 | 3 |
|---|---|---|---|
| image |  |
 |
|
| Title | Колонны здания администрации и думы Новгородской области 2H1A4397WI |
Columns on the façade of the Philharmonie in Luxembourg |
Fassade Mark- Twain- Grundschule 02 |
| Author | Kora27 | Ermell | ThoBel-0043 |
| Score | 25 | 14 | 11 |
| Rank | 1 | 2 | 3 |
|---|---|---|---|
| image |  |
 |
|
| Title | Visitors at the 2024 Easter fire in Rottorf | Campfire at lake Yngen, Filipstad Municipality, Värmland, Sweden |
Osterfeuer im oberen Murtal |
| Author | F. Riedelio | Mozzihh | Bitisajn |
| Score | 21 | 14 | 10 |
Congratulations to Kora27, Ermell, ThoBel-0043, F. Riedelio, Mozzihh and Bitisajn. -- Jarekt (talk) 00:50, 22 June 2024 (UTC)
COM:CSCR in South Korea
Are there laws concerning a consent requirement in South Korea? 2001:4452:11E:F200:51E9:F25D:C71A:2504 05:46, 22 June 2024 (UTC)
- COM:CCSR says, "Yes, with exceptions" but does not spell out those exceptions. - Jmabel ! talk 16:57, 22 June 2024 (UTC)
Looking for category
Is there a category for photos that features both the subject and the photographer? --Trade (talk) 06:49, 22 June 2024 (UTC)
- Something like Category:Group selfies or Category:Selfies with celebrities? ReneeWrites (talk) 07:44, 22 June 2024 (UTC)
- It's not exactly clear who actually belongs in the celebrity category. Same with the subcategories Trade (talk) 08:16, 22 June 2024 (UTC)
Who actually belongs in this category? Looking at the images placed here it looks completely random and quite frankly arbitrary. Most of the people located here are not even working in media Trade (talk) 08:42, 22 June 2024 (UTC)
- Personal opinion: It is limited value trash, though it is long existing trash that seems to have been accepted and have subsidiary categories. — billinghurst sDrewth 12:33, 22 June 2024 (UTC)
- Depending on the definition every person who is notable for a own category on Commons could be in that category making it completely useless. GPSLeo (talk) 13:32, 22 June 2024 (UTC)
- That's what I was thinking too. It strikes me as completely superfluous and arbitrary. ReneeWrites (talk) 16:11, 22 June 2024 (UTC)
- Depending on the definition every person who is notable for a own category on Commons could be in that category making it completely useless. GPSLeo (talk) 13:32, 22 June 2024 (UTC)
- Images where the "[uploader] cannot .. subcategorize .. by profession or status" need to go somewhere. There or to Category:People. You will either have two piles or one pile. Enhancing999 (talk) 14:03, 22 June 2024 (UTC)
- My preference is for Category:People. Looking at the setup of both categories it's where you can reasonably find what you're looking for. When I think celebrities I think actors, athletes, even influencers. All of those are categorized elsewhere. This is like having two sock drawers but one doesn't even have any socks. ReneeWrites (talk) 16:13, 22 June 2024 (UTC)
.svg/15px-Pictogram_voting_comment_(orange).svg.png){kind=small}
Comment I think that it can be argued that the category should have no people listed directly as they would fall into a specific subsidiary category, and probably no images. If they are that much of a celebrity they get their own category which is linked to wikidata. If they are not that much of a celebrity, they are failing. — billinghurst sDrewth 14:15, 22 June 2024 (UTC)
- Hi, I support deletion of this category, although it is useful as a honeypot to catch copyright violations and vanity images. Yann (talk) 16:19, 22 June 2024 (UTC)
- Useless at best. - Jmabel ! talk 17:24, 22 June 2024 (UTC)
- Totally agree. There's nothing in it that can't or shouldn't be put in more specific categories. --Adamant1 (talk) 22:22, 22 June 2024 (UTC)
- Or deleted. Unsurprisingly, there are tons of selfies and otherwise self-promotional images in this category. Omphalographer (talk) 23:59, 22 June 2024 (UTC)
- Useless category. Support depopulating or deleting. Nosferattus (talk) 01:11, 24 June 2024 (UTC)
- What about the 20+ subcategories? Trade (talk) 15:49, 24 June 2024 (UTC)
- Most of these have the same problem as the parent category. The only exceptions I see offhand are Category:An alphabet of celebrities (doesn't need this parent at all, though), Category:Magazines about celebrities, and (barely less problematic, but at least with a bit more of a clear definition) Category:Socialites. Category:Magazines about celebrities could be renamed as Category:Gossip magazines, matching en:Gossip magazine. - Jmabel ! talk 18:33, 24 June 2024 (UTC)
- What about the 20+ subcategories? Trade (talk) 15:49, 24 June 2024 (UTC)
- Comment See also Commons:Village_pump/Archive/2023/08#Category:Celebrities. --A.Savin 12:10, 24 June 2024 (UTC)
- Comment Probably the same could be done for Category:Statesmen, Category:Adventurers, Category:Television personalities, Category:Media personalities, and Category:Social media influencers. Although I'll leave it up to others to decide. --Adamant1 (talk) 21:34, 24 June 2024 (UTC)
- At least the people in those categories seems to actually belong there. Not like Celebrities Trade (talk) 15:48, 25 June 2024 (UTC)
Disease-related deaths in Beijing
Disease-related deaths in Beijing. Looks like vandalism to me. — Preceding unsigned comment added by Broichmore (talk • contribs)
June 23
Is there something like TinEye or Google Image Reverse Search for Wikimedia Commons?
Does Wikimedia Commons have a function where I can input image files and search if any similar-looking images have been uploaded on Commons? --MaplesyrupSushi (talk) 02:24, 23 June 2024 (UTC)
- @MaplesyrupSushi: Duplicate search is built in, see the bottom of the file description page or error messages upon upload. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:43, 23 June 2024 (UTC)
- I don't see a duplicate search button there, is enabling a gadget needed for that? I just have a firefox addon by which one can right click to reverse image search. However, the proper approach to this would be, as suggested earlier, create a script/bot that scans through all the WMC files to find likely copyvios and e.g. put them all in a category for them to be reviewed rather than a huge time-sink of reverse searching individual images manually. Prototyperspective (talk) 09:11, 23 June 2024 (UTC)
- Any reason not to just use Google Image itself and look for images on Commons?
- It might help if you said what is the issue you are trying to solve for which you want this tool. There may be a way to solve it other than the specific way you are suggesting. - Jmabel ! talk 18:17, 23 June 2024 (UTC)
- OptimusPrimeBot by @Don-vip: adds Template:Duplicate to files listed on Special:ListDuplicatedFiles. Afaik the limitation on how many it adds is that it tries to keep backlog in the category:Duplicate short so the task doesn't feel overwhelming (ie. it doesn't flood it). Don-vip also have his own perceptual hash index of Wikimedia Commons files which is used for checking if photo already exits in Wikimedia Commons when uploading. --Zache (talk) 12:23, 24 June 2024 (UTC)
- If I understood you correctly, that is only about duplicate files within Commons but I was saying there needs to be a Tineye/GoogleImage reverse search bot that identifies files that are likely copyvios needing manual review.
- Also I don't know why Jmabel replied beneath my comment because he seems to to address Maplesyrup, not anything I wrote if I'm not mistaken. Prototyperspective (talk) 12:38, 24 June 2024 (UTC)
- Ok, got it. -- Zache (talk) 12:49, 24 June 2024 (UTC)
- @Jeff G.: Where at the bottom of the file description page is this, can you post a screen shot or give a better description of it? Broichmore (talk) 19:31, 23 June 2024 (UTC)
- @Broichmore: Please see the bottom of any page in Category:Duplicate or Special:ListDuplicatedFiles. For example, File:Abhandlung von den Zähnen (Pfaff) 219.jpg is a 1x1 white dot duplicated in 1,602 files for completeness. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:22, 24 June 2024 (UTC)
- I see, thanks, the Category:Duplicate besides being a hidden cat, is put there by a human. So it doesn't help anyone on this thread.
- Interestingly the very first such image I looked at, was wrongly catted, as a duplicate. This file is anything but a duplicate, I have reverted that edit. - Broichmore (talk) 10:33, 24 June 2024 (UTC)
- @Broichmore: Please see the bottom of any page in Category:Duplicate or Special:ListDuplicatedFiles. For example, File:Abhandlung von den Zähnen (Pfaff) 219.jpg is a 1x1 white dot duplicated in 1,602 files for completeness. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:22, 24 June 2024 (UTC)
- I don't see a duplicate search button there, is enabling a gadget needed for that? I just have a firefox addon by which one can right click to reverse image search. However, the proper approach to this would be, as suggested earlier, create a script/bot that scans through all the WMC files to find likely copyvios and e.g. put them all in a category for them to be reviewed rather than a huge time-sink of reverse searching individual images manually. Prototyperspective (talk) 09:11, 23 June 2024 (UTC)
- @MaplesyrupSushi: For the kind of artwork, you’re doing, its essential to attribute the artist/s, the publisher, and the true originating owner museum (the true source of the image) that's step 1.
- Next, it's search through commons, using different search terms, and variations on the artists name, till you have the category for the particular artist complete. Should you have missed an image it’s not a problem.
- This is because 18th and 19th century Lithographs and engravings are all unique, even if they come from the same book and edition, they are different, that’s why provenance and ownership is important, they are different in terms of condition and hand painting, and they should not be overwritten by anything other than the exact same print, from the same book, in the same museum.
- Ranjeet Singh and his bolster image discussions are proof of that.
- Your problem is not really solved by using google and TinEye, very often the exact original title searched for using simple SQL syntax will uncover more of the same item, here and on the internet. As the images are unique, as described, the checksums differ to, they can be too difficult for even google to cope with.
- Variations of the same print are something we want! Degraded duplicates of the same image are not.
- I have to say that engravings from Victorian newspapers, and 18th and 19th century lithographs on commons are routinely uploaded regularly with scant regard for any of the above. If they were obviously modern images they would be deleted on sight.
- As we discussed before, quality of the source of the image is critical, I can't think of a worse source than the Panjab Digital Library, and because most of the images are PD, there's a multitude of real honeys out there. Broichmore (talk) 20:23, 23 June 2024 (UTC)
- @Broichmore - This is very helpful info, thank you very much for the advice/guidance! MaplesyrupSushi (talk) 22:37, 23 June 2024 (UTC)
- @MaplesyrupSushi I forgot to mention two concepts to you, that enable search in commons.
- Firstly, all these files (we have of paintings, engravings, historical photos) need the Artwork template. The essential fields to fill in, are: the artist, the title (as given by the publisher or artist), the date (of publication, creation, in the description field all of the available captions or at least the relevant keywords from it, the institution owner. Nice to have's are the medium, and dimensions.
- Finally, secondly, the museums Accession number, (for the British Library that's the shelfmark number). Any other given numbers can just go into the description field.
- This last item the Accession number is critical, because commons has bots, that occasionally scrape museum sites, and it looks for that number, if the bot cant find it, it will upload a duplicate. The minimum cats are the artist, and engraver (or publisher if not available). Nice to have's are the museum source collection, and the most pertinent descriptive cat.
- Sikh images and Indo, Pakistani original art can be a problem, for these images you can only fill out what you know, but I think you'll find that on finding an image, you will find variants elsewhere that will provide the bits and pieces you need. Be aware that some sites strip this information out, they are in the business of selling prints for decorative purposes, academia means nothing to them, they don't pay out against copyright claims unless challenged. Their defence being that to the best of their knowledge the items are PD, something which they don’t highlight on their sites.
- It goes without saying that licencing is essential for uploading, for your stuff that will come with PD USA. The uploader is not the author, the license is always an art one.
- Hope this helps. - Broichmore (talk) 11:55, 24 June 2024 (UTC)
- @Broichmore - This is very helpful info, thank you very much for the advice/guidance! MaplesyrupSushi (talk) 22:37, 23 June 2024 (UTC)
- I have been working with indexing commons photos images using imagehashes. Current status is that I have 70% of jpg/png/webp/tiff images indexed and there is REST api for querying hashes. However, currently there is no web interface for querying commons images by files or urls as my focus has been on indexing and publishing the database and not yet in the web UI. (see proposal, github). In any case if you have immediate need I could add minimal web form interface for querying commons images using files/urls to toolforge if there is need for that. --Zache (talk) 12:16, 24 June 2024 (UTC)
- @MaplesyrupSushi I wrote a minimal web ui for Imagehash.toolforge.org (example queries: 1, 2, 3) It also allows to upload files but that is little bit slow. Another caveat is that it works better with larger files (ie. over 800x800px than with very small thumbnails.--Zache (talk) 08:35, 26 June 2024 (UTC)
- @Zache - Thanks a lot! I’ll give it a try. MaplesyrupSushi (talk) 11:07, 26 June 2024 (UTC)
can I translate text of any image
i want to translate text of this image.and if I only upload PNG format. is it ok?
--KEmel49 (talk) 06:14, 23 June 2024 (UTC)
- Commons:SVG Translate tool and no, SVG is the preferred format for this as it is easily fixable and scalable. Sjoerd de Bruin (talk) 10:17, 23 June 2024 (UTC)
- The nice thing about this SVG is that the text is actually stored as text and not as image, lines or separate characters. Enhancing999 (talk) 16:49, 23 June 2024 (UTC)
Redlinks to existing pages
Sometimes links to existing pages lead to a Creating page, as if the page did not exist. Currently I have a case like that in Template:GDR propaganda navbar, namely the military link. It should lead to Category:GDR Propaganda; military. But when I click on it, I am told, that I can create the page. (Not sure what would happen if I do.) The other links also turn black, when they lead to the current page. This one does not. Can that be fixed? Watchduck (quack) 17:14, 23 June 2024 (UTC)
- The "p" in "propaganda" is lower case in the template, as well as in all of the other categories in this naming scheme (cf. Special:Prefixindex/Category:GDR propaganda;). I'd recommend that you rename this category for consistency. Omphalographer (talk) 17:22, 23 June 2024 (UTC)
- Oops, thank you. This would be a great case for one of those Did you mean links. Watchduck (quack) 18:45, 23 June 2024 (UTC)
- Not too convinced that the chosen color scheme helps. Enhancing999 (talk) 17:37, 23 June 2024 (UTC)
- The colors fit the topic. It's a bit tongue-in-cheek. Watchduck (quack) 18:45, 23 June 2024 (UTC)
- The color is reserved at WMF sites for a specific type of wikilink. Apparently here the color scheme even confused its creator. Enhancing999 (talk) 18:50, 23 June 2024 (UTC)
- The colors fit the topic. It's a bit tongue-in-cheek. Watchduck (quack) 18:45, 23 June 2024 (UTC)
Squares in Berlin
subcats in Category:Squares in Berlin are arranged in a strange way. different squares bearing the same name are put into a "cat:...platz (Berlin)". is this accepted practice for german squares? RZuo (talk) 20:27, 23 June 2024 (UTC)
- more strangely Category:Streets in Berlin having the same name as another street in Berlin.
- this strange way of creating a "street (Berlin)" has one bad effect. if i type "cat:Schillerpromenade", uploadwizard/hotcat will show me both Schillerpromenade (Berlin-Neukölln) Schillerpromenade (Berlin-Oberschöneweide) as well as Schillerpromenade (Berlin), which confused me (why is there a cat for berlin when there are also two more specific cats?). RZuo (talk) 20:31, 23 June 2024 (UTC)
- Is it the same street spreading across multiple parts of the city? Enhancing999 (talk) 12:09, 24 June 2024 (UTC)
- "having the same name as" is probably kind of a Berliner specialty, as Berlin is probably world's one of few (if not the only one) capital where certain street names are being used more than once.
- The only practical usefulness of this scheme is (IMO), that it can be sorted in parental categories which refer to the name itself (such as Category:Schiller streets in Germany) as a whole, instead of putting each street category into it (usually with the result that some streets are in and some not). Regards --A.Savin 12:18, 24 June 2024 (UTC)
- Plenty of these in NYC (where numbered streets in Manhattan and Brooklyn are completely unrelated; I believe the ones in the Bronx do relate to the Manhattan grid). I suppose it's technically not a capital, but it's a bigger city than Berlin.
- Seattle, where I live, is loaded with streets that are distinguished only by a directional, and may or may not be closely related. First Avenue S is a continuation of First Avenue, but First Avenue NW and First Avenue NE are not. Burke Ave N is basically a line on the map and refers to 7 unconnected streets that fall on that line; there is a Ravenna Ave NE (in two unconnected pieces), Ravenna Pl NE, and an (also discontinuous) NE Ravenna Boulevard (none of which intersect each other, and one of which -- Ravenna Ave NE -- is mostly not in the Ravenna neighborhood). There's a rather famous corner of Pike Place and Pike Street in the heart of Pike Place Market, but it's beaten for sheer confusion by the corner of Bellevue Avenue E, Bellevue Place E, and Bellevue Court E. - Jmabel ! talk 18:56, 24 June 2024 (UTC)
- @Jmabel: Try the corner of Riverside, Riverside, and Riverside in upper Manhattan, NYC. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:47, 25 June 2024 (UTC)
- About the typology of squares: Category:Church squares is usually about squares with a translation of "church" in the name. I'd stick to that At Category:Church squares in Basel it also includes one that isn't named that way. Berlin could probably use a Category:Squares in Berlin by name category. Enhancing999 (talk) 09:43, 25 June 2024 (UTC)
June 24
No sound for uploaded videos (mp4 files)
I've uploaded recently and noticed the mp4 versions don't have sound, but the webm versions do.
For example the files under 'Transcode status' here https://commons.wikimedia.org/wiki/File:1.1_Introductions.webm under
I am using MacOS and Safari, and have tested in Chrome too. I also had a friend test on their Linux machine who confirmed the mp4 files had no sound when streamed or downloaded.
These were originally mp4 files, converted to webm using HandBrake before uploading. The originals play fine for me, but the mp4's on Commons seem to have lost their audio. — Preceding unsigned comment added by Jimmyjrg (talk • contribs)
- Commons does not allow MP4s. Please link to an MP4 you have uploaded. —Justin (koavf)❤T☮C☺M☯ 04:27, 24 June 2024 (UTC)
- It may be worth noting that on 19 June, @Jimmyjrg began uploading many video tutorials claiming "own work" and releasing as CC-BY 4.0, when indeed these are derivative works which depict live Wikipedia pages, including text, WMF logos, and images, some of which are in the Public Domain.
The latter PD status clearly overrides any ownership, license claim, or Creative Commons licensing.I am concerned, but given their veteran status, perhaps Jimmyjrg can independently rectify the license status for these videos (I count 27 as of this writing). I am unsure of which templates/licenses are applicable, apart from {{Copyright by Wikimedia}}. Elizium23 (talk) 04:42, 24 June 2024 (UTC)- @Elizium23: I'm not sure what you are saying here. I haven't looked at the videos. Insofar as the videos incorporate (without licensing) images that are not public domain the licenses need to be indicated, but a video can incorporate public domain content to whatever degree its creator wishes. That is the nature of public domain (although a few countries recognize "moral rights" independent of copyright that require giving credit for some public-domain content). Public-domain status is not "viral". I could make a video that consisted of juxtaposing a series of 100 public-domain images each shown for one second; my video would certainly be eligible for copyright, even though no one image in the video is copyrightable. In other words, to paraphrase but reverse you: PD status of images in a video does not override a copyright claim for the video as a whole. - Jmabel ! talk 05:22, 24 June 2024 (UTC)
- @Jmabel, you're correct, of course. I certainly did have that backwards. I've struck out the offending remark. But I stand by my claim that these videos are derivative, and incorporate plenty of content that belongs to the WMF and to other Wikipedians, and all content demands attribution by their applicable, existing CC licenses. Elizium23 (talk) 05:28, 24 June 2024 (UTC)
- Hi @Elizium23: thanks for bringing this to my attention. It looks like I have completely misunderstood how licensing works for instructional videos. I'll reach out the WMF team members I've been talking with about this project, and I'll amend the licenses asap. Jimmyjrg (talk) 00:01, 25 June 2024 (UTC)
- @Jmabel, you're correct, of course. I certainly did have that backwards. I've struck out the offending remark. But I stand by my claim that these videos are derivative, and incorporate plenty of content that belongs to the WMF and to other Wikipedians, and all content demands attribution by their applicable, existing CC licenses. Elizium23 (talk) 05:28, 24 June 2024 (UTC)
- @Elizium23: I'm not sure what you are saying here. I haven't looked at the videos. Insofar as the videos incorporate (without licensing) images that are not public domain the licenses need to be indicated, but a video can incorporate public domain content to whatever degree its creator wishes. That is the nature of public domain (although a few countries recognize "moral rights" independent of copyright that require giving credit for some public-domain content). Public-domain status is not "viral". I could make a video that consisted of juxtaposing a series of 100 public-domain images each shown for one second; my video would certainly be eligible for copyright, even though no one image in the video is copyrightable. In other words, to paraphrase but reverse you: PD status of images in a video does not override a copyright claim for the video as a whole. - Jmabel ! talk 05:22, 24 June 2024 (UTC)
- @Koavf I uploaded webm videos, but on the Commons file under 'Transcode status' there are links to mp4 files to stream or download. These are the ones I have found have no sound. Jimmyjrg (talk) 23:56, 24 June 2024 (UTC)
- looks like https://phabricator.wikimedia.org/T358342 . RZuo (talk) 13:32, 25 June 2024 (UTC)
- Thanks. It looks like the mp4 files aren't meant to have sound: https://phabricator.wikimedia.org/T368333 It's not at all clear to users, but apparently everything works as designed. Jimmyjrg (talk) 00:05, 26 June 2024 (UTC)
- looks like https://phabricator.wikimedia.org/T358342 . RZuo (talk) 13:32, 25 June 2024 (UTC)
Why are we doing this? (Reasons why WMC is useful)
In the context of discussions relating to Commons:Media knowledge beyond Wikipedia I created an initial version of a list of reasons why Wikimedia Commons is useful or ways it could be used for. You're invited to participate at Commons:Why Wikimedia Commons is useful and add any usecases/reasons that are currently not on the page.
Adding more concrete illustrative examples or barriers usefulness-types would also be helpful. I think such a list could make WMC more useful than it already is, communicate the value of it to relevant people (e.g. people considering freeing their collections or contributing), and raise awareness/activities of users that eventually raise WMC's value and our work here to the world. Things can also be discussed on its talk page. Prototyperspective (talk) 14:26, 24 June 2024 (UTC)
- It has grown a lot recently and probably needs subsections now. Maybe another place would be better to ask about this. I think identifying and improving upon reasons for usefulness is pretty important so it would be best if more users contributed to the list. Prototyperspective (talk) 10:09, 28 June 2024 (UTC)
- @Prototyperspective: I'm not exactly sure where to put it on your list or if it's already been covered, but I've been using galleries to create catalogs of postcards by particular publishers. For instance Postcards published by Edward H. Mitchell. I think this might be the only website doing anything like that. As well the only one where it would even be fusible due to it being a repository of media from a large number of multiple sources across the globe. I guess there's similar things on here like galleries of stamps, but I think the ones for postcard publishers are fairly novel. Logos of postcard publishers is a similar project. It's possibly the biggest gallery of logos for postcard publishers in the world and I'm sure it couldn't have been created anywhere else. --Adamant1 (talk) 11:19, 28 June 2024 (UTC)
- I think it's covered mostly by "Central repository of collaboratively organized structured media" and also "Enabling finding lots of or highly specific media". In general the subject is how what people are doing or making available is useful, not that itself (as in aggregation and organization).
- So one would have to think about and specify how such galleries/catalogs may be useful to users (that could be entertainment, research, educational purposes, and so on)...e.g. this is not about unique valuable things available or enabled by WMC but how (why) these are useful. The usefulness of the two mentioned ways is elaborated next to these points and probably still needs further expansion, these are not as clear/specific as many of the other cases such as "Finding media for illustrating a given Wikipedia article". Prototyperspective (talk) 11:33, 28 June 2024 (UTC)
- Uuuhhh...OK. That makes sense. Sounds like it could be elaborated and expanded. --Adamant1 (talk) 11:36, 28 June 2024 (UTC)
- @Prototyperspective: I'm not exactly sure where to put it on your list or if it's already been covered, but I've been using galleries to create catalogs of postcards by particular publishers. For instance Postcards published by Edward H. Mitchell. I think this might be the only website doing anything like that. As well the only one where it would even be fusible due to it being a repository of media from a large number of multiple sources across the globe. I guess there's similar things on here like galleries of stamps, but I think the ones for postcard publishers are fairly novel. Logos of postcard publishers is a similar project. It's possibly the biggest gallery of logos for postcard publishers in the world and I'm sure it couldn't have been created anywhere else. --Adamant1 (talk) 11:19, 28 June 2024 (UTC)
A new research report on Cross-wiki uploads have been published
Hello all! I'm happy to announce the publication of the UX research report called "Cross-Wiki Uploads on En and Ar Wikipedias". The research, conducted in collaboration with the Structured Content team, was aimed at understanding how users were interacting with the Visual Editor upload tool. We hypothesized that the UI may contribute to users uploading files as "own work" when the work is not theirs. What we found is, indeed, users are erroneously uploading files as "own work".
Some of the findings of the report are:
- 14 of 16 users interviewed from English and Arabic wikis uploaded others work as their own, and only a few of those files had been moderated. So the problem is much larger than documented.
- This is partly because users interpret "own work" differently, so many believe they have the authority to upload when, according to copyright rules, they do not. This is also because the UI does not present alternative options in a way that users understand (the text on the UI is very confusing to them).
- There is widespread confusion about what is/isn't allowed to be uploaded, what constitutes copyright, who holds the copyright, and how does that relate to Creative Commons licenses. The image policy is not accessible or known to users.
- Interestingly, we found that most uploaders were either marketers (editing/uploading on behalf of another entity such as their employer), or they were self-promoters (creating pages about themselves, unaware of the "notability" requirement).
See the full report for details, more key findings, and recommendations. Also feel free to comment on it in this thread. Hope this will help in your work! Sannita (WMF) (talk) 14:34, 24 June 2024 (UTC)
- @Sannita (WMF) a good research! It is timely, considering that I opened a similar issue regarding some problematic cross-wiki uploads (also through the regular VP forum, I think it is still here – not archived as of this posted comment).
- Some two thoughts of mine. Re: "The 'upload page on Wikipedia' statement is the most confusing of all," I think it is due to the general public perception that both Wikipedia and Wikimedia Commons are same, as a single platform for educational content, even if both are different websites that happened to be under the umbrella of Wikimedia Foundation. No matter how we try to educate people about the differences in policies and scopes of the two websites, a layman will still treat both as identical; or, as one website. Even the anti-Wikipedia group ADAGP who opposes FoP does not use "Wikimedia Commons" in their presentation to the EU Parliament in 2015; they used "Wikipedia" instead. Perhaps the upload forms should use understandable, layman's language.
- Re: "Participants don't know what to do with files that are not their own creation," I guess a massive copyright education campaign is needed. Explanations should not use excessive legalese or technical terms. For Wikimedia groups and affiliates, reforms to copyright laws must be pushed to simplify things. Much of the complexity of copyright for an average layman is due to the complex copyright laws. JWilz12345 (Talk|Contrib's.) 16:42, 24 June 2024 (UTC)
- 10 out of 11 English users were promotional - 5 self-promotion and 5 marketing. Only one of those 10 was notable enough to be in scope, and even then it appears there were copyright issues. The problem here is not the UI; the problem is that the entire cross-wiki upload system makes it much easier for spammers without providing much benefit to anyone else. At minimum, cross-wiki upload needs to be turned off from the User: and Draft: namespaces (where most of the spam comes from). Pi.1415926535 (talk) 18:52, 24 June 2024 (UTC)
- I would also say before investing much time and therefore money in improvements for the cross-wiki upload we should discuss if we want to give cross-wiki upload a chance or if we want to block it entirely to not approved (autopatrol or similar on other wikis) accounts. GPSLeo (talk) 18:59, 24 June 2024 (UTC)
- Second in motion to @GPSLeo's suggestion. Cross-wiki uploading had good intentions, but is easily abused. Perhaps only allow cross-wiki uploading to users who are among one of these user groups: admins/sysops, license reviewers, and autopatrolled users. Cross-wiki feature should be treated as a right with burden of responsibility to the uploader. I'm not in favor of axing out the feature entirely. JWilz12345 (Talk|Contrib's.) 02:44, 25 June 2024 (UTC)
- @JWilz12345: How would that work with people having different privileges depending on the site? --Adamant1 (talk) 02:46, 25 June 2024 (UTC)
- @Adamant1 Commons user rights will be the basis for it. Users should have familiarity on Commons policies and project scope. Their uploads should comply our house rules. JWilz12345 (Talk|Contrib's.) 02:54, 25 June 2024 (UTC)
- @JWilz12345: How would that work with people having different privileges depending on the site? --Adamant1 (talk) 02:46, 25 June 2024 (UTC)
- Second in motion to @GPSLeo's suggestion. Cross-wiki uploading had good intentions, but is easily abused. Perhaps only allow cross-wiki uploading to users who are among one of these user groups: admins/sysops, license reviewers, and autopatrolled users. Cross-wiki feature should be treated as a right with burden of responsibility to the uploader. I'm not in favor of axing out the feature entirely. JWilz12345 (Talk|Contrib's.) 02:44, 25 June 2024 (UTC)
- We really, really need some process and tools such that, when files are cross-wiki uploaded and don't remain on the page they were uploaded for (e.g. because the edit adding them was reverted, the page was deleted, or the user never completed an edit adding the image), those files can be identified and deleted from Commons with a minimum of hassle. Right now, there's no good way to spot those images, and deleting them will usually require a DR. That's a lot of overhead to get rid of a file which the uploader may not have ever expected to persist on Commons. Omphalographer (talk) 19:11, 24 June 2024 (UTC)
- @Omphalographer sometimes DRs aren't needed at all. Speedy deletion tag is the key, if evidences gathered from Google Lens and TinEye searches are convincing. JWilz12345 (Talk|Contrib's.) 02:51, 25 June 2024 (UTC)
- For images which are copyvios, sure. But that's an orthogonal concern. Omphalographer (talk) 03:33, 25 June 2024 (UTC)
- @Omphalographer: there is something like that but it is currently limited to only en-wiki rejected drafts: https://heber.toolforge.org/drafts/filter/20240624. MKFI (talk) 07:39, 25 June 2024 (UTC)
- The problem isn't the process, the problem is the backlog of likely millions of files that violate existing, sensible policy (no copyvios, no unusable personal photos) scattered around the project. Identifying these and checking for prior usage/checking user contribs takes time. Gnomingstuff (talk) 05:27, 26 June 2024 (UTC)
- For images which are copyvios, sure. But that's an orthogonal concern. Omphalographer (talk) 03:33, 25 June 2024 (UTC)
- @Omphalographer sometimes DRs aren't needed at all. Speedy deletion tag is the key, if evidences gathered from Google Lens and TinEye searches are convincing. JWilz12345 (Talk|Contrib's.) 02:51, 25 June 2024 (UTC)
- cross-wiki upload should probably just be blocked outright at this point. As it's clearly an issue that has no easy, implementable, solution. At least not in the short-term. IMO there really needs to be a more clear separation between the projects for something like cross-wiki uploading to work. It's never going to "fixed" if everyone using it just thinks Commons is a glorified subdomain of Wikipedia though. --Adamant1 (talk) 22:28, 24 June 2024 (UTC)
- Agreed. Would also solve almost every problem mentioned in this thread at once. ReneeWrites (talk) 19:20, 26 June 2024 (UTC)
- I would also say before investing much time and therefore money in improvements for the cross-wiki upload we should discuss if we want to give cross-wiki upload a chance or if we want to block it entirely to not approved (autopatrol or similar on other wikis) accounts. GPSLeo (talk) 18:59, 24 June 2024 (UTC)
- 10 out of 11 English users were promotional - 5 self-promotion and 5 marketing. Only one of those 10 was notable enough to be in scope, and even then it appears there were copyright issues. The problem here is not the UI; the problem is that the entire cross-wiki upload system makes it much easier for spammers without providing much benefit to anyone else. At minimum, cross-wiki upload needs to be turned off from the User: and Draft: namespaces (where most of the spam comes from). Pi.1415926535 (talk) 18:52, 24 June 2024 (UTC)
- Just about the logo question: maybe the study sees this too much from a Commons' perspective, despite studying English Wikipedia and people contributing to articles there: personally, I think the default recommendation should be to upload a logo for "fair use" directly at enwiki. Enhancing999 (talk) 22:46, 24 June 2024 (UTC)
- Yup. Possibly combined with a "logo" branch in a Wizard that tries to work out what is the relevant country, then describes the relevant threshold of originality and asks whether it is clearly above (keep it local), clearly below (go to Commons) or just plain unclear (keep it local, which is safer). Also, logo + "own work" is almost always wrong, though of course it is very occasionally correct. - Jmabel ! talk 23:08, 24 June 2024 (UTC)
- Of course, some Wikipedias don't allow "local"… - Jmabel ! talk 23:09, 24 June 2024 (UTC)
- It doesn't seem like English Wikipedia wants to host images of logos going by the number we have, but that would be the better solution. Although it would then screw over the ability of other projects to use the files in a lot of cases. So maybe it's not the best way to go about this. --Adamant1 (talk) 23:16, 24 June 2024 (UTC)
- en-wiki routinely hosts logos that are over the threshold of originality, if they have an article about the organization in question. - Jmabel ! talk 23:29, 24 June 2024 (UTC)
- Sure, I was mainly saying it in jest, but we do host a lot of logos that have been sent over from Wikipedia for one reason or another. --Adamant1 (talk) 09:11, 26 June 2024 (UTC)
- en-wiki routinely hosts logos that are over the threshold of originality, if they have an article about the organization in question. - Jmabel ! talk 23:29, 24 June 2024 (UTC)
- It doesn't seem like English Wikipedia wants to host images of logos going by the number we have, but that would be the better solution. Although it would then screw over the ability of other projects to use the files in a lot of cases. So maybe it's not the best way to go about this. --Adamant1 (talk) 23:16, 24 June 2024 (UTC)
- About the "personal images": not sure how the study gets to that conclusion of it being a big issue. If in a sample group people were writing autobiographies about their not-Wikipedia notable selves, why should they consider that their image isn't suitable to be uploaded despite serving as an illustration to the article? If the article actually exists, the image can be uploaded. Also, the subject of an article is the most likely person to have access to correctly licensed or licensable images. Obviously "personal images" can be an issue at Commons, but this may be unrelated to enwiki articles. - Enhancing999 (talk) 09:30, 25 June 2024 (UTC)
- @Enhancing999 may be because images that show the uploaders themselves are only falling within the house rules of Commons, if they serve real purpose like Wikimedia-related activities, uses on user pages in all wiki sites, and in an article (if the article survives the review process of other editors). Assuming an image does not have the purpose of documenting Wikimedia-related events, and it is not used on a userspace page, and it is being used in an article on English Wikipedia. The article is then slapped with AfD request. The article is found to not comply with w:en:WP:GNG (especially on BLP house rules there) and is "sentenced to death". With the article deleted, the image then becomes an "out of scope image" or "unused personal image". JWilz12345 (Talk|Contrib's.) 12:15, 25 June 2024 (UTC)
- Where is that in the study? Enhancing999 (talk) 05:33, 26 June 2024 (UTC)
- @Enhancing999 may be because images that show the uploaders themselves are only falling within the house rules of Commons, if they serve real purpose like Wikimedia-related activities, uses on user pages in all wiki sites, and in an article (if the article survives the review process of other editors). Assuming an image does not have the purpose of documenting Wikimedia-related events, and it is not used on a userspace page, and it is being used in an article on English Wikipedia. The article is then slapped with AfD request. The article is found to not comply with w:en:WP:GNG (especially on BLP house rules there) and is "sentenced to death". With the article deleted, the image then becomes an "out of scope image" or "unused personal image". JWilz12345 (Talk|Contrib's.) 12:15, 25 June 2024 (UTC)
- Comment I hate to have a hot take here, but this (and the whole thing with using AI to identify logos) assumes uploading COPYVIO is even a problem to begin with. It's not like we can't (or don't) delete copyrighted images pretty regularly. Maybe it's secondary to the core principles of Commons, but doing so has the benefit of being able to document artists and dates works become PD. There's as much value in that IMO then automating to the point of stopping people from uploading COPYVIO or really anything because they are so turned off by the warnings. Regardless, we are here to document, preserve, and "maintain" a media repository. Which inherently to some degree depends on people uploading COPYVIO once in a while (if not regularly). The important thing, and I'd argue the current issue that things like this are getting at, is that we should be able to deal with it in a timely manor. Not that it shouldn't exist in the first place. --Adamant1 (talk) 06:05, 26 June 2024 (UTC)
- I get what you're saying, but we're very much at "regularly" and arguably at "frequently." The copyvios that are uploaded, and certainly the ones talked about this thread, are usually recent enough that they won't enter public domain within any of our lifetimes. Gnomingstuff (talk) 18:58, 26 June 2024 (UTC)
MIDI file transcoding
Hi, I've uploaded some MIDI files of chords to Commons (e.g. File:3-4A set class on C.mid) which I need for en:List of set classes, and I gather that eventually Ogg and MP3 audio files are generated. How long do I have to wait? Or, is there some arcane incantation I need to perform that I've missed? Or do I need to add it to a queue somewhere? Is there some documentation somewhere that I can read about it if so? I have so far not found anything. — Jonathanischoice (talk) 22:06, 24 June 2024 (UTC)
Electrical equipment in the background
.jpg/220px-Seattle_City_Light_communications_staff%2c_circa_1960_(53799326997).jpg)
Can anyone say what is the equipment in the background here? I'd like to add further description and appropriate categories. - Jmabel ! talk 23:32, 24 June 2024 (UTC)
- Looks like step by step switches used in a telephone switching network. Take a pair of telephone wires and connect them to any of 100 points (2 digits of a telephone number). One of my professors joked that it was invented by Herman B. Stepbystep. Strowger switch. https://www.youtube.com/watch?v=xZePwin92cI Glrx (talk) 00:28, 25 June 2024 (UTC)
- @Glrx: Yeah, that's a bit like what it looked to me as well, though you have a much more closely matching example. If it's correct, it raises a question of what two Seattle City Light employees were doing posing in front of telephony equipment, rather than equipment involved in the generation of transmission of electricity. But if we can be confident that is the case, I guess we don't have to solve the "why". - Jmabel ! talk 05:01, 25 June 2024 (UTC)
June 25
Unable to use CropTool
I'm unable to use CropTool at File:1983. Febrero, 22. Recibimiento del cardenal José Alí Lebrún.jpg. When clicking directly from the toolbar, I'm directed to CropTool's main page, being asked to enter the file's URL or name, after which I'm confirmed that the file exists but I'm not able to crop it. The tool works perfectly in any other file I have found.
Is it possible this is because its license needs to be reviewed first? Many thanks in advance, --NoonIcarus (talk) 00:30, 25 June 2024 (UTC)
- That appears to be the case. I'm unable to crop any of the files in Category:License review needed. ReneeWrites (talk) 17:46, 25 June 2024 (UTC)
- @NoonIcarus and ReneeWrites: That looks to be the case. I have reviewed the image now, so feel free to give it another go. — billinghurst sDrewth 11:35, 26 June 2024 (UTC)
- @Billinghurst: I was able to crop the image now, thank you! --NoonIcarus (talk) 17:29, 26 June 2024 (UTC)
- @NoonIcarus and ReneeWrites: That looks to be the case. I have reviewed the image now, so feel free to give it another go. — billinghurst sDrewth 11:35, 26 June 2024 (UTC)
Voting to ratify the Wikimedia Movement Charter is now open – cast your vote
- You can find this message translated into additional languages on Meta-wiki. Please help translate to your language
Hello everyone,
The voting to ratify the Wikimedia Movement Charter is now open. The Wikimedia Movement Charter is a document to define roles and responsibilities for all the members and entities of the Wikimedia movement, including the creation of a new body – the Global Council – for movement governance.
The final version of the Wikimedia Movement Charter is available on Meta in different languages and attached here in PDF format for your reading.
Voting commenced on SecurePoll on June 25, 2024 at 00:01 UTC and will conclude on July 9, 2024 at 23:59 UTC. Please read more on the voter information and eligibility details.
After reading the Charter, please vote here and share this note further.
If you have any questions about the ratification vote, please contact the Charter Electoral Commission at cec@wikimedia.org.
On behalf of the CEC,
RamzyM (WMF) 10:51, 25 June 2024 (UTC)
Notification of DMCA takedown demand — President Joe Biden swearing in ceremony
In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the Wikimedia Foundation office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me.
The takedown can be read here.
Affected file(s):
- File:President Joe Biden swearing in ceremony 2.jpg (edit|talk|history|links|watch|logs)
- File:President Joe Biden swearing in ceremony 2 (cropped).jpg (edit|talk|history|links|watch|logs)
- File:President Joe Biden swearing in ceremony 2 (cropped 2).jpg (edit|talk|history|links|watch|logs)
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=edit){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=history){kind=link}
.jpg&limit=999){kind=link}
.jpg&action=watch){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=edit){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=history){kind=link}
.jpg&limit=999){kind=link}
.jpg&action=watch){kind=link}
To discuss this DMCA takedown, please go to COM:DMCA#President Joe Biden swearing in ceremony. Thank you! Joe Sutherland (WMF) (talk) 19:39, 25 June 2024 (UTC)
June 26
Example of SVG with hyperlinks
Hey, can anyone give me an example of an SVG with hyperlinks in so that I can check the syntax? Thanks. — Scott • talk 10:37, 26 June 2024 (UTC)
- File:SVG Gradient.svg has a
useelement. - SVG 1.1 uses
xlink:href. WMF uses an SVG 1.1 rasterizer, so SVG elements such asusemust employ thexlinknamespace. - SVG 2.0 allows either
xlink:hreforhref. Most browsers are compliant with SVG 2.0, so viewing the SVG directly in a browser will work with either form. - Glrx (talk) 15:39, 27 June 2024 (UTC)
Engravings and Lithographs etc.
We have a gigantic epidemic of people overwriting existing Engravings and Lithographic images with different versions of the same image. Also, the same for cropping off captions and border, without creating new files.
18th and 19th century Lithographs and engravings are all unique, even if they come from the same book and edition, they are different, in terms of condition, printing, edition source, and hand painting, and they should not be overwritten by anything other than the exact same print, from the same book, from the same museum or owner.
Lately, I try and protect them with Template:Border is intentional, but I'm overwhelmed at the amount of damage done. It's a losing battle.
These images need the artwork template and we need to some means of ensuring that files are not overwritten with similar, but different images. Are there other templates that can be used.
Can we put in bot measures to protect them, from these oafs? It's bad enough with these people omitting descriptive detail, using dubious sources (that steal images from elsewhere in the net), and claim false ownership. Not to mention all the AI crap, that’s, no doubt on its way.
What extra measures can we employ? Broichmore (talk) 14:54, 26 June 2024 (UTC)
Which template should be preferred?
- {{COUNTRYNAME photographs taken on navbox}} (like {{Brazil photographs taken on navbox}}, for instance)
- {{Country photographs taken on}}
- {{World photos}}
RodRabelo7 (talk) 18:15, 26 June 2024 (UTC)
- {{World photos}} seems to be the most elegant/easy to use because it doesn't require the user to fill in any parameters. So that one gets my vote, so to speak. ReneeWrites (talk) 10:52, 27 June 2024 (UTC)
"Stained glass" versus "stained-glass"
It seems like the usage of a hyphen for categories having to do with images of stained glass is all over the place. The main category and Wikidata are named without a hyphen but then it seems to quickly break down from there with a good portion of sub-categories using one. Personally I prefer no hyphen, but there seems to be a consensus at least in how many use it versus don't that it's the preferred way of naming things. Anyone have a preference or know which is better? Adamant1 (talk) 22:26, 26 June 2024 (UTC)
- "stained glass" as a noun, "stained-glass" as an adjective (e.g. "stained-glass window"). We had this discussion a few years ago, and that consensus was pretty clear. - Jmabel ! talk 04:45, 27 June 2024 (UTC)
- @Jmabel: So just to be clear the consensus is for there to be no hyphen then? --Adamant1 (talk) 01:33, 29 June 2024 (UTC)
June 27
GLAM uploads
Are GLAM uploads always once off? Or does Wiki commons have functionality to allow synching of a GLAM database?
Automated interfaces tend to have functionality -
- At Origin : a trigger job waiting for a change,
- Data cleansing - rules, error handling
- Trigger for transmission - every week, every n records..
- Mapping- a mapping tool of Origin to Target, reuse of maps from the same system, mapping version, envelopes with sequence numbers
- Transmission - path, passwords, encryption, confirmation of receipt, checksums
- At Target - transmission triggers upload into target, error checking
- Error checking that database matches
(Asked a similar question about wiki data with no answer) Wakelamp (talk) 06:06, 27 June 2024 (UTC)
- Most likely it depends on uploader and tool used as most GLAM databases are different in terms of content, interfaces etc. Afaik most uploads are made by custom scripts and and solutions are made in upload tool level. Wiki commons itself doesn't have functionality to sync with external GLAM repositories. --Zache (talk) 18:56, 27 June 2024 (UTC)
- Repeated uploads from the same GLAM are quite common. Synching is actually a bit trickier than you might think. I have some experience with this from the point of view of curating the content brought in from a GLAM by a bot. I'll try to get back here and share my thoughts in that in a day or two if no one else has something solid. @Wakelamp, feel free to hit my up if this slips my mind. - Jmabel ! talk 23:50, 27 June 2024 (UTC)
June 28
YouTube has stopped displaying CC lincenses
I have just found today that YouTube changed the page layout and CC lincenses are no longer being displayed. --トトト (talk) 06:42, 28 June 2024 (UTC)
- Uugghh well that sucks. I think I nominated a couple of videos for deletion a few days ago because the link to YouTube didn't say they were CC licensed even though that was the claim. Great. --Adamant1 (talk) 06:48, 28 June 2024 (UTC)
- @トトト: That's curious. When I go to https://www.youtube.com/watch?v=OYCjGfQJ4kw (a video I happen to have uploaded a screenshot from) and click "...more" at the end of the description, the expanded description still contains "Licence Creative Commons Attribution licence (reuse allowed)". Does it appear on that video for you? Have you got a different example where it doesn't? --bjh21 (talk) 09:53, 28 June 2024 (UTC)
- What do you mean? I still see the license just like before at the bottom of the video description next to License and one can search for videos with that license using filters.
- On a related note, sometimes I think youtube deboosts videos with CC-licenses (maybe because they aren't monetized as much) but nobody knows since the algorithms are not transparent. If that's the case, it discourages users to license their videos this way and I think some articles on this suggest first uploading nonCCBY videos to first get popular before licensing any under CCBY. Please let me know if anybody has any sources/info on this. Prototyperspective (talk) 09:54, 28 June 2024 (UTC)
- I clicked on a video from Commons a while ago that was supposedly CC Licensed and nothing showed uo for me. Maybe its a bug on their end or I just missed it though. --Adamant1 (talk) 10:01, 28 June 2024 (UTC)
- Sometimes the license gets changed. CC-licensing can't be revoked but there are many cases where removal of that license should mean the video also needs to be deleted here...for example the video may contain nonCCBY clips that the uploader only became aware of later or the account was under control of somebody else. When uploading with V2C, there is an link to the archived site so one can check if it was CCBY at time of uploads and its adds a License review needed template so a user checks the current video (people don't seem to be doing this anymore). Prototyperspective (talk) 10:06, 28 June 2024 (UTC)
- Yes, it annoys me a lot... But it depends on if you're logged in afaik. Anyway, you can retrieve the CC-BY note by looking into the website source code and by searching for "Creative Commons". This is where V2C gets his information from. It sucks and I assume there will be several deletion requests because of this misunderstanding --PantheraLeo1359531 😺 (talk) 18:24, 28 June 2024 (UTC)
- Sometimes the license gets changed. CC-licensing can't be revoked but there are many cases where removal of that license should mean the video also needs to be deleted here...for example the video may contain nonCCBY clips that the uploader only became aware of later or the account was under control of somebody else. When uploading with V2C, there is an link to the archived site so one can check if it was CCBY at time of uploads and its adds a License review needed template so a user checks the current video (people don't seem to be doing this anymore). Prototyperspective (talk) 10:06, 28 June 2024 (UTC)
- I clicked on a video from Commons a while ago that was supposedly CC Licensed and nothing showed uo for me. Maybe its a bug on their end or I just missed it though. --Adamant1 (talk) 10:01, 28 June 2024 (UTC)
New York Public Library
Does anyone know what accession number we should be using for items from the Collections of the New York Public Library? -Broichmore (talk) 11:06, 28 June 2024 (UTC)
- FWIW, just for one example, https://digitalcollections.nypl.org/items/225503f5-ae89-40e1-91e3-2f8cf6cc8297 gives three identifiers: RLIN/OCLC, NYPL catalog ID (B-number); and a UUID.
- Our own File:Great Falls of the Potomac, from Robert N. Dennis collection of stereoscopic views.jpg gives three identifiers, but they don't seem to correspond to these in an obvious way: Catalog Call Number (which is clearly not a "B-number"), Record ID, and Digital ID.
- https://archives.nypl.org/mus/24078#c1553136 gives IDs like "b. 164 f. 25" and "b. 110 f. 9-10"; it would not surprise me, though, if those were strictly IDs within the Lou Reed papers, and not in the NYPL collection as a whole, especially given the low numbers.
- Looking at this, I'd be surprised if they have a single system that spans their entire archive.
- @Broichmore: Have you considered contacting NYPL to see if they have a suggestion as to what we might use? - Jmabel ! talk 20:28, 28 June 2024 (UTC)
- No, I haven't contacted them, as yet.
- I suspect, that like the Library of Congress (LOC), this was one of the first GLAMs uploaded en-masse, consequently, it varies in the templates employed. So far, I've discovered that the accession number might be the NYPL catalog ID (B-number), think that's their shelf number.
- There is a source template, I stumbled on, based on the image ID. Also a default sort based on that NYPL catalog ID (B-number) again. See image for an example. - Broichmore (talk) 21:18, 28 June 2024 (UTC)
Finding my own "published" content
Is there any way to do a sane query for files that I've uploaded (and/or for files where my account name occurs as part of the wikisource text on the file page) and where the {{Published}} template is on the talk page? - Jmabel ! talk 20:17, 28 June 2024 (UTC)
Community Wishlist Survey is now Community Wishlist
Thank you everyone who has participated in the restructuring and rebranding conversations of the Wishlist so far.
Regarding the renaming, based on your feedback, we will keep the 'Community Wishlist' and remove 'Survey'.
Please read more about the renaming, check out the vote results and learn more about the re-opening of the Community Wishlist on July 15, 2024, in our latest update. –– STei (WMF) (talk) 20:20, 28 June 2024 (UTC)
License template request: AGPLv3 only
Could someone create the license template Template:AGPLv3 only? We currently only have Template:AGPL, and that's not acceptable for files that don't use the "or any later version" clause.
We already have Template:GPLv3 only, which makes this distinguishment for Template:GPLv3.
I'd create the template myself, as I need to upload a an AGPLv3-only file, but I have no experience with template creation (or even mimicking in this case; inspecting the source didn't help me much).
It also occurred to me that there might be some files incorrectly marked as AGPL, since the correct license tag doesn't exist and apparently never has, so the logical step for the lazy is to just use the AGPL template and be done with your upload (which I'll also do, though I'll change the license to the correct one once someone creates the template). --Veikk0.ma (talk) 23:58, 28 June 2024 (UTC)
- Dunno if this helps, but the Wikidata ID for AGPLv3 (ie. AGPLv3 only) is GNU Affero General Public License, version 3.0 (Q27017232) and AGPLv3 (containing the "any later version" clause) is GNU Affero General Public License, version 3.0 or later (Q27020062). --Veikk0.ma (talk) 00:09, 29 June 2024 (UTC)