Commons:Village pump

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES (index)
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2023/08.

Please note:

  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page:

Search archives:

   
 

Start a new discussion

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Misattributed lithographic plates 4 3 Ooligan 2023-08-15 17:10
2 How independent is Commons in deciding which categories are appropriate? 44 8 Jmabel 2023-08-16 20:10
3 Overwriting historical photos 13 6 Broichmore 2023-08-14 13:46
4 Category:Panama photographs taken on 2020-05-26, ad nauseum 14 9 Prosfilaes 2023-08-12 19:26
5 Category:Daniel Gottfried Reymann 3 2 Yann 2023-08-16 09:10
6 Regarding security of image 8 3 Broichmore 2023-08-14 14:08
7 Non-FP chosen as POTD 5 5 C.Suthorn 2023-08-12 02:29
8 How many files and/or subcategories should a Commons category at least have? 45 12 King of Hearts 2023-08-16 17:02
9 Sound barriers 2 2 A.Savin 2023-08-11 11:58
10 Upscaling AI 7 6 Ooligan 2023-08-15 20:19
11 NSFW category madness 14 7 Ikan Kekek 2023-08-14 17:08
12 Photoshop being used on mainspace wiki image? 4 3 Broichmore 2023-08-14 14:27
13 Export 2 2 HyperGaruda 2023-08-12 11:48
14 Special:Upload appears to be broken 7 5 Pi.1415926535 2023-08-16 19:48
15 How should we define what is a photo of a campus? 14 7 Sdkb 2023-08-15 20:37
16 Mass-revamping of image copyright tags 12 7 Jmabel 2023-08-16 20:00
17 Main page missing several types of Commons files 1 1 Pigsonthewing 2023-08-15 04:34
18 Upload Wizard should allow trusted users to import Flickr images regardless of claimed licence 1 1 Pigsonthewing 2023-08-17 02:55
Legend
  • In the last hour
  • In the last day
  • In the last week
  • In the last month
  • More than one month
Manual settings
When exceptions occur,
please check the setting first.
Village pump and gaslight at a meeting place in the village of Amstetten, Germany. [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive
Template: View   ■ Discuss    ■ Edit   ■ Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

August 01[edit]

Misattributed lithographic plates[edit]

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.

Just a heads-up for anyone working on such images. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 1 August 2023 (UTC)Reply[reply]

@Pigsonthewing, Thank you for noting this issue. -- Ooligan (talk) 02:03, 8 August 2023 (UTC)Reply[reply]
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)Reply[reply]
@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)Reply[reply]

August 04[edit]

How independent is Commons in deciding which categories are appropriate?[edit]

This is about Commons:Categories for discussion/2022/12/Category:Production and manufacturing but the outcome of this discussion might have far-reaching consequences for more Commons categories and our independence.

  1. 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.
  2. 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.

Is Clusternote though right? Did I miss or misinterpret something? --JopkeB (talk) 08:14, 4 August 2023 (UTC)Reply[reply]

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)Reply[reply]
All things being equal they should line up, but there are many categories useful for a media repository that are not useful for an encyclopedia, and vice versa. Certainly there are many areas where our naming does not line up with en-wiki (e.g. en:Category:American writers vs. Category:Writers from the United States because we try to keep things easier for non-native-English-speaking users and contributors. And equally clearly some categories quite useful for one are useless for the other: Category:June 2023 in Washington (state), en:Category:Fourteenth Amendment to the United States Constitution. - Jmabel ! talk 15:16, 4 August 2023 (UTC)Reply[reply]
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:
  1. 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.
  2. 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)Reply[reply]
@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.
  1. 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.
  2. 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.
  3. 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.
The last item is one of my efforts for over 10 years on Commons, and it is not so difficult thing. --Clusternote (talk) 02:22, 6 August 2023 (UTC)Reply[reply]
You are making this way too complicated. No, we don't need to model every concept that is modeled in Wikipedia, nor do they need to model all of ours. Wikidata can deal perfectly well with topics being conflated in one wiki and separated with another. That's what wikidata:Help:Modelling/Wikipedia and Wikimedia concepts#Compound Wikipedia articles is about. - Jmabel ! talk 04:05, 6 August 2023 (UTC)Reply[reply]
Clusternote: Do you agree that wikidata:Help:Modelling/Wikipedia and Wikimedia concepts#Compound Wikipedia articles offers a solution to the problems you described here? --JopkeB (talk) 04:22, 8 August 2023 (UTC)Reply[reply]
@JopkeB: Thank you for mention for me, I could catch up the discussion. --Clusternote (talk) 06:16, 8 August 2023 (UTC)Reply[reply]
@Jmabel: I will take your comment (too complicated) at face value. What is the best way to get things done without too complicated method, may be the important issues for us.
And thank you for introducing the Wikidata help page. Although the section "#Compound Wikipedia articles" is not about the category but about the article, a top section "#Wikipedia categories" on that help page provides a solution for the issue of unity constraint, mentioned on fifth paragraph on my previous post. (by using "category combines topics (P971)" instead of "category's main topic (P301)", on Wikimedia category (Q4167836).) Thanks! --Clusternote (talk) 06:16, 8 August 2023 (UTC)Reply[reply]
Thanks, Clusternote, for your reaction.
  1. Are there any problems left concerning the independency of Commons regarding categories?
  2. Can we reframe your first two points to (the third one looks an opinion to me, with too many if's to reframe):
    1. There is no not always a direct one-to-one correspondence between the categories of other Wikimedia projects and the Commons categories, and Wikidata has not been able to can perhaps not always provide an appropriate mapping. (@Jmabel: is this right? Or can your solution always provide an appropriate mapping?)
    2. 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 (talk) 08:51, 8 August 2023 (UTC)Reply[reply]
@JopkeB: Sorry, I've merely replied to Jmabel, and I didn't agree with you. You seems not read what I wrote.--Clusternote (talk) 09:12, 8 August 2023 (UTC)Reply[reply]
@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 ! talk 18:19, 8 August 2023 (UTC)Reply[reply]
Well, for me that would be a solution as other solutions cannot be applied. JopkeB (talk) 05:45, 9 August 2023 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
1) See d:Wikidata:Requests for comment/Proposal to create a separate section for "Commonswiki" links; here you can leave your comment/opinion about linking from a Wikipedia article to a Commons gallery, category or both.
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)Reply[reply]
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)Reply[reply]
"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 ! talk 18:01, 8 August 2023 (UTC)Reply[reply]
 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)Reply[reply]
The question is what's sufficient? 1 file or more then that? --Adamant1 (talk) 05:05, 9 August 2023 (UTC)Reply[reply]
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)Reply[reply]
This part of the discussion has been moved to Commons:Village pump#How many files and/or subcategories should a Commons category at least have? The outcome may be used in the sequel of this discussion. --JopkeB (talk) 04:34, 11 August 2023 (UTC)Reply[reply]

Status/Resume[edit]

Questions:

  1. 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)
  2. 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)
  • A solution for topics being conflated in one wiki and separated in another can be found on Wikidata:Help:Modelling/Wikipedia and Wikimedia concepts. (Jmabel)
  • 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)
  • If there are no media on Commons related to an article in a sister project, there should not be a Commons category. (Jmabel) (See also discussion: Commons:Village pump#How many files and/or subcategories should a Commons category at least have?.)

Questions still open:

  1. @Clusternote, GPSLeo, Jmabel, Joshbaumgartner, C.Suthorn, Yann, and Adamant1: Is this an accurate resume?
  2. 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?
  3. 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?

--JopkeB (talk) 06:46, 11 August 2023 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]
I is useful as in most cases we want and will have more than one photo in the future. GPSLeo (talk) 07:37, 11 August 2023 (UTC)Reply[reply]
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)Reply[reply]
That is why I added the requirement that there is a corresponding Wikidata item. GPSLeo (talk) 09:09, 11 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
I agree with that: WD entry + (at least one) file = Commons category. Simple and easy. Yann (talk) 12:16, 11 August 2023 (UTC)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
 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)Reply[reply]

Conclusions and questions[edit]

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).

For the minimum amount of files in a category, also in relation to Wikidata: see the outcome of Commons:Village pump#How many files and/or subcategories should a Commons category at least have?.

Questions
Questions for at least @Clusternote, GPSLeo, Jmabel, Joshbaumgartner, C.Suthorn, Yann, and Adamant1:

  1. Do you agree with the conclusions?
  2. If yes:
    1. 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).
      1. Do you agree?
      2. 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?
    2. Where on Commons could the other conclusions be included, especially the ones about
      1. The links to Wikidata, on Commons:Wikidata or Commons:Wikidata infobox help or somewhere else?
      2. The independence of Commons.

--JopkeB (talk) 07:27, 16 August 2023 (UTC)Reply[reply]

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)Reply[reply]
Idem. These conclusions may not be set in stone for the next eon, but OK for now. Yann (talk) 09:04, 16 August 2023 (UTC)Reply[reply]
Just until the next discussion about this subject . JopkeB (talk) 06:29, 17 August 2023 (UTC)Reply[reply]
  1. '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.)? 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"?
  2. 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.
  3. 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 ! talk 20:10, 16 August 2023 (UTC)Reply[reply]
    @Jmabel:
    @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.
    @2: OK.
    @3: Yes, I agree, but apparently not everyone is convinced of the independance of Commons. JopkeB (talk) 06:24, 17 August 2023 (UTC)Reply[reply]

August 05[edit]

Overwriting historical photos[edit]

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)Reply[reply]

Commons:CropTool.--RZuo (talk) 08:58, 6 August 2023 (UTC)Reply[reply]
@RZuo: relevant how? [User:Bubba73]] didn't say they wanted to upload a crop. - Jmabel ! talk 15:27, 6 August 2023 (UTC)Reply[reply]
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)Reply[reply]
@Bubba73: copy the wikitext of an existing page, then upload with Special:Upload, paste, and edit the text as you wish. - Jmabel ! talk 03:42, 7 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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 edits 09:57, 8 August 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
We used to have Commons:derivativeFX for this. Not sure if it still works, doesn't seem to recognize me as being logged in in the first step ... El Grafo (talk) 08:24, 10 August 2023 (UTC)Reply[reply]
That sounds like what I was asking for! I'll try it the next time I have one to do. Bubba73 (talk) 17:32, 10 August 2023 (UTC)Reply[reply]

Here is an example: File:Richard Russell (1).jpg the color is terribly wrong. I want to correct it, but it s a historic photo. Bubba73 (talk) 17:40, 10 August 2023 (UTC)Reply[reply]

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)Reply[reply]

August 06[edit]

Category:Panama photographs taken on 2020-05-26, ad nauseum[edit]

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)Reply[reply]

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.
Elizium23 (talk) 05:00, 6 August 2023 (UTC)Reply[reply]
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)Reply[reply]
they have not existed for a long time. they first emerged only in October 2015. see Commons:Village_pump/Archive/2023/07#Category:2020_photographs_of_Hannover.
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)Reply[reply]
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)Reply[reply]
the proliferance of these cats was probably due to User:TommyG's 2018 edit https://commons.wikimedia.org/w/index.php?title=Template:Taken_on&diff=prev&oldid=293868907 .--RZuo (talk) 14:39, 6 August 2023 (UTC)Reply[reply]
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)Reply[reply]
"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)Reply[reply]
"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 ! talk 15:32, 6 August 2023 (UTC)Reply[reply]
+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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]

August 09[edit]

Category:Daniel Gottfried Reymann[edit]

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)Reply[reply]

German: Daniel Gottlob Reymann. --Raugeier (talk) 15:36, 9 August 2023 (UTC)Reply[reply]
@Raugeier: Thanks a lot. I merged the WD item. Yann (talk) 09:10, 16 August 2023 (UTC)Reply[reply]

Regarding security of image[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
[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)Reply[reply]
"However, the material has to be reproduced accurately..." reads like a prohibition on derivative works, so I think this may not comply with COM:L. —‍Mdaniels5757 (talk • contribs) 19:05, 9 August 2023 (UTC)Reply[reply]
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)Reply[reply]
  • 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)Reply[reply]
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)Reply[reply]

August 11[edit]

Non-FP chosen as POTD[edit]

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)Reply[reply]

✓ 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.
b) I don't know how to prevent. I would support an Abuse filter, but don't know how to write it. --A.Savin 01:17, 11 August 2023 (UTC)Reply[reply]
maybe a bot that checks next two days' potd is more suitable.--RZuo (talk) 07:31, 11 August 2023 (UTC)Reply[reply]
Why should such a bot wait until two days before the POTD? The bot could monitor the creation of POTD-template-pages and raise a notification as soon as one is created. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 02:29, 12 August 2023 (UTC)Reply[reply]
I've added a FP as POTD on August 18th. --XRay 💬 07:41, 11 August 2023 (UTC)Reply[reply]

How many files and/or subcategories should a Commons category at least have?[edit]

Moved from Commons:Village pump#How independent is Commons in deciding which categories are appropriate?: up to and including contributions of 9 August 2023. JopkeB (talk) 04:29, 11 August 2023 (UTC)Reply[reply]

When can we on Commons create a new category? Only when there are sufficient files for. JopkeB (talk) 05:00, 9 August 2023 (UTC)Reply[reply]

The question is what's sufficient? 1 file or more then that? --Adamant1 (talk) 05:05, 9 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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 ! talk 15:26, 9 August 2023 (UTC)Reply[reply]

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)Reply[reply]

@JopkeB: this was a response to "18:01, 8 August 2023 (UTC)". now the context is lost.--RZuo (talk) 07:31, 11 August 2023 (UTC)Reply[reply]
I am sorry. But I thought this part would fit better here. --JopkeB (talk) 09:01, 11 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

I like the proposal of Jmabel, here my comment and additions

  1. Standards:
    1. Categories should only be created for unique concepts. (RZuo)  Agree We should avoid composite categories with concepts that are parent-child or siblings.
    2. Three files and/or subcategories is a bare minumum to create a new category.  Agree
  2. Exceptions:
    1. 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
    2. 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)
    3. 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
    4. One file or subcategory when it is part of a sequence or systematic breakdown of another category.  Agree
    5. 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
    6. One file or subcategory if you are a user with knowledge of a concept and it is a notable subject.  Agree
    7. 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.

--JopkeB (talk) 10:04, 11 August 2023 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]
  • 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.Savin 12:17, 11 August 2023 (UTC)Reply[reply]
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.
These are my thoughts, I think my opinions overlap a lot with Jmabel and Jopkeb --Enyavar (talk) 12:22, 11 August 2023 (UTC)Reply[reply]
 Comment Empty categories are useful for "year maps of country" (Category:1850 maps of India) or "year books from country" (Category:1550 books from France), as if the category is missing, it breaks the navigation via the template. These cases there are many potential files for them. Yann (talk) 12:33, 11 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@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 ! talk 23:47, 11 August 2023 (UTC)Reply[reply]
Maybe "motif" was meant? -- Tuválkin ✉ ✇ 23:56, 11 August 2023 (UTC)Reply[reply]
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)Reply[reply]
@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 ! talk 23:55, 11 August 2023 (UTC)Reply[reply]

Conclusions and questions[edit]

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.

Questions
@Adamant1, Jmabel, RZuo, GPSLeo, Enyavar, A.Savin, Yann, Rudolph Buch, and Tuválkin:

  1. Do you consent to these conclusions?
  2. If yes: what is the procedure to include these conclusions in Commons:Categories?

--JopkeB (talk) 03:32, 15 August 2023 (UTC)Reply[reply]

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 ! talk 15:42, 15 August 2023 (UTC)Reply[reply]
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)Reply[reply]
Commons:Categories is an official policy though, and this appears to be a significant change if we were to place it on that page. I don't think it fits there, but rather into Category:Commons_guidelines, where we can even create a longer abstract, or examples/cases. --Enyavar (talk) 16:01, 15 August 2023 (UTC)Reply[reply]
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:
  1. Do you agree to have a guideline for this matter with our conclusions?
  2. What would be a good name for such a page?
  3. 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?
@Adamant1, Jmabel, RZuo, GPSLeo, Enyavar, A.Savin, Yann, Rudolph Buch, Tuválkin, and Kritzolina: What do you think? JopkeB (talk) 04:15, 16 August 2023 (UTC)Reply[reply]
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)Reply[reply]
If we call it „Best practice“ and not a strict guideline or even policy I would be fine. And the {{Prospective category}} should still be usable. GPSLeo (talk) 05:14, 16 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
1. Yes, I think it is a good idea
2. Commons:Minimal requirements for categories
3. I think we should create a page and discuss on the talkpage of the Commons:Categories page where to link it Kritzolina (talk) 06:19, 16 August 2023 (UTC)Reply[reply]
Thanks, Kritzolina, for your input and clear answers to my questions. Only, "Minimal requirements" is much broader than only the amount of files and subcategories, and is already largely covered by Commons:Categories. JopkeB (talk) 16:19, 16 August 2023 (UTC)Reply[reply]
  • 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.Savin 12:06, 16 August 2023 (UTC)Reply[reply]
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)Reply[reply]
 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)Reply[reply]

Sound barriers[edit]

I havent found any category for sound barriers. examples: File:Rotterdam CS Thalys 2023.jpg, File:Ludwigsfelde - Laermschutz (Sound Barrier) - geo.hlipp.de - 37961.jpg, File:Sound barrier alongside The Becket School - geograph.org.uk - 4088478.jpg. Smiley.toerist (talk) 11:56, 11 August 2023 (UTC)Reply[reply]

Category:Noise barriers. --A.Savin 11:58, 11 August 2023 (UTC)Reply[reply]

Upscaling AI[edit]

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)Reply[reply]

In general, we recommend against upscaling photos. - Jmabel ! talk 23:59, 11 August 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
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)Reply[reply]
Everything you said there would be anethema to an institution archive, or even indeed to a professional reseracher. It's important to keep the original image intact, even if its a tiff. "Improved" copies are permissable too, but they are just that copies. Broichmore (talk) 14:02, 14 August 2023 (UTC)Reply[reply]
@Broichmore, @Jmabel, @Njardarlogar I agree with all your comments.
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)Reply[reply]

August 12[edit]

NSFW category madness[edit]

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 ! talk 00:14, 12 August 2023 (UTC)Reply[reply]

  • 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)Reply[reply]
    • @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 ! talk 16:52, 12 August 2023 (UTC)Reply[reply]
      Why not talk to the creator of the navigation template? Trade (talk) 18:03, 12 August 2023 (UTC)Reply[reply]
      The Category:Topless men showing chest hair is a very curios one as visible chest hair requires to be topless. And the {{People nav}} template on the page is even more useless. "Topless babies (female) showing chest hair"? Really? Category links should at least make sense on a biological basis. GPSLeo (talk) 18:06, 12 August 2023 (UTC)Reply[reply]
  • (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)Reply[reply]
Why can not we just remove red category links from the files? Or is there something I possibly misunderstand? Ymblanter (talk) 18:56, 12 August 2023 (UTC)Reply[reply]
@Ymblanter: feel free, at least as far as I'm concerned. I'm just saying I'm not taking on polishing these particular turds. - Jmabel ! talk 21:35, 12 August 2023 (UTC)Reply[reply]

Depicts human penis (Q8124)[edit]

@Trade: may I ask why, on a photo that shows an entire human from the knees up (several, actually, but only one appears to be male) and where a penis makes up less than 1% of the area of the photo, you choose to add human penis (Q8124)? The picture also depicts a face, a chest, arms, body paint, and also a ukelele, all far more prominently than the penis. Why is this a good use of depicts (P180)? At best this is as if I said File:Donald Trump (53066688047).jpg (Cropped).jpg depicts incisor (Q273543). - Jmabel ! talk 21:47, 12 August 2023 (UTC)Reply[reply]

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.Savin 21:59, 12 August 2023 (UTC)Reply[reply]
  • 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)Reply[reply]

Photoshop being used on mainspace wiki image?[edit]

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)Reply[reply]

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)Reply[reply]
Thanks! REDMAN 2019 (talk) 12:06, 12 August 2023 (UTC)Reply[reply]
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)Reply[reply]

Export[edit]

This File is not copyrightable right because of Iranian government emblem in it en:File:Worker House (national trade union center) (Iran) logo.gif Baratiiman (talk) 08:52, 12 August 2023 (UTC)Reply[reply]

@Baratiiman: some other countries have exceptions to their copyright laws if it is a government publication, but such an exception is not mentioned in Commons:Copyright rules by territory/Iran. Please provide a legal basis for this alleged government non-copyrightability. --HyperGaruda (talk) 11:48, 12 August 2023 (UTC)Reply[reply]

August 13[edit]

Special:Upload appears to be broken[edit]

Tracked in Phabricator
Task T344207

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 ! talk 04:42, 13 August 2023 (UTC)Reply[reply]

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)Reply[reply]
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…
-- Tuválkin ✉ ✇ 23:05, 13 August 2023 (UTC)Reply[reply]
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)Reply[reply]
@Jmabel, @Pi.1415926535: I wonder if this is the same problem as Commons:Help desk/Archive/2023/07#Can not upload new version of image. Weird repeating problem. If it is, turning off the "ImprovedUploadForm" gadget might help. --bjh21 (talk) 12:27, 15 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

How should we define what is a photo of a campus?[edit]

Moved from User talk:Xeror#Campus categories

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.

Cheers, {{u|Sdkb}} talk 15:11, 13 August 2023 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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.
For the company campuses, there is at least one non-educational campus under category:Campuses in the United States. If there is a need (e.g. when there are too many subcategories), we can always split it into more specific ones. Xeror (talk) 09:44, 14 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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 ! talk 15:17, 14 August 2023 (UTC)Reply[reply]

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}} talk 15:59, 14 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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}} talk 20:37, 15 August 2023 (UTC)Reply[reply]

August 14[edit]

Mass-revamping of image copyright tags[edit]

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)Reply[reply]

VFC is a tool for something like that. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 10:32, 14 August 2023 (UTC)Reply[reply]
Seconding what C.Suthorn says. I do this sort of thing all the time. - Jmabel ! talk 15:19, 14 August 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
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)Reply[reply]
  •  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)Reply[reply]
    @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 ! talk 20:30, 14 August 2023 (UTC)Reply[reply]
    @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)Reply[reply]
    • @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 ! talk 00:32, 15 August 2023 (UTC)Reply[reply]
@SuperWIKI you could simply use "Append everywhere (categories etc.)" to append {{PD-USGov-Military-Army}}. RZuo (talk) 13:38, 16 August 2023 (UTC)Reply[reply]
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)Reply[reply]
  1. 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...
  2. 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.
  3. 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.
  4. 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.
Jmabel ! talk 20:00, 16 August 2023 (UTC)Reply[reply]

August 15[edit]

Main page missing several types of Commons files[edit]

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).

Please discuss at Talk:Main Page#Images Sounds Videos ... and? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 04:34, 15 August 2023 (UTC)Reply[reply]

August 17[edit]

Upload Wizard should allow trusted users to import Flickr images regardless of claimed licence[edit]

Tracked in Phabricator
Task T281599

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.

Similarly, the wizard could be extended to import PD images from eBay (typically, old postcards and ephemera) on the same basis. An example file is File:Market Place, Salisbury - Mabbett postcard - obverse.jpg.

Please express your support for allowing such uploads by trusted users. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 02:55, 17 August 2023 (UTC)Reply[reply]

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.
Also: Any programmer could create an external tool that makes upload by URL available to everyone (only limited by the positive/negative lists for allowed websites) C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 07:08, 17 August 2023 (UTC)Reply[reply]
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)Reply[reply]

Lua error in Module:Autotranslate at line 72: No fallback page found for autotranslate[edit]

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.


Anyone to help?--TaronjaSatsuma (talk) 06:58, 17 August 2023 (UTC)Reply[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=793875219"