This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Hi, is there any way to determine usage of images/files from one category in global Wikimedia projects? I know when you click individual file it will show you for that single file, but if there a way to know for all files in one category will be nice. I want to make graphical stats for one of the contest. ̴Kushared (talk) 06:25, 1 August 2023 (UTC)
This is my first post so please suggest a different posting format, location, etc if needed.
Situation: I'd like to post photos to both Wikimedia Commons and Unsplash.
Current understanding: I know the licenses are different and the Unsplash license is not compatible with the Creative Commons license used by Wikimedia. I can't post a photo to Unsplash and then post it to Wikimedia.
Question: Can I post a photo to Wikimedia first, then post it to Unsplash?
More thoughts: Since the Creative Commons license is irrevocable, I thought this might be acceptable, and I wouldn't have to update the photo on Wikimedia. I've found information stating I can't post Unsplash licensed photos on Wikimedia, but I haven't found information on the reverse. If there's already a thread, please let me know. — Preceding unsigned comment added by Matt.burke.images (talk • contribs)
@Matt.burke.images: If this concerns your own images, you are free to do what you want with them after you upload them to Commons. So you can upload them to Unsplash, or any other websites. Yann (talk) 16:40, 1 August 2023 (UTC)
To my understanding you could also do it the other way around, it just might raise questions. But as long as you can prove that you took the image yourself and did not steal it from Unsplash, all should be fine. Kritzolina (talk) 17:07, 1 August 2023 (UTC)
@Matt.burke.images: The Creative Commons licenses are "non-exclusive". If you are the owner of the full copyright of some photos, you can publish them under as many non-exclusive licenses as you want at every places you want. If you however publish an image under an exclusive license you cannot. --C.Suthorn (@Life_is@no-pony.farm) (talk) 17:11, 1 August 2023 (UTC)
@Matt.burke.images: As a matter of practical advice, it is best to start off by uploading a decent number (say, 10+) of images at full resolution with EXIF to Commons only. This will help establish your reputation as a trustworthy uploader. Afterwards, you can upload your photos to Unsplash either before or after Commons, it doesn't matter; people will see from the EXIF that it was taken with the same camera as your Commons-only uploads. It would also help to use an Unsplash username that is similar to your Wikimedia username to help others see the link more clearly. -- King of ♥ ♦ ♣ ♠17:29, 1 August 2023 (UTC)
Or you can simply indicate your Commons account name on your user page on Unsplash. Once you do that, you can do it in whichever order, since anyone can look at Unsplash and verify that both accounts are the same person. - Jmabel ! talk17:50, 1 August 2023 (UTC)
Amount of data in categories
Hi dear community,
I love statistics. And I want to ask if there is a tool that shows you how many megabytes/gigabytes all files in a category (or including subcategories) have? Thank you! --PantheraLeo1359531 😺 (talk) 12:01, 3 August 2023 (UTC)
@Wasiul Bahar: . Install VisualFileChange. Then go to that user's uploads (e.g. Special:ListFiles/Wasiul_Bahar) and use VisualFileChange to append the relevant category to all files; don't forget to put a newline before the new category. (There are other ways to get it in there if you don't want it to be the last category, but those are trickier.) - Jmabel ! talk15:24, 5 August 2023 (UTC)
Hi, This category is a honeypot for catching vanity uploads and copyright violations. I already nominated some files, but all files need a careful check. More eyes needed. Thanks, Yann (talk) 19:47, 1 August 2023 (UTC)
I don't see how this category could be useful. Should we delete it, irrespective of which photos are deleted or kept? -- Ikan Kekek (talk) 23:20, 4 August 2023 (UTC)
+3. It's kind of tangential, but if it were me I'd probably delete Category:Musicians for the same reason since it seems to be a dumping ground for vanity uploads and copyright violations, a lot of times for people who aren't even musicians to begin with. --Adamant1 (talk) 21:07, 6 August 2023 (UTC)
Category:Musicians appears to serve a necessary structural need with reference to its child categories. It's possible the same is true of Category:Celebrities (though the very notion of "celebrity" is a lot shakier than the notion of "musician"). In either case, please do not get rid of the categories without some sort of consensus via CfD. - Jmabel ! talk22:20, 6 August 2023 (UTC)
Celebrities are just people who are famous for something (some people would say "famous for being famous"). Musicians actually do something in particular, like writers, actors, plumbers, what have you. I suppose there are some people who aren't famous for anything they've done, but most celebrities would be better described as politicians, nobles, actors, musicians, writers, media personalities, heirs to fortunes, etc. - something that describes them for what they do or at least what gave them their fame. -- Ikan Kekek (talk) 04:01, 7 August 2023 (UTC)
Sure, I guess. Not in any way that is actually represented in the images that are in the category though. People are musicians because they play an instrument, sing, spin records, Etc Etc. Those things are what is actually being shown with the images and what the cateogry is about IMO. And if someone who thinks they are a musician and wants to upload an image of themselves playing a bag pipe and put it in an actual category for bag pipe players, cool. But Category:musicians just invites randos who want to be musicians as a vanity uploading images of themselves standing next to a tree while not actually doing anything related to playing music just so they can use Commons as an advertising platform. And acting that its at all anologous to plumbers is a ridiculous straw man. No one is mass uploading copyrighted out of scope vanity shots of themselves to advertise their local plumbing business. Same goes for the comparison to writers and actors BTW. Writing and acting are actual things that people do and that's there's picture of them doing. No one "musicians." --Adamant1 (talk) 04:41, 7 August 2023 (UTC)
You're talking to a professional musician, and I have no idea what you think you're saying in your last sentence, but it's ungrammatical. Musicians make music in some kind of way, as you stated earlier. There is no fail-safe way to get unknown or little-known people to stop uploading photos in order to promote themselves, and getting rid of legitimate categories certainly won't have that effect. Such photos have to continue to be nominated for deletion. -- Ikan Kekek (talk) 08:45, 7 August 2023 (UTC)
General Comment: It is quite difficult to separate professional from amateur musicians. I know some people who get some money for playing during Saturday balfolks. Are they professionals or amateurs? Yann (talk) 09:19, 7 August 2023 (UTC)
Professionals are paid for our services, even if we may also sometimes play jams or benefit concerts that we don't get paid for. "Amateur" literally means someone who loves what they do (similarly, "dilettante" literally means someone who delights in something), so in that sense, all musicians should be amateur, but the standard meaning now is that amateurs play music for fun, rather than for money. I think your point is that you often can't tell who is what just by looking at a photo. Which is probably true of pretty much any kind of occupation that could be a hobby. -- Ikan Kekek (talk) 15:43, 7 August 2023 (UTC)
How do you prove that a file was released under the creative commons license in the past?
Recently, a user requested speedy deletion of File:Sexyy Red 2023.png, which is a screenshot of a YouTube video. The video was originally uploaded to YouTube under the creative commons license, but the YouTube channel has changed the licensing to be more restrictive. I don't want the file to be deleted, but I don't know how to prove that it was released under the CCL in the past. Can anyone help me with this? Suhaengpyeongga (talk) 13:17, 7 August 2023 (UTC)
This was only uploaded a few weeks ago. It's relatively unlikely thus that either the licence has changed, or that an archiver has happened to record it in the claimed earlier state. It might not be possible to prove this at all.
Given the purpose of the image, it might be simpler to delete it here and to upload it directly to Wikipedia(s), claiming "fair use". See en:WP:NFCC. This is resisted by most Wikipedias, but this would seem a reasonable situation to justify it at present. Andy Dingley (talk) 14:59, 7 August 2023 (UTC)
Error message
See: File:Gunhilde Tekene LCCN2014718688.jpg. In "Structured data" if I try and enter the location where an image was taken, I get the error: "The property location should not be used on this type of entity, the only valid entity type is Wikibase item." Hos should location be entered? --RAN (talk) 15:47, 2 August 2023 (UTC)
Thanks! Most are intuitive, perhaps we can change the error message to read "Use P1071 (location of creation) instead", that would be more helpful. Do you know how to edit error messages? --RAN (talk) 18:38, 2 August 2023 (UTC)
Four Updates on the Private Incident Reporting Project
Hello everyone. Sorry to use English. Please help translate to your language.
For the past couple of months the Trust and Safety Tools team has been working on finalising Phase 1 of the Incident Reporting System project.
The purpose of this phase was to define possible product direction and scope of the project with your feedback. We now have a better understanding of what to do next.
We are renaming the project as Incident Reporting System
We have some feedback from researching some pilot communities to share with you
We have updated the project’s overview
We have the first iteration of the reporting extension ReportIncident
I do a lot of work on postcards. If it were me I'd create both Category:Black and white postcards, Category:Monochrome postcards and the other categories in whichever one is more appropriate. I was actually planning on doing that a while back but never got around to it. There also seems to be some miss-understanding in general about what makes something black and white or monochrome, but that's a discussion for another conversation. Except to say Category:Black and white photographs contains a lot of photographs that aren't actually black and white. --Adamant1 (talk) 21:30, 9 August 2023 (UTC)
Non-FP chosen as POTD
It appears that Grenadin07 has chosen images that are not featured pictures to be COM:POTD on two occasions: Template:Potd/2023-07-09 and Template:Potd/2023-08-11. The first one has already happened, while we are a few minutes into the second one. I can't find any evidence of authorization to run these non-FPs on the main page. For the latter image, what do we do here? Do we quickly try to find a replacement, or do we just say it's too late and allow it to run for today? Either way, we should look at how to prevent non-FPs from being selected as POTD by well-meaning users in the future. -- King of ♥ ♦ ♣ ♠00:15, 11 August 2023 (UTC)
Done.
a) Thanks King of Hearts for noticing and reporting this.
b) I don't think we should leave it as is.
c) I've taken the liberty of the following: taking the POTD of 18 Aug, moving it and all its language templates to today. Therefore, the 18 Aug is vacant again, I hope someone finds an alternative in the next few days.
Just yesterday I found Commons:Overwriting existing files, which says to not upload a new version of a historical photo, overwriting the old one. I understand this. But could someone make it easier to make an "other version" of a file? That is, this would be in addition to "upload a new version of this file". It could copy all of the information from the old file, create a new file, and make "other versions" links, both ways. This sure would make it a lot easier. Bubba73 (talk) 00:00, 6 August 2023 (UTC)
@Bubba73: if you use Special:Upload, you can copy-paste the wikitext from the old photo. The only thing you have to do manually is the "other versions" part. It would, in any case, be hard to fully automate that because there is no magic way to know whether you want {{Other version}} on both, {{Superseded}} / {{Supersedes}}, or any of a few other possible relationships. - Jmabel ! talk04:11, 6 August 2023 (UTC)
I don't see a "special upload" that does what I'm talking about. I'd want it to copy all of the information (description, categories, permissions, etc) for me and do the other version links, automatically. Then I could edit the description as needed. Bubba73 (talk) 01:48, 7 August 2023 (UTC)
That could be automated to save us some work. "Upload a different version of the file" could be under "upload a new version of the file". Bubba73 (talk) 23:24, 7 August 2023 (UTC)
It could be, but I can't say I'd advocate this as a high-priority use of scarce developer time when there is a pretty decent workaround, for a case that is not all that common. But feel free to raise it in the annual process of proposing what tech work we'd want. - 00:16, 8 August 2023 (UTC)
Make a crop of the existing file (preferably just a very small part it it), using crop tool. Upload your version of the file to overwrite the cropped extract, edit description accordingly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits09:57, 8 August 2023 (UTC)
Sorry, I was just trying to help. I estimate that there are 100,000 "other versions" on Commons. I estimate it may take an editor 5 minutes to manually do all of the work to create a new version and do the links. That would be 8,000 hours of work. I estimate that a person familiar with how to add these things to Wiki could do it in 2 hours - saving thousands of hours. Bubba73 (talk) 04:12, 10 August 2023 (UTC)
Without even looking I knew the photo was taken in the 1950s. Its typical of reproduction quality back then. As such its a part of the authenticity of the image, you could argue. Broichmore (talk) 13:46, 14 August 2023 (UTC)
Regarding security of image
I have been adding images from [1] this website of Government of Bihar. Their website policy say that material produced therein are freely usable if properly attributed.[2] However, that's a dynamic website. Actually it contains image of ministers and leaders. And they will change in future. Hence, I am worried that in future, if someone tries to verify that whether the image I put on commons was from that website or not, they won't find it as the website updates after new government is formed and new assembly is elected.-Admantine123 (talk) 18:21, 9 August 2023 (UTC)
PS: Archiving also doesn't work for this website. I tried it earlier, but archived link opens the home page of website and doesn't proove that it was present there. See my recent upload.-Admantine123 (talk) 18:24, 9 August 2023 (UTC)
Tagging Mdaniels5757, other admins please see, can something like accepting the image from that website as a future policy be formulated for that website like we have for Press Information Bureau files.-Admantine123 (talk) 18:33, 9 August 2023 (UTC)
[3], can someone archive this link for me. It contains present council of ministers images. It will be changed after elections in 2025. I want to see whether I am the only person who is facing problem in Archiving it or not.Admantine123 (talk) 18:58, 9 August 2023 (UTC)
Mdaniels5757, this particular sentence is written below every image and material by any of the Government in India's website. The images from these websites are used by others as for example you can see [4] this link. Now the image of minister Sheela Mandal has been taken from here and circulated widespreadly by various media houses[5]. In fact many websites use the material from here.-Admantine123 (talk) 19:12, 9 August 2023 (UTC)
Look at this website [6], here also same sentence is written. But images from here has been used and uploaded in large numbers on Wikimedia commons under GODL-India' licence. A common example is image of Narendra Modi, used in his article, is taken from this website only.Admantine123 (talk) 19:19, 9 August 2023 (UTC)
The only insurance I know of is to archive the webpage source in somenthing like Wayback Machine at the same time you upload the image. Broichmore (talk) 14:08, 14 August 2023 (UTC)
Photoshop being used on mainspace wiki image?
Hi all, in the course of editing on Wikipedia, I came across w:File:De Bruyne and Foden.jpg and immediately smelt a fairly large rat. The image seems oddly lit, and the stadium background looks suspiciously like something from FIFA 23 or EAFC 24, and on closer inspection there is a blurred halo around the two players which doesn’t seem natural, add the oddly empty pitch, and I’m calling bull. I think it might be photoshopped but could someone more experienced take a look in case I’m just slightly delusional? Cheers. REDMAN 2019 (talk) 08:28, 12 August 2023 (UTC)
Seems to be the second half of this match. The odd lighting is just a coincidence of sunlight reaching only the background, leaving the pitch in shades. The photo is most likely (over)edited here and there to make it look prettier, but nothing of the fake-news type of copypasting. --HyperGaruda (talk) 10:17, 12 August 2023 (UTC)
We shouldnt be uploading tripe like this, even the players boots are a joke. This new era of AI, could destroy this project and render it meaningless. Its only copyright law thats so far saved it. Broichmore (talk) 14:27, 14 August 2023 (UTC)
How independent is Commons in deciding which categories are appropriate?
Since 5 years I am a Commons editor. In that time I learned that Commons has its own set of rules and guidelines, also for categories, and that the Commons editors and administrators decide on the basis of those rules, supplemented with their own common sense, which categories should be on Commons and which should be deleted or get a redirect. Having a similar category or article on EN-WP or Wikidata is no reason to have it on Commons as well, and there is no obligation to name a category the same as in the EN-WP or any other Wikimedia project. That all makes sense to me and I happily internalized and implemented this policy.
But now User:Clusternote has a different vision, see Commons:Categories for discussion/2022/12/Category:Production and manufacturing. (S)He claims that Commons should have categories with the same name as in Wikidata and/or EN-WP (and other WP's) to bridge the gap between (1) the self-contained category structure of Commons, and (2) the practical category structures on other Wikimedia projects; this has been done so for several decades. So those categories should be accepted even if Commons editors like me think those categories are useless on Commons and even when they mess up the category structure (like this one: a parent and a subcategory has been included in one combination category as equals). I could not find a Commons rule or guideline confirming this.
There is no guideline on this. If possible we should have a one to one link to Wikidata as this is most convenient for many tools and we have the nice Infobox. But this is only a de facto standard not a written down guideline. GPSLeo (talk) 08:49, 4 August 2023 (UTC)
Commons and Enwiki are independent when it comes to category naming practices. Naturally, because Commons uses English for category names and Enwiki is the biggest Wikipedia, it is logical on first approach to wonder why we don't just line up the categories 1-for-1 and match up the names between the two. Certainly for the vast majority of topics for which both projects maintain categories, they indeed do use the same category name. However, there are several reason why this is not always the case, and why we do not have any policy to try and make it so, with the two primary ones being language and scope:
Commons, while adopting English for category naming, is a multi-lingual project. Enwiki is an exclusively English-language project. As User:Jmabel alludes to above, there are cases where Commons has chosen English phrasing and so forth in the interest of maximizing accessibility for non-English speakers.
Commons has a much larger and deeper category structure than Enwiki in many cases (about 2x overall). Commons routinely categorizes to much more granular level than Enwiki does. This can lead to unveiling needs for more nuanced and developed category standards and conventions than Enwiki may need.
Essentially, since from what I have seen, Commons seems to give more attention to categorization as a fundamental structure than Enwiki does. This makes sense, as the heart of Enwiki navigation is following links from article to article, and of course articles are their main focus. But that doesn't work for image browsing, so categories play a more central role for Commons.
What User:Clusternote is saying, presuming I am reading it correctly, is understandable to want, but it causes a lot of problems on implementation. We do pretty expressly try and avoid redundancy in the category structure (it is big enough just with 1 category per topic, not 2.) Additionally, while it may seem reasonable at first glance, it really serves no purpose. The bridge between Commons categories and categories on Enwiki and all other Wikis (not to mention other sister projects) is Wikidata, and at this point, that aspect of WD is pretty well implemented. Wikidata doesn't require any naming synergy between the linked categories to work perfectly well. In fact, adding redundant categories or extra layers to category structure to try and create synonymous categories actually makes Wikidata linking harder--should a Q be linked to the Commons category that has the matching content or to the one that has the matching name? This is similar to reasoning why we do not maintain categories for each language, the redundancy makes things unmanageable. Josh (talk) 21:00, 4 August 2023 (UTC)
@Joshbaumgartner: I think your efforts is admirable for the improvement of the Commons categories on Economy. However here is not the academic site but the more relaxed site, so we need inclusive attitude for practical issue, in my opinion. Following is long description on this issue:
Your approach seems like a methods called "Entity Analysis" (EA) or "Data-Oriented Analysis" (DOA) in the software development. In these methods, the data to be processed is scrutinized and formally identified in the abstract concept stage preceding the implementation stage, and especially (1) the items spanning on two or more concepts are carefully divided into individual concepts. However, since we cannot leave these divided individual concepts without the interrelationships, we will link these concepts with the relational-terms such as (2) instance_of and part_of, etc.
However, the above methodologies are only effective for the stages of analysis and conceptual design. In order to develop the implementation model for computer system, it is necessary to introduce more complex relationships as the implementation concepts (or classes), that do not fit in above (2). In particular, if our system had needs to connect to the external system designed with different concepts, our system also needed to handle these foreign concepts. One of the techniques enable this may be: (3) GoF's proxy_pattern mentioned on an original discussion. It is a result of computer science in the 1980s.
Now let's see how the above problem is implemented on Wikidata. While (1) and (2) are related by relational-terms such as instance_of, part_of and their derivatives, on the other hand, (3) is handled by another concept called Wikimedia_category. The theme on the original discussion, Commons Category:Production_and_manufacturing, is originally treated as Wikimedia_category on Wikidata.
The theme of this discussion is how Wikimedia_category on Wikidata should be interpreted on the other Wikimedia projects especially on Commons, in my viewpoint. As for this point, it is not realistic to say that Wikidata should resolve all conflicts and other Wikimedia projects can leave it all. The category under the issue, Wikidata:Category:Production and manufacturing (Q7013216) is a kind of compound object of Wikidata:production (Wikidata:Q739302) and Wikidata:manufacturing (Q187939), so probably we need to add both topics on Wikidata:category's main topic (Q106528655) or similar fields, but we can not do it due to the restriction (a kind of unity constraint). In other words, Wikidata seems to lack a way to properly handle the complex objects needed in the real world. Therefore, it seems that each Wikimedia project needs to make its own judgment on how to respond to Wikimedia_category, instead of the ideal solution for a while.
If we accept the following three points, it seems appropriate to keep this category as a counterpart (proxy) for Wikimedia_category.
There is no one-to-one correspondence between the categories of other Wikimedia projects and the Commons category, and Wikidata has not been able to provide an appropriate mapping.
As a result, users of other Wikimedia projects may feel it difficult to find appropriate Commons categories when searching & uploading media files, and we want to avoid this problem.
If we regarded the Commons category corresponding to Wikimedia_category on Wikidata, as a kind of trading ports or import warehouses, and also if we assign (by copy) the media files under these to the categories based on abstract concept model recommended by User:Josh and User:JopkeB, then two worlds (Wikimedia_category and the abstract concept model, both on Commons) could coexist.
Are there any problems left concerning the independency of Commons regarding categories?
Can we reframe your first two points to (the third one looks an opinion to me, with too many if's to reframe):
There is nonot always a direct one-to-one correspondence between the categories of other Wikimedia projects and the Commons categories, and Wikidata has not been able tocan perhaps not always provide an appropriate mapping. (@Jmabel: is this right? Or can your solution always provide an appropriate mapping?)
As a result, users of other Wikimedia projects may feel it sometimes difficult to find appropriate Commons categories when searching & uploading media files, and we want to avoid this problem. But there are possibilities to fix this in Wikidata (see above) as well as in other Wikimedia projects (for instance via a Template).
@JopkeB: What I'm about to say pertains to en-wiki, though I presume there is something analogous for the other Wikipedias.
Before we had Wikidata as our means of handling interwikis, the normal way for en-wiki to indicate that there were corresponding files on Commons was to use en:Template:Commonscat. That mechanism remains available. Typically, that should be used if Commons categories don't line up neatly with the Wikipedia article. - Jmabel ! talk18:19, 8 August 2023 (UTC)
And in all this talk about cats at commons and wikidata no mention of SDC, even though the depicts on commons are based on Q-items at wikidata, that reference cats on commons, thereby makeing the cats on commons multilingual and requiring to sync the cats on commons with the entries at wikidata. Whatever you decide or not decide has consequences for SDC so you really should include that in your discussion. --C.Suthorn (@Life_is@no-pony.farm) (talk) 09:14, 6 August 2023 (UTC)
C.Suthorn, thanks for your contribution. Could you please inform us about what the consequences could be for SDC (Commons:Structured data)? In what cases could a decision here affect SDC applications negatively? What would be a bad decision for SDC? How could we prevent bad consequences for SDC? JopkeB (talk) 03:59, 8 August 2023 (UTC)
General Comment: An article in Wikipedia should be linked to a Commons category, not to a gallery, as categories are our main way to separate subjects. And categories in Wikipedia should not be linked to a Commons category. Yann (talk) 09:01, 8 August 2023 (UTC)
2) What do you exactly mean: should each Wikipedia article be linked to a Commons category, even when there is no (specific) Commons category for? Or is it the other way around: when there is a Commons category that fits a Wikipedia article, then there should be a link between them? JopkeB (talk) 09:21, 8 August 2023 (UTC)
Actually Commons notability requirements are lower than Wikipedia, so there should be more categories on Commons, than articles on Wikipedia. So if there is not yet a category on Commons corresponding to a Wikipedia article, it should be created. For example, if someone deserves a named picture on Commons, there should be a category linked to a Wikidata entry, but many of these persons do not meet Wikipedia notability requirements. Yann (talk) 10:21, 8 August 2023 (UTC)
"if there is not yet a category on Commons corresponding to a Wikipedia article, it should be created." Often, but not always. There may be no media on Commons related to the article, in which case there clearly shouldn't be a Commons category; the relation between the media used in the article and the article topic may be very tangential (e.g. the illustration used for en:Argumentation theory) so that it really wouldn't be an appropriate category for the image; or there may be only a single photo on Commons for the article subject, in which case it's pretty arbitrary whether we create a category (e.g. en:Albers Brothers Mill: if we have other photos of this building besides the one used in the article, then it probably merits a category, but if not I don't see any advantage in creating a category for the one photo). I suspect there are other cases, but these three leap to mind. - Jmabel ! talk18:01, 8 August 2023 (UTC)
Agree Only create a Commons category when there are sufficient files for (and give it a name according to the Commons rules). JopkeB (talk) 05:00, 9 August 2023 (UTC)
For the sake of this discussion: can we say that a Commons category should have at least X files or subcategories, and if you do not agree, then start elsewhere a discussion about the correct number (or numbers, perhaps differentiate by subject)? I would be happy to join it, but not here. JopkeB (talk) 10:16, 9 August 2023 (UTC)
Should Commons allow categories that are not named according to Commons rules and guidelines, just because of links to Wikidata and other Wikimedia projects? (JopkeB)
Underlying questions: How should a Wikimedia category on Wikidata be interpreted on the other Wikimedia projects, especially on Commons? What is the best way to get things done without too complicated method? (Clusternote)
Facts:
There is not yet a guideline in Commons about this issue. (Jopke + GPSLeo)
The bridge between Commons categories and other Wikimedia projects is Wikidata. (GPSLeo + Josh)
If that solution would not be sufficient in all cases, we still have the Template Commonscat. (JopkeB)
Pro allowing categories in Commons that are not named according to Commons rules and guidelines:
To bridge the gap between (1) the self-contained category structure of Commons, and (2) the practical category structures on other Wikimedia projects (Clusternote)
We need more complex relationships than single-subject categories. (Clusternote)
It is not realistic to say that Wikidata should resolve all conflicts and other Wikimedia projects can leave it all. (Clusternote)
If there is not yet a category on Commons corresponding to a Wikipedia article, it should be created (because Commons notability requirements are lower than Wikipedia). (Yann)
Contra:
There are many categories useful for a media repository that are not useful for an encyclopedia, and vice versa. (Jmabel)
Commons is a multi-lingual project. Therefor on Commons category names should be so chosen that they are maximizing accessibility for non-English speakers. (Josh)
Commons categorizes to much more granular level than for instance Enwiki does. This can lead to more nuanced and developed category standards and conventions. (Josh)
In Commons categories play a more central role in navigation, while navigation in other projects is more focussed on linking from article to article. (Josh)
In Commons we try to avoid redundancy in the category structure, that means one category per topic. (Josh)
Composite categories mess up the category structure in Commons. (JopkeB)
Adding redundant categories or extra layers to category structure to try and create synonymous categories actually makes Wikidata linking harder. (Josh)
To Clusternote: Are there any problems left concerning the way a Wikimedia category on Wikidata should be interpreted on the other Wikimedia projects, especially on Commons? Are the discussed solutions sufficient enough to navigate from sister projects to Commons and vice versa? For which cases would you still need composite Commons categories?
To C.Suthorn: What consequences could there be for SDC (Commons:Structured data)? In what cases could a decision here affect SDC applications negatively? What would be a bad decision for SDC? How could we prevent bad consequences for SDC?
I think that is a correct summary. I would add that for every Wikidata item that has at least one photo there should be a category. Additionally every Wikidata item that likely will have a photo in the near future can also have an empty category with the Wikidata Infobox.(That was done for some photo completions in the past.) GPSLeo (talk) 07:05, 11 August 2023 (UTC)
for every Wikidata item that has at least one photo there should be a category. What's the unique benefit there? It seems like a single image category with an infobox would no really serve any other purpose then just be re-creating the Wikidata entry in an infobox. Like, is the point in categories to organize images or to use them as superficial ways for people to find out basic facts related to a particular topic? --Adamant1 (talk) 07:14, 11 August 2023 (UTC)
I would agree with that if there was a guarantee there would be more then one photo to in the category in the future. There isn't one though and in most cases the categories are just indefinitely left with a single image. If there were a guideline saying that such categories could be created only in cases where we know it will populated in the future though I'd probably support it. But I don't know how it would be enforceable and it isn't helpful to have a bunch of categories filled with single images in the meantime. Check out some stamps by year categories if you want some examples of where it can go bad, like Category:Stamps of New Zealand by year. It just turns into a bunch of single file categories that aren't likely to ever be populated and are full of red links to boot. No one benefits from that. --Adamant1 (talk) 08:19, 11 August 2023 (UTC)
As for single-image categories, they are already permitted, so no need for a new rule. Requiring categories for every Wikidata item with an image presumes that image would be included in the created category. This is a problem. Many WD items share the same image, especially in cases where the items are instances or subclasses of another. Creating a mirror structure would create significant COM:OVERCAT violations and other problems.
As for creating empty categories on the promise of future submissions, that is not a good idea. Sure, if you are going to be uploading or adding images imminently (same day), that is fine, but empty categories are subject to speedy deletion. The reason is that they can easily be created at the time images are added to them, so there is no value in pre-building a bunch of categories ahead of time just for them to sit empty. Josh (talk) 14:13, 11 August 2023 (UTC)
I think the assumption that it is easy to create a new category correctly placed in the category tree is wrong. Nearly all new users fail to add correct or even any category to their photos. GPSLeo (talk) 15:33, 11 August 2023 (UTC)
As for single-image categories, they are already permitted, so no need for a new rule.@Joshbaumgartner: I don't think they are. Or at least if they are "permitted" (whatever that means) it isn't recommended. Otherwise Commons:Categories#Creating a new category wouldn't say "find images (or a gallery or other pages) which should be put in the new category." The guideline also uses the term "files" a lot, not "file." So I think the fact that both are plural kind of insinuates that at least in spirit if not practice categories should contain multiple images. That said, I think the more important thing here is not so much drawing a line in the sand about it one or another, but figuring out when exactly it's good practice to create single image categories and when it isn't. There's clearly times when it's fine to do and one where it just causes more problems then it's worth. And I think we need clarify and curb the later at least if nothing else. --Adamant1 (talk) 23:03, 12 August 2023 (UTC)
@Adamant1: That's a fair point, but I think that's putting a lot of weight on the 's' there. I do think that it is always better when there are multiple images and anyone writing guidelines would certainly be looking to encourage that. However, there are a lot of one-page categories out there and when discussed, the answer seems to be to encourage more to be added, but not for that alone to be grounds for deletion. Take many of the Aircraft by registration categories, where it is very common to have a single image in them. That said, I would agree with a clarification in COM:CAT to mention that while more content is preferred, single-item categories can be appropriate, even where no additional content is imminent, for some topics. Josh (talk) 23:28, 12 August 2023 (UTC)
Simple and easy? Wikidata has well over 100 million items! There are easy tools and games for users to add images to these items, so a huge percentage of them have images (my queries to find out exactly hit a time out because there are too many). I agree it may sound simple and easy at first glance, but in practice, it is a nightmare. Josh (talk) 14:13, 11 August 2023 (UTC)
@JopkeB: or @Clusternote: why exactly is it not realistic to say that Wikidata should resolve all conflicts and why do we need more complex relationships than single-subject categories to begin with? Admittedly it's cherry picking, but the only example I can think of for a multi-subject category is Category:Logos associated with entertainment and leisure, which I assume was created based on a Wikipedia category. It's clearly not useful outside of that though because you end up with logos for hotels in the same category as ones video games since both are associated with entertainment and leisure. I hate to see us get in a situation where we are allowing for and having to maintain similar compound categories that will just become dumps for non-related images. Especially if we aren't able to modify or delete them "because Wikipedia category." So if we allow for multi-subject categories it should at least be contingent on them being properly maintained and us being able to modify or delete them if we want to. Otherwise it's just a recipe for category rot. --Adamant1 (talk) 08:37, 11 August 2023 (UTC)
I fully agree with this. It is a key reason why we have the Selectivity Principle. At best it means more categories to list, confusion for users on where to find what they are looking for, and increased work load on category maintainers. In practice it means inconsistent categorization, both of files directly and within category tree structure, and files end up in different corners, some of which will innevitably be less maintained than others, leading to problems such as the category rot mentioned by User:Adamant1. Josh (talk) 14:13, 11 August 2023 (UTC)
I would like to hear from Clusternote him-/herself that all problems here discussed are solved with the solutions we have offered here. I think we cannot close this discussion without his/her consent. That is why I explicitly asked for his/her opinion. And Clusternote may be a representative of perhaps many other people who look at Commons from a Wikidata/EN-WP perspective. I would like to solve this issue once and for all and therefor want to know what obstacles are still there. I am all pro single-subject categories and I read that a lot of us are, but I think we are not the bottleneck here. JopkeB (talk) 14:55, 11 August 2023 (UTC)
@JopkeB: I agree, it is a reason why I am always hesitant to bring other users' ideas to a new discussion/forum except maybe in the form of a direct quote. In my experience, you have generally been pretty fair in your summations of other discussions I have read, but still nothing can replace the user speaking for themself on the matter. It is also why in my responses to things attributed to Clusternote, they merely address the substance of the points as presented here and should not be construed as concurrence with or rejection of Clusternote themself or their actual views. Josh (talk) 23:40, 12 August 2023 (UTC)
Comment re: User:Yann's pro based on notability standards: Notability doesn't really apply to Commons categories, or at least not directly. Instead, it applies to the files themselves (I think it is seen more as a question of scope in those discussions vs. notability, but essentially analogous). Categories exist to support the Files, not for their own sake. That is why empty categories are deleted, and why they need nothing more to be created than for there to be a file to categorize in them. Forcing additional categories on the basis of existing Enwiki articles or Wikidata items implies that such categories would not otherwise be created and maintained under existing Commons category policies, either because there are no files that warrant their creation, or because they would be redundant to existing COM:CAT-compliant categorization. Neither of those practices are healthy for Commons categories, and thus we should not adopt such a new rule. Josh (talk) 14:13, 11 August 2023 (UTC)
Conclusions and questions
Since there was no addition for a few days, I think it is time to draw conclusions and decide what next steps to take.
Conclusions
There is not yet a guideline or policy in Commons about this issue.
Commons can make and maintain its own set of policies and guidelines, independant from Wikidata, EN-WP or any other Wikimedia project. Among them:
Commons category names should be useful for a media repository and comply with the rules of Commons, like: Category names should be so chosen that they are maximizing accessibility for non-English speakers.
Try to avoid redundancy in the category structure, that means one category per topic and avoid multi-subject/composite/compound categories (categories with "and" in the name, except for geographical names).
The bridge between Commons categories and other Wikimedia projects is Wikidata. A solution for topics being conflated in one wiki and separated in another can be found on Wikidata:Help:Modelling/Wikipedia and Wikimedia concepts. If that solution would not be sufficient in all cases, we still have the Template Commonscat.
Since no one gave examples of the opposite, we may assume that:
There are no problems left concerning the way a Wikimedia category on Wikidata should be interpreted on the other Wikimedia projects, especially on Commons.
The decisions that are taken here, have no consequences for SDC (Commons:Structured data).
I would like to add There should be one category per topic; multi-subject categories (categories with "and" in the name, except for geographical names)should be avoided. as a rule to Commons:Categories (or a better formulated/clearer one with the same purport).
Do you agree?
What would be the procedure to do so? Can just anybody/I add this rule or should an administrator do that, or is there anything else that should be done?
Where on Commons could the other conclusions be included, especially the ones about
Sounds reasonable. I'm not sure what the exact procedure for adding something to a guideline is, but I assume you can just do it after enough people agree with the changes or additions. No clue where to make the changes though. Probably a combination of the places you've mentioned. --Adamant1 (talk) 08:06, 16 August 2023 (UTC)
'categories with "and" in the name, except for geographical names': I don't follow this? By "geographical names" do you just mean "proper names" (which are not necessarily geographical, e.g. Category:Seattle and Walla Walla Railroad)? or do you mean that there is something special about geographical names, and if so what? Would you really want to allow a category like "Category:New York and New England"?
I think all we need to say about interwiki links is that nowadays that is done almost entirely through Wikidata, and then point people to the documentation there as to how to do it.
The independence of each sister project is a longstanding default, I don't think we need to say anything about that except maybe to note it in passing. - Jmabel ! talk20:10, 16 August 2023 (UTC)
@1: I think you are right: it should be "proper names", not only "geographical names". And no, I just mean official names in the real world, that have "and" in it, like Category:Bosnia and Herzegovina, book and film titles, and names of food like Category:Fish and chips, not a new combination that is just made up. And I see now more combinations in Commons that should stay, like relationships between countries, and Monuments and memorials (because many are both and often you cannot tell which of the two it is). Because these are too many exceptions, I remove the explanation.
@JopkeB: I agree in principle. I am presuming this would be a sentence added to the Selectivity Principle (currently reads simply "This principle suggests not to combine too many different criteria.") I think there is enough consensus to add your sentence. If there is backlash in the future, we can always revisit it. I would also make sure this conversation is permalinked to COM:CAT's talk page. Josh (talk) 22:36, 17 August 2023 (UTC)
@JopkeB: That's a good question. For a VP chat, linking to this page doesn't work, as this will be archived soon. The only way I know is to wait until it is archived and actually link to the archive page and section. If someone knows a better way, I'm all ears. (It is one reason I really like how COM:CFD is set up, with each discussion its own page which can be added as a template to any other page.) Josh (talk) 13:21, 18 August 2023 (UTC)
@JopkeB and Joshbaumgartner: "For a VP chat, linking to this page doesn't work, as this will be archived soon": this is exactly why we have permalinks. Use a permalink to the present version of the VP. - Jmabel ! talk20:24, 18 August 2023 (UTC)
Thank you, @Jmabel: , linking to the version with the discussion still in it (access it via the history tab) should work just fine. Linking to the 'present' version will only work if the discussion has yet to be archived. Josh (talk) 20:32, 18 August 2023 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. --JopkeB (talk) 02:35, 22 August 2023 (UTC)
Main page missing several types of Commons files
On the home page is a sub-menu: "Images Sounds Videos". We need to add to this "Documents", "3D models" and "Data" (possibly splitting the latter into "tabular data" and "map data"; see Commons:Data).
Hi, I am surprised that I can't find any information about this person. May be someone speaking German may be get better results? Thanks, Yann (talk) 15:28, 9 August 2023 (UTC)
On Special:Upload, when I fill everything out and click "Upload file", the page simply reloads rather than submitting. I'm guessing someone made a recent mistake that changed the server-side functionality and which completely ignores the POSTed content of the form. I'm guessing that this wwould affect everyone who uses this method of uploading, so I'm a little surprised not to see other reports here. - Jmabel ! talk04:42, 13 August 2023 (UTC)
I've been having a similar issue for about a week with the basic upload form. It reloads the page shortly after opening - usually just after I've clicked the "Choose file" button, but sometimes before. Pi.1415926535 (talk) 05:36, 13 August 2023 (UTC)
I always use Special:Upload for individual files uploaded from my localhost (i.e., excl. things like CropTool etc.). I didn’t encounter this issue because I doidn’t upload any such file recently.
It’s very important that this is fixed ASAP. Even cynical jaded (paranoid?) me would not think that (someone at) the WMF would intentionally neglect this fix in order to further ostracize a specific type of user…
I've filed a bug report for the reloading issue. Not only is it annoying, it redirects to the plain upload form that lacks the "preview" button, so it's a loss of functionality. It may also be related to this bug, which I noticed at the same time. Pi.1415926535 (talk) 23:17, 14 August 2023 (UTC)
I tested this. I use the basic upload form (Special:Upload&uploadformstyle=basic). Unchecking the "ImprovedUploadForm" gadget does eliminate the reloading of the form (the reloading with "&uploadformstyle=plain"). However, the form is without the preview button that used to be there. -- Asclepias (talk) 13:20, 15 August 2023 (UTC)
Both this issue and the other bug I noted have been resolved on Phabricator. I can confirm that I have the "preview" button back and no more redirects. Pi.1415926535 (talk) 19:48, 16 August 2023 (UTC)
Edit undo request
Hello to Commons community!
I have a very simple question.
Could someone restore File:Wikipedia-logo-v2-zgh.svg to version 18:12, 25 June 2017?
I keep finding images of lithographic plates from old books, which are misattributed to the authors or editors of those books.
For example File:Biolcam.jpg was attributed to "Eds Godman and Salvin" until I recently corrected (and categorised) it to "Robert H. F. Rippon" - note his name, suffixed "Del et lith" ("drew and lithographed"), bottom left on the plate.
This makes it harder to document lithographers and artists, and excludes their works from categories linked from their biographies on Wikipedia articles, and makes their reuse on those projects less likely.
This is a problem right across the board for art, I seem to do little else, than correct or fill in this information. Part of the problem is the uploading portals are just not up to the job. Broichmore (talk) 13:27, 14 August 2023 (UTC)
@Broichmore, could a [Category:Media needing proper attribution] or other category name help? If there are files that need correction, but volunteers do not have the time, experience or inclination to correct these files could use it. I would be willing to visit that category to help make corrections. Pinging, the winged porcine @Pigsonthewing -- Ooligan (talk) 17:10, 15 August 2023 (UTC)
What upscaling AI are we recommending, the ones I have used previously are no longer free, they now watermark the free version output. --RAN (talk) 16:14, 11 August 2023 (UTC)
So long as we have the original and properly categorize the final product as upscaled, I see no problem with upscaling. It simply makes the image bigger without increasing the noise and grain. When Sir Peter Jackson applies it to historic images, he gets awards. It is no different than photoshopping out a crack in a glass negative, or even cropping an image, or removing the background, or desaturating a sepia image to black and white, or adjusting contrast and brightness. We use what tools we have available to improve an image. --RAN (talk) 03:56, 12 August 2023 (UTC)
It is impossible to increase the resolution (i.e. resolving power) of an image using software (outside of lens profiles and similar methods based on technical data). The algorithm will create a new and larger image that should seem compatible with the original image, but which will feature artefacts of various sorts, such as missing smaller features that are not resolved in the original image, introduce patterns and shapes that are not real, and so on. It is thus comparable to retouching and photoshopping. Upscaling can be done on images downloaded from Commons for those who so desire, but they should generally not be uploaded to Commons unless they are marked with a template equivalent to {{Retouched picture}}. Personally, I would prefer that they are not uploaded at all, unless to illustrate upscaling technologies. --Njardarlogar (talk) 18:13, 13 August 2023 (UTC)
Everything you said there would be anathema to an institution archive, or even indeed to a professional researcher. It's important to keep the original image intact, especially if it's a tiff. Tiffs are reference files that can be exorted as jpg's which are friendlier to website's and scale so much better. "Improved" copies are permissable too, but they are just that copies. Broichmore (talk) 14:02, 14 August 2023 (UTC)
This Commons Project should be a resource for authentic, credible and verifiable photographs and files for its long-term viability. Artificial Intelligence ( AI ) alterations and creations will need continuous discussion (like here) and perhaps more COM:AI policy modifications.
See this current Deletion Request (DR): Commons:Deletion requests/Files uploaded by Giorgio Pallavicini found among these creations here Category:Photos modified by AI This DR includes some terrible algorithmic output. I did not realize (until I found this DR)- is that some of these AI alterations are being used instead of or substituted for the original image(s) on Wikipedia projects worldwide. Some Wikipedia editors may unknowingly choose an AI altered photo. Given a transparent file name that clearly states it is an AI modified file, editors may choose an unaltered, non-AI photo instead.
For instance, File:Aspasia Manos 3.jpg, this file name does not mention that it has been altered by AI, modified by AI or a "retouched picture." This AI modified file was created from the non-AI File:Aspasia Manos 2.jpg. Many persons do not click to open and read the full file page, nor check the categories to find out if an image has been modified by AI or non-AI.
Perhaps, a proposal is needed to require that file names clearly state that the file has been "altered by AI" or "modified by AI." -- Ooligan (talk) 20:19, 15 August 2023 (UTC)
The so called original of this Aspasia Manos is from pinterest, it's also likely to be faked. In any event its a candidate for deletion as there is no attribution or reliable source here. It contravenes many of wikipedia's policies, and criteria. Broichmore (talk) 14:41, 17 August 2023 (UTC)
Mass-revamping of image copyright tags
I recently uploaded (via flickr2commons) around 180 images from the Flickr account of the U.S. Army's 3rd Infantry Regiment. Their images carry the Public Domain Mark (PDM) which is insufficient as proof of public domain on Wikimedia Commons, thus the files now have a warning template reflecting that.
I usually replace the warning template with the more specific PD US Army tag (as the 3rd Infantry Regiment is a U.S. Army unit). However, it will be extremely time-consuming to manually replace the tags on my uploads. Is there a more efficient way of replacing these tags that I am not aware of? SuperWIKI (talk) 04:45, 14 August 2023 (UTC)
How can you best define which are the affected files? A range on your upload log? A category?
Especially if this is a simple category set, this is easy to do. Just ask, but please ask precisely (state the change, and to which files) as that makes it easier. Andy Dingley (talk) 15:24, 14 August 2023 (UTC)
A consistent range on my file uploads. All of them start with "CSA SMA Change of Responsibility Ceremony, Aug. 4, 2023" with a bracketed number afterwards. SuperWIKI (talk) 15:31, 14 August 2023 (UTC)
Question Why is a public domain mark insufficient proof of an image being in the public domain? Sometimes, I think we make too much work for ourselves on this site. -- Ikan Kekek (talk) 17:12, 14 August 2023 (UTC)
@Ikan Kekek: because we try consistently to use license templates that indicate why each particular image is in the public domain, both in its country of origin and in the U.S. Just a statement that it is PD isn't enough for that. - Jmabel ! talk20:30, 14 August 2023 (UTC)
@Jmabel: The one exception is the license tags in Category:PD per authority, where we consider a third-party organization to be as rigorous as or more rigorous than we are at determining PD status, so we simply rely on that declaration without necessarily being able to independently verify why. -- King of ♥ ♦ ♣ ♠22:28, 14 August 2023 (UTC)
@King of Hearts: Agreed, but I think you will find that each photo in the subcats there has a template of some sort that effectively explains the rationale for PD, even if that rationale amounts to "we accepted someone else's authority." - Jmabel ! talk00:32, 15 August 2023 (UTC)
Pardon my lack of understanding of VFC (I used it for the first time yesterday), but wouldn't that affect files that already have that and don't need appending? Or does that function include selecting individual files in said category? SuperWIKI (talk) 13:43, 16 August 2023 (UTC)
Separate from what follows: if the current rationale/tag is wrong, you should be using "replace", not "append". But back to the case where you are not concerned with that...
If you are using VFC to add a category to files you find as a result of a search, you can use "-incategory:" in the search to avoid including files already in the category.
If for one or another reason that won't work (e.g. not finding them by a search, or the string in question is about something other than a category), you can first use VFC to get rid of the string/category wherever it occurs, then use VFC a second time to add it to everything, so the result is that you end up with one instance on each file.
By the way, don't forget that when you are appending rather than replacing, you almost always want to start your string with a newline.
Why not Category:Panama color photographs of Coleoptera taken on 2020-05-26 with Nikon D40? Surely, that's not too specific! Seriously, though, what is the point of these categories (most of which only have 1 or 2 images)? Is it just to make the database servers melt? It looks like these categories were created and populated by RudolphousBot (run by Rudolphous), although I can't find any discussion where this task was approved by the community. Can someone point me to it? If it wasn't approved by the community, I would like to request that all 8 million of these categories be deleted. Nosferattus (talk) 04:40, 6 August 2023 (UTC)
Rudolphous appears to have taken a cue from categories (millions?) that already existed when Commons:Bots/Requests/RudolphousBot (extra) request was filed and discussed. However, the way it is worded, and with the edit examples, Rudolphous appears to assert that he intends to insert "|location=xxx" into templates, while taking date cues from existing categories. I see nowhere that adding such categories by bot is discussed.
There are already 18 million files in these categories. The categories already exist a very long time and on daily basis multiple users add pictures to them and spend hours and hours to categorize them. If we want to delete categories I know some more specific examples to start with Rudolphous (talk) 06:54, 6 August 2023 (UTC)
my opinion is that "country by date"-kind of cats are ok but the current name is bad. should have been like "photographs of Panama taken on 2020-05-26" or "photographs of Panama (2020-05-26)".--RZuo (talk) 08:58, 6 August 2023 (UTC)
This template was created in 2014. So 2014/2015 was indeed the time it started probably. About your proposal: The first option looks indeed a better name to me. Rudolphous (talk) 09:45, 6 August 2023 (UTC)
Well, no, not really. The categories already existed before that and I simply followed what at the time, seemed to be an already established standard. My edit was to implement automatic categorisation into appropriate categories when using the {{Taken on}} template. The preceding discussion can be found on the template talk page. The intention at the time, was to use this for country level categorisation by date, which I feel can be useful. TommyG (talk) 07:37, 7 August 2023 (UTC)
"proliferance"
between oct 2015 and apr 2018 (2.5 years) only roughly 20000 such cats were created. now there're 500000. RZuo (talk) 13:51, 7 August 2023 (UTC)
"country-by-date" seems to me to be an acceptable compromise between those who don't want to do anything of the sort and those who would do "city-by-date" categories.
And we don't want to rename categories affecting 18 million files unless there is a serious problem. A comprehensible but less-than-optimal category name is not a serious problem. - Jmabel ! talk15:32, 6 August 2023 (UTC)
+1. These "by date" categories are just needlessly excessive. The same goes for "by year" categories in a lot of cases and depending on the subject. "country-by-date" categories are probably fine though. --Adamant1 (talk) 20:28, 6 August 2023 (UTC)
I don't see any reason to reject "city-by-date" and have "country-by-date". Panama is 4.3 million people, and there are over eighty cities that are larger than it. Countries vary so much, from the enormous to the tiny, that they aren't a useful dividing line.--Prosfilaes (talk) 19:26, 12 August 2023 (UTC)
I truly dislike participating in siloed micro-discussions which avoid acknowledging the bigger picture. However, to address the example originally offered, Category:May 2020 in Panama doesn't exist, with three valid categories underneath. This appears to violate our policy, which is to create categories in a hierarchy. There was an admin who took exception to my fixing the problem of "Births in XXX" when "People of XXX" didn't exist by means other than creating scads of un(der)populated intermediate categories. The same issue applies: why were these categories created in the first place without regard for maintaining the integrity of the hierarchy? There's still plenty of broken trees lying around due to this admin's interference with my efforts, which caused me to quit bothering with it. Bot/script editing may make things "easier", that is, until it's not "easier" when someone else has to come along and clean up the messes.RadioKAOS (talk) 02:36, 7 August 2023 (UTC)
@RadioKAOS: I suppose the bigger problem is people bot-creating hundreds of thousands of categories without bothering to have a community discussion about it first. I also recall someone bot uploading something like 1,000,000 photos of clouds taken automatically by the International Space Station without any discussion. Just try clicking "Random file" for a while and you'll probably see one (except the ones taken at night are black). Can Commons please have an enforcable bot policy? Nosferattus (talk) 22:38, 10 August 2023 (UTC)
Are the ISS photos related to this category discussion? Why are we having a category discussion outside of CfD?
If there are hundreds of thousands of categories, and they have an identifiable purpose, and they stem from a reasonable design decision, then I don't see why we should disallow them, just because they've grown to six digits' worth. If they are creating software problems at scale, if they are unwieldy for bots to manage, if they are causing heartburn for MediaWiki software in some way, then by all means we should rethink them. But surely we could have envisioned that categorizing works by the intersection of place/date would certainly grow, like grow a lot.
I was initially confused about why Rudolphous' bot request did not explicitly say it was going to add categories, and then I realized that the categories are automatically generated by the template when RudolphousBot adds a parameter to them. I think that as the project grows, we will have more instances of hundreds of thousands of whatevers, and so I think this simply puts a stress test on the limits of MediaWiki software, and also creates opportunities for bot developers to find ways to efficiently, programmatically process category trees that can barely be comprehended by humans. Elizium23 (talk) 00:01, 11 August 2023 (UTC)
I do not have a problem with the 'photographs taken on date' series of categories existing more-or-less as it is structured, but there are some real hazards that it causes by how it is implemented. The naming is problematic for some...what are "Panama photographs"? If we mean Photographs of Panama, then fine, that is what is should be named (see Universality Principle). Also a problem is the one alluded to by some above, that there are photographs sorted here that are not in their analogous topical categories. People sort their picture of Panama into this category and then it turns out if someone looks for May 2020 in Panama, they don't find it. 'Photographs of' categories are in the Media types tree, not the Topics tree (see major category policy for info on these). Thus any files in one of these categories should also exist in a topical category. Certainly, any case where a 'photographs of' category exists and the analogous topical category does not even exist is a huge problem. If these categories are being added by a template on the image, it means that often users will never drill down beyond the 'photographs of' category to discover this and these will be left without topical links en masse. All of these categories should be marked as non-topical categories (specifically as 'media type' categories) so that less-experienced users are not duped into thinking images are properly categorized because they see them in a 'photographs of' category. Josh (talk) 19:41, 18 August 2023 (UTC)
NSFW category madness
Category:Nude men with visible pubic hair (and of course many will not want to click on that) has five nonexistent parent categories, one extant parent category (Category:Men's pubic hair), and a navigation template show 12 hypothetically related categories, none of which exist. I discovered this category only because a picture I took of a naked cyclist in a parade got placed in the category.
I'll say it straight out: I'm done trying to clean up sloppy work in categories related to naked people, including but not limited to some categories that seem to me to be of only fetishistic interest (e.g. Category:3 women with nude men, which has similar problems with nonexistent parent categories). Would someone who values these categories please take on the work of cleaning them up?
I'm also probably done with licensing photos of things like the Fremont Solstice Parade in ways that are compatible with Commons, because I find it very disrespectful to the subjects of these photos that their images are ending up in these fetishistic categories. Nothing against Commons covering fetishism, but a good deal against mixing nudism and fetishism as if they were the same thing. - Jmabel ! talk00:14, 12 August 2023 (UTC)
How is "3 women with nude men" fetishistic and disrespectful? If I was to ask an AI to describe the image, that is what I would get. --RAN (talk) 04:02, 12 August 2023 (UTC)
@Richard Arthur Norton (1958- ): because it is hard for me to imagine anyone particularly looking for that of they didn't have a CFNM fetish. But if that's not a good enough example, how about Category:Topless men showing chest hair? (These are just a few examples out of dozens, and of course there are far more objectifying categories about women than men.) And if you consider these categories fine, then you can feel more than free to be the one who addresses issues like having five nonexistent parent categories and a navigation template show 12 hypothetically related categories, none of which exist. - Jmabel ! talk16:52, 12 August 2023 (UTC)
(Parenthetically, it is certainly possible for a man who is not topless to nevertheless have some tufts of chest hair poking out of the top of his t-shirt.) -- Ikan Kekek (talk) 17:08, 14 August 2023 (UTC)
Probably some bias that has to do with unhealthy relationship of many people to their own body and the human body in general: they may think that every picture of a nude person where genitalia is visible was actually nothing more than a picture of genitalia (in other word(s), pornography). --A.Savin21:59, 12 August 2023 (UTC)
No. But I find it laughable at least, to add merely the "Penis" statement and/or category to this picture, given the fact that there are lots of topics fitting here just as well, such as: "Man", "Woman", "Bodypainting", "Demonstration", "Ukulele", "Bicycle", "Leather", "Hair", "Chest", "Breast", "Nose", "Legs",... --A.Savin09:33, 18 August 2023 (UTC)
Discussing the de minimis threshold on categorization of an image is a perfectly valid one to have. However, declaring that a health disorder or bias is the probable motivation for another user's good faith edits without evidence is completely out of order and irrelevant to any valid discussion on the subject matter. Even if you had evidence, it would be at best an ad hominin argument. Josh (talk) 18:59, 18 August 2023 (UTC)
We mark nudity so that people can filter out nudity in Google results. Google will blur nudity by default, so our categories and depict statements aids in those endeavors. --RAN (talk) 18:07, 13 August 2023 (UTC)
@Jmabel: I can't speak to the motivations of the user in question. I can speak to the use of depicts (P180) in the structured data to add something seemingly only a minimal part of the image. depicts (P180) is described as a property to link any item "visually depicted in an image, literarily described in a work, or otherwise incorporated into an audiovisual or other medium" with the work it is depicted in. This is a pretty broad definition. It is worth noting that the more specific main subject (P921) also exists which is for the primary item(s) depicted in a work. This would seem to indicate that regardless of the amount of the work dedicated to depicting an item, so long as the item is depicted at all, depicts (P180) is a valid property for describing this relationship. Note also, that the option exists to mark any item under depicts (P180) as prominent. This adds weight to the idea that non-prominent items are valid to be added with depicts (P180), otherwise, there would be no need for such an option. All of the items you listed for both images may well be valid additions under depicts (P180). They may seem incidental to many users, but are perhaps consequential to others. As RAN points out above, these statements are not only used to find images of a particular item, but also to filter out images with particular items. Josh (talk) 19:16, 18 August 2023 (UTC)
@Joshbaumgartner: that would be fine with me if someone were adding a good number of relevant categories, including far more relevant categories. I myself am still going to stop uploading images like this, given that they appear to be an excuse for a game of "where's Waldo, penis division". I think it's insulting to the person who is the subject of a photo of a body-painted man in a parade playing a ukelele when the image is described simply as depicting a naked man and his [barely visible] penis. - Jmabel ! talk20:36, 18 August 2023 (UTC)
Well, if he would only wield his ukulele more strategically, it could better emphasize the relative importance of the instrument. Elizium23 (talk) 20:49, 18 August 2023 (UTC)
@Jmabel: I think there is a bit of conflation between adding categories and adding depicts (P180) in the structured data. There is certainly a relationship there, but each is its own distinct thing. I think if we are going to get into the nitty gritty, we need to be clear which process we are discussing.
That said, I would like to know more about your comment, "I think it's insulting to the person who is the subject of a photo of a body-painted man in a parade playing a ukelele when the image is described simply as depicting a naked man and his [barely visible] penis." I don't know that whether or not people are insulted by how their images are categorized is really all that relevant to our categorization scheme. Obviously, we should never be categorizing for the purpose of denigration or to cause offense, and if a non-derogatory option is available for naming or such that still meets the needs of categorization, then by all means, that would be preferable. Also, it sounds like one of your concerns is that we have categorized this image by a particular body part being in evidence, while not bothering to categorize by other depicted elements. I can certainly agree with the sentiment that most of us do not wish to be reduced down to our most sexualized body parts at the exclusion of the rest of what we are and do. However, in the scope of categorization, it would seem that what is wrong is that this image is not in Ukeleles (diffused appropriately of course), or other various things depicted in the image.
We have no control over how people will use the images they access on Commons. We do of course control how we categorize those images, but our categorization scheme can't make special allowances for how individuals feel about how images depicting them or created by them are presented. This is not because those individuals' feelings are not valid, but because it just isn't workable in a standardized system to do so. That said, releasing your copyright by contributing your works to this project is a choice. If you are uncomfortable with how certain images you have uploaded are curated, then as regrettable as it may be, I fully support your decision to cease uploading certain images. Hopefully though, it will become clear that the project (I can't speak to the motives of individual users, nor do I think they matter) is not seeking to demean or degrade either your works nor their subjects, so hence why I am interested in learning more about exactly what your thoughts are on this. Josh (talk) 21:39, 18 August 2023 (UTC)
I feel that reducing an image of a human being to being an image of an array of body parts is objectifying and demeaning. Pretty much end of story, especially for me. And, yes, I see this done mainly in a sexualizing or even porn-ifying way. No one singles out that an image of a whole person shows an ear or a nose or an elbow. - Jmabel ! talk01:48, 19 August 2023 (UTC)
Lua error in Module:Autotranslate at line 72: No fallback page found for autotranslate
I'm having the Lua error in Module:Autotranslate at line 72: No fallback page found for autotranslate error message in both this template and a reserve one I made in order to fix the problem, but it repeats again.
I know it's a missing page I didn't create, but I've been creating templates for campaigns for years and never found such a persistent error like this one.
The "-base" thing is inherited from older templates I used as a model. Now I don't want to change anything for fear of breaking a template TaronjaSatsuma (talk) 17:06, 17 August 2023 (UTC)
@TaronjaSatsuma: I am not afraid of that and cleaned up the three (!) interlinking templates to only have:
This image was provided to Wikimedia Commons during Wiki Loves Cosplay 2023 photo contest.
{{Autotranslate}} looks for a subtemplate <base>/<lang> with ultimate fallback to English. Base should always set to the name of the template, so "Wiki Loves Cosplay 2023" in this case so the default will be Template:Wiki Loves Cosplay 2023/en.
The /layout template is used used as a base template so all languages look the same
The /lang template is used for navigation between languages and can be filled with {{Lle}}
Not sure where best to raise this, but: these are currently duplicates, so according to our guidelines, one should be deleted (and indeed, for the versions with non-transparent backgrounds, the table at SVG chess pieces instructs people to just use "Chess e..." pieces when they need "Chess B..." pieces). However, the elephant File:Chess edt45.svg has, at several points in its history, depicted an elephant instead of being a duplicate of the inverted bishop File:Chess Bdt45.svg. So I want to check: should the elephant be a duplicate of the inverted bishop and thus deleted? or should we have a file depicting an elephant piece? (Another reason I'm not tagging it for deletion is that in my experience users vote to keep exact duplicate images as long as they have different names, so starting requests for deletion is pointless.) -sche (talk) 20:59, 19 August 2023 (UTC)
example colors on the left and their distortions on the right
The image on the right gives an example of the difference between intended colors and those actually shown on Commons, Wikipedia etc.
(This image is not subject to the distortion, because it is shown in its original size.)
This is probably not good for articles like Impressionism or Color vision.
But it also means, that graphics intended to show pale colors look rather gaudy.
The Phabricator ticket is open since February, and there is no indication that this might soon be solved.
Is this supposed to remain like this for the next years? Can anyone help? --Watchduck (quack) 22:36, 19 August 2023 (UTC)
screenshot showing the thumbnail on the right with distorted colors
@Watchduck: I took a screenshot of the image and I see a very small distortion in the 110px thumb but not anything like your example. A screenshot in Paint.net color picker tool shows FF5454/00CD00/5454FF for the 110px version and FF5555/00CC00/5555FF for the bigger image. MKFI (talk) 08:25, 20 August 2023 (UTC)
@MKFI: What is the URL of your 110px thumbnail? Also the one with .../7/7b/...?
All of these examples are scaled on browser side and use the same original file. So the problem is in the browser and not in the thumbnail renderer as the renderer is not used in this case. GPSLeo (talk) 08:33, 20 August 2023 (UTC)
@GPSLeo: It would be terrible for loading times, if large images like this were loaded in original size, and scaled in the browser. That is, why the server sends thumbnails in the requested size. Above I have linked the URL of the 110px thumbnail. --Watchduck (quack) 08:55, 20 August 2023 (UTC)
In this case with the small file and relatively big thumbnails there is not server side down scaling. I had a look at a server side scaled version of the file [7] and there the colors are correct. GPSLeo (talk) 13:06, 20 August 2023 (UTC)
The "screenshot" version shows what you describe. It is not reproduced with thumbnails generated from the original image. It may be something with your system. -- Asclepias (talk) 12:38, 20 August 2023 (UTC)
That seems to be true. My browsers show me some thumbnails with wrong colors. But after downloading them, I can can confirm, that they contain the correct colors. Sorry for the false alarm. --Watchduck (quack) 13:12, 20 August 2023 (UTC)
Wiki Loves Pride (Malta and EuroPride 2023)
Dear Wikimedians - I would like to bring to your attention a general Wiki Loves Pride international camapign that would like to encourage you to create LGBT+ related content in your language and more specifically to those in or traveling Malta to join Wiki Loves EuroPride 2023 campaign by contributing media (photo, video and audio recordings) as Valletta is hosting EuroPride soon.
If you are interested to collaborate in any way and help us with promotion, outreach or other aspects please get in touch! --Zblace (talk) 10:28, 20 August 2023 (UTC)
I see you are mayor contributor of photos of Malta and I wonder if you would be interested to contribute to this cause and towards documentation of events in Malta next month @User:Continentaleurope @User:Marika Caruana @User:Hekk-u-hekk
Yes, User:Fæ did millions of mass uploads from large sites such as LoC. Files from mass uploads often need refinements and corrections or sometimes deletions. Sources are there, it can be done, although it is tedious. -- Asclepias (talk) 20:39, 20 August 2023 (UTC)
which is named "Image 4 of Sanborn Fire Insurance Map from Tacoma, Pierce County, Washington"
then the server will suggest a filename "service-gmd-gmd428m-g4284m-g4284tm-g4284tm_g09345189602-09345_02_1896-0051R.jp2"
this filename contains the correct plate number (51) and indicates that this is a dual page plate, "R"ight subpage.
Additionally, the filename now used on commons does not include the publishing date and the volume number, both also part of the suggested filename.
It does include a LOC-internal serial number (004), but the (Sanborn offical) release year and volume number are more useful to identify a map set. Given two serial numbers, 004 and 009, conveys less information than the respective year+volume (1896 Volume 2 and 1950 Volume 2). Also the year is currently just not part of the commons filename.
Is there a way to find out how many links exist between wikipedia and this map collection? I think a small fraction of people who should know about it do know about it. It is not really used much, that is my impression.
Finally there are plenty more maps available for download. Is there a reason except that nobody is doing it?
PS: what is the point of downloading 100mb+ tiff images. The jp2 versions of these files have 10% of the file size.
considering that there are plenty more maps to come in the future and that these maps are a tremendously useful resource, i think these problems should be addressed.
There is also another opportunity: the indices to the maps include a lot of company names. These indices could be given an OCR treatment and be made searchable. With the right kind of expertise OCR could also be applied to the maps themselves, which contain useful clues, for example the words "foundry", "ship yard", "warehouse" and so on, which do not appear in the index. Nowakki (talk) 18:53, 19 August 2023 (UTC)
high quality jpg files can be created from jp2. There is no point to include either tiff or jp2 files on commons though when they are so easy to obtain elsewhere. Nowakki (talk) 20:33, 19 August 2023 (UTC)
@Nowakki: you are identifying how many articles use these, not how many references they make. For example, look at List of structures on Elliott Bay, you'll see I used these heavily (though generally for Seattle I prefer Baist, which is more detailed for the years where it is available). - Jmabel ! talk01:35, 20 August 2023 (UTC)
@Jmabel: anyway, i am trying to solve a problem here. it is only going to get worse. somebody should pay attention to this. it is a really big data set. the flaw is obvious and easy to fix. can save a lot of future headache. Nowakki (talk) 15:25, 20 August 2023 (UTC)
@Nowakki: "service-gmd-gmd428m-g4284m-g4284tm-g4284tm_g09345189602-09345_02_1896-0051R.jp2" is an awful filename, even if it contains information that is potentially useful to someone who happens to know how it is structured. If you want to propose a standard for naming Sanborn maps on Commons, I'd be fine with that, but it needs to be sanely comprehensible to a normal human; give that these are maps of North America, sanely comprehensible to an English-speaker. - Jmabel ! talk19:57, 20 August 2023 (UTC)
@Jmabel: i am proposing to use information contained in the filename, not the filename.
If i asked you now to find company/street X in town Y, you could read the correct index and get a plate number. Then you have no idea which indexed file contains the plate and you have to search through a few of them or click on one and calculate the difference. You can see where this is going when hundreds of people start using these files. The original uploader did not know what he was doing.
"Sanborn Fire Insurance Map from San Francisco, San Francisco County, California, Vol 1, 1899, Plate 5"
"Sanborn Fire Insurance Map from San Francisco, San Francisco County, California, Vol 1, 1913-1948, Index1"
everything up to the last subindex (the plate number) would be stored in one folder, just like on the Library of Congress site. Nowakki (talk) 05:30, 21 August 2023 (UTC)
I think it is better to keep the same names within the atlas. But if anyone wants to add categories for specific places, great! Yann (talk) 14:00, 21 August 2023 (UTC)
Assistance wanted: Confirming IA scans as Public Domain...
The Template {{IA}} was recently updated to allow for scans to be marked as reviewed as being in the public domain, or under a "free" license.
It would be appreciated if some experienced contributors (most likely license reviewers) were able to start adding the relevant parameter to the uses of the template, and to add appropriate catalog data to the files concerned such as {{Book}} or {{Artwork}} as appropriate, converting between them as needed.
Unreviewed scans/items will appear in the hidden category : , which once the reviewing process is completed should contain as few files as possible.
Reviewing most of the files should be straightforward, as the vast majority of the scans ARE under Commons Compatible licensing.
"G. Duf[?????]". No double-f, the given name just starts with G - that could indeed be a George, or also Gina, Guillelme or Gaston. The final characters are all x-height and increasingly small, so your reading as "Paris" might be correct, but it could also be part of a longer name petering out, like "Dufunnene". --Enyavar (talk) 09:32, 21 August 2023 (UTC)
@Richard Arthur Norton (1958- ): There appear to be three lines of text. The first is cursive and looks like a signature. The second is in block capitals and looks like "MARNE-". I can't make out the third line but it might be "Paris." However, MARNE is outside of Paris, so that would be a logical connection. From Hill To Shore (talk) 18:16, 22 August 2023 (UTC)
Personality rights question
How do we handle personality rights around here, especially when it comes to children? I have my doubts about these two images. One might argue that this is a problem only if the children are clearly identifiable. Well, their parents would certainly recognize them, or anyone who knows them.
I personally don't think these are great photos anyway that are an asset to Wikimedia Commons or to any Wikipedia article. So are these worth keeping?
There are other issues with these images, like: How do we know that the uploader is identical with the copyright holder? I see no indication of that. --2003:C0:8F16:2100:79CF:D018:617C:C4E05:46, 22 August 2023 (UTC)
I don't know enough about French law to say what the personality rights issues would be there. I know France is tighter on this than most countries. In the U.S., the first image would be completely unproblematic (because it is a clearly public space by any reasonable definition, and in the U.S. that is enough). The second might raise some issues.
Why would you doubt that this person is uploading their own work? She identifies herself in the "author" field as associated with the museum. - Jmabel ! talk18:20, 22 August 2023 (UTC)
To the first question, the fact that there are identifiable persons might be a problem. However, considering that the former children are now about 25 years old and that the photos have been on Wikimedia for fifteen years, I'm not sure if the fact that those adults were children in 2006 is, as such, an additional problem now. To the second question, the photos are in use in Wikipedia and that determines that they are deemed in scope and worth keeping, if they are legal. To the third question, there is indication but no proof. The uploader might seem to claim to be the holder of the copyright through the use of the prefix in the licensing section, but that's sometimes a mistake and not a proof in the absence of verification. The uploader does not claim that the photos are own work. The source is said to be the Musée. In that context, the name in the author field does not seem a self-identification, but an attribution to the author different from the uploader. -- Asclepias (talk) 19:39, 22 August 2023 (UTC)
I've prevously seen scans of real ID's with personal information, filled out tax forms or job applications, etc. Those are in real need to get deleted. The same applies to revenge uploads (of the classmate the underage uploader hates, with an unflattering description.) Full names and adresses in case of non-consenting or accidental uploads are a no-no. Don't keep. Doxxing is a real issue, and steps need to be taken to prevent obvious cases, delete images or revision-delete unwanted information.
These two photos are (imo) in no way harmful, the children are not easily identifiable, and we don't get high-resolution portraits that could be used in face recognition (arguably the worst case of non-obvious doxxing in our AI times now). There are also no names given - I'd say they are save. Myself, I blur out identifiable details of bystanders in my photos, unless they're the subject of interest - But not everyone does.. In the case you present here, the children playing with objects is the interesting part.
And then there's this, this, this, this, this, this ... Yup. I'm saying Commons has hundreds of thousands of photos depicting children, or people in general not being aware they are photographed and about to be uploaded to Commons. Some may have been asked for permission, others might not. We generally want to keep such pictures (preferabbly anonymous, etc.). Exceptions have to be discussed in individual deletion requests.
An adult may wish his baby picture to get deleted, since he never gave informed consent, and I think we would grant the request, depending on circumstances. But given that most pictures are uploaded anonymously, few will come here 15 or more years after the fact and file the request.
A former soldier may come here and request that an image taken as part of their official duty is to get deleted: Essentially revoking the informed consent given many years prior. [that is a point of heated contention].
I can think of many more cases, usually revolving around "harm done?" "consent given?" "consent inadmissable?" "laws violated?" "is it in-use?" "quality?" that can be used to decide whether or not images of a photographed person can be deleted based on personality rights. Best --Enyavar (talk) 22:42, 22 August 2023 (UTC)
Upload Wizard should allow trusted users to import Flickr images regardless of claimed licence
Commons Upload Wizard currently allows users to upload images from Flickr, where the licence used there is compatible with Commons. But there are many images on Flickr, with more restive licences applied, but where the content is in reality PD by dint of age, or ineligibility through simplicity. An example is File:Postcard Drawing of Marble Arms 1907 Gladstone Michigan.jpg, a 1907 postcard tagged here as {{PD-US-expired}} but with a by-nc-nd licence on Flickr.
Currently these can only be uploaded by a tedious process of downloading images to the user's machine, and uploading from there. Metadata then needs to be transferred manually.
I have suggested in the above ticket that trusted users should be given a right to use the tool wizard to upload such images (and then apply a suitable PD template), and have been asked to demonstrate consensus for this.
What is the criterion for a user to be "trusted" for this kind of uploads? For example there are many users with large upload counts who got this count by using the LinguaLibre tool (uploading recordings of their own voice), technically they are experienced users, but actually they may have no knowledge of copyright questions at all.
Just my opinion as someone who does a lot of work with postcards and browses eBay for them a lot, but usually images of postcards and ephemera on eBay are either of extremely low quality or watermarked to the point that aren't worth uploading to Commons even if the actual image is actually good. So providing an easy way for people to easily import images from eBay just seems like a recipe for disaster. I like the idea of making it easier for "trusted" users to upload images from Flickr though. At least the image are usually pretty quality in that case. --Adamant1 (talk) 07:52, 17 August 2023 (UTC)
The meaning of "trusted" is to be decided by the community, as with any user-right. It is unlikely that the community would equate it to "experienced at making and uploading audio files"
This will not "increase the risk a lot of copyright violations", because only trusted users will be able to use it. In fact, the use of a tag in edit summaries will reduce the risk, because manual uploads such as those that occur at the moment are not tagged.
I suggested a separate tool, and the devs at the Wikimania hackathon responded that updating the wizard would be preferred.
Those devs have not raised any concerns that "This will make the uploadwizard too complicated "
We have well over 6000 images in Category:Images from eBay (and no doubt more that are not in that category). There is clearly a need to be able to upload images from the site.
I have previously asked eBay to add this functionality at their end (I know it was discussed at executive level) and had no response. Similarly, Flickr are unlikely to add it.
That said a browser-user script to add the functionality would meet my need, albeit maintenance requirements may be harder to satisfy.
I agree that we should have a tool, at Flickr you choose your default license when you create your account. I have hundreds of obituaries that are in the public domain in my Flickr accounts, I imagine other people are not even aware of their default license. --RAN (talk) 17:35, 19 August 2023 (UTC)
Is this really a common enough scenario to justify creating a new workflow in UploadWizard rather than just uploading them manually? I'm skeptical. Nosferattus (talk) 00:21, 23 August 2023 (UTC)
CommentThere is clearly a need to be able to upload images from the site. Just to clarify, I never said there isn't a need to be able to upload images from eBay. I upload them myself and the process could for sure be easier. Users having to go through the process of uploading images to their machine, re-uploading them to commons, and then adding the Metadata manually all (at IMO) act as important guard rails that keep low quality images being uploaded to Commons in mass. Otherwise people just browse a few images from specific sellers, assume all of their images are fine "because PD", and hit the easy import button regardless of the quality or if the images are in scope. That already happens to a degree with the Flickr to Commons tool. It's also important to point out that a lot of eBay sellers are extremely hawkish when it comes to images of their listings being copied. The fact is that the easier we make it for people to upload images from eBay the more likely it will be that sellers start watermarking said images, which doesn't benefit us in the long run. A slow, semi-tedious upload process makes sure that won't happen though. --Adamant1 (talk) 09:41, 23 August 2023 (UTC)
Original discussion here was about Flickr. I don't really get why we are now talking about eBay.
before clicking the file i already guessed it's probably from a samsung phone. they often have this gibberish code in exif. idk what causes it.--RZuo (talk) 14:17, 27 August 2023 (UTC)
This sentence, “A South African work that is in the public domain in South Africa according to this rule is in the public domain in the U.S. only if it was in the public domain in South Africa in 1996, e.g. if it was published before 1946 and no copyright was registered in the U.S. (This is the effect of 17 USC 104A with its critical date of January 1, 1996.)” is not supported by the cited US law which applies only to restored work; thus, it should be removed or reworded to avoid confusion.
The law stipulates that "A) Copyright subsists, in accordance with this section, in restored works, and vests automatically on the date of restoration." and
"(B) Any work in which copyright is restored under this section shall subsist for the remainder of the term of copyright that the work would have otherwise been granted in the United States if the work never entered the public domain in the United States."
The confusion stems from including the “A South African work that is in .." in the template, which means any images that meet the South Africa PD 50 years criteria can be deleted or considered copyvio when they are not. OR the wording should be amended to align with US law by specifying that it applies to "restored work" FuzzyMagma (talk) 09:41, 19 August 2023 (UTC)
I don't understand your point; all South African works in copyright in South Africa on 1/1/1996 with no US connection (as detailed in the law) are restored works, and the US doesn't have the rule of the shorter term for any works that were in US copyright on that date.--Prosfilaes (talk) 09:51, 19 August 2023 (UTC)
Why would it be? Assuming you meant something that's PD in South Africa now, like an anonymous work from 1972, then it would have been in copyright in South Africa in 1996 and would have had copyright restored in the US, and then it would be treated like a US work (that fulfilled all formalities) from then on, c.f. the Hirtle chart.--Prosfilaes (talk) 14:13, 20 August 2023 (UTC)
The argument keeps coming up as to using "author=unknown" versus "author=anonymous" and whether Commons makes any legal distinction between the two. The argument has been made by someone that "author=anonymous" should only be used when someone makes a legal declaration of anonymity, such as for the first publication of Primary Colors. I don't see it used that way at Commons. So, is there a legal distinction at Commons in the way it is used? Should a bot harmonize all usage to make a distinction? RAN (talk) 16:16, 19 August 2023 (UTC)
The point being that saying a work is "anonymous" means that the author name was not stated. "Unknown" just means "we don't know". For example, when you have one side of a postcard or one arbitrary page of a book, you can't say the work is "anonymous," because the author's name may well have been stated in a portion of the work that we don't have access to. - Jmabel ! talk19:59, 19 August 2023 (UTC)
Hello RAN, maybe the image to the right here helps to understand. It is part of an album with cartes de visite. These cartes de visite became rather populair in the 1860's for wealthy people. In this case you see 6 cartes de visite were (still) inserted. Quite often the name of the photographer was on the backside, sometimes it was (also) on the bottom of the front side. When inserted in an album that name is usually no longer visible. When you turn to the next/previous page, you might see that name on the backside if there is no carte de visite at that specific location (as is the case for the two empty slots where a name is printed immediately before the word 'photographer' in French and Dutch). If I crop an image of a album page like that to have a picture of one specific person, I usually don't know the photographer's name. The fact that I don't know the name doesn't mean the carte de visite was anonymous; it is just something I don't know. - Robotje (talk) 10:54, 20 August 2023 (UTC)
And there might be a difference in copyright: in some countries "Anonymous" works are in the public domain 70 years after the first publication of a work, while for "author = unknown" it might take much longer (in Commons: 120 years after first publication). --JopkeB (talk) 02:46, 22 August 2023 (UTC)
120 years is for unpublished material. The template reads: "the death date of its author is not known, and it was created before 1903; it is an anonymous work, a pseudonymous work, or a work made for hire, and it was created before 1903." Not_known and anonymous are used synonymously. --RAN (talk) 02:39, 25 August 2023 (UTC)
The thumbnail you provided does not have polka dots. File page looked OK, but clicking on 1558×2048 image did not show polka dots. I purged the cache, and now the thumbnail and 1558 image have polka dots. Do not know why. Glrx (talk) 19:12, 31 August 2023 (UTC)
Now I can see the polka dot pattern too. How weird! but the problem was solved. Thank you very much to both of you. All the best
Thanks for doing the moves related to images of campuses — I've noticed a bunch on my watchlist, and it seems helpful! To help keep the categories organized, I was wondering, do you have any standards for how to define what is a picture of a campus vs. just a picture of a college?
Personally, to take a stab at it, I might define it as a picture where the physical built environment of the institution is the main focus. This would mean that most outdoor pictures would go in the campus category, unless there's some activity happening in them that is clearly the focus (e.g. as here).
I'm not quite sure how to deal with indoor photos. This dining hall pic is plausibly a photo of the campus, or maybe it's not because the focus is the dining hall rather than the campus at large. And if you zoom in a bit, this seems like it's not.
How do you propose we go about this? If we don't define some standards (and then articulate those standards at the category pages), they're going to get hopelessly muddled over time.
The problem is to find a definition for campus. Does a campus need more than one educational or research institution? Or can a singe university form a campus? If a single institution can form a campus what is needed to make it a campus and not just the area of an institute. What types of educational or research institutions can form a campus? A useful definition for our categorization system could be that an area is a campus if there are at least two categories for buildings on these area. GPSLeo (talk) 15:56, 13 August 2023 (UTC)
Very interesting to me, because of Category:Campus maps which I always understood to be the plans/maps of multi-building institutions for education that have outer spaces larger than a mere schoolyard. (Which is why campus maps exist in the first place, a university/school/institution that doesn't require a campus map, doesn't have a campus. Mere floor plans for a single building don't count, btw.)
Now, en:Campus says that one might include non-educational campuses as well, which is not my understanding and should be a different category - maybe "company campus" or something. Anyway, interior shots should in my opinion be categorized according to the function of the rooms: Library, dining hall, lecture rooms, floors, etc. The "Campus area" that would be tagged as such, is outside the buildings. If you want to have all pictures in one category: that's why one needs to categorize by name of the institution, too. All the best, --Enyavar (talk) 07:14, 14 August 2023 (UTC)
You have raised some interesting questions. I do not have definite answers to them. I believe subcategories are used for organizing files rather than defining the meaning of the term "campus". They are similar to the folders on your computer. That being said, having some criteria which files to be put under the campus subcategory is useful. For now, I put any file that the main topic of an image is a static physical object within the campus of the institution. It may be too board. Hence, a picture of a display may not be considered. Here are my tentative classification criteria:
Yes:
Outside of buildings
Sculptures
Open Spaces
Aerials
Maybe:
Inside of buildings
Paintings or murals
Experiment facilities or equipment
Displays or postings
No:
Protestings
Talks or presentations
Other activities
Feel free to move items from one category to another.
Regarding if a single institution can form a campus. I believe the answer is yes. However, it should consist of at least a few buildings, like @Enyavar said. It may also have multiple campuses. Here I use the meaning of a physical area of one or more institutions, rather than the individual institution of a multi-campus university system. For the latter, I refer them as institutions.
For interiors of buildings, there could be some dilemmas here. Since the subcategory of a specific building will be placed under the campus category, and inside the building category there will be some interior images, that may indirectly imply that those interior images are under the campus category as well. However, removing either the images from the building category or removing the building category from the campus category may also be problematic. That's why I put them in the Maybe classification above.
Some of the points are problematic. If "Talks or presentations" should not be categorized as campuses they could not be categorized to the building where they take place as the building is part of the campus. It is very common to categorize events in the location they took place. GPSLeo (talk) 12:27, 14 August 2023 (UTC)
That'd be a question on whether the events should be categorized in the building or just a general category of events at that institution, and reserve the building category only for the images of the building. The first approach would not only create the same dilemma as the interior images problem, but also make most of the images fall under the campus category or its subcategories. Xeror (talk) 14:11, 14 August 2023 (UTC)
I disagree with the direction this is taking. Some colleges and universities (e.g. Antioch College, originally only in Yellow Springs, Ohio, but now in multiple U.S. locations) and the University of Washington (originally in Downtown Seattle, later moved to the present University District, and still later with additional campuses in Bothell and Tacoma) are both examples where a single university has multiple campuses, which for many purposes function as separate institutions. We would want to put a protest or an official activity under the relevant campus. In fact, almost anything other than a photo of a person, symbol, etc. associated with the broad institution would probably belong with a campus as one of its ancestor categories. - Jmabel ! talk15:17, 14 August 2023 (UTC)
That makes sense for institutions with multiple campuses, but I think the simplest example is something like Category:Endicott College, which clearly only has one campus, but still has the separate Category:Endicott College campus as a subcategory. "Campus" there doesn't mean that an image falls relates to some subconcept of the college located in a different place (since no such subconcept exists), but rather that it relates to the college's physical environment, i.e. its campus. That seems like the better way to use "campus" for our categorization purposes, and to be consistent, that should apply even to institutions that have multiple locations. {{u|Sdkb}}talk15:59, 14 August 2023 (UTC)
Right, but still, if a protest takes place on a campus that's recognizable, the campus should be one of the categories for the image. -- Ikan Kekek (talk) 17:11, 14 August 2023 (UTC)
It may entirely depend on the category tree in question. I have seen Category trees that have "Cat:Uni" with the subcats "Cat:Campus", "Cat:Buildings", "Cat:Staff" and so on. In that case, images showing just one Building from the outside, or its interior, don't really fall into "Campus", but "Building X". But all images of a student fair/presentation/protest/etc. in the open - those would be "Campus", as long as you can recognize the place as such. Pictures showing the entirety of Building A and Building B together with the trees in between, would go into "Cat:Campus", "Cat:Building A" and "Cat:Building B".
In another possible case where the category tree has the "Cat:Buildings" as child nodes of "Cat:Campus", I'd place the same picture just under "Cat:Campus", to avoid redundant categorizing. For both such cat-tree structures however, "Entrance hall of Building C" has to be placed in "Cat:Building C", not under "Campus" (as long as Building C has its own category). Of course, if a bland lecture room cannot be distinguished from any other, it would be placed under "Cat:Campus" or even the largest parent, "Cat:Uni".
I've studied both in a place with one large distinct campus, as well in a place with faculty buildings strewn all over the city, and only four of them somewhat grouped together. In my latter case, I would say that there is rather no campus at all, just various separate Uni-buildings. Jmabel's description of two distinct campuses just means (to me) that there should be two categories for them. Or seven, for seven Campuses, like the case of Category:University_of_São_Paulo. And extra-cats for all off-campus buildings of course.
The idea to harmonize categories is good, but I don't think we can define the ultimate criteria here, just rough guidelines. Not all unis have a full category tree, not to mention that they rarely have the same structure. Best, --Enyavar (talk) 18:30, 14 August 2023 (UTC)
In my view, a campus is a contiguous piece of land which accomodates the buildings and associated facilities of an institution. Ideally the institution itself should use the name campus to describe the various pieces of land and associated facilities. Translating this to Commons, we could have
Category: University of ABC
Category: University of ABC, PQ Campus
Category: University of ABC, XY Campus
The latter two would be sub-categories of the first. They themseves would have further sub-categories. Images would be slotted into the appropriate category. From the point of view of categories, think of ABC as a country and PQ and XY as provinces of that country. I don't see the problem, or am I missing something?. Martinvl (talk) 20:14, 14 August 2023 (UTC)
There is also "Category: University of DEF, PQ Campus" for shared campuses. And campuses shared by educational institutions and other organizations. GPSLeo (talk) 15:23, 15 August 2023 (UTC)
In this case there would be a number of options, depending on how the campus is shared. Are all the facilities shared between the two institutions or are only some facilities (eg student accomodation, parking and sports facilities might be shared, but accademic buildings separate)? Such cases houd be handled on a case-by-case basis using common sense, otherwise the rules will become unwieldy. Martinvl (talk) 20:17, 15 August 2023 (UTC)
Part of what I'm seeing in this discussion (which doesn't seem to be approaching much of a universal consensus) is the issues inherent in having a giant category tree, where we need to consider not just what it means for a category to have an image but what it means for all the categories above it. Someday we'll be using structured data to organize our content rather than traditional categories, and I hope that day isn't too distant. {{u|Sdkb}}talk20:37, 15 August 2023 (UTC)
The problem with Chinese unis is different universities used the same buildings in the campuses in different period of time. Haha, messier than spaghetti.
I largely agree with Martinvl's suggestion. To put it simply, treat university as an organisation and campus/building as a location/building. An organisation is a more abstract concept. It can have multiple locations and move from place to place. A building is fixed. It's a physically existent concept. Roy17 (talk) 12:31, 22 August 2023 (UTC)
Okay, so taking stock of everything, I'm seeing several different viewpoints, but not much movement toward a consensus definition, let alone one we could enforce. Anyone have thoughts about how we could move toward something that'd concretely help us to keep these categories better organized? {{u|Sdkb}}talk02:41, 24 August 2023 (UTC)
I think the key here is that a campus is a place (though it may coincide with an institution). I think it is actually clearest how to use this when the campus isn't the same as an institution (institution with multiple campuses that do not have any autonomy; multiple institutions sharing a campus), in which case it is simply a place, but more difficult for things like Category:University of Washington Tacoma, which is in many ways an institution in its own right, but shares the top administration with the other campuses (President, Office of the President, not sure how much else); it's sort of like a college within a university, but its orthogonal to that. - Jmabel ! talk15:35, 24 August 2023 (UTC)
I am very unhappy that User:Xeror is ignoring this discussion (which began on their own talk page, and was moved here) and is changing things left and right. I think changes like [8] are dead wrong. USC is basically a one-campus university, and that campus is, to the best of my knowledge, not shared with any other educational institution. There is almost no reason to have a separate category for the campus. This picture I took, which is clearly a picture of a building, no longer has Category:Buildings anywhere in its parent category tree! - 17:27, 25 August 2023 (UTC)
From the beginning, I have said that the word "campus" with its multiple definitions should be interpreted as a physical place rather than an institution (see my reply above). Several people expressed the same opinion as mine above. Xeror (talk) 16:03, 26 August 2023 (UTC)
@Xeror: so are you saying that you will clean up and make sure that pictures of buildings will end up back in "buidling" categories? I ask, because it seems to me that the category you removed in this case was precisely correct for this photo. - Jmabel ! talk16:45, 26 August 2023 (UTC)
@Xeror, mass changes require a high level of consensus. In this case, that means that agreement on what a campus category means needs to come before large-scale changes to implement that agreement. And it means that "several people expressed the same opinion as mine above" is not sufficient consensus when several others seem to have a different view.
I had a quasi-organized system at Category:Pomona College previously, where images that showed landscaping elements were put in the campus category, regardless of whether they were also depicting a specific building, whereas interiors of that building were not. You just came through and made a whole bunch of changes, and now I'm not sure what the standard is. Why is File:Closed Campus.jpg not put in the campus subcategory, but File:Pomona College Outdoor Education Center in April 2023.jpg is?
You've clearly been devoting a bunch of effort to this categorization initiative, and that's appreciated, but that effort is 99% wasted if there are no standards. Since otherwise the next person to come along in the future is going to have an entirely different understanding of what a campus subcategory is, and they're going to make a bunch of changes that will mess up your scheme, just as your changes have messed up existing schemes. We need to make some decisions here, and then to document them such that future editors will have guidance to rely on when editing in this area. {{u|Sdkb}}talk21:27, 26 August 2023 (UTC)
@Sdkb: I am not making mass changes. It's only to clean up the USC category. It is not ideal yet.
I might have missed one or two images so don't take my changes as a standard. The closed campus image should probably in the campus category too.
That being said, I have expressed my criteria above. Few people has addressed any of my criteria. However, this whole conversation has been shifted to "what is a campus?" rather than the original topic of "what images should be put in the campus category?" I honestly do not see this is going anywhere. Xeror (talk) 22:28, 26 August 2023 (UTC)
I think it is not redundant the category of the institution the should have a category for the campus to have is separate to staff or publications categories. And most universities will have external places with institutes or research stations. GPSLeo (talk) 14:27, 27 August 2023 (UTC)
Endemic and chronic copyright infringement
I haven't found a place to ask and I don't know if this is the best one. There is a user on Flickr named "Laura Buononome" https://www.flickr.com/photos/195828402@N06/ who violates the Italian copyright laws, publishes not open and non-free images on his account with "false new" a free license which are then washed and recycled here on commons by some years (see for example on this talk user all notifications of deletion https://commons.wikimedia.org/wiki/User_talk:Corvettec6r). Therefore I beg you to take the due and necessary measures, to blocking uploading of this photos. 5.91.94.6710:43, 23 August 2023 (UTC)
Those deletions were for failing to use a license template. There is nothing offhand to say the images actually were copyvios. Looking at https://www.flickr.com/photos/195828402@N06/, it looks to me to be likely to be one person's work. Unless I see some more evidence here, I see nothing to act on. - Jmabel ! talk15:40, 24 August 2023 (UTC)
i support blacklisting this account. most if not all photos have no camera data. they were taken in vastly distant places, e.g.
It could be useful as a hidden maintenance category to help identify photos of buildings known to be in that town that have a visible "10" on them. But that's about it. - Jmabel ! talk16:32, 23 August 2023 (UTC)
House numbers are used to identify a building, these cats help you locate a building from a bunch of similarly named streets, roads, crescents, places, closes, etc, etc, etc and also if you are not sure which borough your structure or street is located under. Thus these cats help you locate a particular structure. Your links only show the last time the Categories were edited not when they were created giving a false impression of how old they are/not Most of the London ones are from around 2015. I don't see any harm these cats do, if you don't wish to use them just ignore them. Oxyman (talk) 17:18, 23 August 2023 (UTC)
No that is incorrect you are misunderstanding what your links are showing, they show the last edit not time of cat creation. Oxyman (talk) 19:03, 23 August 2023 (UTC)
As to the first question, presumably you know as you link to the answer (begs the question why ask?) as to the second question why am I supposed to know? Oxyman (talk) 05:29, 26 August 2023 (UTC)
so it begs the question, but some fools are too foolish to even answer that correctly. "to be exact, at least (3051-394)/3051=87% were created after june 2018." was calculated based on the answer to that question. presumably even fools and horses would understand that, but what's more stupid than fools or horses? RZuo (talk) 07:07, 26 August 2023 (UTC)
Where did you get that number from? It's not your links as I said before you are misunderstanding what your links are showing, since I have no accurate number and you fail to link to credible numbers that you actually understand, neither of us know "to be exact" but what's more stupid than fools or horses who cannot accept they misinterpreted their own evidence. Oxyman (talk) 14:51, 26 August 2023 (UTC)
I daresay that whoever created this spurious cat in the first place, cognited at some point that they were wasting their time, and gave up on it. If you wanted to locate a property you would use Google streetview not commons. As far as streets go this is descriptive of nothing, therefore we should delete these cats. Complete curation would be impossible, beyond scope, and have little or no interest.
It's not the geographic location these are used to find (I would have said that was obvious) it's the cat at commons. House numbers are used to identify a building what else would you use to describe an individual building? It's geolocation? I'm hardly the only person to use these cats nor was I the first so others seem to find them useful. It's a little self-absorbed to suggest they should be deleted just because you can't see their use. Oxyman (talk) 15:04, 26 August 2023 (UTC)
I really despair at your not seeing this type of cat as unworkable. Far better to put in geo locations or if you must What3words references. It's always a catastrophe to try and make commons do something that it's fundamentally not designed for. commons is a repository, not a dynamic tool, as your trying to shoehorn it into here. How do these cats define, an image in any exact way? That’s why we shouldn't create them. Making cats hidden, renders them useless for research. Hidden cats are for internal maintenance, and cats of this type have no maintenance value. Broichmore (talk) 13:21, 27 August 2023 (UTC)
@Brichmore: the maintenance value is that when you encounter a third-party picture that has a street address number in it but does not have precise location data, these can help identify the building. Happens to me all the time in dealing with early 20th century photos. - Jmabel ! talk16:52, 27 August 2023 (UTC)
Rebecca Blacks single Friday is the internet meme in question but we cannot upload that to Commons for obvious reasons Trade (talk) 16:06, 24 August 2023 (UTC)
Surely, a second-level category such as "People involved in Internet memes" could contain cats such as Black's. I don't see why a person who is most strongly associated with meme culture should be entirely excluded from the category tree. Elizium23 (talk) 07:00, 27 August 2023 (UTC)
imo it's never appropriate to put a person cat directly under memes.
take Disaster Girl as an example. it should be organised this way:
cat:Zoë Roth
cat:Disaster Girl
all files related to the meme.
other files related to Zoë Roth but not the meme.
cat:Disaster Girl (but not cat:Zoë Roth) goes under cat:memes. and we dont need a "People involved in Internet memes".--RZuo (talk) 14:17, 27 August 2023 (UTC)
uploading photos I took but have published elsewhere
Hi, I plan to upload some photos I took, but have published in my personal blog before. What's the best way to do this? Still note sure after reading Commons:FAQ. Thank you very much! --Suiren2022 (talk) 21:38, 24 August 2023 (UTC)
@Suiren2022: The (typically) simplest way: if you still have access to the relevant blog pages, indicate the relevant license there where you used the photos, then upload and reference that as a source. (Or, if you are licensing all photos you used on the blog, you can indicate the license one place on the blog as covering all photos, and reference that in the "permissions" section of {{Information}}.) If that won't work, or would be difficult (especially if we are talking about a very large number of photos but not all, so that would be a lot of editing), there are other ways; just say here whether you want the other approaches listed out. - Jmabel ! talk22:40, 24 August 2023 (UTC)
Thank you. But what if I want to upload the photos directly from my laptop (instead of downloading them from my blog, and then uploading)? Should I still list my blog as the source of these photos, instead of my own work? Could I indicate in my blog that I am Suiren2022 at Wikimedia Commons, and upload those photos to Commons as I would do with those that haven't been posted before (putting source as: my own work)? --Suiren2022 (talk) 02:29, 25 August 2023 (UTC)
@Suiren2022: Yes, that would work. Also, on your user page here, link the place on your blog where you clarify that you are the same person.
The advantage of indicating the license on the blog and indicating the blog as the source is that it makes the chain of publication and copyright clearer. If you take your approach, don't be surprised if some of these get nominated for deletion by someone who doesn't put two and two together. Of course, if you contest the nomination for deletion you'll win and the image will be kept, but it might prove to be more hassle than dealing with it up front. Anyway, in theory having the blog and your user page link to one another suffices, and you can always go back later and do the "heavier lifting" if this proves to involve hassle. There are tools (notably VFC) that make it pretty easy to do any mass edits that are needed on the Commons side, but I do understand that marking a bunch of photos on an existing blog could be a royal pain. - Jmabel ! talk17:17, 25 August 2023 (UTC)
Have you considered uploading your new images directly by batch upload to commons, this would take care of the chore of assigning copyright. Then in your blog you could use those those photos by providing links direct to commons. The advantage being the photos ony need to be stored in one place, and copyright already assigned. Broichmore (talk) 10:43, 26 August 2023 (UTC)
That would involve editing many pages in the blog, which they are trying to avoid. Also, in my experience from a blog I maintained for a while, it's actually more hassle around being clear about licensing than the way Suiren2022 is doing it right now. - Jmabel ! talk16:53, 26 August 2023 (UTC)
They dont need to change any script from the past, just start afresh. If the images are only on commons, then their copyright status is held there, and there only. Seeing as they would be PD by definition, I dont see that this would add any kind of chore or overhead to him. Broichmore (talk) 13:28, 27 August 2023 (UTC)
@Broichmore: (1) why would they be PD? They have as much right as anyone else to use CC-BY-SA or another similar license. (2) These images are currently on their existing blog, presumably stored on the server that hosts the blog. How would it not involve major work to make their blog take the images from Commons instead? Not to mention that if you are simply deep-linking to get an image, that does not deal with attribution issues. - Jmabel ! talk16:59, 27 August 2023 (UTC)
Some blogging software (for example the micro blogging service Mastodon, probably also the blogging service Friendica) provide a way to verify the identity of authors between different platforms. This is supported by the MW software (RealMe extension). In commons preferences you can list the URLs of your blog(s) and insert links to your blog in your user page. They will be marked with the "rel=me" meta parameter and the backlink from the blog will show up as "verified". C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 22:57, 28 August 2023 (UTC)
The Enforcement Guidelines require a Building Committee form to draft a charter that outlines procedures and details for a global committee to be called the Universal Code of Conduct Coordinating Committee (U4C). Over the past few months, the U4C Building Committee worked together as a group to discuss and draft the U4C charter. The U4C Building Committee welcomes feedback about the draft charter now through 22 September 2023. After that date, the U4C Building Committee will revise the charter as needed and a community vote will open shortly afterward.
Well, I could not find a guideline for it and I think the opinions may vary a lot. This discussion (about the independence of Commons) does not depend on the outcome of this new question and therefor I suggest to address it in a separate discussion. JopkeB (talk) 05:34, 9 August 2023 (UTC)
I'm aware that's not what the discussion is about. I just thought I'd ask since it was brought up. I'm fine with starting a separate discussion about it if you prefer that though. --Adamant1 (talk) 05:40, 9 August 2023 (UTC)
I agree that there is no solid guideline, and I'd hate to create something rigid. My own personal rules of thumb:
Never create an empty category unless you are about to use it (within a few hours).
The only time to create a category for a single photo is when it is part of a sequence or systematic breakdown of another category (e.g if we have Category:PERSON by year and we already have categories for most dates in the 1940s but have only one photo of them for 1947, I'd probably create the Category:PERSON in 1947.
For two photos, I'd sometimes create a category if there is already a Wikidata item or Wikipedia article.
Otherwise, three is a bare minumum, and I probably wouldn't do less than four (usually five) if they already group together (sorted next to one another) as part of an existing category with less than 200 images. I'd be more likely to do the four or five with no Wikidata item or Wikipedia article if I either anticipate a future article, or I think we will have a lot more such photos.
I suppose I've pushed that a little sometimes when I have a lot of information about a person from roughly 100+ years ago and only a couple of photos; usually that also calls for making a Wikidata item, but I'll admit to sometimes being lazy about the latter when it's all stuff I can express via parent categories. - Jmabel ! talk15:26, 9 August 2023 (UTC)
cats should be created for unique concepts that are expected to get photographed easily, e.g. living celebrities, buildings. cats can be hooked up with wikidata which record lots of info. sooner or later more files will be uploaded. it makes it much easier to categorise those files with an established cat. if users with the knowledge of a concept cannot create the cat because of these stupid rules, then chances are the files will become mis- or uncategorised when they come. look at this bureaucracy https://commons.wikimedia.org/w/index.php?title=Special:Log&page=Category%3AMia+Khalifa . RZuo (talk) 07:13, 9 August 2023 (UTC)
I really have to disagree. That just sounds like a bad recipe for having thousands of empty categories because someone decided to pre-create them ahead of time and then dodged out half through their project or something similar. I much rather administrators delete a category 5 times over as many years then the inventible massive mess your recommendation would create. --Adamant1 (talk) 07:48, 9 August 2023 (UTC)
Empty categories they are liked to Wikidata are very useful for tools and especially new users. They can also speedup the workflow of experienced users. This of course only applies to topics like protected areas, mountains, or members of a parliament, where we expect to get photos of in the near future. We should not create empty or nearly empty "by year" categories. GPSLeo (talk) 07:14, 11 August 2023 (UTC)
Wikidata has essentially no notability guidelines outside of the entry needing to have a single external reference. So there's no guarantee that just because something has a Wikidata entry that it will every have images related to it uploaded to Commons. In fact, most never will. That's not even accounting for the fact that there needs to be someone willing to upload images related to it in the first place, which there often isn't.
I'd probably support either creating empty categories or ones with single images in cases where it's a clearly notable subject and there's a guarantee someone will upload images of it in the near future though. I just don't know how it would be enforced or tracked. Maybe we could create a special category system or template just for those types of categories like there are for DRs. I don't think they should be mixed in with normal categories though. At least not in mass. Otherwise it could easily make parent categories hard to browse through and/or maintain. --Adamant1 (talk) 08:53, 11 August 2023 (UTC)
Full agreement with Adamant on empty categories. As an addendum: A few rare times I have created Commons categories about notable people, where the images later got deleted, so the category is now an empty remnant. As long as it's about notable things and connected with an entry via Wikidata, I see no problem keeping such a category. --Enyavar (talk) 12:22, 11 August 2023 (UTC)
I like the proposal of Jmabel, here my comment and additions
Standards:
Categories should only be created for unique concepts. (RZuo) Agree We should avoid composite categories with concepts that are parent-child or siblings.
Three files and/or subcategories is a bare minumum to create a new category. Agree
Exceptions:
Four or five files is the minimum if the files already group together as part of an existing category with less than 200 images. Neutral
Two files if they have three or more parents in common. This is to avoid multiple overcrowded categories with the same files and to create better overviews. (added by JopkeB)
Two files or subcategories if there is already a Wikidata item (note: there should always be a Wikidata item if there is a Wikipedia article) Agree
One file or subcategory when it is part of a sequence or systematic breakdown of another category. Agree
One file if it is expected that more photos come easily, e.g. living celebrities, buildings. It makes it much easier to categorise new files with an established category. Agree
One file or subcategory if you are a user with knowledge of a concept and it is a notable subject. Agree
Should we allow empty categories? For instance because they are useful for tools and new users, and they can also speedup the workflow of experienced users, for subjects where we expect to get photos of in the near future, created by users with the knowledge of a concept, "by year" categories. Oppose I am not a supporter of creating and keeping empty categories. I can see the advantages but I doubt whether they outweigh the cons such as the mess described by Adamant1 on August 9. They should be very scarce and they always should have a note or template, like Adamant1 suggests, why they exist.
That sounds reasonable to me. Except with the caveat for number 4 that we shouldn't allow for one file or subcategory when it is part of a sequence or systematic breakdown of another category if either one is "by year" or has anything to do with "by year" categories. I agree with it other then that though. --Adamant1 (talk) 10:30, 11 August 2023 (UTC)
With the empty categories we maybe could make a guideline that they have to be maintained by an active WikiProject or by an annual photo competition. GPSLeo (talk) 10:52, 11 August 2023 (UTC)
Of course it is and should remain allowed to create a category with only 1 file, or just with a non-empty subcat. And if this category can be linked with a Wikipedia article and a Wikidata item via WD infobox, this is not only allowed, but also encouraged. Regards --A.Savin12:17, 11 August 2023 (UTC)
Hi, in my opinion the answer to the question is very much: "it depends". I would split possible categories into two kinds: specific (about 1 event/object/person: these categories should be allowed to be as tiny as needed) and non-specific (about any event/object/person that fits the criteria)
For the first:
there are very useful category structures where I create a new category just for a single picture, to complement the other branches of the same category tree. (Category:1977 elections in Morocco, which is part of "1977..in Africa", part of "..in Morocco by year", etc. I hope we will get more stuff in it, but one file suffices already.)
there are well-defined categories, like about one special book title. (Category:Stalky & Co. is perfectly fine with just 2 files. Although: If it's just one file from/about a book, I'd still prefer that file being properly categorized, without a new category.)
For the second:
I find three images on Commons depicting "Porcelain vases with horse paintings". That may seem to be a very clear category definition, possibly falling under "Porcelain vases with paintings" and "Horses in art", but it's still an arbitrary definition and with too few files matching the criteria. I'd rather supper "Horses in porcelain art", and then splitting that further as soon as the category grows too large, probably first dividing into statues and paintings. 6-10 files should be a minimum for such groupings.
this also goes for "location in time"-categories. Any event/work/building/map/photo/person/etc related to the history of Krakow, and created/photographed/happening/died/etc in 1879, may go into "1879 in Krakow". The definition is vague and arbitrary in a different way here, but still: There is currently one file. (Category:Kraków in the 1870s holds 7 files in total, but uses four categories to do so.) So for "history of location"-categories, I'd prefer "by decade" over "by year" and only create the latter once the decade-category gets overcrowded.
I sometimes find categories that are too small and if I am invested enough, I actively seek dissolution. Category:1840s maps of Lithuania now has 9 files which have previously been spread over 8 subcategories. I moved the files to the parent cat, and will at some point in the future ask for the deletion of the (now empty) sub-cats. As long as we don't suddenly get an influx of dozens more 1840s maps of Lithuania, these by-year-subcats are just too granular to be useful.
In other cases I often find categories that are "too small", but I'm not invested enough to start a debate: Category:Voting lines in India is granularly sub-divided by states of India, sometimes with just 2 pictures. That is in my opinion not how it should be, but it fits into "<theme> in India by state", so I'm not complaining.
Thanks for the comment, and I fully agree on "year books from country", but... Comment "year maps of country" stops being useful the further you go back into the past: Maps were drawn years after the surveys, maps were reproduced unchanged for years, decades and even centuries, maps were dated wrong by authors, archives and later by the uploaders, etc. So, I support navigation templates, but for most maps before the 20th-century, we shouldn't do breakdowns by year, but by decades instead. With exceptions for when there is lots of material of course. This whole thing is slightly off-topic here and I have pages more cases and material to discuss, so I leave it at that until me make it a whole own topic. --Enyavar (talk) 19:40, 11 August 2023 (UTC)
For named entities - specifically notable people - single file categories should be accepted and their creation should be encouraged. Even if it contains just one file, an individual category provides links to corresponding articles, increases the chance that further uploads are fully categorized and keeps the topical category pages tidy. Why would it be better if a category like Category:Members of the 11th German Bundestag contained 73 single files instead of the additional 73 single file categories for the respective persons? --Rudolph Buch (talk) 18:21, 11 August 2023 (UTC)
Take a more zoomed out perspective on this. The main purpose of Commons is for people to find media related to a subject, Not information related to it. To the degree that we do provide such information that's what file descriptions are for. In your example someone is either going to want to find "Members of the 11th German Bundestag" or an individual person who was a member. So in that case they will either search for Members of the 11th German Bundestag" which will give them the category so find images of multiple members, or they will search for a specific name and go the file for that person. If you create a category for each individual member your just create pointless intermediary steps that people looking for "members" have to go through to get the images. Like if I want images of five of them, I now have to go to the main category, click into the individual category, click the image, download it, click back into the individual category, click back into the main category, and do it all over again multiple times. It's just obtuse and creates browsing dead ends.
Whereas the person who wants in image for a individual member can already do that using the search box and clicking on the image of the person. So the category adds nothing. Same for the infoboxes since the information will (or at least should) already be contained in the file description. At least IMO the point in infoboxes is to provide general information about a subject people are browsing images related to. It acts as an orientation point. It's less about providing the raw facts to people who are looking for them because we aren't Wikipedia. It's not like we can't just link to Wikipedia or Wikidata in the file description either. But you want browsing images to be intuitive and have as little end points as possible. The ability to find out someone's birthdate in an infobox shouldn't come at the cost of adding 5 more levels of clicking to the user interface. You see that with "nested" categories that only contain a single category and no images a lot. There's instances out there where it turns into a game of clicking through 12 empty nested categories just to get to the a single image. At which point the person looking for said image has probably long wondered off out of frustration and found it through Google Image Search. --Adamant1 (talk) 19:28, 11 August 2023 (UTC)
You are right, single files should (usually) not get their own category, and I'm also a skeptic when it comes to empty categories. But once there is a second photo of a notable person, they are eligible for their own category (as per here), in order to have all media related to the person in the same place, and that includes removing them from other categories. Commons' categories are not curated image galleries, and "Members of the 100th U.S. Senate" has the same "problem" as the 11th BT above. Cheers, --Enyavar (talk) 20:58, 11 August 2023 (UTC)
@Adamant1: These issues are the same whether there´s a minimum of one, two or ten files for an individual category. With any minimum number you still have personal categories, just not for all of the files. And a mix means you got to look in two places instead of one. Mostly you describe a different problem: In many categories we do not distinguish between "feature of the related entity" and "feature of the actual motive". Our rules stipulate to categorize the image of a dinner plate under category "Mayors of New York" if the owner was one of those. I prefer to have the plate (or tombstone, residence, pencil sharperner etc.) in the specific mayor´s named subcategory, even it´s the only file there. Apart from that I agree that we have too many non-essential and non-reliable categories relating to people.- --Rudolph Buch (talk) 22:33, 11 August 2023 (UTC)
I prefer to have the plate...in the specific mayor´s named subcategory, even it´s the only file there. I have to disagree there. It's probably good to assumepeople will be looking for images of the mayor if they are searching for their name. Not some random plate that they eat dinner off of once. Whereas, people who are looking into plates will be interested in the image regardless of whom owned it. I could maybe see it for members of higher office, but we usually have other images of them in that case anyway. More broaderly though categories shouldn't be created unless the category will contain at least one image directly related to the subject. Otherwise the image should just go somewhere else. I don't think we should be creating categories for every person that we happen to have an image related to though. Otherwise we'd be creating single file categories for every non-notable person we have a passport, letter, gravestone, or whatever for. Which clearly wouldn't be useful. So you have to draw the line somewhere. --Adamant1 (talk) 22:57, 11 August 2023 (UTC)
@Rudolph Buch: I suspect your use of "motive" here is a false cognate from another language. I don't know what you mean by it. "Motive" in English means a reason for doing something. - Jmabel ! talk23:47, 11 August 2023 (UTC)
Right. ("Motiv" in German can have two meanings: Reason for doing something, same as motive in English, or "what is depicted in a picture". Deepl tells me I should have used "subject" or "motif" instead - which seems strange as the "Sujet" and the "Motiv" of a picture mean very different things in German.) Rudolph Buch (talk) 00:25, 12 August 2023 (UTC)
@Adamant1: the issue presumably isn't creating single-file categories for non-notable people where we have one artifact related to that person. I suppose there is someone who would consider doing such a thing (I've seen some seriously useless categories) but the issue there would be more about having an artifact related to a notable person when we don't actually have a picture of that notable person. I could easily imagine that happening with someone reclusive who doesn't like having their picture taken. For example, we happen to have pictures of Thomas Pynchon from the 1950s, but he's pretty much avoided having his picture taken since; we'd want Category:Thomas Pynchon even without those. If we ever had an image related to Elena Ferrante, we'd probably want a category for her, even if we still lacked a photo of her. - Jmabel ! talk23:55, 11 August 2023 (UTC)
Conclusions and questions
Since there was no addition for a few days, I think it is time to draw conclusions and decide what next steps to take.
Conclusions
There is no guideline yet.
Opnions vary a lot. What do we agree on?
Standards:
Three files and/or subcategories is a bare minumum to create a new category.
Exceptions: the minimum should be:
Four or five files if the files already group together as part of an existing category with less than 200 images.
Two files if they have three or more parents in common.
One file or subcategory if there is already a Wikidata item.
We do not agree on:
Allowing empty categories. So I suggest to keep the current policy of not having empty categories.
Categories with only one file or subcategory in special cases, and there is no Wikidata item yet. I suggest to allow them to be created scarcely and leave it to the judgment of the editor whether to create one. Though often it would be better to have such single files and subcategories in a more general category.
I have no problem with any of this, as long as it is understood to be a guideline, not a rigid standard. There will always be some reasonable exceptions. - Jmabel ! talk15:42, 15 August 2023 (UTC)
I did not take part in the discussion, but was reading along and I also think these are all good points that could be included as a guideline in some way. Kritzolina (talk) 15:58, 15 August 2023 (UTC)
Yes, I agree, also with a longer abstract and examples. So it will have a page of its own, something like Commons:Amount of elements in categories? I am open for a better name. Then there could also be a paragraph about the maximum amount, with long lists as an exception, but that is another discussion.
Questions:
Do you agree to have a guideline for this matter with our conclusions?
What would be a good name for such a page?
How do we implement this? Should we discuss the content of the guideline here, or does someone make a proposal and shall we discuss it on the Talk page of the new page?
I say implement it. Adding some examples would be helpful to but they can always be added after it's implemented. --Adamant1 (talk) 04:37, 16 August 2023 (UTC)
What's wrong with it being a guideline? If we just call it a "best practice" then there's no reason anyone would follow it. Plus there would just be the same kind of arguing over when to create categories or not that already exists and this is suppose to hopefully solve. The whole point in this is to figure out standards that can (and should) actually be followed. Not just to write a toothless essay about "best practices" that will just be ignored. --Adamant1 (talk) 05:36, 16 August 2023 (UTC)
Strict guidelines for a category system that has to handle complex edge cases could lead to disputes on cases where following the guideline is not the best solution. GPSLeo (talk) 11:28, 16 August 2023 (UTC)
I don't really see how it's strict to allow them to be created in some cases or to leave it up to the judgment of users whether to create the category or not. Especially if the guideline includes examples. That's essentially how things are done now. It will just be more formal. As to it increasing disputes, there's plenty of disputes already that are caused by there not being a guideline. I don't think there will be more if there is one because a person can just use their judgement and create the category if they want to. Baring a few specific instances that will covered by the guideline, but they already can't create categories in those instances anyway, or at least they will receive push back and be blocked if they do. This just makes it more formal so it doesn't take them re-creating the categories and people leaving them multiple warnings not to create the categories before it's can be dealt with. --Adamant1 (talk) 12:01, 16 August 2023 (UTC)
I don't think we should have a rule on minimal number of files in a category, apart from disallowing empty categories. Whether a category is useful or not, is seldom a matter of the number of files in it, but much more frequently of its scope, naming, formal correctness, and quality of its media content. As Enyavar correctly pointed above, it depends. Thanks --A.Savin12:06, 16 August 2023 (UTC)
There's cases where its clearly not good to create categories that only contain a single file or category. For instance by year categories where there's only one file for a single year in the decade. There's currently nothing stopping people from doing that. In fact a user recently did it in mass for "stamps by year" categories where the stamps from the years he was created categories for were copyrighted, and refused to stop until he was eventually blocked. Maybe I'm being naive, but I'd like to believe things like would be curbed or at least easier to deal with if there was a guideline making it clear not to create categories in such an instance. --Adamant1 (talk) 12:19, 16 August 2023 (UTC)
Agree I prefer a guideline as well. There are 96 million files now, and perhaps hundreds of editors (or more). To let them categorize more or less the same way, let them not make a mess of the categories and to avoid disputes over and over again, we should have enforceable rules/guidelines. JopkeB (talk) 16:32, 16 August 2023 (UTC)
Strong oppose any hard line on the minimum number of pages in a category above 0. Empty categories are already subject to Speedy Delete, so no change required on that. There are thousands of categories with only 1 or 2 files in them that are perfectly valid, so a policy to not allow 1- or 2-file categories anymore would be a huge problem. Categories with a well-developed set of 'by country', 'by year', 'by quantity', 'by color', etc. are a good example of this. Let's take a use case:
A user uploads an image of a green item. They see that categories exist for red, orange, and blue items of the same kind, but there is none for green items. Normally, they could simply create the green item category and add their image to it, but the proposed 3-item minimum would prohibit that action unless they additionally commit to searching around and finding an additional 2 green item images to add to the category as well. For an experienced category crawler, this is not a high bar, but for a lot of users, this is going to incentivize them to no longer sort their uploads by color (in this case) and instead just dump them in main categories, leaving the load to others to diffuse them.
I'm all for encouraging such a user to then go to the main cat and move green items into their new category, but that should merely be encouragement, not policy.
Adopting such a policy would cause all existing 1- or 2-file categories to be targeted by well-meaning users seeking to comply with this policy, either by calling for their deletion in COM:CFD or just simply taking direct action themselves to delete large numbers of existing categories on the basis that they have fewer than 3 files.
Note also, by giving a minimum number, not only are you communicating that no category should have less than that number, but also, inherently that any category with at least that number is perfectly fine. You might not be meaning that, but that is the message that many readers will take away from it. That will make this ammunition for nonsense categories to be defended on the basis they have more than 3 files in them.
Of course, I note the exception for those with WD items, but this has its own issues. Does this mean that it is perfectly fine to create 1-file nonsense categories as long as the user creates a WD item to go with it? The existence of a Commons category is on its own justification for a WD item, according to WD notability policy. So making a the existence of a WD item a justification for a Commons category just seems like a circular logic chain at that point.
I'm also not sure why this would need to be spelled out in any place different than COM:CAT itself, but since I oppose this policy period, I suppose that might be a moot point what page it is put on.
I do like some of what King of Hearts and Crouch, Swale have come up with at Commons:Category inclusion criteria, as it is more nuanced and covers more of the different use cases that exist for categories. I haven't fully digested it and might have some detail reservations before supporting adopting it as more than an essay, but it seems to be a significant improvement over the arbitrary rules proposed in this discussion.
Personally, I think whether sub-categories make sense or not has more to do with the content of the main category than on any specific number of images for a specific sub-category. If there is a product with 6 images, 4 or type A and 2 of type B, this policy would mean a category for type A is okay, but not for type B. In my mind, that is nonsensical...we should either have a subcategory for each type or a subcategory for both type. The decision should be based on the parent category and whether it is useful to diffuse that category by a given criteria. Josh (talk) 18:44, 18 August 2023 (UTC)
The proposed guideline should point out that users should look for certain aspects to judge whether or not a "tiny" category makes sense for the grouping of images that they wish to apply it to. As far as I understand guidelines, they are purposefully notpolicies or hard lines, but essentially infomaterial. (Like most guidelines, most people won't read or know them, but they can be great to show to inexperienced users to explain some practical considerations around categories). I'd also like to note that we do have a category for green items. We do not have a category for "Porcelain vases with horse paintings", and I while that appears to be valid category name, I would still discourage people from creating it without overarching structures being in place (see my comment pretty much at the start, regarding specific and non-specific categories). --Enyavar (talk) 19:19, 18 August 2023 (UTC)
@Joshbaumgartner: As Enyavar says, guidelines aren't hard and fast rules; they are descriptions of what is normal. Also, your hypothetical "green items" would be fine, because it is part of a breakdown into parallel categories (essentially, one of a series, even if in this case a series with no particular order). - Jmabel ! talk20:29, 18 August 2023 (UTC)
@Jmabel: I agree that there is a difference between guidelines and policies. However, the wording of this proposal, regardless of whether it is officially labeled as a policy or a guideline, is very specific and has all of the hallmarks of being a bright red line. Many users are not fully aware of semantic difference guidelines and policies, and so if it is only to be a guideline, it should be written as one. Language such "standards" and "minimum" and using exact numbers are the language of rules and are appropriate for policies. If we really want to just have a guidline, language changes should include:
Replace "Standards:" with "Guidelines:"
Replace "Three files and/or subcategories is a bare minumum to create a new category." with "It is preferable to add multiple (ideally 3 or more) files or sub-categories when creating a new category."
Replace "Exceptions:" with further guidelines for other situations. Exceptions apply to rules, in that they are a list of acceptable cases that don't fit within the predescribed rule. Guidelines don't need exceptions, just simply list any further guidelines that might apply.
For the most part, the proposals under Exceptions are too specific to be needed in a guideline,
You yourself noted that it was important that this proposal only be adopted as a guideline, not as policy. We are in agreement on that. It is important however that we not just label it as a guideline, but write it as one as well. The original proposal was not presented as being only a guideline (or at least that wasn't made clear), and it was following comments such as your own that mentioned it should be a guideline. To that end, my opposition to a hard line policy remains, and it sounds like you agree that a hard line policy should not be adopted. As a guideline, if rewritten as one, I could see some value in it, see Commons:Category inclusion criteria as a good example of that kind of thing. Josh (talk) 21:04, 18 August 2023 (UTC)
@Enyavar: It is not clear whether the original proposal is intended merely as a guideline, or as a policy. The fact that it is written like a policy not a guideline doesn't help. See my note above on some ideas on how to reword it if it is to be a guideline. I'm not sure what you are going on about green items for (Category:Green items actually does not exist), my comment was not specifically about Green objects (what you actually were think of?), it was a hypothetical...replace 'green items' with 'green foos' if that is easier to get as such. It sounds like you agree with my opposition to adopting this proposal as a hard line. Hopefully, we can do some rewording to ensure that if adopted as a guideline, it doesn't get mistakenly mis-applied as a policy. Josh (talk) 21:15, 18 August 2023 (UTC)
So far, I think this is an affair of shadowboxing in the ivory tower. I am unaware of any proposed text that might get included into the possible future draft of a suggested guideline page. Once I find such a text, I will gladly participate in the discussion about how to amended it, so that it won't be understood as a hard guideline: The principle of having guidelines for categories is something I support, as long as it doesn't become restrictive, which was why I dropped my 2c in the first place. I still think that we can distinguish our categories into "specific" vs "unspecific" (or however we name that concept ontologically), and build the recommendations around that. Either way, there will be divergent and special cases that I/we/you haven't even considered yet and that will mess up the first guideline draft - regardless how the guideline turns out. --Enyavar (talk) 21:44, 18 August 2023 (UTC)
That's what I was going to say. No proposal is the completely, fully fleshed out guideline. Also, Jmabel said at the beginning of the discussion "I agree that there is no solid guideline, and I'd hate to create something rigid" and their comment is what the proposal was based on. No one has said they think it should be a policy or hard and fast rule in the meantime. I've actually gone out of my way several times to call it a guideline and said it should ultimately be up to the user to decide when it's appropriate to create single file categories, baring a few examples that everyone agrees on. So this is clearly an exercise in shadowboxing. Could the specific wording of the guideline be ironed out once it's implemented? Sure, that has nothing to do with the merits of the proposal though. Again, no proposal is the final, complete, document and no one is saying that specific wording can't or won't be changed once the guideline is actually written out. --Adamant1 (talk) 22:09, 18 August 2023 (UTC)
Josh wrote: "The existence of a Commons category is on its own justification for a WD item, according to WD notability policy." but that is not quite right, only for exceptions, see Wikidata:Notability nr. 1.4:
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 Commons-categorie category for pictures taken with equipment (P2033).
I think if there is a Wikipedia article or otherwise its likely the topic would be notable then generally only 1 page is needed. Many places like the Brosdale Island example may currently have only a few pages but obviously more can be added if more images are uploaded. If someone wants to take a few pictures of a named building and upload them I don't see why we can't have a category as it could still have more images and defining it is easy. If someone wants to take pictures of say a cloud or small plant without a name and upload then then having a category for cloud at 7 June above Summertown, Vermont for a few pages would be a bit more dubious though. Generally I'd say there are not many rules with notability as, if a topic isn't notable then its likely the images (say of a person or company) can be deleted as being out of scope and then the category deleted as empty. Crouch, Swale (talk) 08:42, 19 August 2023 (UTC)
Summary of the remarks on the conclusions of 15 August + new questions
It should be a guideline, not a rigid standard.
Our conclusions should not become a part of Commons:Categories (official policy), but of Category:Commons guidelines, where we can create a longer abstract, and/or add examples/cases.
Someone can start the page with a first text, others can add examples and other remarks, we can discuss the proposal on the Talk page.
Remarks about the content:
Because it is only to be a guideline, it should be written as one, and not have words like "standards", "minimum" and exact numbers. The original proposal was written as a policy, so it should be rewritten as a guideline. At least some words and lines should be replaced:
Replace "Standards:" with "Guidelines:".
Replace "Three files and/or subcategories is a bare minumum to create a new category." with" It is preferable to add multiple (ideally 3 or more) files or sub-categories when creating a new category."
For the most part, the proposals under Exceptions are too specific to be needed in a guideline. At least replace "Exceptions:" with "Further guidelines for other situations".
The guideline should point out that users should look for certain aspects to judge whether or not a "tiny" category makes sense for the grouping of images.
@JopkeB: something like that. Plus "amount" would almost never be preferable to "quantity" in a context like this, it's just not the word one would typically use in something at all formal. - Jmabel ! talk15:28, 24 August 2023 (UTC)
@RZuo: doesn't that potentially become circular? You can create a Wikidata item for virtually anything that can be defined, so this could allow virtually anything to be turned into a category. For example, for an area I've worked in, Wikidata would consider it acceptable to create an item for every identifiable individual who ever taught school in Seattle Public Schools, but surely we don't want a separate category for each of those people from whom we have one photo. - Jmabel ! talk18:13, 22 August 2023 (UTC)
my personal standard is higher than what's practised here on commons. there're plenty of cats that cannot be linked to wikidata, e.g. Category:Brittany Wagner (model).
(clarifying what i mean by linking to wikidata. i would create an item only if statements about its existence on other notable websites can be added. again, my standard is higher than what's practised on wikidata. there're items that hinge on a single mention in some obscure databases, e.g. most of the "scholarly articles", most cbdb entries like Yuan Kuangfu (Q65920297)...)
i dont create items for every teacher in public high/primary schools, but every professor in a university should be eligible for a wikidata item. if someone creates those items, that's their problem.
the proposed mechanic rule would rule out perfectly normal things, but fail to prevent trivial things that would pass the rule.
one easy way to generate enough number of elements for any category of a unique concept is uploading pronunciation of its name. you can set your number to be as much as 60 but then people just need files in 61 languages, or have both male and female recordings in 30 languages. so easily bypassed, what stupid rule is that? RZuo (talk) 19:20, 22 August 2023 (UTC)
My final conclusions:
We still do not agree on the minimum number of files/subcategories a category should have.
If we now would make a guideline, it would not be the document that at least I had in mind when we started this discussion. It would become a toothless, non-binding document that cannot be used or referred to in discussions and deletion requests. I will not start such a guideline.
It is useless to continue this discussion, because we'll never agree, no matter how many viewpoints we will add or how long this discussion will last. The positions are too far apart.
For WikiShootMe, the problem stil persists. But at night I noticed an interesting phenomenon: while a new window with WikiShootMe could not be opened using the link, the window open before was still working and loading the current data. --ŠJů (talk) 14:23, 1 September 2023 (UTC)
Wikimedia Summit 2024 will be happening in April, and will probably be the last meaningful chance for input to the Movement Charter, which will probably determine a great deal about Wikimedia governance going forward, including (indirectly, but almost without a doubt) a lot about how money and resources are allocated. Because the "community" (vs. Foundation) involvement for the conference is entirely through affiliates and user groups -- not through "projects" such as Commons -- there is no overt representation for Commons at the Summit. When I raised this question, someone pointed out that there will be a representative of the Commons Photographers User Group (I'm not sure whom, and there is no indication on that page), but of course the focus (so to speak) of that group is much narrower than that of Commons as a whole.
If we, as a community, have concerns that we would like represented in Berlin in April, we would do well to identify those concerns, and either (1) organize them in a way that they can be brought into the discussion by one or more of us who are already attending, or (2) see if we might be allowed belatedly to form a Commons User Group and be represented that way. I think a lot of Commons' likely concerns are different than those of the various Wikipedias, and may be very underrepresented in what is largely a gathering of geographical and topic-based groups.
Just in general, it concerns me that the basis for representation at the Summit seems to completely ignore the many users, probably the majority of users, whose involvement is strictly on-wiki. I raised that issue in today's "engagement session," and while some other participants clearly shared my concern, the response from those running the session was somewhere between "the train already left the station" and a massive shrug. I don't question their good intentions, but it appears to me that if Commons as a community has concerns about the Charter, we are going to have to make a very active effort to bring those forward, we will not be pro-actively consulted. (Similarly for anyone not involved in affiliates or user groups, and whose participation is strictly on-line.) - Jmabel ! talk20:46, 29 August 2023 (UTC)
thx for the tipoff.
as i saw the location could be conveniently reached, i jumped to the page you linked, only to find out, as you did, that users without any affiliation are not eligible at all. there're not even any wildcard or first-come-first-serve walk-in places. seriously? it appears not only commons but also wikidata doesnt have affiliate groups? so the two most important cross-project wikis cannot have representation? what the fun...
without your tipoff, i'm totally unaware of such things taking place either, even though i'm active on-wiki almost daily. yet this is the sort of the things that make decisions about wiki projects?
with all that money spent on talking shops, when will wmf finally put aside a bit for developing essential tools like video2commons. RZuo (talk) 08:23, 1 September 2023 (UTC)
I noticed people cropping (particularly automobile) photos a lot over the last few years. Sometimes it is beneficial, where the subject otherwise only occupies a small section, but sometimes it seems wholly unnecessary and just makes for pointless additional files. See a few examples. Are there any relevant guidelines for when it's worthwhile to create new crops? Thanks, mr.choppers (talk)-en-03:20, 30 August 2023 (UTC)
The first is such a minimal crop as to be a bit bizarre; hard to see why anyone would care about the few pixels difference, but apparently the person putting it in an article did. I see you are the original uploader: did you ask the person who did this why they did it? The second: well, I probably wouldn't have uploaded that photo if I'd taken it -- hard to see a use for it -- but the cropped version is probably a bit better composition.
Do keep in mind: storage is cheap. I believe the only downsides to additional files are possible clutter in categories, and possible dual maintenance issues if further edits are to be made to the files. - Jmabel ! talk05:56, 30 August 2023 (UTC)
Totally agree with the sentiments made here, these particular croppings are as good as downgrades. As an aside we shouldn't be blurring out license plates on cars, rather we should upload the original with the plate, and then overwrite them with a smudged version. After 25 years revert them, the plates are historical items in their own right. I also don’t hold with the right to privacy bollocks that comes out about blurring the plates either, I doubt very much whether the owners would even know or even care. I'm guessing they would be as pleased as punch to see their car here. Broichmore (talk) 09:57, 30 August 2023 (UTC)
The first example makes a difference of 2% in pixel dimensions. I think crops should only be exeucted to show a detail inside an image or to crop out irrelevant space like white paper without content. The thing with the license plate is that unfortunately there is no option to publish an image 25 years later right now. --PantheraLeo1359531 😺 (talk) 20:59, 30 August 2023 (UTC)
Sometimes very slight crops make sense (e.g. to get rid of some inconvenient artifact very near an edge of a photo), and if you don't have the original uploader's/photographer's permission it is probably best to do that under a new filename. But here I see no obvious good reason. PageOrganizer, can you explain why you made this crop? - Jmabel ! talk22:44, 30 August 2023 (UTC)
Thank you all, I feel the same way. Broichmore, I always blur the license plates as that is what I tell people when they catch me photographing their cars. You'd think people would like having their car on WP, but I have been threatened on many occasions (and it's not just Americans, a German once was upset that I uploaded a picture of her car with her face blurred and demanded 200 Euro), a guy showed me a gun once (upstate NY), so if it makes car owners more comfortable to have the plates blanked then I will certainly do so - FOP be damned. Look here for another unhinged example. I believe they think that I will take a piece of their soul by photographing their publicly parked vehicles. If I upload the original and then overwrite, someone could always revert it and make a liar out of me. I have twice gotten out of uncomfortable situations by showing my WP uploads with anonymized photos. mr.choppers (talk)-en-10:58, 31 August 2023 (UTC)
For Germany: As far as I know, it is not necessary to make license plates unrecognizable if no information about private persons is disclosed via the license plate. The plate itself is therefore usually not a violation of privacy or data protection, since it usually does not reveal any information about the owner. However, the location of the car with a license plate may reveal something if the vehicle is parked on private property. In short, an identifiable license plate is a violation of privacy rules only under certain conditions. Only the police can look up who the owner of a car with the corresponding license plate is. See more here (German): https://www.anwalt.de/rechtstipps/autokennzeichen-auf-fotos-erlaubt-update-17-11-2022-203209.html --PantheraLeo1359531 😺 (talk) 15:31, 31 August 2023 (UTC)
Hi Jmabel, the reason I had made two crops is because when I made the first crop, it was squished (it was only squished for me, which I didn't realise until later), and I didn't know how to revert it back to original, so I had made a copy of the image. Sorry about this PageOrganizer (talk) 11:30, 31 August 2023 (UTC)
Images sometimes take up too much vertical space on wiki pages (desktop), so I tend to remove as many pixels as possible above and below the subject. --Sitacuisses (talk) 12:05, 1 September 2023 (UTC)
That’s epic-level infringement against the principle that Commons should not editorialize in other projects… I would say that this concern is to be addressed when, in another project, the editor thereon choses a suitable illustration from Commons, picking the desired ratio — be it square or oblong, portrait or landscape — among a wealth of available options, and then judiciously tweaks the |upright= image parameter for the best result. Cropping all images in Commons to be squar-e/-ish or landscape seems to be the worse way to go about it. -- Tuválkin✉✇01:34, 6 September 2023 (UTC)
Best way to have images reviewed(?) and permission made clearer
I came across some files I later realised were part of the Miles Glendinning Tower Block archive. Although many were good-quality images, it wasn't at all clear to me whether the source link supported the claimed CC-BY-SA-4.0 license. (Since this is the default license, it quite often appears on copyvios).
A bit of checking showed that they were indeed legitimate and part of a collection. The site says:
The images on the site are made available under a Creative Commons Attribution licence, meaning they may be distributed and re-used as long as credit is given to the original creator, Prof. Miles Glendinning.
However, I don't think all this is sufficiently clear on the image file pages themselves.
My thoughts were that we should have these formally reviewed and possibly the description amended with a link to the permission page and others. But I don't want to jump in and bulk edit all 167 images(!)
Any thoughts?
I'd like to thank Crowsus (talk·contribs) for the upload of these useful images and make clear that no criticism is intended here, I just want to help make the status of these images clear so we don't run into any problems in the future. Ubcule (talk) 18:26, 29 August 2023 (UTC)
@Jmabel: - That's one idea, thank you. As I mentioned, I'm not sure how finding out that there seems to be a separate and much larger upload of the same archive- partially overlapping with this one and with its own dedicated template- changes what should be done. My gut reaction is that the two categories should be combined anyway. Ubcule (talk) 21:41, 29 August 2023 (UTC)
The two categories can merged, they are exactly the same thing, I just uploaded ones I wanted in 2018 (those are in the Miles Glendinning folder) whereas the other is a bulk upload of everything in the collection 3 years later (obviously I'd not have gone to the trouble had I known that was in the pipeline!) Obviously the higher quality images should be retained and the more formal (original from site I think?) labelling and permissions should be used too. I would like the categories of 'my' versions to be retained if possible as they are much better than the bulk set's generic ones. I don't even mind copying them over manually before mine are overwritten - if that is what is to happen - if someone could give me a heads up when that is likely to take place. Crowsus (talk) 22:12, 29 August 2023 (UTC)
@Crowsus: - Yes, I noticed that the categorisation of your images was more comprehensive, so we'd want to keep that. (Also, your filenames are more descriptive as to the specific details, e.g. File:Trottick.jpg vs. File:Tower Block UK photo sc 1141800.png. The bulk uploads all include the original literal filename but nothing descriptive, so they're less clear in that respect.)
However, the example above also draws attention to the fact that the versions of the images in your upload aren't identical to thosesome of the files in the bulk upload by PaulineDataWard (talk·contribs). I notice that yours come from towerblock.eca.ed.ac.uk (e.g.) whereas the bulk ones come from datashare.ed.ac.uk (e.g.).
The example above:-
is a PNG (rather than JPG) file,
has higher resolution, and
has noticeably different colour rendition- while the bulk version appears more saturated (vivid), its colour also looks distinctly less natural in the sky and especially the grass (i.e. it's not just the same as your version with the saturation turned up).
(Side note on that last point- which those not interested in the technicalities can ignore!- my gut reaction was that this looked more like a colour space issue than colour balance or saturation. And lo and behold when I loaded up the bulk version- whose profile was "Adobe RGB"- and assigned the standard "sRGB" profile to it it then looked identical to yours other than the higher resolution.)
tl;dr - The versions of the files from the two sources are different, higher resolution versions are probably better though there may be some minor issues with colour? A few of the bulk upload images are different, most are not(!)
@Crowsus: - I've looked into this and there are a few points:-
Turns out that none of your original uploads are exact duplicates of files still on Commons. Any files within the bulk upload which were identical to any of yours were deleted and redirected to your (older) upload (e.g. this edit by Túrelio (talk·contribs)).
Only problem is that your original uploads (i.e. the ones that were retained) don't have the full descriptive text scraped from the website that the bulk uploaded versions did. It'd be good if there was an easy way to recover and combine that with your upload automatically (while keeping your categorisation), but I can't think how.
I've partially renamed your uploads in Category:Miles Glendinning Tower Block archive for greater consistency with the bulk upload names, but retained the descriptive parts (e.g. "Airdrie 1988-2.jpg" became "File:Tower Block UK photo cl1-07 (Airdrie 1988-2).jpg") and everything else. (They remain within your original category for now until I've double-checked that each of them have been correctly added to Category:Tower Block Archive or one of its subcategories.)
Ignore what I said above about the .png/.jpg versions as this only applies to circa 20 images (all associated with Dundee for some reason) so likely isn't worth worrying about.
OK thanks for the update. If need be, it will be a lot quicker to recategorise as I got Cat A Lot last year and I can recognise most if not all of the towers I uploaded by sight, so wouldn't take long. But will wait til whatever needs fixed is completed of course. Crowsus (talk) 19:30, 6 September 2023 (UTC)
Barriers to Cross-Platform Collaboration - Wikipedia / Commons
In The Signpost an interesting article based on interviews with editors on Commons and (English) Wikipedia:
After a cursory reading, it seems that categories is the culprit. Heh, not even in my most dishevelled curmudgeonly of rants I would resort to hyperbolize that the WMF would try to mask their failiures in Commons by pointing a finger to “power users” and our work with categories. And yet, here we are. -- Tuválkin✉✇02:07, 1 September 2023 (UTC)
One of the main solutions suggested in the article is to increase our use of Wikidata. I hope as it becomes more prominent, it will indeed help us in the ways suggested. Regarding the Boeing 777 section, I don't think there's actually a problem there needing solving. It is overwhelming, but there's lots of positives to our extensive collection of pictures of Boeing planes. I think our "Good Pictures" system, though a bit hidden away, can be a great system for letting users find the quality pictures for general usecases. ~Mable (chat) 07:36, 4 September 2023 (UTC)
I didn't realize until reading this article that I had only checked English Wikipedia for requested photos, despite the fact that I live in Japan. Checking the Japanese Wikipedia there's many more requested photos for places in Japan including even in my town.Photos of Japan (talk) 10:45, 5 September 2023 (UTC)
I seldom look at Requested Photos at all, because they are so sparse and seldom accompanied by geographic coordinates. WikiShootMe shows a map with red dots. It doesn't depend on a particular language, except whatever languages are used to describe a particular Wikidata item. The majority of the red dots are unimportant, being for things that no longer exist or don't need a photo. And some of the green dots could use a second or third picture, but on the whole it's a rich list of targets.
As for putting pictures in our tangled category tree and finding them, I've often wondered why we don't use #HashTags. Our two most used systems of tagging require some kind of registration in advance. Category, or Depicts, must first be created in Commons or as a WD Item. Categories must fit into correctly determined places in the existing tree, and Wikidata Items must fit into an existing Properties network. Hashtags just grow spontaneously; the uploader need not understand the existing structure. The majority of hashtags end up not really mattering, but there are usually enough good ones to work modestly well. And, once established, they could be connected to, or perhaps replaced with, Cats & Items by habitual cat wranglers such as me. Jim.henderson (talk) 23:51, 7 September 2023 (UTC)
Redundancy 'Wikidata Infobox' and 'Object location' in category descriptions
or copied from somewhere and identical (with a certain precision) to the wikidata coordinates. Often a legacy problem, as {{Object location}} was there before {{Wikidata Infobox}}.
Bots are cleaning up stuff shown in the {{Wikidata Infobox}} elsewhere in the category description, but not for {{Object location}}. I'm consolidating redundant coordinates and removing {{Object location}} manually when I stumble accross. But in general it would make sense to
remove {{Object location}} per bot in the two cases above (where nearness of coordinates due to rounding should be used instead of identity)
and afterwards consolidate coordinates wherever necessary. Let's see what is left after first step. Coordinates should be corrected on WD and {{Object location}} should be removed from the category description.
In principle, that's reasonable. The problem is that I think there are more eyes watching Commons for vandalism than watching Wikidata, so at this time getting rid of explicit coords in Commons probably makes us more vulnerable to vandals. But we've already accepted that risk for birth & death dates, so I guess we've crossed the bridge. - Jmabel ! talk15:47, 24 August 2023 (UTC)
Support. I have often wondered about this situation, but rarely dared to remove {{Object location}} due to a lack of relevant guidelines/precedence. Personally, I think coordinates attract less vandalism than other data on Wikidata, so I am not too concerned. --HyperGaruda (talk) 23:35, 24 August 2023 (UTC)
@HyperGaruda: but, like changing a date, it is very insidious vandalism when it happens, because it is so hard to tell a legitimate correction from vandalism. - 02:24, 25 August 2023 (UTC)
@HyperGaruda: Only if there are landmarks to go by. If we have (for example) an old picture of someone hiking in a forest, and someone changes the coords, it is very hard to tell a correction from vandalism. - Jmabel ! talk17:09, 25 August 2023 (UTC)
Would the categories in question not almost always be for landmark-type features? At least I have a hard time coming up with other categories that need coordinates and I don't think Cat:Hiking in forests will be one of them. How would you tell the difference in the current Commons-based situation anyway? --HyperGaruda (talk) 08:15, 26 August 2023 (UTC)
@HyperGaruda: You are right, I am wrong. I was thinking of an issue that has arisen for photos (moving coords into the SDC), not categories. (There might be the occasional category for an event that has a particular location, but that's an edge case.) - Jmabel ! talk16:50, 26 August 2023 (UTC)
if vandalism is the concern, and hinders us removing / consolidating duplicate and eventually contradicting coordinates, we are done. I do it manually anyway. Wasn't there a feature planned to protect some properties by special rights? I check the compactness of coordinates on WD from time to time using something like this query. BTW, if there is an infobox with a map, I do not have a look at other coordinates (unless I'm there for checking purposes).
Some bots do copy coordinates from the descriptions to SD and nobody seems to care for the messages when the redundant information is not in sync any more. I suppose, we have a much bigger problem with wrong coordinates than with vandalism on coordinates. --Herzi Pinki (talk) 18:18, 25 August 2023 (UTC)
Oppose: Ever since Wikidata and SCD were inflicted on us, I have solved countless «discrepancies» between the geolocation data in a file’s {{Object location}} or {{Camera location}} or a cat’s {{Object location}} and the geolocation data transcluded thereon from Wikidata via {{Wikidata Infobox}}. In all those cases, the latter was wrong — that maybe due to Wikidata’s porosity to spammers and vandals, to its smaller community, to its own workflow… I don’t know and I don’t care: What I care about is accurate geolocation data in Commons’ file and cat pages, and that can be achieved by {{Object location}} and/or {{Camera location}}. Should a discrepancy occurr, it should be manually fixed by human users who actually know the subject, and Wikidata is very welcome to syphon off that sanitized info back to its GIGO machine (as it did and does with with so much of Commons’ content), to be therat eventually mangled and confused again at which time rinse and repeat. -- Tuválkin✉✇02:32, 1 September 2023 (UTC)
Do you synchronize back to WD discrepancies you have found, @Tuvalkin: ? Or don't you care for the discrepancy and fix only the commons location? (Until someone comes around and fixes it the other way round). If the commons coordinates are much more reliable than the WD coordinates, and we can agree on that, we could as well remove the coordinates from the Wikidata Infobox instead for the purpose to solve the redundancy. My process is to fix the coordinates on WD and than remove the {{Object location}} here on commons. I admit, I do not care for the location copied to SDC. Your point Tuválkin is about data quality and not about vandalism (if we assume good will for all those automatized copy-pasters). {{Camera location}}, btw, is something completely different and not in the scope of my proposal. --Herzi Pinki (talk) 09:24, 2 September 2023 (UTC)
I do attempt to synchronize every time I notice one of those distance/discrepancy notices in a file or cat. When Wikidata and global login are working properly (so, about 90% of the time), I successfully enact that synchronization. There might have been cases when that correction was later undone on the WD side, but right now I cannot track any example.
While I’m no friend of Wikidata, even I can see how having that discrepancy warning can be beneficial to both projects. Is it confusing for the casual browser? Maybe, but Commons is a wiki, we don’t hide the wrinkles: «Hey look, right now two repositories curate this item’s geolocation with different values, it will be fixed.» The casual browser should become used to this kind of things.
ok. thanks. My primary proposal was to remove {{Object location}}when the location is identical or nearby to the WD location (or even just taken from WD by using parameter wikidata=). In this case either both are correct of both are wrong, but wrong location will not jump into your eyes. Then as a second step to manually consolidate divergent locations. There is no sense in keeping them just to make readers get used to this kind of discrepancy. I think, this does not in any way contradict your intentions. best --Herzi Pinki (talk) 13:29, 2 September 2023 (UTC)
If you remove {{Object location}} from a page, trusting Wikidata will keep the data carefully curated by human users, experience says it will not work. Keeping both sets of values causes no harm when they agree and is a useful warning to curators when they don’t.
Even in the odd case that vandalism or honest mistake currupts the data on Commons’ side (it can happen), having its previous value in Wikidata as a sort of backup would simplify a later correction.
I cannot see any advantage in the proposed removal and I ask for this section to be closed: This deceased equine is pinning for the fjords.
This section is resolved and can be archived. If you disagree, replace this template with your comment. --JopkeB (talk) 02:35, 22 August 2023 (UTC)
Moved from User talk:Xeror#Campus categories
.svg/15px-Pictogram_voting_comment_(orange).svg.png)
Comment: It is quite difficult to separate professional from amateur musicians. I know some people who get some money for playing during Saturday balfolks. Are they professionals or amateurs? Yann (talk) 09:19, 7 August 2023 (UTC)
Done.
Agree Only create a Commons category when there are sufficient files for (and give it a name according to the Commons rules). JopkeB (talk) 05:00, 9 August 2023 (UTC)
. At best it means more categories to list, confusion for users on where to find what they are looking for, and increased work load on category maintainers. In practice it means inconsistent categorization, both of files directly and within category tree structure, and files end up in different corners, some of which will innevitably be less maintained than others, leading to problems such as the category rot mentioned by User:Adamant1. Josh (talk) 14:13, 11 August 2023 (UTC)
. JopkeB (talk) 06:29, 17 August 2023 (UTC)
Question Why is a public domain mark insufficient proof of an image being in the public domain? Sometimes, I think we make too much work for ourselves on this site. -- Ikan Kekek (talk) 17:12, 14 August 2023 (UTC)
Neutral
Oppose I am not a supporter of creating and keeping empty categories. I can see the advantages but I doubt whether they outweigh the cons such as the mess described by Adamant1 on August 9. They should be very scarce and they always should have a note or template, like Adamant1 suggests, why they exist.
Strong oppose any hard line on the minimum number of pages in a category above 0. Empty categories are already subject to Speedy Delete, so no change required on that. There are thousands of categories with only 1 or 2 files in them that are perfectly valid, so a policy to not allow 1- or 2-file categories anymore would be a huge problem. Categories with a well-developed set of 'by country', 'by year', 'by quantity', 'by color', etc. are a good example of this. Let's take a use case:
Original.jpg/250px-2023_Lexus_RX_350_Premium_Plus_in_Matador_Red_Mica%2C_rear_left_(cropped).jpg)
Crop
.jpg)
_-_geo.hlipp.de_-_37961.jpg){kind=link}
_(Iran)_logo.gif){kind=link}
.jpg){kind=link}
.jpg_(Cropped).jpg){kind=link}
.jpg){kind=link}
![[7]](https://upload.wikimedia.org/wikipedia/commons/thumb/7/7b/Red_f55%2C_green_0c0%2C_blue_55f_and_their_distortions.png/30px-Red_f55%2C_green_0c0%2C_blue_55f_and_their_distortions.png){kind=link}
.jpg){kind=link}
_(cropped).jpg){kind=link}
![[8]](https://commons.wikimedia.org/w/index.php?title=File:USC_School_of_Cinematic_Arts_03.jpg&diff=prev&oldid=795842883){kind=link}
.jpg){kind=link}
Support. I have often wondered about this situation, but rarely dared to remove {{Object location}} due to a lack of relevant guidelines/precedence. Personally, I think coordinates attract less vandalism than other data on Wikidata, so I am not too concerned. --HyperGaruda (talk) 23:35, 24 August 2023 (UTC)