Commons:Village pump

Shortcut: COM:VP

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

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

COMMONS DISCUSSION PAGES (index) Commons Help desk Village pump (general discussion) Copyright Proposals Technical Graphics and photography discussion Photography critiques Image improvement Illustration workshop Map workshop Photography workshop Video and sound workshop Categories for discussion Undeletion requests Deletion requests Volunteer Response Team/Noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests Oversight requests Telegram IRC webchat Commons mailing list (archive) Commons' bugs on Phabricator Welcome to the Village pump This page is used for discussions of the operations, 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: If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias. Have you read our FAQ? For changing the name of a file, see Commons:File renaming. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer). Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam. Purposes which do not meet the scope of this page: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound workshop. For translation requests, please post at Commons:Requests for translation. For media requests, please post at Commons:File requests. Search archives:       Start a new discussion

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.

The last town pump to be in use in Saint Helier, Jersey, until early 20th century [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Should Commons opt-in to global abuse filters, or opt-out from them? (22 March 2023) Overhaul of categories by period (5 December 2022) Tolerate users to upload pre-1949 Chinese books (13 November 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) 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.

July 23

Is Wikimedia Commons blocked in Pakistan?

I have just been a week in Pakistan, and I could not open Commons (it starts loading and gets loading forever). All other Wikimedia projects I tried opened withot any problems. Pictures embedded into Wikipedia articles are shown. Do we know anything about this? Ymblanter (talk) 14:21, 23 July 2023 (UTC)

en:Internet censorship in Pakistan doesn't mention Commons. It says that a block on "Wikipedia" was lifted in February. There's an Arabic version of that article, which is really outdated. IIUC, images are proxied/cached for the articles, which is also why you can see a pseudo-info page for them with a tab called "View on Commons".

Did you try any specific URLs beyond the Main Page? What about the mobile site? Elizium23 (talk) 14:39, 23 July 2023 (UTC)

I could not load the main page, the watchlist, and some specific page, but I do not remember which one. I did not try mobile version. Ymblanter (talk) 15:00, 23 July 2023 (UTC)

But the result was consistent over the whole week. Ymblanter (talk) 15:01, 23 July 2023 (UTC)

Media files are hotlinked from upload.wikimedia.org/wikipedia/commons/... so it is absolutly possible. that commons.wikimedia.org is blocked and upload.wikimedia.org is not. Maybe it was an error, when the blocking of wikipedia was lifted. commons.wikimedia.org has been forgotten and uploads.wikimedia.org may haver never been blocked at all. C.Suthorn (@Life_is@no-pony.farm) (talk) 20:01, 23 July 2023 (UTC)

Thanks. Is there any place I should report this for WMF? Ymblanter (talk) 06:59, 24 July 2023 (UTC)

There are several email addresses on the WMF contact page. Yann (talk) 07:43, 24 July 2023 (UTC)

Thanks. Not sure it would be extremely efficient, but I will give it a try. Ymblanter (talk) 14:06, 24 July 2023 (UTC)

Thank you for raising this issue. As of now, I have no official reports of Wikimedia Commons being blocked in Pakistan. However, I'm actively looking into this and will update you as soon as I have more information. Udehb-WMF (talk) 14:15, 27 July 2023 (UTC)

Thank you @Udehb-WMF: Ymblanter (talk) 05:20, 28 July 2023 (UTC)

Also, thank you @Udehb-WMF -- Ooligan (talk) 22:50, 3 August 2023 (UTC)

WMF response

Thank you for bringing this to our attention. It's hard to fully confirm from the data but we believe that access to Wikimedia Commons may be limited by certain Internet Service Providers (ISPs) in Pakistan. This means that, depending on the ISP, some users may experience access limitations to commons. We are very concerned about this limitation and its impact on our community. Please know we are and will continue to monitor this closely. Udehb-WMF (talk) 07:23, 4 August 2023 (UTC)

Thank you @Udehb-WMF: , great to know that you are on it. Ymblanter (talk) 18:42, 6 August 2023 (UTC)

@Udehb-WMF, Please, update us here by September 1st, if you are willing and able. Thanks, -- Ooligan (talk) 01:41, 8 August 2023 (UTC)

July 31

Problems with deletion nomination with Android users editing with the mobile app who have a different number system as standard

Tracked in Phabricator
Task T343668

I stumbled upon Commons:Deletion requests/۲۰۲۲/۰۴/۰۶ which is a deletion request page, that just transcludes Commons:Deletion requests/File:Amirreza Alizadeh Singer.jpg. I found this weird. I made some searches and at least 26 pages match the regex ^Commons:Deletion requests\/۲/. These are all created by different users, but they all seem to use Arabic alphabet, and all related file names also seem to be in Arabic. Also, all of the pages has been made using the mobile app from Android. Now the Arabic signs in the pagetitles, eg ۲۰۲۲/۰۴/۰۶, seem to be dates as far as I can tell. Can it be so, that there is a bug with the mobile app, that when you are using an Android and have the Arabic alphabet as standard, beside from the normal deletion request page, there is a seperate deletion request page created automatically, with the date in Arabic instead of the file name after Deletion requests/? This is my best guess. I don't think so many different users would create these weird deletion requests intentionally. Jonteemil (talk) 01:59, 31 July 2023 (UTC)

To be precise, this is the Persian variant of the Arabic script. Arabian Arabic does not use ۴ and ۶ and in fact Ar-wiki defaults to regular international numerals as can be seen in this page history. As far as I can tell, Fa-wiki uses their own script by default. I wonder if more languages show this problem based on their default wiki numerals, like Bengali. --HyperGaruda (talk) 20:02, 31 July 2023 (UTC)

Intresting. I will make a bug report. Jonteemil (talk) 04:08, 1 August 2023 (UTC)

@HyperGaruda: The creation date of Commons:Deletion requests/٢٠٢٢/٠٣/٠١ is 11:15, 1 March 2022‎. Does ٢٠٢٢/٠٣/٠١ perhaps correspond to that date? Or what does it mean? Jonteemil (talk) 04:33, 1 August 2023 (UTC)

See Arabic numerals. The string transliterates to "2022/03/01". Glrx (talk) 13:46, 1 August 2023 (UTC)

Okay, so it is what I suspected. The date. Jonteemil (talk) 15:46, 1 August 2023 (UTC)

Okay, now I got it. When a deletion request is created you add it to the logs, which are in the format Commons:Deletion requests/2023/08/01, but these users does not have the Arabic numerals as standard so it thinks the log format is based off of their number system. So these deletion requests are incorrectly added to a log with their number system instead of our normal logs. I wonder if it's a Android Mobile app bug or a AjaxQuickDelete bug, @Mdaniels5757: might you know? Jonteemil (talk) 17:32, 1 August 2023 (UTC)

Commons:Deletion requests/٢٠٢٢/٠٣/٠١ is hence the Persian Arabic number system variant of Commons:Deletion requests/2022/03/01. Jonteemil (talk) 17:39, 1 August 2023 (UTC)

This seems to be an Android app bug. I'd recommend sending a bug report via Phabricator. —‍Mdaniels5757 (talk • contribs) 19:05, 6 August 2023 (UTC)

 Done: phab:T343668.Jonteemil (talk) 21:22, 6 August 2023 (UTC)

@HyperGaruda: With this search query I actually found two more DRs with another script than Arabic. I'm assuming Bengali as you wrote. It's Com:Deletion requests/২০২৩/০৭/০৬ and Com:Deletion requests/২০২৩/০৬/০৮. Jonteemil (talk) 16:06, 1 August 2023 (UTC)

Do I read correctly that this search query finds all Deletion request pages not starting with regular ASCII letters and numbers? If this is everything, it does not look too bad, but it preferably needs fixing. Most indeed are dates in either Persian or Bengali, except for one DR that really is about a page written in Bengali. It looks like all of them have received proper closure. Only Commons:Deletion requests/٢٠٢٢/٠٥/١٦ is still open, but the uploader seems to have retracted the nomination. --HyperGaruda (talk) 05:01, 2 August 2023 (UTC)

August 01

Misattributed lithographic plates

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)

@Pigsonthewing, Thank you for noting this issue. -- Ooligan (talk) 02:03, 8 August 2023 (UTC)

Category:Celebrities

Hi, This category is a honeypot for catching vanity uploads and copyright violations. I already nominated some files, but all files need a careful check. More eyes needed. Thanks, Yann (talk) 19:47, 1 August 2023 (UTC)

I don't see how this category could be useful. Should we delete it, irrespective of which photos are deleted or kept? -- Ikan Kekek (talk) 23:20, 4 August 2023 (UTC)

+1. --A.Savin 00:06, 5 August 2023 (UTC)

Yes, it should be deleted, but better to clean it first. Yann (talk) 20:47, 6 August 2023 (UTC)

+3. It's kind of tangential, but if it were me I'd probably delete Category:Musicians for the same reason since it seems to be a dumping ground for vanity uploads and copyright violations, a lot of times for people who aren't even musicians to begin with. --Adamant1 (talk) 21:07, 6 August 2023 (UTC)

Category:Musicians appears to serve a necessary structural need with reference to its child categories. It's possible the same is true of Category:Celebrities (though the very notion of "celebrity" is a lot shakier than the notion of "musician"). In either case, please do not get rid of the categories without some sort of consensus via CfD. - Jmabel ! talk 22:20, 6 August 2023 (UTC)

Celebrities are just people who are famous for something (some people would say "famous for being famous"). Musicians actually do something in particular, like writers, actors, plumbers, what have you. I suppose there are some people who aren't famous for anything they've done, but most celebrities would be better described as politicians, nobles, actors, musicians, writers, media personalities, heirs to fortunes, etc. - something that describes them for what they do or at least what gave them their fame. -- Ikan Kekek (talk) 04:01, 7 August 2023 (UTC)

Sure, I guess. Not in any way that is actually represented in the images that are in the category though. People are musicians because they play an instrument, sing, spin records, Etc Etc. Those things are what is actually being shown with the images and what the cateogry is about IMO. And if someone who thinks they are a musician and wants to upload an image of themselves playing a bag pipe and put it in an actual category for bag pipe players, cool. But Category:musicians just invites randos who want to be musicians as a vanity uploading images of themselves standing next to a tree while not actually doing anything related to playing music just so they can use Commons as an advertising platform. And acting that its at all anologous to plumbers is a ridiculous straw man. No one is mass uploading copyrighted out of scope vanity shots of themselves to advertise their local plumbing business. Same goes for the comparison to writers and actors BTW. Writing and acting are actual things that people do and that's there's picture of them doing. No one "musicians." --Adamant1 (talk) 04:41, 7 August 2023 (UTC)

You're talking to a professional musician, and I have no idea what you think you're saying in your last sentence, but it's ungrammatical. Musicians make music in some kind of way, as you stated earlier. There is no fail-safe way to get unknown or little-known people to stop uploading photos in order to promote themselves, and getting rid of legitimate categories certainly won't have that effect. Such photos have to continue to be nominated for deletion. -- Ikan Kekek (talk) 08:45, 7 August 2023 (UTC)

General  Comment: It is quite difficult to separate professional from amateur musicians. I know some people who get some money for playing during Saturday balfolks. Are they professionals or amateurs? Yann (talk) 09:19, 7 August 2023 (UTC)

Probably same goes not just for musicians, "photographers" might be an even more inflationary used category. --A.Savin 09:34, 7 August 2023 (UTC)

Professionals are paid for our services, even if we may also sometimes play jams or benefit concerts that we don't get paid for. "Amateur" literally means someone who loves what they do (similarly, "dilettante" literally means someone who delights in something), so in that sense, all musicians should be amateur, but the standard meaning now is that amateurs play music for fun, rather than for money. I think your point is that you often can't tell who is what just by looking at a photo. Which is probably true of pretty much any kind of occupation that could be a hobby. -- Ikan Kekek (talk) 15:43, 7 August 2023 (UTC)

August 02

Error message

See: File:Gunhilde Tekene LCCN2014718688.jpg. In "Structured data" if I try and enter the location where an image was taken, I get the error: "The property location should not be used on this type of entity, the only valid entity type is Wikibase item." Hos should location be entered? --RAN (talk) 15:47, 2 August 2023 (UTC)

@Richard Arthur Norton (1958- ): You used location (P276) but you want location of creation (P1071). You might want to read (or at least skim) Commons:Structured data/Properties table. - Jmabel ! talk 18:08, 2 August 2023 (UTC)

• Thanks! Most are intuitive, perhaps we can change the error message to read "Use P1071 (location of creation) instead", that would be more helpful. Do you know how to edit error messages? --RAN (talk) 18:38, 2 August 2023 (UTC)

August 04

How independent is Commons in deciding which categories are appropriate?

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)

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)

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)

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)

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

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)

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)

@JopkeB: Thank you for mention for me, I could catch up the discussion. --Clusternote (talk) 06:16, 8 August 2023 (UTC)

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

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)

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

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

Well, for me that would be a solution as other solutions cannot be applied. JopkeB (talk) 05:45, 9 August 2023 (UTC)

And in all this talk about cats at commons and wikidata no mention of SDC, even though the depicts on commons are based on Q-items at wikidata, that reference cats on commons, thereby makeing the cats on commons multilingual and requiring to sync the cats on commons with the entries at wikidata. Whatever you decide or not decide has consequences for SDC so you really should include that in your discussion. --C.Suthorn (@Life_is@no-pony.farm) (talk) 09:14, 6 August 2023 (UTC)

C.Suthorn, thanks for your contribution. Could you please inform us about what the consequences could be for SDC (Commons:Structured data)? In what cases could a decision here affect SDC applications negatively? What would be a bad decision for SDC? How could we prevent bad consequences for SDC? JopkeB (talk) 03:59, 8 August 2023 (UTC)

General  Comment: An article in Wikipedia should be linked to a Commons category, not to a gallery, as categories are our main way to separate subjects. And categories in Wikipedia should not be linked to a Commons category. Yann (talk) 09:01, 8 August 2023 (UTC)

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)

Actually Commons notability requirements are lower than Wikipedia, so there should be more categories on Commons, than articles on Wikipedia. So if there is not yet a category on Commons corresponding to a Wikipedia article, it should be created. For example, if someone deserves a named picture on Commons, there should be a category linked to a Wikidata entry, but many of these persons do not meet Wikipedia notability requirements. Yann (talk) 10:21, 8 August 2023 (UTC)

"if there is not yet a category on Commons corresponding to a Wikipedia article, it should be created." Often, but not always. There may be no media on Commons related to the article, in which case there clearly shouldn't be a Commons category; the relation between the media used in the article and the article topic may be very tangential (e.g. the illustration used for en:Argumentation theory) so that it really wouldn't be an appropriate category for the image; or there may be only a single photo on Commons for the article subject, in which case it's pretty arbitrary whether we create a category (e.g. en:Albers Brothers Mill: if we have other photos of this building besides the one used in the article, then it probably merits a category, but if not I don't see any advantage in creating a category for the one photo). I suspect there are other cases, but these three leap to mind. - Jmabel ! talk 18:01, 8 August 2023 (UTC)

 Agree Only create a Commons category when there are sufficient files for (and give it a name according to the Commons rules). JopkeB (talk) 05:00, 9 August 2023 (UTC)

The question is what's sufficient? 1 file or more then that? --Adamant1 (talk) 05:05, 9 August 2023 (UTC)

For the sake of this discussion: can we say that a Commons category should have at least X files or subcategories, and if you do not agree, then start elsewhere a discussion about the correct number (or numbers, perhaps differentiate by subject)? I would be happy to join it, but not here. JopkeB (talk) 10:16, 9 August 2023 (UTC)

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)

Status/Resume

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)

I think that is a correct summary. I would add that for every Wikidata item that has at least one photo there should be a category. Additionally every Wikidata item that likely will have a photo in the near future can also have an empty category with the Wikidata Infobox.(That was done for some photo completions in the past.) GPSLeo (talk) 07:05, 11 August 2023 (UTC)

for every Wikidata item that has at least one photo there should be a category. What's the unique benefit there? It seems like a single image category with an infobox would no really serve any other purpose then just be re-creating the Wikidata entry in an infobox. Like, is the point in categories to organize images or to use them as superficial ways for people to find out basic facts related to a particular topic? --Adamant1 (talk) 07:14, 11 August 2023 (UTC)

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

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)

That is why I added the requirement that there is a corresponding Wikidata item. GPSLeo (talk) 09:09, 11 August 2023 (UTC)

As for single-image categories, they are already permitted, so no need for a new rule. Requiring categories for every Wikidata item with an image presumes that image would be included in the created category. This is a problem. Many WD items share the same image, especially in cases where the items are instances or subclasses of another. Creating a mirror structure would create significant COM:OVERCAT violations and other problems.

As for creating empty categories on the promise of future submissions, that is not a good idea. Sure, if you are going to be uploading or adding images imminently (same day), that is fine, but empty categories are subject to speedy deletion. The reason is that they can easily be created at the time images are added to them, so there is no value in pre-building a bunch of categories ahead of time just for them to sit empty. Josh (talk) 14:13, 11 August 2023 (UTC)

I think the assumption that it is easy to create a new category correctly placed in the category tree is wrong. Nearly all new users fail to add correct or even any category to their photos. GPSLeo (talk) 15:33, 11 August 2023 (UTC)

I agree with that: WD entry + (at least one) file = Commons category. Simple and easy. Yann (talk) 12:16, 11 August 2023 (UTC)

Simple and easy? Wikidata has well over 100 million items! There are easy tools and games for users to add images to these items, so a huge percentage of them have images (my queries to find out exactly hit a time out because there are too many). I agree it may sound simple and easy at first glance, but in practice, it is a nightmare. Josh (talk) 14:13, 11 August 2023 (UTC)

@JopkeB: or @Clusternote: why exactly is it not realistic to say that Wikidata should resolve all conflicts and why do we need more complex relationships than single-subject categories to begin with? Admittedly it's cherry picking, but the only example I can think of for a multi-subject category is Category:Logos associated with entertainment and leisure, which I assume was created based on a Wikipedia category. It's clearly not useful outside of that though because you end up with logos for hotels in the same category as ones video games since both are associated with entertainment and leisure. I hate to see us get in a situation where we are allowing for and having to maintain similar compound categories that will just become dumps for non-related images. Especially if we aren't able to modify or delete them "because Wikipedia category." So if we allow for multi-subject categories it should at least be contingent on them being properly maintained and us being able to modify or delete them if we want to. Otherwise it's just a recipe for category rot. --Adamant1 (talk) 08:37, 11 August 2023 (UTC)

I fully agree with this. It is a key reason why we have the Selectivity Principle . At best it means more categories to list, confusion for users on where to find what they are looking for, and increased work load on category maintainers. In practice it means inconsistent categorization, both of files directly and within category tree structure, and files end up in different corners, some of which will innevitably be less maintained than others, leading to problems such as the category rot mentioned by User:Adamant1. Josh (talk) 14:13, 11 August 2023 (UTC)

I would like to hear from Clusternote him-/herself that all problems here discussed are solved with the solutions we have offered here. I think we cannot close this discussion without his/her consent. That is why I explicitly asked for his/her opinion. And Clusternote may be a representative of perhaps many other people who look at Commons from a Wikidata/EN-WP perspective. I would like to solve this issue once and for all and therefor want to know what obstacles are still there. I am all pro single-subject categories and I read that a lot of us are, but I think we are not the bottleneck here. JopkeB (talk) 14:55, 11 August 2023 (UTC)

 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)

August 05

Adding category

Is there any way to add a specific category in all the images uploaded by a user?--Wasiul Bahar (talk) 05:33, 5 August 2023 (UTC)

• @Wasiul Bahar: . Install VisualFileChange. Then go to that user's uploads (e.g. Special:ListFiles/Wasiul_Bahar) and use VisualFileChange to append the relevant category to all files; don't forget to put a newline before the new category. (There are other ways to get it in there if you don't want it to be the last category, but those are trickier.) - Jmabel ! talk 15:24, 5 August 2023 (UTC)

if it involves a large number of files you might consider com:bwr to ask someone to use a bot.--RZuo (talk) 08:58, 6 August 2023 (UTC)

Photo challenge June results

rainbow colors: Entries • Votes • Scores

Rank	1	2	3
image
Title	Tunnel at London King's Cross illuminated in rainbow colours	Rainbow yarn for knitting, display in front of a needlework shop in Graz, Austria	This shows the view directly above the basket of a hot air balloon.
Author	The wub	Lusi Lindwurm	Hu Nhu
Score	19	11	8

tents: Entries • Votes • Scores

Rank	1	2	3
image
Title	Kasachische Jurten in der Kyzylkum/ Usbekistan	Chegem-001	Chegem-002
Author	Carsten Siegel	Саня Новиков	Саня Новиков
Score	17	17	13

Congratulations to The wub, Lusi Lindwurm, Hu Nhu, Carsten Siegel and Саня Новиков. -- Jarekt (talk) 06:00, 5 August 2023 (UTC)

Wich type of French train type?

The numbers usualy give me a guide, but short nummbers dont. There is a very similar type (SNCF Class X 73500).Smiley.toerist (talk) 09:45, 5 August 2023 (UTC)

I think it's an X 73500. Do you have any other photos of it showing the EVN? Railwayfan2005 (talk) 19:27, 5 August 2023 (UTC)

I have other examples with only a three digits: File:Mulhouse station 2023 2.jpg.Smiley.toerist (talk) 10:40, 6 August 2023 (UTC)

Overwriting historical photos

Just yesterday I found Commons:Overwriting existing files, which says to not upload a new version of a historical photo, overwriting the old one. I understand this. But could someone make it easier to make an "other version" of a file? That is, this would be in addition to "upload a new version of this file". It could copy all of the information from the old file, create a new file, and make "other versions" links, both ways. This sure would make it a lot easier. Bubba73 (talk) 00:00, 6 August 2023 (UTC)

• @Bubba73: if you use Special:Upload, you can copy-paste the wikitext from the old photo. The only thing you have to do manually is the "other versions" part. It would, in any case, be hard to fully automate that because there is no magic way to know whether you want {{Other version}} on both, {{Superseded}} / {{Supersedes}}, or any of a few other possible relationships. - Jmabel ! talk 04:11, 6 August 2023 (UTC)

Commons:CropTool.--RZuo (talk) 08:58, 6 August 2023 (UTC)

@RZuo: relevant how? [User:Bubba73]] didn't say they wanted to upload a crop. - Jmabel ! talk 15:27, 6 August 2023 (UTC)

I don't see a "special upload" that does what I'm talking about. I'd want it to copy all of the information (description, categories, permissions, etc) for me and do the other version links, automatically. Then I could edit the description as needed. Bubba73 (talk) 01:48, 7 August 2023 (UTC)

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

That could be automated to save us some work. "Upload a different version of the file" could be under "upload a new version of the file". Bubba73 (talk) 23:24, 7 August 2023 (UTC)

It could be, but I can't say I'd advocate this as a high-priority use of scarce developer time when there is a pretty decent workaround, for a case that is not all that common. But feel free to raise it in the annual process of proposing what tech work we'd want. - 00:16, 8 August 2023 (UTC)

Make a crop of the existing file (preferably just a very small part it it), using crop tool. Upload your version of the file to overwrite the cropped extract, edit description accordingly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:57, 8 August 2023 (UTC)

• Sorry, I was just trying to help. I estimate that there are 100,000 "other versions" on Commons. I estimate it may take an editor 5 minutes to manually do all of the work to create a new version and do the links. That would be 8,000 hours of work. I estimate that a person familiar with how to add these things to Wiki could do it in 2 hours - saving thousands of hours. Bubba73 (talk) 04:12, 10 August 2023 (UTC)

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)

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)

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)

August 06

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

Why not Category:Panama color photographs of Coleoptera taken on 2020-05-26 with Nikon D40? Surely, that's not too specific! Seriously, though, what is the point of these categories (most of which only have 1 or 2 images)? Is it just to make the database servers melt? It looks like these categories were created and populated by RudolphousBot (run by Rudolphous), although I can't find any discussion where this task was approved by the community. Can someone point me to it? If it wasn't approved by the community, I would like to request that all 8 million of these categories be deleted. Nosferattus (talk) 04:40, 6 August 2023 (UTC)

Rudolphous appears to have taken a cue from categories (millions?) that already existed when Commons:Bots/Requests/RudolphousBot (extra) request was filed and discussed. However, the way it is worded, and with the edit examples, Rudolphous appears to assert that he intends to insert "|location=xxx" into templates, while taking date cues from existing categories. I see nowhere that adding such categories by bot is discussed.

Elizium23 (talk) 05:00, 6 August 2023 (UTC)

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)

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)

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)

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)

Well, no, not really. The categories already existed before that and I simply followed what at the time, seemed to be an already established standard. My edit was to implement automatic categorisation into appropriate categories when using the {{Taken on}} template. The preceding discussion can be found on the template talk page. The intention at the time, was to use this for country level categorisation by date, which I feel can be useful. TommyG (talk) 07:37, 7 August 2023 (UTC)

"proliferance"

between oct 2015 and apr 2018 (2.5 years) only roughly 20000 such cats were created. now there're 500000. RZuo (talk) 13:51, 7 August 2023 (UTC)

"country-by-date" seems to me to be an acceptable compromise between those who don't want to do anything of the sort and those who would do "city-by-date" categories.

And we don't want to rename categories affecting 18 million files unless there is a serious problem. A comprehensible but less-than-optimal category name is not a serious problem. - Jmabel ! talk 15:32, 6 August 2023 (UTC)

+1. These "by date" categories are just needlessly excessive. The same goes for "by year" categories in a lot of cases and depending on the subject. "country-by-date" categories are probably fine though. --Adamant1 (talk) 20:28, 6 August 2023 (UTC)

I truly dislike participating in siloed micro-discussions which avoid acknowledging the bigger picture. However, to address the example originally offered, Category:May 2020 in Panama doesn't exist, with three valid categories underneath. This appears to violate our policy, which is to create categories in a hierarchy. There was an admin who took exception to my fixing the problem of "Births in XXX" when "People of XXX" didn't exist by means other than creating scads of un(der)populated intermediate categories. The same issue applies: why were these categories created in the first place without regard for maintaining the integrity of the hierarchy? There's still plenty of broken trees lying around due to this admin's interference with my efforts, which caused me to quit bothering with it. Bot/script editing may make things "easier", that is, until it's not "easier" when someone else has to come along and clean up the messes.RadioKAOS (talk) 02:36, 7 August 2023 (UTC)

@RadioKAOS: I suppose the bigger problem is people bot-creating hundreds of thousands of categories without bothering to have a community discussion about it first. I also recall someone bot uploading something like 1,000,000 photos of clouds taken automatically by the International Space Station without any discussion. Just try clicking "Random file" for a while and you'll probably see one (except the ones taken at night are black). Can Commons please have an enforcable bot policy? Nosferattus (talk) 22:38, 10 August 2023 (UTC)

Are the ISS photos related to this category discussion? Why are we having a category discussion outside of CfD?

If there are hundreds of thousands of categories, and they have an identifiable purpose, and they stem from a reasonable design decision, then I don't see why we should disallow them, just because they've grown to six digits' worth. If they are creating software problems at scale, if they are unwieldy for bots to manage, if they are causing heartburn for MediaWiki software in some way, then by all means we should rethink them. But surely we could have envisioned that categorizing works by the intersection of place/date would certainly grow, like grow a lot.

I was initially confused about why Rudolphous' bot request did not explicitly say it was going to add categories, and then I realized that the categories are automatically generated by the template when RudolphousBot adds a parameter to them. I think that as the project grows, we will have more instances of hundreds of thousands of whatevers, and so I think this simply puts a stress test on the limits of MediaWiki software, and also creates opportunities for bot developers to find ways to efficiently, programmatically process category trees that can barely be comprehended by humans. Elizium23 (talk) 00:01, 11 August 2023 (UTC)

Proposal: rename cat tree User BG-x

• User BG-0‎ (1 P)
• User BG-1‎ (3 P)
• User BG-2‎ (8 P)
• User BG-3‎ (9 P)
• User BG-4‎ (1 P)

i propose renaming these cats to "Category:User bitmap-x" because of confusion with Category:User bg. the proposed names follow Template:User bitmap-0. any objection?--RZuo (talk) 08:58, 6 August 2023 (UTC)

@RZuo: No objection, but wouldn't you normally do this with a CfD? - Jmabel ! talk 22:24, 6 August 2023 (UTC)

August 07

How do you prove that a file was released under the creative commons license in the past?

Recently, a user requested speedy deletion of File:Sexyy Red 2023.png, which is a screenshot of a YouTube video. The video was originally uploaded to YouTube under the creative commons license, but the YouTube channel has changed the licensing to be more restrictive. I don't want the file to be deleted, but I don't know how to prove that it was released under the CCL in the past. Can anyone help me with this? Suhaengpyeongga (talk) 13:17, 7 August 2023 (UTC)

Try the Internet Archive. Yann (talk) 14:25, 7 August 2023 (UTC)

I'll try that. Thank you! Suhaengpyeongga (talk) 14:58, 7 August 2023 (UTC)

https://web.archive.org/web/20230622060152/https://www.youtube.com/watch?v=q6ybHwR4vrQ

This does indeed have a CC-by licence on it. Andy Dingley (talk) 15:01, 7 August 2023 (UTC)

I changed the license to {{YouTube}} and reviewed it. Yann (talk) 16:52, 7 August 2023 (UTC)

• This was only uploaded a few weeks ago. It's relatively unlikely thus that either the licence has changed, or that an archiver has happened to record it in the claimed earlier state. It might not be possible to prove this at all.

Given the purpose of the image, it might be simpler to delete it here and to upload it directly to Wikipedia(s), claiming "fair use". See en:WP:NFCC. This is resisted by most Wikipedias, but this would seem a reasonable situation to justify it at present. Andy Dingley (talk) 14:59, 7 August 2023 (UTC)

August 08

Four Updates on the Private Incident Reporting Project

Hello everyone. Sorry to use English. Please help translate to your language.

For the past couple of months the Trust and Safety Tools team has been working on finalising Phase 1 of the Incident Reporting System project.

The purpose of this phase was to define possible product direction and scope of the project with your feedback. We now have a better understanding of what to do next.

1. We are renaming the project as Incident Reporting System
2. We have some feedback from researching some pilot communities to share with you
3. We have updated the project’s overview
4. We have the first iteration of the reporting extension ReportIncident

Please visit the project's update page to get more details.

On behalf of Trust & Safety Tools Team –– STei (WMF)

12:29, 8 August 2023 (UTC)

August 09

Category:Daniel Gottfried Reymann

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)

German: Daniel Gottlob Reymann. --Raugeier (talk) 15:36, 9 August 2023 (UTC)

Global ban for Бучач-Львів

Per the Global bans policy, I’m informing the project of this request for comment: RfC/Global ban for Бучач-Львів. --Jphwra (talk) 17:08, 9 August 2023 (UTC)

Regarding security of image

I have been adding images from [1] this website of Government of Bihar. Their website policy say that material produced therein are freely usable if properly attributed.[2] However, that's a dynamic website. Actually it contains image of ministers and leaders. And they will change in future. Hence, I am worried that in future, if someone tries to verify that whether the image I put on commons was from that website or not, they won't find it as the website updates after new government is formed and new assembly is elected.-Admantine123 (talk) 18:21, 9 August 2023 (UTC)

PS: Archiving also doesn't work for this website. I tried it earlier, but archived link opens the home page of website and doesn't proove that it was present there. See my recent upload.-Admantine123 (talk) 18:24, 9 August 2023 (UTC)

Tagging Mdaniels5757, other admins please see, can something like accepting the image from that website as a future policy be formulated for that website like we have for Press Information Bureau files.-Admantine123 (talk) 18:33, 9 August 2023 (UTC)

[3], can someone archive this link for me. It contains present council of ministers images. It will be changed after elections in 2025. I want to see whether I am the only person who is facing problem in Archiving it or not.Admantine123 (talk) 18:58, 9 August 2023 (UTC)

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

Mdaniels5757, this particular sentence is written below every image and material by any of the Government in India's website. The images from these websites are used by others as for example you can see [4] this link. Now the image of minister Sheela Mandal has been taken from here and circulated widespreadly by various media houses[5]. In fact many websites use the material from here.-Admantine123 (talk) 19:12, 9 August 2023 (UTC)

• Look at this website [6], here also same sentence is written. But images from here has been used and uploaded in large numbers on Wikimedia commons under GODL-India' licence. A common example is image of Narendra Modi, used in his article, is taken from this website only.Admantine123 (talk) 19:19, 9 August 2023 (UTC)

Postcard categories

We have Category:Black and white postcards of Piran and two others with the same prefix; and Category:Monochrome postcards of bridges in Landkreis Leipzig, but nether Category:Black and white postcards nor Category:Monochrome postcards. How should the former examples be categorised (or renamed)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:22, 9 August 2023 (UTC)

I do a lot of work on postcards. If it were me I'd create both Category:Black and white postcards, Category:Monochrome postcards and the other categories in whichever one is more appropriate. I was actually planning on doing that a while back but never got around to it. There also seems to be some miss-understanding in general about what makes something black and white or monochrome, but that's a discussion for another conversation. Except to say Category:Black and white photographs contains a lot of photographs that aren't actually black and white. --Adamant1 (talk) 21:30, 9 August 2023 (UTC)

August 11

Non-FP chosen as POTD

It appears that Grenadin07 has chosen images that are not featured pictures to be COM:POTD on two occasions: Template:Potd/2023-07-09 and Template:Potd/2023-08-11. The first one has already happened, while we are a few minutes into the second one. I can't find any evidence of authorization to run these non-FPs on the main page. For the latter image, what do we do here? Do we quickly try to find a replacement, or do we just say it's too late and allow it to run for today? Either way, we should look at how to prevent non-FPs from being selected as POTD by well-meaning users in the future. -- King of ♥ ♦ ♣ ♠ 00:15, 11 August 2023 (UTC)

 Done.

a) Thanks King of Hearts for noticing and reporting this.

b) I don't think we should leave it as is.

c) I've taken the liberty of the following: taking the POTD of 18 Aug, moving it and all its language templates to today. Therefore, the 18 Aug is vacant again, I hope someone finds an alternative in the next few days.

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)

maybe a bot that checks next two days' potd is more suitable.--RZuo (talk) 07:31, 11 August 2023 (UTC)

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)

I've added a FP as POTD on August 18th. --XRay 💬 07:41, 11 August 2023 (UTC)

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

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)

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

The question is what's sufficient? 1 file or more then that? --Adamant1 (talk) 05:05, 9 August 2023 (UTC)

Well, I could not find a guideline for it and I think the opinions may vary a lot. This discussion (about the independence of Commons) does not depend on the outcome of this new question and therefor I suggest to address it in a separate discussion. JopkeB (talk) 05:34, 9 August 2023 (UTC)

I'm aware that's not what the discussion is about. I just thought I'd ask since it was brought up. I'm fine with starting a separate discussion about it if you prefer that though. --Adamant1 (talk) 05:40, 9 August 2023 (UTC)

I agree that there is no solid guideline, and I'd hate to create something rigid. My own personal rules of thumb:

• Never create an empty category unless you are about to use it (within a few hours).
• The only time to create a category for a single photo is when it is part of a sequence or systematic breakdown of another category (e.g if we have Category:PERSON by year and we already have categories for most dates in the 1940s but have only one photo of them for 1947, I'd probably create the Category:PERSON in 1947.
• For two photos, I'd sometimes create a category if there is already a Wikidata item or Wikipedia article.
• Otherwise, three is a bare minumum, and I probably wouldn't do less than four (usually five) if they already group together (sorted next to one another) as part of an existing category with less than 200 images. I'd be more likely to do the four or five with no Wikidata item or Wikipedia article if I either anticipate a future article, or I think we will have a lot more such photos.

I suppose I've pushed that a little sometimes when I have a lot of information about a person from roughly 100+ years ago and only a couple of photos; usually that also calls for making a Wikidata item, but I'll admit to sometimes being lazy about the latter when it's all stuff I can express via parent categories. - Jmabel ! talk 15:26, 9 August 2023 (UTC)

cats should be created for unique concepts that are expected to get photographed easily, e.g. living celebrities, buildings. cats can be hooked up with wikidata which record lots of info. sooner or later more files will be uploaded. it makes it much easier to categorise those files with an established cat. if users with the knowledge of a concept cannot create the cat because of these stupid rules, then chances are the files will become mis- or uncategorised when they come. look at this bureaucracy https://commons.wikimedia.org/w/index.php?title=Special:Log&page=Category%3AMia+Khalifa . RZuo (talk) 07:13, 9 August 2023 (UTC)

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

I am sorry. But I thought this part would fit better here. --JopkeB (talk) 09:01, 11 August 2023 (UTC)

I really have to disagree. That just sounds like a bad recipe for having thousands of empty categories because someone decided to pre-create them ahead of time and then dodged out half through their project or something similar. I much rather administrators delete a category 5 times over as many years then the inventible massive mess your recommendation would create. --Adamant1 (talk) 07:48, 9 August 2023 (UTC)

Empty categories they are liked to Wikidata are very useful for tools and especially new users. They can also speedup the workflow of experienced users. This of course only applies to topics like protected areas, mountains, or members of a parliament, where we expect to get photos of in the near future. We should not create empty or nearly empty "by year" categories. GPSLeo (talk) 07:14, 11 August 2023 (UTC)

Wikidata has essentially no notability guidelines outside of the entry needing to have a single external reference. So there's no guarantee that just because something has a Wikidata entry that it will every have images related to it uploaded to Commons. In fact, most never will. That's not even accounting for the fact that there needs to be someone willing to upload images related to it in the first place, which there often isn't.

I'd probably support either creating empty categories or ones with single images in cases where it's a clearly notable subject and there's a guarantee someone will upload images of it in the near future though. I just don't know how it would be enforced or tracked. Maybe we could create a special category system or template just for those types of categories like there are for DRs. I don't think they should be mixed in with normal categories though. At least not in mass. Otherwise it could easily make parent categories hard to browse through and/or maintain. --Adamant1 (talk) 08:53, 11 August 2023 (UTC)

Full agreement with Adamant on empty categories. As an addendum: A few rare times I have created Commons categories about notable people, where the images later got deleted, so the category is now an empty remnant. As long as it's about notable things and connected with an entry via Wikidata, I see no problem keeping such a category. --Enyavar (talk) 12:22, 11 August 2023 (UTC)

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

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)

That sounds reasonable to me. Except with the caveat for number 4 that we shouldn't allow for one file or subcategory when it is part of a sequence or systematic breakdown of another category if either one is "by year" or has anything to do with "by year" categories. I agree with it other then that though. --Adamant1 (talk) 10:30, 11 August 2023 (UTC)

With the empty categories we maybe could make a guideline that they have to be maintained by an active WikiProject or by an annual photo competition. GPSLeo (talk) 10:52, 11 August 2023 (UTC)

• Of course it is and should remain allowed to create a category with only 1 file, or just with a non-empty subcat. And if this category can be linked with a Wikipedia article and a Wikidata item via WD infobox, this is not only allowed, but also encouraged. Regards --A.Savin 12:17, 11 August 2023 (UTC)

Hi, in my opinion the answer to the question is very much: "it depends". I would split possible categories into two kinds: specific (about 1 event/object/person: these categories should be allowed to be as tiny as needed) and non-specific (about any event/object/person that fits the criteria)

• For the first:
  • there are very useful category structures where I create a new category just for a single picture, to complement the other branches of the same category tree. (Category:1977 elections in Morocco, which is part of "1977..in Africa", part of "..in Morocco by year", etc. I hope we will get more stuff in it, but one file suffices already.)
  • there are well-defined categories, like about one special book title. (Category:Stalky & Co. is perfectly fine with just 2 files. Although: If it's just one file from/about a book, I'd still prefer that file being properly categorized, without a new category.)
• For the second:
  • I find three images on Commons depicting "Porcelain vases with horse paintings". That may seem to be a very clear category definition, possibly falling under "Porcelain vases with paintings" and "Horses in art", but it's still an arbitrary definition and with too few files matching the criteria. I'd rather supper "Horses in porcelain art", and then splitting that further as soon as the category grows too large, probably first dividing into statues and paintings. 6-10 files should be a minimum for such groupings.
  • this also goes for "location in time"-categories. Any event/work/building/map/photo/person/etc related to the history of Krakow, and created/photographed/happening/died/etc in 1879, may go into "1879 in Krakow". The definition is vague and arbitrary in a different way here, but still: There is currently one file. (Category:Kraków in the 1870s holds 7 files in total, but uses four categories to do so.) So for "history of location"-categories, I'd prefer "by decade" over "by year" and only create the latter once the decade-category gets overcrowded.
  • I sometimes find categories that are too small and if I am invested enough, I actively seek dissolution. Category:1840s maps of Lithuania now has 9 files which have previously been spread over 8 subcategories. I moved the files to the parent cat, and will at some point in the future ask for the deletion of the (now empty) sub-cats. As long as we don't suddenly get an influx of dozens more 1840s maps of Lithuania, these by-year-subcats are just too granular to be useful.
  • In other cases I often find categories that are "too small", but I'm not invested enough to start a debate: Category:Voting lines in India is granularly sub-divided by states of India, sometimes with just 2 pictures. That is in my opinion not how it should be, but it fits into "<theme> in India by state", so I'm not complaining.

These are my thoughts, I think my opinions overlap a lot with Jmabel and Jopkeb --Enyavar (talk) 12:22, 11 August 2023 (UTC)

 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)

Thanks for the comment, and I fully agree on "year books from country", but...  Comment "year maps of country" stops being useful the further you go back into the past: Maps were drawn years after the surveys, maps were reproduced unchanged for years, decades and even centuries, maps were dated wrong by authors, archives and later by the uploaders, etc. So, I support navigation templates, but for most maps before the 20th-century, we shouldn't do breakdowns by year, but by decades instead. With exceptions for when there is lots of material of course. This whole thing is slightly off-topic here and I have pages more cases and material to discuss, so I leave it at that until me make it a whole own topic. --Enyavar (talk) 19:40, 11 August 2023 (UTC)

For named entities - specifically notable people - single file categories should be accepted and their creation should be encouraged. Even if it contains just one file, an individual category provides links to corresponding articles, increases the chance that further uploads are fully categorized and keeps the topical category pages tidy. Why would it be better if a category like Category:Members of the 11th German Bundestag contained 73 single files instead of the additional 73 single file categories for the respective persons? --Rudolph Buch (talk) 18:21, 11 August 2023 (UTC)

Take a more zoomed out perspective on this. The main purpose of Commons is for people to find media related to a subject, Not information related to it. To the degree that we do provide such information that's what file descriptions are for. In your example someone is either going to want to find "Members of the 11th German Bundestag" or an individual person who was a member. So in that case they will either search for Members of the 11th German Bundestag" which will give them the category so find images of multiple members, or they will search for a specific name and go the file for that person. If you create a category for each individual member your just create pointless intermediary steps that people looking for "members" have to go through to get the images. Like if I want images of five of them, I now have to go to the main category, click into the individual category, click the image, download it, click back into the individual category, click back into the main category, and do it all over again multiple times. It's just obtuse and creates browsing dead ends.

Whereas the person who wants in image for a individual member can already do that using the search box and clicking on the image of the person. So the category adds nothing. Same for the infoboxes since the information will (or at least should) already be contained in the file description. At least IMO the point in infoboxes is to provide general information about a subject people are browsing images related to. It acts as an orientation point. It's less about providing the raw facts to people who are looking for them because we aren't Wikipedia. It's not like we can't just link to Wikipedia or Wikidata in the file description either. But you want browsing images to be intuitive and have as little end points as possible. The ability to find out someone's birthdate in an infobox shouldn't come at the cost of adding 5 more levels of clicking to the user interface. You see that with "nested" categories that only contain a single category and no images a lot. There's instances out there where it turns into a game of clicking through 12 empty nested categories just to get to the a single image. At which point the person looking for said image has probably long wondered off out of frustration and found it through Google Image Search. --Adamant1 (talk) 19:28, 11 August 2023 (UTC)

You are right, single files should (usually) not get their own category, and I'm also a skeptic when it comes to empty categories. But once there is a second photo of a notable person, they are eligible for their own category (as per here), in order to have all media related to the person in the same place, and that includes removing them from other categories. Commons' categories are not curated image galleries, and "Members of the 100th U.S. Senate" has the same "problem" as the 11th BT above. Cheers, --Enyavar (talk) 20:58, 11 August 2023 (UTC)

@Adamant1: These issues are the same whether there´s a minimum of one, two or ten files for an individual category. With any minimum number you still have personal categories, just not for all of the files. And a mix means you got to look in two places instead of one. Mostly you describe a different problem: In many categories we do not distinguish between "feature of the related entity" and "feature of the actual motive". Our rules stipulate to categorize the image of a dinner plate under category "Mayors of New York" if the owner was one of those. I prefer to have the plate (or tombstone, residence, pencil sharperner etc.) in the specific mayor´s named subcategory, even it´s the only file there. Apart from that I agree that we have too many non-essential and non-reliable categories relating to people.- --Rudolph Buch (talk) 22:33, 11 August 2023 (UTC)

I prefer to have the plate...in the specific mayor´s named subcategory, even it´s the only file there. I have to disagree there. It's probably good to assumepeople will be looking for images of the mayor if they are searching for their name. Not some random plate that they eat dinner off of once. Whereas, people who are looking into plates will be interested in the image regardless of whom owned it. I could maybe see it for members of higher office, but we usually have other images of them in that case anyway. More broaderly though categories shouldn't be created unless the category will contain at least one image directly related to the subject. Otherwise the image should just go somewhere else. I don't think we should be creating categories for every person that we happen to have an image related to though. Otherwise we'd be creating single file categories for every non-notable person we have a passport, letter, gravestone, or whatever for. Which clearly wouldn't be useful. So you have to draw the line somewhere. --Adamant1 (talk) 22:57, 11 August 2023 (UTC)

@Rudolph Buch: I suspect your use of "motive" here is a false cognate from another language. I don't know what you mean by it. "Motive" in English means a reason for doing something. - Jmabel ! talk 23:47, 11 August 2023 (UTC)

Maybe "motif" was meant? -- Tuválkin ✉ ✇ 23:56, 11 August 2023 (UTC)

Right. ("Motiv" in German can have two meanings: Reason for doing something, same as motive in English, or "what is depicted in a picture". Deepl tells me I should have used "subject" or "motif" instead - which seems strange as the "Sujet" and the "Motiv" of a picture mean very different things in German.) Rudolph Buch (talk) 00:25, 12 August 2023 (UTC)

@Adamant1: the issue presumably isn't creating single-file categories for non-notable people where we have one artifact related to that person. I suppose there is someone who would consider doing such a thing (I've seen some seriously useless categories) but the issue there would be more about having an artifact related to a notable person when we don't actually have a picture of that notable person. I could easily imagine that happening with someone reclusive who doesn't like having their picture taken. For example, we happen to have pictures of Thomas Pynchon from the 1950s, but he's pretty much avoided having his picture taken since; we'd want Category:Thomas Pynchon even without those. If we ever had an image related to Elena Ferrante, we'd probably want a category for her, even if we still lacked a photo of her. - Jmabel ! talk 23:55, 11 August 2023 (UTC)

Sound barriers

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)

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

Upscaling AI

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)

In general, we recommend against upscaling photos. - Jmabel ! talk 23:59, 11 August 2023 (UTC)

• So long as we have the original and properly categorize the final product as upscaled, I see no problem with upscaling. It simply makes the image bigger without increasing the noise and grain. When Sir Peter Jackson applies it to historic images, he gets awards. It is no different than photoshopping out a crack in a glass negative, or even cropping an image, or removing the background, or desaturating a sepia image to black and white, or adjusting contrast and brightness. We use what tools we have available to improve an image. --RAN (talk) 03:56, 12 August 2023 (UTC)

August 12

NSFW category madness

Category:Nude men with visible pubic hair (and of course many will not want to click on that) has five nonexistent parent categories, one extant parent category (Category:Men's pubic hair), and a navigation template show 12 hypothetically related categories, none of which exist. I discovered this category only because a picture I took of a naked cyclist in a parade got placed in the category.

I'll say it straight out: I'm done trying to clean up sloppy work in categories related to naked people, including but not limited to some categories that seem to me to be of only fetishistic interest (e.g. Category:3 women with nude men, which has similar problems with nonexistent parent categories). Would someone who values these categories please take on the work of cleaning them up?

I'm also probably done with licensing photos of things like the Fremont Solstice Parade in ways that are compatible with Commons, because I find it very disrespectful to the subjects of these photos that their images are ending up in these fetishistic categories. Nothing against Commons covering fetishism, but a good deal against mixing nudism and fetishism as if they were the same thing. - Jmabel ! talk 00:14, 12 August 2023 (UTC)

• How is "3 women with nude men" fetishistic and disrespectful? If I was to ask an AI to describe the image, that is what I would get. --RAN (talk) 04:02, 12 August 2023 (UTC)

Photoshop being used on mainspace wiki image?

Hi all, in the course of editing on Wikipedia, I came across w:File:De Bruyne and Foden.jpg and immediately smelt a fairly large rat. The image seems oddly lit, and the stadium background looks suspiciously like something from FIFA 23 or EAFC 24, and on closer inspection there is a blurred halo around the two players which doesn’t seem natural, add the oddly empty pitch, and I’m calling bull. I think it might be photoshopped but could someone more experienced take a look in case I’m just slightly delusional? Cheers. REDMAN 2019 (talk) 08:28, 12 August 2023 (UTC)

Export

This File is not copyrightable right because of Iranian government emblem in it https://en.m.wikipedia.org/wiki/File:Worker_House_(national_trade_union_center)_(Iran)_logo.gif Baratiiman (talk) 08:52, 12 August 2023 (UTC)