Commons:Village pump

Latest comment: 1 hour ago by Jeff G. in topic Special:UncategorizedCategories

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
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/2024/06.

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:


   
 
# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Category:Film characters by actors 19 7 ReneeWrites 2024-06-20 18:22
2 I'm unable to use the image I just uploaded. 0 0
3 Special:UncategorizedCategories 8 3 Jeff G. 2024-06-21 05:30
4 RFC: Automatic categorisation both bane and gain; work needed to identify source of categorisation 33 10 JopkeB 2024-06-18 11:55
5 Japanese categories 7 4 Smiley.toerist 2024-06-17 10:21
6 Category:Flags of fictional countries 17 6 Trade 2024-06-19 15:22
7 New designs for logo detection tool 11 7 Jmabel 2024-06-20 19:36
8 Is the June 2024 Ukraine peace summit logo copyright-free? 7 3 Shiro D. Neko 2024-06-16 15:37
9 Weibo Watermark- Advertising? 3 3 ReneeWrites 2024-06-17 23:06
10 Low server performance? 7 3 Jeff G. 2024-06-14 03:19
11 Have I got this right now 11 7 Broichmore 2024-06-14 22:18
12 File:לירן כוג'הינוף - עותק.jpg 6 3 Jmabel 2024-06-14 17:12
13 COM:Exif 2 2 Ruslik0 2024-06-14 20:05
14 7000x Georgia, the country 15 7 Enhancing999 2024-06-17 19:00
15 Uploading while editing wikipedias: beneficial or problematic? 32 11 Enhancing999 2024-06-17 09:50
16 Ideas or help related to the use of GFDL wiki-wide 2 2 TheDJ 2024-06-15 08:18
17 Mirrored image 2 2 Jeff G. 2024-06-15 14:26
18 How to find the source cat for why a given image is in a specific category tree? 9 4 Prototyperspective 2024-06-19 14:45
19 Wikidata sufficient for scope? 16 11 Bedivere 2024-06-20 20:41
20 Intersection categories 36 12 Ghouston 2024-06-20 02:36
21 Commons:The Commoner 1 1 JWilz12345 2024-06-18 15:43
22 Subpages for documentation in category namespace 1 1 Enhancing999 2024-06-18 17:38
23 Supersede images : what to do with old page ? 3 2 Yug 2024-06-18 18:37
24 New changes to the "Depicts" step in UploadWizard available on Beta Commons 9 5 CParle (WMF) 2024-06-20 14:58
25 User:Stilfehler/Garden plants that thrive in USDA Plant Hardiness Zone 10 3 2 Stilfehler 2024-06-19 18:39
26 Incorrect use of "Extracted from" template? 12 4 Ubcule 2024-06-20 13:47
27 Category:Engraved illustrations from Iconographic Encyclopedia of Science, Literature and Art, Published in 1851 4 3 AndyVolykhov 2024-06-20 16:13
28 Approval for PDF 2 2 Geohakkeri 2024-06-20 15:17
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 in Diepenheim, Netherlands, being packed in straw to prevent freezing (1950) [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.

May 28

edit

Category:Film characters by actors

edit

Most of these categories contain no media of their own, but subcategories of characters (that are often played by multiple actors), and the structure is often circular in nature (e.g. the category "Whoopi Goldberg" has the subcategory "Whoopi Goldberg characters", which has the subcategory "Shenzi", which has the subcategory "Whoopi Goldberg"). Most if not all of these were made by the same IP user who created a huge amount of category spam in Category:Space Jam, Category:Mickey Mouse and a bunch of others.

I don't think this category tree structure is inherently invalid, but I feel it's mis-applied and excessive in most of these cases. I'd like to hear more people's thoughts on this before I take this to CfD though. ReneeWrites (talk) 19:19, 28 May 2024 (UTC)Reply

The whole thing seems rather ambiguous and pointless. Like the parent is called "Film characters" but then the subcategories aren't even characters. Or maybe they are. Is a category like that suppose to be for "characters of Chris Rock" or "Characters played by Chris Rock"? It's not really clear. Then on top of it a lot of the sub-categories only contain one child category but no files, which I'm not really a fan of. --Adamant1 (talk) 19:49, 28 May 2024 (UTC)Reply
I think this category structure is invalid, and these categories should be deleted. The purpose of categories on Commons is fundamentally to categorize media files. These categories don't organize media; instead, they attempt to represent abstract relationships between subjects. But that's what we have Wikidata for! We don't need to create a clumsy imitation of it on this site.
The same probably goes for the following categories, at a minimum:
Omphalographer (talk) 17:58, 29 May 2024 (UTC)Reply
Most of the categories in Category:Actors by role were made by the same guy who filled Category:Film characters by actors and made the over 500 categories for Space Jam, Mickey Mouse, Scooby Doo etc. I took to CfD earlier. ReneeWrites (talk) 10:19, 30 May 2024 (UTC)Reply
CfD plz Trade (talk) 15:59, 30 May 2024 (UTC)Reply
@Trade: Created a CfD for Film characters by actors and Actors by role. ReneeWrites (talk) 19:29, 30 May 2024 (UTC)Reply

Commons is not the place for this. Al Capone is not defined by Alec Baldwin and neither is Alec Baldwin defined by Al Capone. All of these categories should be deleted. The only place this data should be presented is in Wikipedia. Wikidata, might hold the names of movies and their casts, however that again is held in Wikipedia. We are not a repository of facts; we hold files, last time I looked. Only recently we had to go through this nonsense with film locations. Broichmore (talk) 12:20, 4 June 2024 (UTC)Reply

@Broichmore: Could you link me to the discussion about film locations? Was there a consensus? ReneeWrites (talk) 20:31, 4 June 2024 (UTC)Reply
Commons:Categories for discussion/2021/03/Category:Film locations by film (and the discussion which led into that, Commons:Categories for discussion/2020/11/Category:Film locations of Sonic the Hedgehog). Omphalographer (talk) 21:58, 4 June 2024 (UTC)Reply
Thank you 🙂 ReneeWrites (talk) 22:05, 4 June 2024 (UTC)Reply
Why is the category blue if consensus were to delete? Trade (talk) 02:42, 9 June 2024 (UTC)Reply
@Trade: This is about a current discussion, not one that his been concluded. - Jmabel ! talk 15:27, 9 June 2024 (UTC)Reply
Agree about the general problem, as mentioned above, the problem with Category:Films by actor from the United States (or Category:Films by actor) in general is similar.
The main question to solve is: where to place a picture of actor x playing the character y in the film z? In the three categories for each of these. Enhancing999 (talk) 17:27, 9 June 2024 (UTC)Reply
Under the actor, the character (if we have such a category), and (if that character is not a subcat of the film) the film. If we have more than a handful of such images for the same actor in the same film, then we can make a subcat bringing the three together. - Jmabel ! talk 23:56, 9 June 2024 (UTC)Reply
Laughingly Liam Neeson apparently played Hitler in a mini series. If we had a picture of him dressed up as Hitler, I certainly don’t want to see him filed under Hitler. Yes, under category Liam Neeson, and if we had one, for the TV series The latter should only have pix of the actual production, and in 121 years time, stills from the show, and the film itself. Broichmore (talk) 17:02, 16 June 2024 (UTC)Reply
I think something specifically about actors playing Hitler, used only for images in that role, would be a lot better than the current Category:Adolf Hitler interpreters which consists entirely of categories about people, by name. - Jmabel ! talk 23:29, 16 June 2024 (UTC)Reply
Every single "[Character] interpreters" category is like that. You can find them all compiled in Category:Actors by role and a CfD I opened for it last month at Discussion: Category:Actors by role where I made a similar argument about how to subcategorize actors playing specific characters. I also argued for all the "[Character] interpreters" categories to be deleted. ReneeWrites (talk) 08:03, 17 June 2024 (UTC)Reply
Still another approach at Commons:Categories for discussion/2024/06/Category:Madras (film), where the category for an actor is a subcategory of the film, but we don't have any media related to the film itself. Possibly the same problem applies to any film category that only has subcategories. Enhancing999 (talk) 09:40, 20 June 2024 (UTC)Reply
This is not that different from actors being subcategorized with characters they've played in films (see Category:Actors by role). It's actually the same problem. Broichmore put it really well in a comment he made earlier. To borrow his Al Capone example, Al Capone's not an appropriate subcategory of Alec Baldwin, nor is Alec Baldwin an appropriate subcategory of Al Capone. But once we have media on Commons of Alec Baldwin as Al Capone it can be added to both those categories. If we have enough media to justify creating a category for it on its own it can be named something like "Category:Alec Baldwin as Al Capone" and be made a subcategory for both of them. ReneeWrites (talk) 18:22, 20 June 2024 (UTC)Reply

May 31

edit

I'm unable to use the image I just uploaded.

edit

Hi I don't seem to be able to use the file https://commons.wikimedia.org/wiki/File:M_F_Gervais_Holy_Roman_Empire.pdf It show up in Commons but in Wikipedia I'm not able to use it. Why? It happened for my last file and someone 'did' something... I don't know what was done but it worked. What should I do to fix it? — Preceding unsigned comment added by M F Gervais (talk • contribs) 18:45, 31 May 2024 (UTC)Reply

@M F Gervais: It is there and it functional however due to how big and unwieldy it is as a pdf it takes a while to render, especially whern it has to develop the image cache first:
 
Now because PDFs are typically multipage document it can need extra formatting if you are trying to do it through standard wiki formatting. mw:help:images. PDFs should not be used if you want to display an image, please upload an image file per Com:File types — Preceding unsigned comment added by Billinghurst (talk • contribs) 07:59, 1 June 2024‎ (UTC)Reply

June 05

edit

Special:UncategorizedCategories

edit

Special:UncategorizedCategories is back over 1000 categories. If you can add appropriate parent categories to any of the many that have otherwise reasonable content, that would be very helpful. If you're not a admin, don't worry about the empty ones, one or another admin will eventually find those and delete them. - Jmabel ! talk 06:05, 5 June 2024 (UTC)Reply

Now up to 1165 categories. I have the feeling almost no one is addressing this. I've done literally thousands, probably over 5000, and while I still try to do 50 or so per week, that is not enough to keep up. - Jmabel ! talk 17:53, 10 June 2024 (UTC)Reply
@Jmabel: I did a few today and about once a month a small portion.
  Question Is it a good idea to have the numbers next to the categories, like in other pages? Then you can see at a glance which are empty and not bother about them (for none admins like me) or to be able to remove them in quick succession (for admins). JopkeB (talk) 07:50, 15 June 2024 (UTC)Reply
Wouldn't that be nice? As it is, in case you haven't noticed, you can hover over the link and see whether there are files in the category. - Jmabel ! talk 14:56, 15 June 2024 (UTC)Reply
No I did not notice and I still do not see it. When I hover over a link, I see only the category name, for instance Category:Activité supplémentaire bibliothéquaire, but nothing else. JopkeB (talk) 07:31, 18 June 2024 (UTC)Reply
Weird that you get a different behavior than I do. So you don't get a thing like this in the popup?
Category:Queensferry Parish Church, South Queensferry ⋅ actions ⋅ popups
44 bytes, 0 wikiLinks, 0 images, 0 categories, 1 week 4 days old
----
Queensferry Parish Church, South Queensferry
Category members (5 shown)
File:Queensferry Parish Church 01.jpg, File:Queensferry Parish Church 02.jpg, File:Queensferry Parish Church 03.jpg, File:Queensferry Parish Church 04.jpg, File:South Queensferry Townscape , Queensferry Parish Church - geograph.org.uk - 3034870.jpg
Jmabel ! talk 18:25, 18 June 2024 (UTC)Reply
No Jmabel, in the pop-up I only get the name of the category again, nothing else. Is it something in my preferences? JopkeB (talk) 04:01, 21 June 2024 (UTC)Reply
@JopkeB: Yes, please search Special:Preferences#mw-prefsection-gadgets for "Popups".   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 05:30, 21 June 2024 (UTC)Reply

June 09

edit

RFC: Automatic categorisation both bane and gain; work needed to identify source of categorisation

edit

Hi. Having been involved in large amounts of tidying over the years we are starting to get to an administrative burden from automatic categorisation where it is going wrong, Our use of complex and layered templates that directly apply categories, eg. Template:Topic by country, or the inhalation of categories based on Template:Wikidata infobox, or through Modules is requiring more and more time and more and more complex knowledge to resolve this (mis)categorisation where it goes wrong, or where it causes issues outside of our criteria.

We need some better technical solutions. We need a direct and overt ability to know the source of the categorisation be it:

  1. direct category in the page
  2. template that has local data
  3. template that is importing information from wikidata

Some of this sort of exists when one has Com:HotCat as a gadget, though the other two have no ready means to identify the source.

Categorisation is clearly something where automation is useful and it is not in itself the problem. When it is wrong, and needs a lot of work to resolve, then it moves from problem to big problem.

We also need a better means for getting resolution categorisation fixes of the points in #2 and #3. We need guidance to people to how they best address categorisation that has gone wrong and they don't know how to fix it. Some of that is that we need to review our documentation in the templates to ensure that they have guidance for the appropriate use of the template, and what it actually does, as well as the guidance on the appropriate use of the parameters. Template designers/creators need to be involved in that space as an expectation, and those that put them through major rewrites. If it is hard to use and hard to understand then the community needs to challenge both its design and its purpose.

If we don't do something the categorisation issues are going to continue to multiply, and the rules that we have in place will be ignored and we will just have mess. I know that I am partly just stating the problem, and not necessarily the solution, however, at this point I am looking for comments about where others think we are, and some general thoughts on how we can address this at a higher level before drilling down into all the solutions.  — billinghurst sDrewth 00:22, 9 June 2024 (UTC)Reply

It's probably a side thing, but I have a serious problem with categories being forced on us through infoboxes. Like there's a ton of people who are recipients of minor, non-notable awards that automatically get sorted into categories for said awards and their various sub-awards when it's not really useful to have things categorized down to that small of a level. You can't really do anything about it on our end either. Regardless, we shouldn't have how we categorize things dictated by other projects period. We certainly don't name categories based on standards set by Wikipedia editors, or keep files that violate the guidelines simply because of how other projects do things. -Adamant1 (talk) 00:34, 9 June 2024 (UTC)Reply
Wikidata Infoboxes provide given name, surname, and birth and death dates, and "living people", which should presumably be uncontroversial. [Similarly, some gender info so it can do "men by name" and "women by name" as well as "people by name". - Jmabel ! talk 01:53, 9 June 2024 (UTC)] I'm not at all sure they should do any other automatic addition of categories, though there may be some others that are equally clear. I haven't really seen this thing with awards, but that may say something about what topics I work on. @Adamant1: can you give an example and (anyone) is there documentation somewhere about what categories infoboxes add? - Jmabel ! talk 01:00, 9 June 2024 (UTC)Reply
@Jmabel: I don't necessarily have an issue with infoboxes providing given name, surname, or birth and death dates. That's about it though. If you want an example of what I'm talking about checkout the subcategories in Category:Recipients of Russian military awards and decorations. Like categories for people that have won the various "X Years of Victory in the Great Patriotic War 1941–1945" medals. For instance Category:Heydar Aliyev, where there's like 30 categories for minor awards that I assume were all added by the infobox and can't be removed or edited. The whole thing is totally ridiculous overkill. --Adamant1 (talk) 01:11, 9 June 2024 (UTC)Reply
How do we decide which military awards are notable enough for a category, though? Trade (talk) 01:42, 9 June 2024 (UTC)Reply
The same way we decide anything else of the sort. It does seem odd for the decision to be hidden in a template. - Jmabel ! talk 01:44, 9 June 2024 (UTC)Reply
Interesting territory, and there I think that we need to take a bit of a step back. The first question has to be whether the category should exist here, prior to what and how it is populated. Only after that can we then discuss the means that we want things populated, and whether they are falling into a variation of Com:OVERCAT. I don't mind cats coming from WD data as long as it is sustainable and comparatively easy to manage and resolve. It is the deep/problematic dives that we need to resolve, either in the finding or in the fixing.  — billinghurst sDrewth 02:18, 9 June 2024 (UTC)Reply
That's an excellent point by @Billinghurst. Fundamentally, we should be creating good categories and populating them in compliance with Commons category policies   first and foremost, regardless of how this is done, be it manually or using templates and other tools. I agree very strongly with @Adamant1 that some of these categorization schemes (e.g. "recipients of X award") which clearly are really about storing data points about a topic in the form of categorization are not good form, as they aren't really about categorizing media, but trivial categorization of topics, which is not the purview of Commons. Josh (talk) 15:31, 10 June 2024 (UTC)Reply
@Jmabel: The code is in {{Wikidata infobox}}, which should be documented on that page.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 01:36, 9 June 2024 (UTC)Reply
But as far as I can see it is not at all documented there; not even the mechanism (buried somewhere other than the code on that page) is documented. It's not at all clear where one would look to see what properties/categories are handled this way. - Jmabel ! talk 01:48, 9 June 2024 (UTC)Reply
Template:Wikidata Infobox/core documentation mentions "awards", but doesn't indicate what Wikidata properties are involved. - Jmabel ! talk 01:51, 9 June 2024 (UTC)Reply
I think Wikidata could be helpful for populating categories about video games, movies, television shows and animes. Adding the correct categories by hand is somewhat of an tedious process Trade (talk) 01:41, 9 June 2024 (UTC)Reply
Wikidata Infoboxes provide given name, surname, and birth and death dates, and "living people", which should presumably be uncontroversial. I'd dispute that! Broad categories like "living people" or "2000 deaths" have limited utility on Commons. There are extraordinarily few situations where they are genuinely useful as a means of locating media. Omphalographer (talk) 02:00, 9 June 2024 (UTC)Reply
Bollocks. The Commons category structure has been an untenable mess for years. A large part of the problem expressly lies with editors from Wikidata and Wikipedia who bring their baggage with them and fail to understand that Commons is a separate site with its own policies. A prime example of the Wikidata side of the problem is with the "Births in" categories. These editors have actively sandbagged a clear segregation from "People of" categories, resulting in a massive clusterfuck of superfluous categorization and a failure to understand what a meta category actually is, as opposed to what they personally think a meta category should be. In the few times where Commons admins have crossed paths with me in attempting to clean up this mess, I gained the impression that those admins had zero understanding of COM:CAT. However, let's not get bogged down with examples, because the problem's a lot bigger than any example.RadioKAOS (talk) 02:05, 9 June 2024 (UTC)Reply
What's the issue with editors from Wikipedia? Trade (talk) 02:20, 9 June 2024 (UTC)Reply
@RadioKAOS: I am very comfortable with us using WD data to categorise here. My issue primarily is how we fix it when it goes askew. Our categories, our categorisation, and decision-making how we use WD data to categorise here. We will always face the issue of implementation of decisions from contributors who edit elsewhere, so the issue isn't their ideas, it is the consensus they need to reach in its implementation, instead of unilateral implementation.

So for the moment, rather than stray into the "whataboutism" it would be nice if we focus on the issue, rather than inflate to a blame game.  — billinghurst sDrewth 02:27, 9 June 2024 (UTC)Reply

@Billinghurst: Not to point fingers at Wikipedia users, but I think it gets to one route cause of the problem, which is that it seems like people from other projects use categories as a rudimentary way to store (or display) information about a subject. Not necessarily organize media related to it. Like with the example of categories related to awards, if you look at Category:Ivan Matyukhin there's 10 categories for awards that they have received but absolutely zero images in the category having to do with them.
So the categories are just being used as rudimentary ways to store and display biographical facts about Ivan Matyukhin, not to organize media related to the awards. And again not to point fingers, but I don't think that's something regular users of Commons would do on our end. Regardless, I think the problem could largely be solved if we were clearer about (and better enforced) the idea that categories are intended to group related pages and media. Not act as shoo-ins for Wikidata data item's or something. But then we don't have the ability to do that if the categories are being automatically created and added by the infoboxes either. So... --Adamant1 (talk) 11:37, 9 June 2024 (UTC)Reply
@Adamant1: Creation of a cat and the population of a cat are different and separate acts. For WD, they are also both happening here, not at WD, as they are in templates that we control. Someone has created the category and someone has added the code to Template:Wikidata infobox for the population to occur. The automation thereafter is due to having created the cat, and done the coding to add the cat, the population is from data at WD. If that is the issue, then can we please address that in a different thread. At this time, it is the ability to locate and identify from where the categorisation is taking place and resolving that.  — billinghurst sDrewth 01:21, 10 June 2024 (UTC)Reply
@Billinghurst If I understand you correctly, it seems what you are saying is that it is not the automation per se that is the problem, but instead our process of having created these kinds of categories in the first place...if Category:Ivan Matyukhin exists and the 10 'Category:Recipient of...' categories exist, we can hardly blame the automated tool for adding those presumably accurate connections, but instead it rests on us as a community to have the deeper discussion and develop a consensus on how much of this kind of categorization we should have in the first place. Am I reading you correctly? Josh (talk) 15:41, 10 June 2024 (UTC)Reply
@Billinghurst If I understand you correctly, it seems what you are saying is that it is not the automation per se that is the problem, but instead our process of having created these kinds of categories in the first place...if Category:Ivan Matyukhin exists and the 10 'Category:Recipient of...' categories exist, we can hardly blame the automated tool for adding those presumably accurate connections, but instead it rests on us as a community to have the deeper discussion and develop a consensus on how much of this kind of categorization we should have in the first place. Am I reading you correctly? Josh (talk) 15:41, 10 June 2024 (UTC)Reply
@Joshbaumgartner: My original point, is the fixing of problematic categorisation which was the primary reason for my raising the issue. These are all categories that are created by us, and the coding in the templates is by us, either through WD infobox or other Commons templates. Finding how and where to fix things is increasingly becoming difficult, and I am looking for solutions there. We need to show how it gets there, and either how to fix it, or where to request the remedy, AND we cannot be relying on individuals. [So a clear means to identify auto-populated cats, and in the documentation in the template to show it autopopulates and where.]

My second point is that we own our categories and their creation. If we allow them to exist, then auto-population is okay, though the criteria in my first point needs to be met. Point 2 cannot exist in isolation.  — billinghurst sDrewth 04:02, 11 June 2024 (UTC)Reply

I fixed a few cases when trying to work on categories stuck in Category:Non-empty category redirects. This concerned mostly categories on category pages (not files) and -- beyond the question which name to choose -- the categorization itself was rarely controversial. (There is some debate about the "old map" and "historical map" categories at Module_talk:Messtischblatt, categorization added for years).
Categories added by Template:Topic by country are actually relatively straightforward, but that template did lack documentation (somewhat improved yesterday). They can highlight problems in our category tree. Wikidata was rarely much of an issue. (I did blame it by error when a category was added with &html entities).
A search in the source text of Template: or Module: namespace usually finds the definition of a categorization. "|setscats= " in template documentation is meant to help. A general problem with categories added by templates is that everything needs to be refreshed if it's changed. Once one was identified a search with PetScan on subcategories of Category:Non-empty category redirects helped find other problematic uses. I noted some finds on User talk:RussBot/category redirect log. Enhancing999 (talk) 09:14, 10 June 2024 (UTC)Reply
To me this is that if a template categorises other pages, then the template needs to specifically say that is its purpose, and give clear statements of what it is doing, ie. where to expect to see results. Ideally I would like to see a complete list of categories that it populates as that makes reverse finding useful. I would also like to see categories that are populated automatically also have a maintenance category that says that can be autopopulated by such and such template. Clarity is gold in these situations. If there is a master template for broad categorisation, then it should have a section for problems noted, and it should be identified for watching by numbers of people. (fixing problems early before they propagate is also gold)  — billinghurst sDrewth 04:27, 11 June 2024 (UTC)Reply
Not sure how practical that is. Potentially it could mean that one would have to edit every parent category (A of X, B of X, C of X) for each subcategory (NEW of X) instead of just a category.
Unless we find a central way to add them, this could mean that for 250 new categories one would have to edit every occurrence of several parent categories (All A of .., All B of .., All C of ..), possibly thousands. Enhancing999 (talk) 12:18, 11 June 2024 (UTC)Reply
Thanks a lot @Billinghurst: for starting this RfC, I totally agree with your description of the problems that templates can create. So we need to:
  • inventorize the problems
  • give solutions, how can we address these problems.
  Agree Templates are often a great tool, for instance for the date categories and the template that is importing information from wikidata (as long as it is limited to the basic categories, like given name, surname, birth and death dates (useful to decide whether works of an artist are in PD), people/men/women by name).
But I am struggling too often with automatic categorisation by templates, and indeed Template:Topic by country is one of them (others are about photographers). Some of my problems:
  1. The template is automatically adding parent categories that do not exist for that country, while a parent of it or another alternative category does exists, and/or there are not enough files or subcategories to justify creating the red one (and it is a lot of work to create new ones over and over again, which I consider part of the "administrative burden" Billinghurst is talking about).
  2. Sometimes there is even a better child category for a country/location than the automatically added one (for instance for the photographer by location by date: the standard parent is the location, but sometimes "history of location" or even a category that groups all the photographers together for the location and/or date would be better).
  3. Some templates make use of lists or other pages that I cannot find, they might be hidden, but anyway not documented (with links) in the template.
Though it is indeed probably a side thing, I agree with Adamant1 that there are editors who create categories, just because there is a Wikidata item or an EN-WP category/page with the same name, no matter whether we need them on Commons or not. And then it is a lot of work to put that right again. That also contributes to the administrative burden.
Suggestions for solutions:
  • Before you intend to create a new template that is more complicated than a simple date template: present your proposal to the community (at least in plain English, you might of coarse also present (a part of) the proposed program), ask for comment. Same for adding automatically new parent categories by a WD template.
  • Good documentation should be a basic feature in each template, before a new one is published or in use:
    • in plain English, like functional specifications; explaining what the template does (what actions), how it does it ( mechanisms and for instance: what lists/other things/links it uses), when to use it (in what kind of categories) and how to use it (what exactly should you do to make it work). Written with people in mind who know nothing or very little of programming, but are interested in templates. This should also be checked and done for existing templates as well.
    • technically, for editors who will solve problems when the creator is not available.
  • A procedure for when a template creates trouble:
    • Where to drop the problem?
    • Who is going to solve it? Especially when the original creator is not available (or refuses to solve it, what I have experienced as well).
    • Can we remove the template and add better parent categories (and often a navigation template) instead? Without the risk that the next editor will reverse it?
JopkeB (talk) 06:39, 11 June 2024 (UTC)Reply

  Question@Mike Peel: do you have a system-based solution for how we can readily identify the categories that are/can be populated from WD (and thinking as maintenance cats) if it isn't already. What is done at WD end, and what can be done at Commons end to be clearly overt?  — billinghurst sDrewth 00:56, 12 June 2024 (UTC)Reply

Solution mode

edit

So taking the next step, what exactly do we want to achieve?

Starting simple, what if anything do we want to achieve at

and without getting into the detail, where else are we looking to get information into place, or where might we need clear procedural change, or mention of expectations.  — billinghurst sDrewth 00:50, 12 June 2024 (UTC)Reply

It looks like the guidelines are roughly speaking OK, perhaps just some additions. The main issues might be applying and enforcement. JopkeB (talk) 07:42, 14 June 2024 (UTC)Reply
For applying these policies, this can be done manually or automatically. To support manual application, the best tools are well-written and easily-accessible guidelines for editors of all levels on how to do so correctly and efficiently. For automated application, good tools, such as templates, are needed. These tools should allow for manual override (e.g. a nocat parameter to suppress automated categorization on a given application) where applicable. Documentation should make it clear to users how to use these options.
For enforcement, which I see basically as maintenance, automation is valuable in the form of good monitoring tools, such as automated flags for cases that are outside of the guidelines and spotting areas of inconsistent category organization and naming. However, actually addressing these situations is incumbent on human editors to do. As for the term 'enforcement', I associate that more with the involvement of authority, such as admin action to stop abuse or dealing with intentional disruption, while 'maintenance' doesn't necessarily imply that previous editors did anything wrong per se, but just that we are continuing to evolve and improve our categorization and so forth.
Ultimately, human editors are the key to successful categorization. Templates and other tools can be used by them to help increase their efficiency, but it is up to the human to ensure those tools are correctly applied. For example, applying a template and then saying that the categorization must be adhered to because that is what the template added is not appropriate. Thus the guidelines should focus on ensuring editors understand what the end goal is of categorization and provide them with tools on how to get there, with or without templates and gadgets. I would certainly like to start looking at some specific language being proposed for the above policies to get to the meat of the matter. Josh (talk) 14:55, 17 June 2024 (UTC)Reply
Undoubtfully tools can play a role. But I think step one is to convince people who create (and/or adjust) templates, that creating(/adjusting) a template is only half of the job. The other half consists of creating(/adjusting) good documentation (and testing according to a test plan). JopkeB (talk) 11:55, 18 June 2024 (UTC)Reply
Updating Commons:Templates and Commons:Template documentation is certainly a good idea. Both of these have relatively little and out-of-date information, so both lack utility in their current guise. The implications of what is changed are significant however, with a great potential for unintended consequences, so new wording should be first proposed with significant input solicited before any actual adoption of a new and revamped template policy is published. I think it is an effort worth doing, however, and look forward to participating. Josh (talk) 14:30, 17 June 2024 (UTC)Reply
On the Wikidata side, if we are going to allow any element of Commons categorization to be controlled by Wikidata properties, then there has to be a clear rule set agreed to on the WD side for each of those controlling properties to ensure that changes on the WD side do not adversely damage our categorization scheme here. For example, existing properties such as 'instance of' and 'subclass of' are probably are unworkable, as the WD scheme for these is well established but quite different for Commons categorization in many ways. Perhaps a new set of properties will need to be thought out and proposed on WD specifically to support Commons categorization. This could all be very useful, and a cross-project collaboration effort which brings both Commons and WD minds together may well be able to work out some good tools for this. Josh (talk) 14:30, 17 June 2024 (UTC)Reply

June 10

edit

Japanese categories

edit

These type of coin operated 'game' machines are usualy only found in funfairs, but in Japan these are in permanent shops. I hesitade to call these shops, but how should we classify them?

These kind of overhead power distribution is very common in Japan. Wich category? Smiley.toerist (talk) 09:30, 10 June 2024 (UTC)Reply

For the second question: Category:Pole-mounted transformers in Japan I suppose. Alexpl (talk) 13:19, 10 June 2024 (UTC)Reply
I created: Category:Electrical distribution in Japan. Smiley.toerist (talk) 10:08, 17 June 2024 (UTC)Reply
@Smiley.toerist: In British English I'd call the first kind of thing an "amusement arcade". They're quite common in seaside resorts here. And we've got Category:Amusement arcades in Japan which seems to cover the right kind of thing. --bjh21 (talk) 13:48, 10 June 2024 (UTC)Reply

This machine is basicaly an ticketing machine, but it has also a money change function where banknotes are exchanged for coins.Smiley.toerist (talk) 22:35, 15 June 2024 (UTC)Reply

@Smiley.toerist, please see Category:Ticket machines in Japan and Category:Automatic coin dispensers. —⁠andrybak (talk) 00:28, 17 June 2024 (UTC)Reply
I propose to create a subcategory: 'Rail fare machines on rail vehicles in Japan'. Sometimes no ticket is issued but you get permission to leave the train/tram after dropping the coins or check out with a card. On some local trains you print a ticket with the starting station. Above is a display showing how much must be paid at the next station from the starting station. At buzy stations the payment/check is done at the station gate.Smiley.toerist (talk) 10:21, 17 June 2024 (UTC)Reply

Category:Flags of fictional countries

edit

Is this category for flags that are fictional? Or is it for flags for countries featured in creative works? There is no way to infer this from the category name alone Trade (talk) 22:21, 10 June 2024 (UTC)Reply

As I've interpreted it, it's both - they're flags which are fictional, and which have appeared in fictional works. I'm not sure how you'd have one without the other. Omphalographer (talk) 05:00, 11 June 2024 (UTC)Reply
Also note: We're keeping flags from notable works of fiction there. Files that are just about personal fiction (look at the awesome symbols of the micronation my roleplaying group founded yesterday) should get deleted as soon as possible. And see also the Category:Fictional flags of historical entities (to be replaced and deleted), now that category name should speak for itself. --Enyavar (talk) 07:47, 11 June 2024 (UTC)Reply
Right, so we are we showing both type of flags into the exact same category? This is just a mess to keep track of Trade (talk) 18:22, 11 June 2024 (UTC)Reply
What do you mean by "both types"? As far as I'm aware, there is (or should be) only one type of image in this category - depictions of flags which stem from fictional works, and which represent countries which only exist within those works of fiction. A typical example would be File:Gilead-Flag.gif, the flag of the fictional country of Gilead from The Handmaid's Tale. Omphalographer (talk) 18:31, 11 June 2024 (UTC)Reply
There is nothing in the category nor it's name to indicate that only flags from creative works should be features. Trade (talk) 22:24, 12 June 2024 (UTC)Reply
I could be totally off base here but I've done some work in the area and I think at least some of the problem is the ambiguity of the parent categories and how the whole thing is structured going up from there. For instance the category has both Category:Flags in fiction and Category:Special or fictional flags as parents. But then Category:Special or fictional flags is also a parent of Category:Flags in fiction. So it's just circular. Plus the Wikidata entry for Category:Special or fictional flags appears to be about "unofficial flag", which really has nothing to with fictional flags to begin with. Regardless, it seems like this combines "special", "fictional", and "unofficial" flags into the same category and does it in a way were the categories are just circular. We should just pick a term, go with it, and make the parents categories actually lead somewhere meaningful. --Adamant1 (talk) 00:06, 13 June 2024 (UTC)Reply
How about "Flags of countries from creative works"? This could then be a subcategory of "Flags from creative works", with it being a subcategory of "Symbols from creative works" Trade (talk) 21:57, 13 June 2024 (UTC)Reply
I think not. That could as easily mean fictional flags of real countries as flags of fictional countries. - Jmabel ! talk 01:10, 14 June 2024 (UTC)Reply
Fictional flag does not equal Flag from creative work Trade (talk) 14:00, 15 June 2024 (UTC)Reply
The current name applies the adjective 'fictional' to the country, not the flag, which indicates that a fictional flag of a real country would not apply here. A fictional country is one from a fictional work (our scope would limit this further to notable fictional works), so any flag that is used by such a country would go here. However, renaming this category to "Flags of countries from creative work" could be interpreted either in the exact same way (expression: "(flags) of (countries from creative works)") or as Jmabel does as fictional flags of real countries (expression: "(flags of countries) from (creative works)") which is always a possibility when using a double-prepositional phrase. Thus I think the current category name is more clear. Josh (talk) 13:47, 17 June 2024 (UTC)Reply
At this point Commons have hundreds if not more than a thousand fictional flags while flags from creative works makes up less than a hundred files. One is very clearly an issue, the other is not. Trade (talk) 14:23, 19 June 2024 (UTC)Reply
@Adamant1, Category:Special or fictional flags is a complete violation of the Selectivity Principle   and Simplicity Principle  . A special flag (presumably described by the linked WD item as a privately used, unofficial flag) is very different from a fictional flag. The former is very much a real flag, while the latter is patently not real. Since these alone are two different topics, they should be two distinct categories, not to mention any other hodge podge that is currently in this category. As for the names, "special flags" is a horrible category name, as 'special' is way to broad of a concept. We should focus on what the flags represent (and hence whether they fit in our scope), so 'flags of countries', 'flags of social movements', 'flags of companies', 'flags of individual people', etc. are all potentially good concepts for categories. I would say the the OP category 'flags of fictional countries' also is fine as a concept for this reason. Josh (talk) 14:02, 17 June 2024 (UTC)Reply
As far as i can tell "special flag" is just an euphemism for any flag that isn't a nation flag Trade (talk) 14:36, 19 June 2024 (UTC)Reply

@Omphalographer: way back on your 05:00, 11 June 2024 remark about "I'm not sure how you'd have one without the other," it seems to me that most micronations are "fictional countries" without necessarily involving any fictional creative work. I don't think there is any escaping needing an explanatory headnote for any name we might come up with in this terrain. - Jmabel ! talk 19:17, 17 June 2024 (UTC)Reply

I think there is a meaningful distinction we can make between flags which are generally acknowledged as artifacts of fictional works (e.g. flags from books, movies, video games, etc) and flags which were created to be used in the real world to represent some entity, even if it's an entity of dubious existence like a micronation. Omphalographer (talk) 20:31, 17 June 2024 (UTC)Reply
How do we name the two categories in a way that makes the distinction blatant? Trade (talk) 15:22, 19 June 2024 (UTC)Reply

June 11

edit

New designs for logo detection tool

edit
 
Mockup for an alert when a logo is detected

Hello all! We're happy to share that we will work on logo detection in the following months and that we defined an initial approach for this.

You can read more at the project page and you can have your say in the project's talk.

We want your feedback on it, and we need your insights on how to further tune the detection tool.

Thanks for your attention! Sannita (WMF) (talk) 13:54, 11 June 2024 (UTC)Reply

I'm rather confused. The general feed back seemed to me to amount to "logo detection isn't very useful." I was told by a couple of people when I asked informally, "Don't worry, it isn't like logo detection isn't the goal, this was just a side effect of work on something else that someone thought might be useful." And now you say that further work is proceeding on this front? What, exactly, put this on the front burner, especially given that we are constantly being reminded that dev has very limited resources for Commons? What is the problem we are trying to solve? - Jmabel ! talk 22:25, 11 June 2024 (UTC)Reply
@Jmabel Our impression, to be fair, was quite the opposite: that it was something that could be useful in dealing with the third-most frequent rationale for requests for deletions (the first two being copyvios and FoP, which we found it was impossible to tackle in an automated way). There was more difficulty in defining how this could be implemented, but not on its usefulness. This is why we are re-opening the feedback period, to understand how it could be implemented. Sannita (WMF) (talk) 10:36, 13 June 2024 (UTC)Reply
@Sannita (WMF) "third-most frequent rationale for requests for deletions (the first two being copyvios" - This doesn't make sense at all. The only reason we would delete a logo is because it's a copyvio, not because its a logo. There are scores of logos which are in the public domain, either by age or by lack of creativity, while others get licensed under free licenses. I'm not sure why we should discourage people of uploading that specific content with such a warning, when those exact same rules apply to everything else. As it is, I tend to not support that implementation. And as JMabel mentioned, it's disheartening to see that resources were wasted developing such an apparently useless tool, when there are clearly established priorities (see the old wish lists, for instance). Darwin Ahoy! 16:16, 13 June 2024 (UTC)Reply
@Sannita (WMF), Jmabel, and DarwIn: I'll leave others to decide on the best or most suited UI for the logo detection. As for the feature, I am supportive of this, but conditionally. Suggest this feature should be mandatory for users who do not have the appropriate user rights; I suggest users who are not admins/sysops, license reviewers, and/or autopatrolled. Users who are under these three tiers of user groups are free to upload logos and should not be slapped with this filter, since they are already aware of copyright issues and TOO considerations for logos. If possible, the feature should effectively block uses of "FileExporter" and other cross-wiki file transfer tools. And one more thing, I suggest the filter can prohibit new users (those who are not autoconfirmed) from uploading or importing logos (even photos showing logos that are non-de minimis/non-incidental). Hopefully, this will trim down at least a third or less (my guess) of deletion requests that contribute to the perennial backlogs. There are many more areas in Commons that also need attentions and resolutions, like Commons:Categories for discussion/Older (some open discussions were from before the lockdown era of 2020). JWilz12345 (Talk|Contrib's.) 08:30, 14 June 2024 (UTC)Reply
@JWilz12345: I think the plan is for this to become a secret feature. It has no effect on the upload itself and nobody but the uploader will know about the warning. Possibly, the same effect could have been achieved by merely editing the current interface and noting "if it's a logo, follow logo guidelines". Enhancing999 (talk) 08:43, 14 June 2024 (UTC)Reply
Just my opinion, but having a specific warning to the uploader saying the image might be a logo seems rather pointless. If not borderline condensing towards users. People generally know what they are uploading images of. The less clear thing is what license to use in any specific instance and I don't really how this deals with that. A better thing would probably just be a specific checkbox for logos that automatically adds a license and puts the image in a specific category for images that need reviewing on upload. Otherwise people are just going to just ignore the warning just like they are already ignoring guidelines by uploading the image to begin with. What we really need is better ways to review and deal with problematic images on our end though. Not try to unload that on uploaders by over complicating the UploadWizard with a bunch of warnings, extra boxes, and the like. --Adamant1 (talk) 20:52, 15 June 2024 (UTC)Reply
@Adamant1: anything related to copyright is already complicated enough. That's perhaps a price to pay for establishing/creating a free media repository site like Commons, or more so, Wikipedia itself way back more than 20 years ago. Something that founders Wales and Sanger likely did not forseen or anticipate. (Note: just a part of my thoughts, and not a representative of my general perspective on Wikimedia movement, which I still support in the context of mandating global FoP). JWilz12345 (Talk|Contrib's.) 21:12, 15 June 2024 (UTC)Reply
Thanks everyone for your comments! @Adamant1 about the checkbox, we thought of that option too, but ultimately decided against, because we didn't want to clutter too much the UploadWizard and make it more complicated for legitimate uploaders to upload a legitimate logo or fall into the "I'll just ignore that" kind of case. Anyway, our scope is to get to a better and more seamless way of uploading medias, but this will take more designing, prototyping, and testing, so it won't happen overnight.
To everyone, we're open to ideas for eventual moderation of logos in general, given that we don't want to unload a new bunch of work on volunteers without there being consensus. Sannita (WMF) (talk) 14:08, 20 June 2024 (UTC)Reply
I just want to provide some context on @Sannita (WMF)'s post above ... what we're working towards here is an automatic process by which we reliably estimate the likelihood that an uploaded image will be deleted for any reason
If we had that process we'd be able to inform users that their upload is likely to be deleted (and why) during the upload process, which would be a better (and more educational) user experience than we have now. Also moderators would be able to find (and deal with) potentially problematic uploads much more easily
Our initial experiments with machine learning showed we can detect logos reliably, and they're a pretty common reason for DRs, so logo detection seemed like a promising place to start CParle (WMF) (talk) 14:36, 20 June 2024 (UTC)Reply
There may be a misunderstanding here: being a logo is not a reason to delete. We have tens of thousands of logos legitimately on Commons. Laying aside logos that are PD because they are very old, or created by certain governments that don't claim copyrights, etc., an enormous number of logos are below the threshold of originality for copyright, especially in countries like the U.S. where that threshold is quite high. False positives -- discouraging or (worse) preventing upload of content that could legitimately be hosted on Commons -- is at least as bad, and arguably worse than false negatives, letting a "bad" file through. We can always delete a bad file; we cannot conjure a file we don't get to see. - Jmabel ! talk 19:36, 20 June 2024 (UTC)Reply
edit

Does the 15-16 June 2024 Ukraine peace summit logo consist "entirely of a simple geometric combination of shapes and text"? The official alt text describes the ring pattern as "overlapping blue and yellow circles". I see them rather as 10 greyish concentric annuli and 10 yellowish concentric annuli with a partial transparency rule used to show the intersecting parts. So rather simple, but not completely trivial. The Swiss flag is on there too, and that is geometrically very simple and has at least one PD version on Commons.

So does this logo count as a free logo under the simple geometric combination argument, as described at w:Wikipedia:Logos#Copyright-free logos? Is it uploadable to Commons? Boud (talk) 20:00, 11 June 2024 (UTC)Reply

@Boud: Looks OK. In the future, when providing links, it is much preferred not to use URLs that result in downloads to the file system of the computer that is accessing. - Jmabel ! talk 22:35, 11 June 2024 (UTC)Reply
OK, cool - thanks! Regarding the URL, I don't see how it's possible to provide a URL to a file that does not result in downloading the file. Without downloading the file, the file cannot be viewed.
But you also refer to storage in a file system. My guess is what you mean is that it's better to provide a URL that can be used to view an image in a browser tab - in which case the file is downloaded and stored in RAM and very likely also in a cache on a file system, which the user will generally not notice. I did notice that that my browser refuses to display that file in a tab using that URL. Just now I found that removing /jcr:content/renditions/original is sufficient for browser display of the file, in which the file is only stored in RAM and in a cache area of the file system - so thanks for the tip :). I guess jcr:content/... redirects to a script which insists on downloading and storage in a file system and refuses to allow downloading and displaying in a browser tab. Boud (talk) 23:01, 11 June 2024 (UTC)Reply
Yes, everything is likely cached, but normally when you browse to a page you don't need to explicitly delete it to free the disk space back up. - Jmabel ! talk 23:18, 11 June 2024 (UTC)Reply
By the way, for copyright expertise, Village pump/Copyright is generally a better place to ask. - Jmabel ! talk 22:36, 11 June 2024 (UTC)Reply
OK, thanks, noted. Boud (talk) 23:01, 11 June 2024 (UTC)Reply
it's may be COM:TOO Switzerland--Shiro NekoОбг. 15:37, 16 June 2024 (UTC)Reply

Weibo Watermark- Advertising?

edit

Hey-- Is the Weibo Watermark in the lower right of this image advertising per Commons? File:全景图 深圳湾公园 远看香港 - By 科技小辛 - panoramio.jpg --Geographyinitiative (talk) 22:19, 11 June 2024 (UTC)Reply

It is not a reason not to host the photo, assuming that is what you are asking. - Jmabel ! talk 22:39, 11 June 2024 (UTC)Reply
I think he's asking about the watermark specifically. COM:WM makes a distinction between different types of watermarks, this one squarely lands in the second category (promotional watermarks). Those kinds of watermarks should be removed but the file is fine to host here, even with the watermark. ReneeWrites (talk) 23:06, 17 June 2024 (UTC)Reply

June 13

edit

Low server performance?

edit

Hi!

It feels like the servers' performance seems to be decreased compared to the last weeks. Database queries take a lot longer, file publishing sometimes has a huge delay, and also the amount of uploaded files and data has decreased considerably. Do you experience this, too and what could be the reasons? Greetings --PantheraLeo1359531 😺 (talk) 08:49, 13 June 2024 (UTC)Reply

@PantheraLeo1359531: This may have something to do with phab:T363622.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 12:11, 13 June 2024 (UTC)Reply
Thanks :) --PantheraLeo1359531 😺 (talk) 13:39, 13 June 2024 (UTC)Reply
I was trying to edit my watchlist to reduce it .. but that times out too. Enhancing999 (talk) 13:16, 13 June 2024 (UTC)Reply
@Enhancing999: I got the following when I tried:
MediaWiki internal error.
Original exception: [f497cc8d-d5a6-4ad1-95eb-db2be5de539e] 2024-06-13 13:19:30: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
  — 🇺🇦Jeff G. please ping or talk to me🇺🇦 13:22, 13 June 2024 (UTC)Reply
Special:EditWatchlist/raw works. Enhancing999 (talk) 13:30, 13 June 2024 (UTC)Reply
@Enhancing999: Thanks, but "Not enough memory to open this page" is not exactly a ringing endorsement.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 03:19, 14 June 2024 (UTC)Reply

Have I got this right now

edit

The file that I uploaded File:An illustration of a Swedish warship, probably Mars, under attack by a Danish ship.jpg has a warning of deletion as the copyright status is unclear. This is a reproduction of an illustration made in the year 1585. I have sourced it from its appearance in an academic paper, though it is also available on flickr (both sources given with the file). Have I met all the requirements or am I still missing something? Thanks, ThoughtIdRetired (talk) 20:36, 13 June 2024 (UTC)Reply

@ThoughtIdRetired You uploaded the file without a license, so the bot came and tagged it. Next time this happens simply remove the deletion notice after fixing the license. Darwin Ahoy! 21:42, 13 June 2024 (UTC)Reply
Thanks, though I have to say that removing the deletion notice sounds a bit like marking your own homework. For some reason I have never felt totally comfortable with my level of understanding copyright law, which might explain that sentiment. And that bot must have worked pretty quickly on this occasion, because in the past I have often uploaded with the wrong or a missing licence then immediately edited with the correct licence from a file that I know to have an identical copyright situation. ThoughtIdRetired (talk) 22:14, 13 June 2024 (UTC)Reply
@ThoughtIdRetired: if you are less than fully confident, then rather than just remove the tag, start a DR, and in the DR, note what you did. - Jmabel ! talk 01:06, 14 June 2024 (UTC)Reply
Can you decode "DR" for me? Thanks. ThoughtIdRetired (talk) 10:32, 14 June 2024 (UTC)Reply
That would be a deletion request. --Robert Flogaus-Faust (talk) 13:30, 14 June 2024 (UTC)Reply

& @ThoughtIdRetired: Good stuff! Any idea why the cannonballs have flames from both sides, were they incendiary cannonballs? Was it a special weapon, or just an artist never drawing a cannonball before. --RAN (talk) 14:55, 14 June 2024 (UTC)Reply

Our original upload in 2014 describes this picture as The battle between the Danish and Swedish admiral ships Jägmästaren and Sankt Erik. The image was used en:Action of 7 July 1565. Broichmore (talk) 15:54, 14 June 2024 (UTC)Reply
Looking at a larger image, they seem to be incendiary cannonballs. -- Asclepias (talk) 16:39, 14 June 2024 (UTC)Reply
The paper cited as the source argues that the ship is "probably" Mars. The arguments seem reasonable as this is a two decked ship (rare at the time, certainly in the Baltic) which caught fire in battle and ultimately exploded. I would suggest taking a look at the two archaeological papers cited in the article on Mars. Frustratingly, there are different historical accounts of the action – it probably doesn't help that the Swedish admiral involved was a bit of a celebrity. I take it that the cannon balls are incendiary ammunition – the original source of the illustration was a treatise on naval gunnery, so it seems. ThoughtIdRetired (talk) 20:39, 14 June 2024 (UTC)Reply
Many thanks. I'll leave it to you to cross refer notes on the two images. Also, same for whether or not Deventer is a von or a van? Once you decide, I'll enter him into Wikidata. Last, the cannballs, this is actually en:Chain shot of a kind? Broichmore (talk) 22:18, 14 June 2024 (UTC)Reply

June 14

edit

File:לירן כוג'הינוף - עותק.jpg

edit

Please undelete File:לירן כוג'הינוף - עותק.jpg. There is VRT permission for this file. Thanks Hanay (talk) 00:29, 14 June 2024 (UTC)Reply

COM:Exif

edit

I recently noticed that COM:Exif is linked from Special:UploadWizard's warning that files may contain metadata. I migrated the translation to the Translate extension, and while doing so I noticed that a lot of the page is either out of date (there's advice for Windows XP) or not particularly useful to a non-technical user. I'm not in a position to rewrite it, as I only use exiftool on Linux to mess with metadata. AntiCompositeNumber (talk) 18:59, 14 June 2024 (UTC)Reply

The Windows XP's part should probably be removed. Ruslik (talk) 20:05, 14 June 2024 (UTC)Reply

7000x Georgia, the country

edit

What's the plan for the 7000+ subcategories, now that the country was moved from Category:Georgia to Category:Georgia (country)?

The discussion started in 2017 was finally closed at the beginning of the month (see Commons:Categories for discussion/2017/03/Category:Georgia).

Ideally we wont have these categories in different states for months or years. Enhancing999 (talk) 22:41, 14 June 2024 (UTC)Reply

It clearly should have been part of the conversation. Short-sighted to not have had a plan of the extensive nature, and the migration, and whether that change should have occurred.  — billinghurst sDrewth 23:37, 14 June 2024 (UTC)Reply
It's going to be particularly tricky for anything template-driven. - Jmabel ! talk 23:58, 14 June 2024 (UTC)Reply
I did not take part in that discussion, but I agree with you. It might be of a big help if Cat-a-lot would work again for categories. JopkeB (talk) 08:01, 15 June 2024 (UTC)Reply
Supposedly people involved were aware that this can imply a lot of work.
I guess we would need to find an admin to do the requests at User:CommonsDelinker/commands. I can help with Category:Non-empty category redirects. Enhancing999 (talk) 10:03, 15 June 2024 (UTC)Reply

What? This is an outrageous decision! This was 10-6 votes over the course of seven years, which means practically nobody participated and people were not aware that this was ongoing. If this were still open now, I'd vote   Strong oppose; no other extant country needs to be disambiguated. Is there support for a CfD to quickly move it back? --Enyavar (talk) 13:02, 16 June 2024 (UTC)Reply

  Strong oppose as well! There is a LOT of disagreement in the CfD, but all of a sudden Sbb1413 simply declared a clear consensus without notifying any of the several users who clearly disagreed with it. This CfD needs to be reopened and the small amount of change done already backed off until a real consensus is reached to make such a massive change. No more categories should be changed to (country) form until this happens. Josh (talk) 15:05, 17 June 2024 (UTC)Reply

Apologies for my decision. I couldn't understand that there were a lot of disagreements related to the country name. I won't close any controversial CFD now on. The CFD can be reopened without prejudice. Sbb1413 (he) (talkcontribs) 15:08, 17 June 2024 (UTC)Reply
@Sbb1413 Completely understood. I am very confident that it was a well meaning attempt, and hopefully I was clear in my comments on re-opening that this wasn't about you at all, just a need to close it correctly and make sure it really is a consensus. I've done the same thing, closing a discussion I thought was a consensus, only to get a ton of blowback upon implementing it, so I understand how a well-meaning effort can go like this. I have a ton of respect for your work and contributions to CfD's and hope I haven't dented your enthusiasm for participating. Josh (talk) 16:15, 17 June 2024 (UTC)Reply
Also apologies, my outburst yesterday was also not directed towards Sbb1413, who certainly meant to finally close one of the oldest CfDs. It just really surprised me to read about this even happening; and I have now lodged my concerns in the re-opened debate. This also got me thinking: there should be a way to announce such consequential CfDs to a larger audience, so that nobody gets surprised (but so that nobody gets accused of vote-rallying, either). I check the pump every other week now, so here's a good place to start. --Enyavar (talk) 17:51, 17 June 2024 (UTC)Reply
It seems to me that if one disagrees with a closure, the right thing to do is to ask a neutral admin to review it, rather then merely reopening it and restart the discussion, without adding much new and copying over other discussions. Enhancing999 (talk) 18:42, 17 June 2024 (UTC)Reply
Unfortunately, such procedure is followed mainly in Wikipedia. Since the disagreement with closure rarely occurs in Commons, we don't need such bureaucratic procedure here until such disagreement is common enough. Sbb1413 (he) (talkcontribs) 18:49, 17 June 2024 (UTC)Reply
Seems more like common(s) sense than bureaucracy. So shall we open a third discussion somewhere else? Enhancing999 (talk) 18:53, 17 June 2024 (UTC)Reply
No need for it right now. If there's an option to relist the CFDs here (like Wikipedia's WP:RFD), the discussion will be better. Sbb1413 (he) (talkcontribs) 18:56, 17 June 2024 (UTC)Reply
I'd assume everything relevant had been said and re-said.
I think someone should just assess the consensus and we can move from there. Right now it just leads to an even more prolonged mess due this reopening by the two of you. Enhancing999 (talk) 19:00, 17 June 2024 (UTC)Reply

June 15

edit

Uploading while editing wikipedias: beneficial or problematic?

edit

I don't know if someone had posted about the issues surrounding uploads made by uploaders while editing articles on Wikipedias. Several of these uploads are found by reviewers like me to be copyright violations (whether obvious or suspected), like stolen from the Internet or not freely-licensed images harvested from Flickr or other media repository sites (no prior checking of licensing compatibility).

Similar issue also arises for uploads that were made from other wikis ("cross-wiki uploads"). JWilz12345 (Talk|Contrib's.) 03:20, 15 June 2024 (UTC)Reply

And also for uploads directly to Commons, no? - Jmabel ! talk 03:53, 15 June 2024 (UTC)Reply
@Jmabel I'm only referring to uplpads that were made through cross-wiki or while editing Wikipedia articles. IMO, these are usually not easily detected, and many of the uploads that I see are questionable. Time to restrict cross-wiki editing to three groups only? (Only autopatrolled, image reviewers, and admins/sysops can do cross-wiki and/or while-editing-on-Wikipedia uploads.) JWilz12345 (Talk|Contrib's.) 04:23, 15 June 2024 (UTC)Reply
Why aren't those uploads caught by the existing cross-wiki filter (153)? -- Asclepias (talk) 12:06, 15 June 2024 (UTC)Reply
I don't know anything about coding syntax, so forgive me for this silly question, but when a change to the cross-wiki filter added an exemption for users whose user group includes the string "confirmed", did that have the unintended effect of exempting also the users who are "autoconfirmed", thus basically nullifying the main criteria of the filter? -- Asclepias (talk) 18:43, 15 June 2024 (UTC)Reply
  Comment @Asclepias: any user_group noted is local (not at the wiki where editing) per Special:ListGroupRights and is not based on user_rights which you can note in the second of the columns. So autoconfirmed user_group is different from confirmed user_group; also noting the "confirmed" is a specific allocated right by admins, not inherited as per autoconfirmed.  — billinghurst sDrewth 01:06, 16 June 2024 (UTC)Reply
Thank you for replying. Yes, I get that about the nature of the user groups. But my doubt was about the syntax that code the conditions of the filters. In filter 153, when the exemption condition says that accounts are exempted when the string of characters "confirmed" is found in their "user_groups", does that mean that nothing else can exist before or after strictly the nine letters "confirmed", or does that find also "autoconfirmed" because the string "confirmed" is found also in "autoconfirmed"? I'm trying to find an explanation for why uploads are not filtered when apparently they should be if the main conditions of the filter were applied. -- Asclepias (talk) 02:28, 16 June 2024 (UTC)Reply

Another example also by the same uploader: File:Navette arles.jpg (original is this unfree Flickr image). JWilz12345 (Talk|Contrib's.) 04:24, 15 June 2024 (UTC)Reply

why are we surprised that editors make mistakes ? Have you tried teaching them ? —TheDJ (talkcontribs) 08:16, 15 June 2024 (UTC)Reply
@TheDJ mistakes may either be accidental or (as my experience in image reviewing suggests) intentional. The speedy deletion tags are enough to teach them the hard way. The prevalence of social media has made many netizens disrespect copyright rules; in the case of our country, it has been normal to not attribute original authors and instead go away with usage of "CTTO" or "credit(s) to the owner", even if authorities and scholars/media and information literacy instructors continue to remind Filipinos to refrain from using "credits to the owner" and cite / attribute sources and authors properly.
What I want to suggest, is to effectively disallow any cross-wiki or "edits-from-Wikipedias" uploading, except if the user belongs to three user groups – autopatrolled, license reviewer, and/or admin/sysop (the basis of user group should be the user group status at Commons, not on Wikipedias). This would hopefully trim down at least around a tenth (my guess) of possibly copyvio files. JWilz12345 (Talk|Contrib's.) 10:38, 15 June 2024 (UTC)Reply
@JWilz12345: Please see phab:T214230.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 14:35, 15 June 2024 (UTC)Reply
@Jeff G. the intention for cross-wiki uploading is good, but Wikimedia community unintentionally invited vandals and trolls to upload either out-of-scope or copyvio files seamlessly. This has resulted to numerous problematic files that needed to be reviewed and/or nuked one-by-one (image reviewing is an intense effort in which a mass deletion request could only be used as a "last-resort"). Some of these files, were only detected a year or two after upload, seemingly slipped off the supposed edit filter. In fact, I conducted some recent file reviews by finding recent WEBP images, as I can still recall the discussion at Commons:Village pump/Proposals/Archive/2023/11#Restrict webp upload. One such file I found was from a certain Alexandre071109 (talk · contribs), who uploaded numerous problematic files (in terms of copyright violations) through "upload-while-editing-Wikipedia" method.
Note that my perspective on that discussion has changed. Restricting WEBP upload does not solve things, as copyvios in PNG and JPEG file types can still be uploaded by vandals/trolls, using any easy methods in uploading. A possible viable solution is to only permit cross-wiki/"upload-while-editing-wiki" methods to experienced users. JWilz12345 (Talk|Contrib's.) 14:56, 15 June 2024 (UTC)Reply

Still one more example, uploaded a few hours ago: File:PsychoClown5.webp, "Uploaded while editing 'List of current champions in Lucha Libre AAA Worldwide' on en.wikipedia.org." Thanks @Belbury: for the speedy deletion tag. JWilz12345 (Talk|Contrib's.) 14:59, 15 June 2024 (UTC)Reply

Do we have any figures on how often "while editing" uploads turn out to be copyvios, compared to locally-uploaded ones? I flag a lot of copyvios in general but the connection hadn't occured to me. Belbury (talk) 15:20, 15 June 2024 (UTC)Reply
Actually I suppose the more important question is how many "while editing" uploads are useful ones. If this is a situation where 95% are copyvios or vandalism then it might be worth changing our approach to them, but we need some proper numbers on this. Belbury (talk) 22:32, 15 June 2024 (UTC)Reply

One more I just tagged now: File:TELEMMGLPICT000291129217 trans NvBQzQNjv4BqsJKoeWavxz5iDO 6aHC-NNzDn6JMw4oMG9nccdeVAbM.webp, "Uploaded while editing 'Polly Walker' on en.wikipedia.org" JWilz12345 (Talk|Contrib's.) 20:01, 15 June 2024 (UTC) More tagging's: files uploaded by BrainMind Diana (talk · contribs), like File:Karen-Rommelfanger.jpg (‎"Uploaded while editing 'Draft:Karen Rommelfanger' on en.wikipedia.org") and File:Buzzy picture.png ("Uploaded while editing 'Amy Baxter' on en.wikipedia.org"). JWilz12345 (Talk|Contrib's.) 20:19, 15 June 2024 (UTC) Still another that I just tagged: File:El Primo Skin-Default.webp, "Uploaded while editing 'Holliston, Massachusetts' on en.wikipedia.org" (but there was no intention to use it on enwiki article). JWilz12345 (Talk|Contrib's.) 20:48, 15 June 2024 (UTC)Reply

Still one more thing, sharing it here as an emphasis on the problem. File:Hack.intro.webp, "Uploaded while editing 'Babhalgaon' on en.wikipedia.org." Unused on w:en:Babhalgaon, and the uploader's intention is likely trolling or treating Commons as similar to a socmed site, since it is unreasonable to use a cybersecurity-related stock image in an article of a small Indian village of 7,000+ residents that has no connection to I.T. industry or even cybersecurity experts. No obvious relation or connection, incoherent, just used cross-wiki uploading to "play"/"troll"/"test upload" (whatever that may be). On top of that, it is a COM:NETCOPYVIO. JWilz12345 (Talk|Contrib's.) 21:19, 15 June 2024 (UTC)Reply

The entire point of Commons is (or at least was at the beginning) that Wikipedia contributors can upload images to a common repository while editing. Enhancing999 (talk) 21:56, 15 June 2024 (UTC)Reply
@Enhancing999 this just reinforces what one WMF peep observed regarding Commons (see here). In their observation, "the primary focus of the Commons community is the collecting of free content, rather than its dissemination." This may be suitable for another thread, but may be partly true after all. Worse, we are failing to curate several uploads while we are collecting free content, so copyvios are slipping through. JWilz12345 (Talk|Contrib's.) 15:10, 16 June 2024 (UTC)Reply

Another worthwhile question might be whether we should take more steps to identify and delete "abandoned" cross-wiki uploads, where an image was uploaded from another wiki, but where the image is no longer in use there (e.g. because the edit was reverted or the target page was deleted). My intuition is that those images are particularly likely to be out of scope and/or copyvios, and a lot of them will simply be unusable due to a lack of context. Any interest in reviewing these? Omphalographer (talk) 00:35, 16 June 2024 (UTC)Reply

@Omphalographer with regards to the supposed Babhalgaon upload (an irrelevant stock image representing cybersecurity), based on enwiki article's history, the uploader – Balaji 7978 (talk · contribs) – did some irrelevant and one vandalism contributions, which were promptly reverted. JWilz12345 (Talk|Contrib's.) 02:38, 16 June 2024 (UTC)Reply
Omphalographer, after some more digging on enwiki article's history, it appeared he (yes, he) added his apparent real name on the notable people section list and claimed he is from a national cybersecurity agency from India. That now explains why his only upload here was a stock image representing cybersecurity. Possibly implicit self-promotion but his upload is a copyvio anyway. JWilz12345 (Talk|Contrib's.) 02:47, 16 June 2024 (UTC)Reply

  Comment To note that the system already produces a list of successful cross-wiki-uploads => https://commons.wikimedia.org/w/index.php?title=Special:RecentChanges&tagfilter=cross-wiki-upload <= where you will be able to determine what has or has not been deleted.

Now we just need someone to divine a query that allows us to identify those files that have got the tag and are not used. And I would guess that we are looking for those that fit that criteria in the past week; alternatively works that don't have eyeball'd categorisation.  — billinghurst sDrewth 03:32, 16 June 2024 (UTC)Reply

From [1], I would say at least 90% of these uploads are problematic. Among the last 27 uploads (10:16 to 12:03 today), only File:Bílá Třemešná, schody zbořeného zámku.jpg seems really OK, but without any category. Eight (8) are already deleted, the rest is tagged, except File:Patinoire du centre sportif La Mosane.jpg should be moved to the French Wikipedia (no FOP in France). Yann (talk) 10:17, 16 June 2024 (UTC)Reply
Assuming that people do upload to Commons to illustrate Wikipedia articles, I wonder what the percentage highlights.
  • 1. New users have a hard time doing it correctly?
  • 2. The upload workflow that is tagged as "cross-wiki-upload" is significantly worse than others?
  • 3. mostly "bad" files follow that route.
Cases #1 and #2 would need some fixing, but #3 might actually be a good thing as you wont need to search for them elsewhere.
dewiki has many lists linking to specialized upload forms and these are rarely problematic AFAIK. Enhancing999 (talk) 08:13, 17 June 2024 (UTC)Reply
IMO, the two main reasons for which there is a high number of problematic files are: 1. there are much less requirements than through the Upload Wizard on Commons; 2. it is technically easier to upload files that way. So the probabilities for the rate of success lead to have people uploading a lot of files without much checking. Yann (talk) 08:34, 17 June 2024 (UTC)Reply
Somehow I missed the point that that a different tool is being used. It's actually quite convenient (more than most other methods) except that one needs to remove "own" claims afterwards (also I duplicated the file extension). I think I will use that going forward. Enhancing999 (talk) 09:50, 17 June 2024 (UTC)Reply
The upload links the dewiki lists are in most cases for topics were you will not find any photo online. Therefore it is not possible to claim the work of someone else as own as these works do not exist. Additionally I think the society in Germany is much more aware on copyright regulation than in most other countries at least in Europe. To address the topic specific differences is might be useful to not allow cross-wiki upload at articles about people but allowing it for articles about geographical features. GPSLeo (talk) 09:47, 17 June 2024 (UTC)Reply
edit

{{GFDL}}-only is no longer accepted for new uploads on Commons (since 2018), English Wikipedia (since 2021) and some other wikis because GFDL is not a good license for media files. {{GFDL-with-disclaimers}} are even worse so a lot have been done for many years to get rid of them per en:Wikipedia:GFDL standardization (since 2007).

I noticed that some wikis still upload files licensed GFDL and some even with disclaimers (and more still host such files).

So if there are anyone out there that have any good ideas on how to get all wikis to stop using disclaimers and if possible also the use of GFDL-only or would like to help make that happen it would be great.

I have made a list of wikis and files uploaded with GFDL (table below only have a few of the wikis and it is just to illustrate):

Language/category Number of files Remarks
w:af:Kategorie:GFDL-beelde 182
w:als:Kategorie:GFDL-Bild 24
w:an:Categoría:Imáchens GFDL 13
w:ar:تصنيف:صور رخصة جنو 552
w:en:Category:GFDL files with disclaimers 10,914
v:it:Categoria:Immagini GFDL 34
v:ru:Категория:Файлы:GFDL 7
voy:en:Category:GFDL files 13
m:Category:Presumed GFDL images 459

The full list is located at m:User:MGA73/GFDL files.

I noted some idea at m:User:MGA73/Status#How_to_help_cleaning_up_GFDL and basicly it is stop upload of new files, clean up existing files, move the good files to Commons (if possible) and delete the bad files. (If possible also fix m:File metadata cleanup drive.)

But that will only work if someone does something and it goes a lot faster if many help :-) --MGA73 (talk) 07:26, 15 June 2024 (UTC)Reply

Nice, thanks for making the list! —TheDJ (talkcontribs) 08:18, 15 June 2024 (UTC)Reply

Mirrored image

edit

File:Drake Milligan at The Brick Bar Oxford Ohio.jpg is clearly mirrored, as all other images of Drake Milligan show him playing right-handed. (The bass in the background is mirrored too.) Can someone please un-mirror this image? TenPoundHammer (talk) 10:37, 15 June 2024 (UTC)Reply

@TenPoundHammer: I added it to Category:Images to be flopped back for you.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 14:26, 15 June 2024 (UTC)Reply

June 16

edit

How to find the source cat for why a given image is in a specific category tree?

edit

I'd like to find out why the files shown in this petscan like File:Life expectancy in Albania.svg are somewhere in the category tree of Category:Maps of the world. Prototyperspective (talk) 12:16, 16 June 2024 (UTC)Reply

Probably because first Category:Demographics of the European Union is falsely in the category tree of Category:Maps of the European Union, and second Category:Maps of Afro-Eurasia is falsely in Category:Maps of the world indicating regions?
Just correct it, it is nothing new that sometimes editors make bad categorization choices in good faith. --Enyavar (talk) 12:37, 16 June 2024 (UTC)Reply
Just correct it that requires me, and for other cases many other editors, to be able to quickly and easily see what the source of the category is. Hence my question.
(And I went through the cat tree but didn't check Demographics of the European Union somewhere in the branches above it and don't know how you found it). Prototyperspective (talk) 12:55, 16 June 2024 (UTC)Reply
Right, you were hoping for a method there. I admit, I just randomly went up the tree from the in-file-categories to see which upwards category was most likely to lead towards "maps of the world". --Enyavar (talk) 13:09, 16 June 2024 (UTC)Reply
 
Example (this is already part of the FastCCI gadget)
Yes and I was looking for a method that it isn't manually going through all the category's cats' cats etc but quick reliable technical method. I found such a way today but I'm looking for something that does just that: the FastCCI tool can load all quality images anywhere in branch of a given category and when clicking on any item of it, it loads how the file is placed in it – see the screenshot. It's just this feature that I'd like to use on a given file, eg by entering the file's url into an additional searchbox shown on the category page or anything else. Prototyperspective (talk) 15:48, 16 June 2024 (UTC)Reply
Perhaps the problem is that there aren't really clearly-defined 'source cats' (or more commonly referred to as a 'main category' or 'main topic') for topics in the category tree. We even have a maincat tag that has been added to some, but still no real agreement on what exactly makes one exact category a main category vs. any other. We have parent categories and sub-categories, but any category could conceivably be considered a main cat for all of its child tree, depending on the perspective of a given user. The reality is that categories are not exactly class-subclass or set-subset relationships. They may resemble that in many cases, but they are not limited to that. Categories are really not even trees so much as webs, so it as desirable as it might be to have a 'source cat' with some kind of defined 'tree' of sub-cat branches under it, that just isn't how categories ultimately are structured, and your example shows a lot of the reasons why.
Your example File:Krettnach Wegekreuz L138.jpg at the right illustrates the problem with rooting the category tree. It seems to present a singular linear path of categorization. The image in question is in 15 categories directly, but this tool only picks 1 to navigate up through. That makes sense as this tool is focused on quality images but even then this file is in 4 quality image categories...it picked 1. The same pick-one problem recurs at each level, leading to essentially a random category navigation exercise to a certain level. Josh (talk) 16:43, 17 June 2024 (UTC)Reply
The main category/ies subject is certainly interesting but it's pretty much unrelated to this topic: this is about finding why a specific image is located in a specific category (such as the example file somewhere underneath "Maps of the world").
Yes, that's a good point but still not really what this topic is about: that one can check the source of categorization for a file (its category path) doesn't mean that it will or needs to be altered just if it doesn't seem to be right. For example, the "Maps of the world" cat contains a "Category:Maps of the world in art" that contains a lot of files one wouldn't expect to find anywhere underneath "Maps of the world". When one sees that it's just included due to the recurring standardized "xyz in art" subcategory, it won't need to be removed. It would be useful if for example tools/views that show files from many subcategories of a category like FastCCI could distinguish between several kinds of subcategories to e.g. exclude certain ones or give the user the option to do so but that's not what this is about and just something that could follow up on this.
If there are multiple paths a file included it should show each of these. Prototyperspective (talk) 20:54, 17 June 2024 (UTC)Reply
This gets back to something I had wanted to pursue when we first introduced SDC, but most of the people pushing SDC were more or less antagonistic to categories, so they weren't interested in integrating the two well. Little by little some of this has made its way into Wikidata regardless, but not in a way that is particularly useful to us, because when it made its way into Wikidata, Commons' needs weren't particularly considered. In particular, distinctions in Wikidata like "subclass of" vs. "instance of" vs. "location" as a relation between items are all at one remove from categories, which are at best related to their parents (or, more precisely, to their parents' "main topics") with "category combines topics". It might yet be possible to piece this all back together and use structured data (I would hope in Wikidata rather than SDC, but I'd settle for either) to express the nature of each case of category inheritance. - Jmabel ! talk 18:35, 18 June 2024 (UTC)Reply
I think SDC can only ever be useful if it gets synced with categories and changed whenever categories are changed. For most files SDC are missing and easily half of those have them have flawed and/or very incomplete data in there, the data is a bit hidden and little cared about so people don't notice if there's false or vandalizing data. An example issue is that "depicting" something is different from a file having something as a subject. Lastly, I don't think SDC for WMC files has any use at this point whatsoever so is just a time-drain that could and would better be populated by bots/scripts only that largely use well-maintained categories if at all since it mostly just duplicates metadata & maintenance. Not even Wikidata is well-maintained, for example the items for subjects as fundamental and large-order as "Past", "Present", and "Future" were heavily flawed before I fixed them and categories and their contents should and could be as query-able as Wikidata items (example where they're not: one can't do a petscan and then run WMC category operations on all the files in the results). Most studies are also not in Wikidata, just an arbitrary 1% or so subset of them and queries for such as Scholia does them for charts about studies on a given research topic etc or by a specific author are not useful at this point either. Often there is data in categories not in fields that make WDInfoboxes auto-set categories and these infoboxes cause UI issues (reduce columns). Manually (really in 2024?) translated captions are frequently moved to other languages by vandals. WD item data could be useful to make the relation between categories more explicit, often they are phrased in a way that explains the relation but it could be more explicit.
I was thinking about how to make these more useful and maybe I can concretize some proposal soon. This also related to this question here as a tool that shows cat-paths for files could be useful for eliminating miscategorizations better enabling the categories to be used by bots/scripts that populate structure data / Wikidata based on them.
As for the issue of showing why a file is in a cat I've asked about it at Talk:FastCCI in case somebody could use its code for that. Prototyperspective (talk) 14:45, 19 June 2024 (UTC)Reply

Wikidata sufficient for scope?

edit

Hi, It seems unclear if creating a Wikidata item is sufficient for being in scope. Files were recently deleted when a WD item was created by the same user who uploaded the files. Here it concerns Commons:Deletion requests/Files in Category:Insane Ashraf. Yann (talk) 12:46, 16 June 2024 (UTC)Reply

Wouldn't this better be asked at the Scope talk page? In COM:SCOPE it does say "legitimately" in use. That would mean it depends on the legitimacy of the Wikidata item itself and the legitimacy of the use there (does it actually show what the Wikidata item is about? is there a much better file available that should be used instead?). Prototyperspective (talk) 12:53, 16 June 2024 (UTC)Reply
Actually these files and category were created by a sockpuppet farm, so I would delete for this reason alone. But the general question remains for future cases. Yann (talk) 14:49, 16 June 2024 (UTC)Reply
It could be used to artificially cause a scope loop between Commons and Wikidata. AFAIK, Wikidata is the only Wikimedia website where an item can be in scope for no other reason than because it links to a page on Commons. A file about a person can be in scope on Commons if the file can be potentially useful to someone somewhere in a very broad educational sense, even if there is no page about that person on any other Wikimedia website. But that doesn't go so far as to include photos of non-notable persons in non-relevant contexts. Of course, a file about a person can be more easily assumed to be in scope on Commons if another Wikimedia website has a page about that person. (N.B.: that question is different and independent of the question of whether a file is in use or not on another Wikimedia website.) That makes sense based on the assumption that the other website has independent notability criteria. But that does not make sense when the only inclusion criterion being met on Wikidata by a person is that the Wikidata page links to a page on Commons. -- Asclepias (talk) 15:16, 16 June 2024 (UTC)Reply
'Wikidata, has nothing to do with defining scope for Wikipedia or commons. Look to the policies for both projects separately to ascertain what is scope. There are differences, minor ones perhaps. Generally speaking, if it passes the scope test for Wikipedia. it will be okay for commons too, as the latter is marginally more liberal. As far as we are concerned, Wikidata is a tool, and nothing more. Broichmore (talk) 16:35, 16 June 2024 (UTC)Reply
I'd think yes. I noticed in a recent cleanup exercice some stuff got tossed that was in use there, but that seemed relatively marginal. Enhancing999 (talk) 22:29, 16 June 2024 (UTC)Reply
It seems to me that the only times an image that is used to illustrate a Wikidata item would be appropriate to delete on a "scope" basis would be (1) the Wikidata item shouldn't exist, which should first be dealt with on Wikidata or (2) the image does not meet Wikidata's criteria for images illustrating an item, which should first be dealt with on Wikidata. And, no, I wouldn't defend the case where the only justification for the Wikidata item is that the Commons image exists and vice versa.
@Broichmore: are you saying (above) that it would be appropriate do delete an image that is legitimately in use on Wikidata, or just that the presence of a Wikidata item is insufficient to justify having other images of the subject in question? I'd agree with the latter: I believe there are cases where there are Wikidata items for every name on a war memorial or every person buried in a particular graveyard. That would merit hosting a single image of any of these people to support Wikidata, but would not mean that we would want an open-ended number of images of each such person. - Jmabel ! talk 23:44, 16 June 2024 (UTC)Reply
@Jmabel: Not to speak for Broichmore, but read through Wikidata:Requests_for_deletions#Q125118469. Especially the last 4 or 5 comments. I assume it's similar to what Broichmore is talking about. --Adamant1 (talk) 23:59, 16 June 2024 (UTC)Reply
As your all too aware, criteria for uploading images on commons centres on copyright (we want only PD), modified by notability, the emphasis on the former.
In Wikipedia, it's possible to upload a non-PD item (using, the fair use parameter), if there's no other image (of even dubious suitability) available. Even so, the item then needs to be degraded so it's worthless commercially. Only items, most representative, are entertained. A pix of the ship. The person's face. an LP cover. An actual passport style portrait of the item.
Wikidata says it wants an image of (the) relevant illustration of the subject; if available, use more specific properties (sample: coat of arms image, locator map, flag image, signature image, logo image, collage image); only images which exist on Wikimedia Commons are acceptable. In other words only PD and no fair use.
Briefly, again, wanted images for the Wikipedia infobox and wikidata are passport only portraits, in that spirit I've been known to crop out portraits for that purpose. This example was used for both projects. That portrait will be replaced, only when better surfaces.
Wikipedia carries only one pix in its infobox, and so should Wikidata, however the latter can carry more. Perhaps a persons facial image, representative from different stages of their life. There's no real limit. I don’t think this has actually been tested, by abuse yet, the tacit acceptance is, use only one image, perhaps two, following Wikipedia guidelines.
Wikidata’s scope for inclusion is immense in comparison to WP and commons. Briefly an item should be represented by at least one valid sitelink to a page on Wikipedia, Wikivoyage, Wikisource, Wikiquote, Wikinews, Wikibooks, Wikidata, Wikispecies, Wikiversity, or Wikimedia Commons. ’’Note it refers to itself, it’s a bit woolly. But it wants to tag everything useful in the world. Read the policy here.
As I see it, Wikidata has three uses for us, first our infobox, containing the variables that dictate licensing, secondly (for an artist, if there's no WP article); locations of work by time period, useful for correct attribution, and third, disambiguation of artists or place names. Broichmore (talk) 11:07, 17 June 2024 (UTC)Reply
It doesn't help there that the user whose contributions are largely at issue keeps cycling back and forth between reasonably serious arguments, ad hominem remarks, and remarks that seem entirely intended to derail the discussion. But I stand by what I wrote above: circular justification doesn't cut it; a Wikidata item can justify keeping one photo on Commons that would otherwise be deleted, to function as an image for that item; and it isn't up to us on Commons to decide whether the item meets Wikidata's (generally lower) threshold of notability. - Jmabel 01:09, 17 June 2024 (UTC)
The "scope loop" breaks on the Wikidata side. Per d:Wikidata:Notability, "Category items with a sitelink only to Wikimedia Commons are not permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as category for pictures taken with equipment (P2033)". Commons can expedite the cleanup of objects involved in these loops by ignoring media uses on Wikidata which only refer back to Commons. Omphalographer (talk) 23:56, 16 June 2024 (UTC)Reply
Concur. WD item creation that is involved with the uploader/creator in sequence within the same timeframe, and otherwise fails their notability (articles or independent linkage) is not "in use" (image or category). If it is borderline, or where I am in doubt, I will nominate there for deletion with appropriate commentary, and then nominate the image here with a DR, so we can do some follow-up (our DR review takes longer than theirs). That is pretty much what I will do for a draft article where it is dodgy and reeking of COI at the WPs.  — billinghurst sDrewth 04:38, 17 June 2024 (UTC)Reply
@Omphalographer: that seems more of a technicality about WD than something germane here. It's specifically about Category items. That just means that if you are making up (for example) an item about Person FOO and the only Category:Person FOO is on Commons, you can make an item about "Person FOO", but not about "Category:Person FOO". - Jmabel ! talk 06:38, 17 June 2024 (UTC)Reply
@Jmabel, actually, you could, if "Person FOO" is sustainable itself. The item for "Category:Person FOO" is allowed per criteria #3 as structurally required as the topic's main category (P910) for the former item. What is not allowed is if "Person FOO" does not exist on Wikidata, and you solely wanted to create an item for "Category:Person FOO" with the only sitelink being to the Commons category. That would fail all three of the criteria for notability there. Of course, as you stated, this is all applicable to Wikidata alone and has no real relevance to Commons, except that you probably shouldn't add {{Wikidata infobox}} to "Category:Person FOO" without a valid corresponding Wikidata item. If that category is a valid Commons category, we certainly should not delete it just because it does not support a Wikidata link. Josh (talk) 17:08, 17 June 2024 (UTC)Reply
@Joshbaumgartner: No. I have no idea of your level of experience on Wikidata (and feel free to correct me if that experience is extensive, and you can provide examples of something I've never seen), but in my experience no one goes around creating a "category" item just to use it within Wikidata for a topic's main category (P910). Otherwise, every item would get a corresponding "category" item. Hell, every category item could get a corresponding, totally useless "Category:Category" item, etc. ad infinitum. Until a "category" item is justified by the existence of categories on some sister project other than Commons or Wikidata itself, it should not be created. - Jmabel ! talk 19:29, 17 June 2024 (UTC)Reply
@Omphalographer, note that only applies if attempting to sustain notability under criteria 1 (i.e. solely on the basis of a sitelink). If an item qualifies under criteria 2 or 3 (i.e. is a "clearly identifiable conceptual or material entity that can be described using serious and publicly available references" or "fulfills a structural need"), the exclusion of 'items with a sitelink only to Wikimedia Commons' is not applicable. Josh (talk) 16:58, 17 June 2024 (UTC)Reply
For people, I think it'd be acceptable to declare as in scope those items with an identifier that may presume the subject is notable or relevant, such as those of National Libraries. Bedivere (talk) 20:41, 20 June 2024 (UTC)Reply

June 17

edit

Intersection categories

edit

I would appreciate additional opinions on a disagreement I am having with User:AnRo0002 (see User talk:AnRo0002#Intersection categories for the discussion so far). They have been creating a number of very specific time-based intersection categories such as Category:Snow in Massachusetts in February 2012, Category:October 2016 in bus transport in Massachusetts, and Category:April 2014 in rail transport in Massachusetts. I believe these categories are not useful - they provide no benefit to users, while making them sort through more subcategories to find files, and require additional editor work to categorize files. From what I have seen, the consensus at noticeboards and CfDs has generally been against the creation of highly specific intersection categories. Pi.1415926535 (talk) 02:55, 17 June 2024 (UTC)Reply

Reminds me of the Steamboat Willie deletions. Enhancing999 (talk) 07:43, 17 June 2024 (UTC)Reply
@Pi.1415926535: How about Category:September 11, 2001 in New York or Category:September 2001 in Manhattan as a subcat of Category:September 2001 in New York?   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 13:12, 17 June 2024 (UTC)Reply
See Category:New York City photographs taken on 2001-09-11 and Category:September 2001 in Manhattan, New York City, which are both two years old. Breaking out New York City photographs by day is two years old according to {{New York City photographs taken on navbox}}. Category:September 2001 in New York (state) is seven years old. I believe the effort to subcategorize Manhattan (and other borough) media by month began before the pandemic. One Wikimedia Foundation trustee uploads New York City images by the hundreds when he attends a board meeting every year--see Category:March 2023 in Manhattan, New York City and Category:March 2024 in Manhattan, New York City, for example. Some NYC subway and bus fans upload images by the score each month as well. -- DanielPenfield (talk) 15:53, 17 June 2024 (UTC)Reply
Those seem like a bit of a special case. Those categories are less of an intersection by date, more photos of an event which is known primarily by its date. I would hesitate to generalize from there. Omphalographer (talk) 19:43, 17 June 2024 (UTC)Reply
You're ignoring Category:March 2023 in Manhattan, New York City and Category:March 2024 in Manhattan, New York City, the latter of which contain photographs of quite possibly every last meteorite in the American Museum of Natural History as well as every nook and cranny in Riverside Park (Manhattan). Then there's the hundreds-to-thousands of photographs taken each year by an obsessive contributor in Category:New York City Subway photographs by Tdorante10--each one of those is categorized a month-specific "New York City Subway in MMM YYYY" category. You can pretend that the problem is one of overly-specific categorization, but really the root cause is an increasing number of contributors who like to upload images by the hundreds or thousands that depict the same subject over and over and over and over. That is what drives the quantity and therefore specificity of categories. Want an image of a bus in Midtown Manhattan? Well, then select one of the 754 in Category:Buses in Midtown Manhattan or one of scores more in any of its 10 subcategories. -- DanielPenfield (talk) 04:06, 18 June 2024 (UTC)Reply
Having complete coverage of useful subjects is generally a good thing - that's why we have GLAM collaborations. While there is a need to avoid actual duplicates (and yes, a few uploaders need to be reminded of that fact), I don't think that's the main factor behind the increasing number of questionable categories. A great many subjects are extremely complex and will rightfully have a large number of files; our category system should be designed to allow users to navigate those files efficiently.
The key issues to me are:
  • How do we decide which intersection categories are useful and which are not (the reason I started this discussion)
  • What tools need to be created to enhance the category system and have it adequately serve the 100+ million files on Commons, and
  • For tools that are beyond the resources of Commons volunteers to create and maintain, how do we get the WMF to prioritize making them?
Without steering the discussion too far away from that first point, there seems to be general agreement that we need the ability to arbitrarily subdivide a category by certain parameters. In particular, we need a tool that can allow you to find all files in a category (or category tree) within a selected date range - and have it be available on the category pages as well as in the search function. This would eliminate a large swath of intersection categories - in particular, the ones that require the most labor to populate and provide the least benefit. Division by date, file type, resolution, and license could all be done with existing structured data; it would provide a great deal of functionality without getting into any areas likely to be controversial. Pi.1415926535 (talk) 06:08, 18 June 2024 (UTC)Reply
@Pi.1415926535 As to your 3 questions:
  1. The question of intersection categories is a constant one on COM:CFD. Essentially, nearly every topic category is an intersection category. Thus I don't think how we treat discussions on intersection categories is really that different from how we approach topic categories in general. There are sometimes calls to arbitrarily limit the amount of sub-categorization of a topic (essentially a process of intersecting categories), but these rarely gain consensus as it usually involves unintended consequences and lots of exceptions. Essentially, the basics are that there ought to be enough media to support an intersection category, that the intersection be sufficiently distinguishable to make a distinct category, and there it offer some meaningful sub-division of its parent categories. If any of these are in question, the issue is raised and discussed at COM:CFD (or other appropriate forum) and consensus for that particular use case is implemented. Basically, if a user creates a category, so long as it does not violate Commons category policies  , until there is a consensus that it is not useful, it is presumed useful and kept.
  2. As for tools we need, better and more accessible search tools that obviate the need to use categories as search criteria would be high on my wish list. There are some good SPARQL query tools and gadgets that are helpful for those users with the initiative to learn and apply them, but they are not available to the mainstream and most users I would presume are not interested in learning to code just to view the media they are looking for. User-friendly interfaces built directly into the Commons interface (not requiring opt-in gadgets or third-party sites) are a must to make these useful for more than a small group of users.
  3. Clearly, involvement beyond volunteer contributors will be needed for at least some of these tools, and I have absolutely no clue how to push that cart. I'm not politically minded, nor am I steeped in the inner circle workings of the project, so I wouldn't even know how to start such a drive, but I'll gladly sign on to voice support for valuable tools. I added my name to several items on the wishlist a while ago...not sure if that did anything.
While I continue to look forward to better tools and development in the future and am eager to see how we can use them to best effect, I have been doing Wiki projects since 2005 and the idea that we shouldn't worry about making current systems work since there is a new tool just around the corner that will solve all problems is a song I have heard for going on 20 years now and one that all too rarely fails to deliver on the promises. Thus, my approach is to make the system we have now work as well as possible, and here that means making sure the categorization system provides the most robust and accessible system possible for finding media. I'll be pleased the day search tools obviate the need for it, but until that is shown to be true, I will be opposed to any attempt to limit categorization on the promise that search tools are the answer. Josh (talk) 17:03, 18 June 2024 (UTC)Reply
Subcategories shouldn't be created simply because a category had a large number of files in it. If there are a lot of images related to something, that is what it is; we don't need to introduce artificial distinctions just to make categories smaller. Time-based category intersections in particular seem to have little value unless they're categorizing something which changes over time in a way that's significant to the topic. Photos of a person, perhaps (although breaking it down by month would still be excessive); photos of generic topics like weather, not so much. Omphalographer (talk) 15:01, 17 June 2024 (UTC)Reply
Those categories definitely need to be deleted. I'm not sure there's much point in having a discussion here. Please nominate them for deletion at Commons:Categories for discussion. Nosferattus (talk) 15:28, 17 June 2024 (UTC)Reply
@Nosferattus: I will take them to CfD, but there's little point in doing so until AnRo stops creating them. Pi.1415926535 (talk) 18:05, 17 June 2024 (UTC)Reply
Chronological categorization seems to be coming under increased scrutiny lately. As the number of hosted files continues to grow and topical categories get larger, there seems to be increasing efforts to diffuse topics by date, and by increasingly precise dates at that. Beside appearing to be a benign effort to diffuse bloated topic categories, there can be specific technical value to categorization by specific date for maintenance, curation, and some specific research efforts. However, the unintended consequence is that topic files become buried in layers of date-based categorization, frustrating most users looking for images of that topic who are not concerned with exactly when the image is of. I think it is fair to conclude that the vast majority of users looking for images of snow in Massachusetts do not care if happens to be January or February of 2012, or if it is February of 2012 or 2013. Maybe one might want to focus on more recent times vs. pictures of yore, and some may indeed be interested in January vs. February for seasonal differences (not caring which exact year), but most don't probably care about the exact year even, much less month or day. Requiring them to select one particular moment in time to see images is very frustrating for most. This also makes normal diffusion more difficult, as files moved to specific dates are less likely to correctly get diffused to more appropriate sub-categories (e.g. a pic already moved to Snow in Massachusetts in February 2012 is less likely to ever be correctly be put into Snow in Boston as it no longer appears directly under Snow in Massachusetts).
The solution to this dilemma would be one where the files are available in the main topic category for users to look through without requiring they select a specific date to be limited to, while also permitting the images to be collated by date to whatever level of specificity is meaningful for the topic. We have the same issue with categorization by media type. Most users are not looking for images of a precise type to limit their browsing to, but such categorization does have a lot of technical value to specific users. What we have done is make the Category:Media types tree separate from the Category:Topics tree. Files can be added to the Category:Media types tree and be diffused to whatever exact media type specification they fit, however, they are not to be removed from the Category:Topics tree (i.e. the main topic categories for the file). The Category:Media types categories are to be "__HIDDEN__" which puts them in a separate list of categories (only visible to users who elect to see non-topical categories).
We could adopt this approach for date-based categorization, creating Category:Chronological categories as a separate non-topical tree. This would allow continued categorization by specific date without diffusing topical categories. For example, in the case of Massachusetts snow, all files regardless of date would be present under Category:Snow in Massachusetts, a topical (visible) category. The files themselves can be additionally categorized by date under Chronological categories to whatever level of precision those involved feel is warranted. They could be accessed from the main category via Snow in Massachusetts by period which would still appear under the main category for all users. Josh (talk) 17:44, 17 June 2024 (UTC)Reply
Is there a reason specific dates can't be off loaded to structured data? I think that would be a better way to do things since we are already having issues with the amount of needless categories in general. Really most categories could, and probably should, be off loaded to structured data at this point. --Adamant1 (talk) 19:54, 17 June 2024 (UTC)Reply
To query for images from a certain date, just use inception date (wdt:P571) in a structured data query at https://commons-query.wikimedia.org/. We need to stop treating categories like a query language. They are ill-suited for that purpose. And if using structured data queries is too difficult, we should get the WMF to add more capabilities to Special:MediaSearch, for example, filtering by date. Nosferattus (talk) 20:48, 17 June 2024 (UTC)Reply
@Nosferattus, structured queries are great, and you are right that categories are not queries! Unfortunately, requiring users to have SPARQL knowledge in order to search for files is, I fear, a bridge too far. We need tools to bridge that gap and bring query functionality to a broader user base before we can point to that as the answer to the problem. Josh (talk) 16:08, 18 June 2024 (UTC)Reply
@Adamant1 That is absolutely the way it should be done, but right now the structured data just isn't there yet to make this an accessible option for a lot of users and use cases. I'm all for moving that forward. In the meantime, this issue will persist. Josh (talk) 16:05, 18 June 2024 (UTC)Reply
  • My general opinion: If there are enough files to create a new category: do so. Otherwise it is only annoying. For this specific case: I think that it is OK to have subcategories with more than ± 10 files, like Category:May 2014 in rail transport in Massachusetts‎ (23 files), but not for Category:Snow in Massachusetts in February 2012 (1 file).
    • I do think date categories are useful, especially when you are looking for other photographs taken on a certain date or month of the same subject and either harmonize their categories or create a new category, or to check whether a photo can indeed be taken on a certain day (if there is snow on the other photos instead of rain or blue sky, you know that something is wrong).
    • I disagree with Omphalographer that subcategories shouldn't be created simply because a category has a large number of files in it. If a topic category has more than 200 files, it should be broken down into subcategories to keep a good overview. Those new subcategories should preferably be topic categories, not date categories. Exceptions might be longlists and subjects like all the pages of a book.
    • I agree with Josh that files in date categories should also be available/stay in topic categories, for the reasons he mentions.
    • I agree with Pi.1415926535 that we need a tool that can allow you to find all files in a category (or category tree) within a selected date range.
    • See also Commons:Requests for comment/Categories of photographs by country by date, where (among other things) is discussed to which level of a country the diffusion would be allowed.
--JopkeB (talk) 09:24, 18 June 2024 (UTC)Reply
@JopkeB: We have a tool that allows you to find whatever you want without abusing catagories. Want to see all the photographs of snow taken on January 1, 2009? Here you go: https://w.wiki/ARP$. Just click the Run button. Frankly though, I think the use case of needing to find images of a certain subject at a certain location on a certain date is entirely made up. Who has ever actually needed this? I certainly haven't. And if we're going to diffuse by location and date, why stop there? We could also diffuse by file type, license, aspect ratio, color vs. black and white, photographer, etc. The point is, categories are a poor substitute for search queries and are not what they were designed for. But when all you have is a hammer, everything looks like a nail. Fortunately, we now have other tools, so we don't have to keep abusing categories. And if writing queries is intimidating, just ask Magnus or the WMF to create whatever type of search interface you want. The data is there. We don't need categories to redundantly encode it. Nosferattus (talk) 14:39, 18 June 2024 (UTC)Reply
@Nosferattus, we do diffuse by many of the things you list, such as photographer, color, file type, and a hundred other criteria, depending on the topic. Scoffing at those who aren't prepared to create SPARQL queries to view what they need is not the answer. Also, no, the structured data is not all there yet, so queries are rarely complete. In theory you are not wrong...in fact a good enough database with a good enough search interface may make categories completely obsolete. We aren't there on either the data or the interface yet. If it is as easy as you claim it is, then go forward, get WMF to create the interface and demonstrate how the average user can easily use it in lieu of category browsing and maybe then you will have a valid argument to not use categories. Until then, we need categories to work for the broad user base that continues to need them. Josh (talk) 16:25, 18 June 2024 (UTC)Reply
You do have a good point that the data and interface are not complete. However, in my opinion, they are a lot more usable than our terrible category system which is only getting less and less useful by the day, mainly due to over-diffusion. Nosferattus (talk) 17:02, 18 June 2024 (UTC)Reply
@Nosferattus And I agree that over-diffusion is a serious issue. This is why I've floated the idea, at least in the case of the date diffusion, to remove that from the topic category tree and make it a separate tree, leaving the files undiffused in the original topic category. I see search tools as a valuable adjunct to this, in fact. I am not personally well versed in our third-party interfaces, but I would like to build a template (or bit to include in existing templates) that invokes a search to identify any files in a non-topical category that are not still present in the related topic category. This would permit easier maintenance reversing incorrect removals from the topic category. Josh (talk) 17:09, 18 June 2024 (UTC)Reply
Thanks, @Nosferattus: for the link. But I am one of those for who aquiring "SPARQL knowledge in order to search for files is ... a bridge too far." as Josh says. And I agree with him that this tool only show files with the correct structured data, what is not good enough for me. JopkeB (talk) 09:44, 19 June 2024 (UTC)Reply
@JopkeB, as you can probably guess, I'm in agreement of most of what you've written here as many of these ideas are things that have come op in CfDs and other forums we've participated in. I am not a fan of placing hard arbitrary lower or upper limits on category size because I find topics and structures where very large or small categories do make sense within the scope of the topic and the available media. Of course, truly bloated categories do need to be diffused into meaningful sub-categorization, preferably by multiple different criteria. They don't even necessarily need to get to 200 files to warrant this in many cases. I do see you accept some exceptions though, which is good. One issue is stating 'subcategories should preferably be topic categories, not date categories.' I think I get what you are trying to say and I agree, but the root of this discussion is based on the fact that 'date categories' are 'topic categories' at the moment, at least structurally. The main effect of this is that, per COM:OVERCAT it is in fact required to remove a file from the main topic category when adding it to a date category. This is why I'm floating the idea of breaking date cats away from the topic tree and making them their own tree, akin to media type cats, thus reversing that requirement and making it a requirement to keep the media in the topic cat when adding it to a date cat. Josh (talk) 16:38, 18 June 2024 (UTC)Reply
I support the idea of making date categories non-diffusing, although my first choice would be to just delete them all. Nosferattus (talk) 17:09, 18 June 2024 (UTC)Reply
I'm not a big user of date categories, though I've had to work on several of them as part of being a broad-based maintainer. Commons doesn't have an exact analogue to Enwiki's non-diffusing categories, but we do have major category trees (see major category policy  ) which are similar in effect, in that categories under one major category do not diffuse categories in another major category (e.g. a file in a Media types category does not diffuse from the related Topics category; the file should exist separately in both). This is why I presented the idea of creating Category:Chronological categories as a major category and making all 'by date' categories fall under this, prohibiting diffusion of the original topic category. I understand that nuking date categories would be your first choice, but appreciate your understanding that at least making them non-diffusing is an improvement that should be made if they are to be retained. Josh (talk) 17:21, 18 June 2024 (UTC)Reply
I also support this idea. Whether we ultimately keep these date-based subcategories or not, infusing their contents back into parent categories is a clear step in the right direction. Omphalographer (talk) 17:21, 18 June 2024 (UTC)Reply
Support the idea in absence of a better option like moving dates to structured data. The whole thing just seems circular though. We don't fully embrace SDC. So it's not properly implemented, naturally leading to lower adoption rates Etc. Etc. I'd like to at least see a realistic plan with some implementable steps to move in that direction. Along better guidelines and enforcement around these kinds of things. Although admittedly both are tangential to the current problem and I have no issue with Josh's idea in the midterm. --Adamant1 (talk) 21:20, 18 June 2024 (UTC)Reply
@Joshbaumgartner: The numbers I gave were not meant as hard lower or upper limits on category size, just indications that might be workable. JopkeB (talk) 09:59, 19 June 2024 (UTC)Reply
Understood and I agree. Josh (talk) 22:41, 19 June 2024 (UTC)Reply
I absolutely agree with the suggestion of always keeping/ automatically adding some other category (by default, the parent one, in no better one is available) besides date categories. COM:OVERCAT has been misused and abused a lot here, unfortunately, either by lack of good sense either by some obsession with pigeonholing everything people see in a cat - and pushing files into data cats while removing the parent cat is only one of those situations. Darwin Ahoy! 17:50, 19 June 2024 (UTC)Reply
I remember complaining about it years ago at Commons:Village_pump/Archive/2013/10#Category_madness_in_Hong_Kong, but there didn't seem to be much agreement that it was a problem. It's also a long-time obsession in the Australian categories, so you end up with the likes of Category:January 2012 at Launceston Airport. I ignore it. --ghouston (talk) 02:36, 20 June 2024 (UTC)Reply

What to do in this case

edit

While we continue to discuss broader issues, I'd like to get some consensus as to what should be done in this specific case. AnRo continues to create hyperspecific categories such as Category:Spring 1951 in Boston, many of which have very few files, and they have not responded here nor at their talk page since this discussion began. To my mind, this is now an administrative matter - disruptive editing and a refusal to communicate - that needs action. Pi.1415926535 (talk) 18:03, 18 June 2024 (UTC)Reply

Yes, I just noticed that they created Category:Forests in Saxony in autumn 2019 and several others despite your polite request that they stop while discussion is ongoing. I've also asked them to stop. Nosferattus (talk) 20:42, 18 June 2024 (UTC)Reply
They should have at least held off until there was some agreement in the discussion about it. --Adamant1 (talk) 21:03, 18 June 2024 (UTC)Reply
This is just exacerbating the situation. There is some good discussion going on about how we can improve the system, but no matter what systemic changes we make, a disruptive effort by someone seemingly unwilling to participate in discussion is always going to be a problem. Unfortunately, some specific further action on that front might be needed. They don't even seem to be employing a consistent naming structure to these categories. Josh (talk) 22:59, 19 June 2024 (UTC)Reply

June 18

edit

Commons:The Commoner

edit

Apparently, we had some publication similar to w:en:Wikipedia:Wikipedia Signpost: Commons:The Commoner. JWilz12345 (Talk|Contrib's.) 15:43, 18 June 2024 (UTC)Reply

Subpages for documentation in category namespace

edit

Sample:

Is this usual in this wiki? Similar to templates with subpages, I found a few abandoned, bot-created pages by a retired user and listed them at Commons:Categories for discussion/2024/06/Category:GLAM dashboard reports. A user there asserts that it's correct to create such subpages, but I'm not aware of any other wikis doing that and the end up coming up in searches for categories elsewhere. Enhancing999 (talk) 17:38, 18 June 2024 (UTC)Reply

Supersede images : what to do with old page ?

edit
Category clean up : Category:Files supported by Wikimedia France - Elix - obsolete supersede by Category:Files supported by Wikimedia France - Elix.

As part of a Wikimedia France project on sign languages I uploaded better files for a whole category of 100 files and I have the authorisation to remove the old files. I see Wikidata uses these files 83 times (see https://glamtools.toolforge.org/glamorous.php ). I would like wikimedia projects to migrate to the new .webm files, and delete the old .ogv files. How should I proceed ?

  •   Done Upload new *.webm files, who provide better online support, see https://caniuse.com/ogv vs https://caniuse.com/webm.
  •   Done Added {Superseded2|NewFile.webm} to all old files
  •   Done Edited the specialized {{Elix}} template to create distinct categories
  •   Done Update Wikidata 83 items (by hand).

As fore migration then deletion of the obsolete, what should I do ?

  1. Delete obsolete files from Commons ? Replace by a #REDIRECT [[:file:newfile]] ? How ? (here)

Yug (talk) 17:39, 18 June 2024 (UTC)Reply

Just link the new format from the file description page of current format. ("other versions") Enhancing999 (talk) 17:46, 18 June 2024 (UTC)Reply
Done: I added the `other_versions` value to the {tl|Elix}} template. Maybe it will help bots to detect those pages, remove them, and put a Redirect in place. Yug (talk) 18:37, 18 June 2024 (UTC)Reply

June 19

edit

New changes to the "Depicts" step in UploadWizard available on Beta Commons

edit

Hi all! I wanted to announce that on Beta Commons a new version of the "depicts" step of UploadWizard is available for testing.

A brief note about the changes:

  • basic "depicts" annotations (and other statements set up in campaigns) without qualifiers or references can now be added on the same page where the user is entering captions, locations, etc
  • the separate extra page for adding structured data is removed from UploadWizard
  • qualifiers and references can still be added on individual File pages as before (and that will take only one extra click)

The reason for us doing this is that we're hoping that by simplifying depicts annotations we'll make it easier to spot copyvios (and in particular FoP violations). The drawback from a user perspective that we already know of is mostly for users who might be uploading multiple images at once with non-depicts statements and/or qualifiers and references, and copying those from the first image to all other images in the upload. This functionality is no longer available - as far as we can tell it's not used much, but if there are people using it then we'd like to hear from those users who use it.

This new version will be available on Beta Commons until Monday afternoon. We're waiting for your feedback on it! --Sannita (WMF) (talk) 10:23, 19 June 2024 (UTC)Reply

Two minor questions so far:
  1. Why does the Main subjects visible in this work (optional) label have a “pointer” cursor? Clicking it doesn’t seem to do anything (it doesn’t focus the input field).
  2. Why will this only be available until Monday afternoon?
Lucas Werkmeister (talk) 11:44, 19 June 2024 (UTC)Reply
The "pointer" cursor is unintentional - raised a ticket for it https://phabricator.wikimedia.org/T367976
It'll be available until Monday afternoon because we have to revert it by Monday evening, otherwise it automatically goes to production. If there's demand for more testing we can re-enable it on beta on Tuesday (until the following Monday) CParle (WMF) (talk) 14:09, 19 June 2024 (UTC)Reply
I think this change has a lot of potential!
  1. Regarding adding more structured data with "one extra click", I think there should be a button for that on the last page of the wizard (next to each uploaded photo).
  2. Why do you call it "Main subjects visible in this work" when the values are used in a depicts statement? I think inconsistent terminology creates confusion.
  3. I think the created depicts statements could be automatically marked as prominent ("The most prominent subject(s) depicted in this work").
  4. Do you (or do you plan to) suggest categories based on the chosen Wikidata items?
It would be nice to read about the plans for this kind of changes. TuukkaH (talk) 14:32, 19 June 2024 (UTC)Reply
Glad you think it has potential @TuukkaH!
  1. There's a link to the File page for each image on the last page, and that's where you can click the "structured data" tab and add extra structured data. We actually talked on the team about adding another link directly to the structured data tab, but weren't convinced that the extra clutter on the page was worth it
  2. We're calling it "Main subjects visible in this work" because we weren't sure if new uploaders would understand "depicts" (we had a lot of discussion about the exact wording). Open to other suggestions if you have them
  3. I'm not sure this is really necessary, but if there's community demand for it we can certainly do it
  4. It's an interesting idea, but likely to be a lot of work to figure out how to do that (and it's not on our roadmap atm)
FYI the plans for all these kinds of changes are covered on the project page and the phab tickets linked from there CParle (WMF) (talk) 14:55, 20 June 2024 (UTC)Reply
@Sannita (WMF) I tried to upload an image, but it doesn't appear (the file appears, but without the image itself). Is this expected? Darwin Ahoy! 17:30, 19 June 2024 (UTC)Reply
Beta can be a bit flaky, but an upload worked for me right now. Worth trying again maybe? CParle (WMF) (talk) 14:58, 20 June 2024 (UTC)Reply
@Sannita (WMF) I usually upload dozens of photos at once, and I used to upload them in batches so that it was very easy to put the "depicts" with the "apply to all" or "copy to all" function. If this is no longer available, and we'll have to pick depicts for every single file, I believe I'll stop adding them entirely. The extra field will be only additional, useless clutter, and I would frankly prefer if it wasn't there at all, or was hidden in another tab, as before. So, to me, in such a workflow, it's an unwanted change, and one for the worst. But I really don't get how do you think this change will help spotting copyvios, to start with. Darwin Ahoy! 17:37, 19 June 2024 (UTC)Reply
@DarwIn you actually can still copy "depicts", just not other statements (or qualifiers/references)
Freedom of panorama copyvios are the most common reason for deletion requests on commons (see here https://phabricator.wikimedia.org/T340546). What we're hoping is If someone uploads a picture of, for example, Burj Khalifa then they'll add depicts:Burj Khalifa, and we'll be able to spot the FoP violation automatically
Note that we don't propose to take any automatic action right now, but we're working towards better automatic detection of files that are likely to get deleted CParle (WMF) (talk) 13:58, 20 June 2024 (UTC)Reply

I started this gallery in my user space. Before I move it to the public space (ideally a more comprehensive version), I would like to make sure that such a gallery complies with what is considered acceptable in this project. Otherwise I would gladly leave it where it is. There is not corresponding category after all. But from the reader's point of view, I see multiple practical purposes of such a gallery, for example can it serve as an aid to identify species that they have seen in a garden. Stilfehler (talk) 16:57, 19 June 2024 (UTC)Reply

Perfectly acceptable gallery. - Jmabel ! talk 18:33, 19 June 2024 (UTC)Reply
Thanks! Stilfehler (talk) 18:39, 19 June 2024 (UTC)Reply

Incorrect use of "Extracted from" template?

edit

Is it correct to use the "Extracted from" template for images that are merely filtered and aren't a crop or "extracted" in any meaningful way? (And if it *is* okay, what's the difference between that and *any* derivative image?)

I ask because I notice that one of my uploads- File:William Hartnell, 1950 (halftone filtered).jpg, a filtered version of an existing image which I'd marked as a "derivative" image was converted to "extracted" by Mewhen123 (talk · contribs).

I reverted the changes and explained why at the user's talk page.

I didn't receive a reponse, but some time *after* this, they did the same thing to another upload I'd made regardless.

Since I didn't receive a response or any form of engagement the first time round, I figured it would be more productive to ask here whether or not this was okay or not? Ubcule (talk) 19:03, 19 June 2024 (UTC)Reply

The template documentation of "extracted from" explicitly says that it is for cropped images. However, the two examples are probably not derivative works either in the sense of Commons:Derivative works (you do not seem to be claiming to have added distinctly copyrightable content). They are probably simply "retouched pictures". -- Asclepias (talk) 19:27, 19 June 2024 (UTC)Reply
@Asclepias: - Okay, so we're both agreed that the use of "extracted from" for such images is misleading and incorrect regardless.
However, if you feel that Template:Derived from is inappropriate for indicating the source and/or "other versions" in the information box, which should be used instead? Ubcule (talk) 21:02, 19 June 2024 (UTC)Reply
Probably just cross-link with {{Other version}}. - Jmabel ! talk 21:42, 19 June 2024 (UTC)Reply
Sometimes a source is just a source. IMO, the simple normal link in the source field does just fine. Optionally, a thumbnail can be displayed in the other versions field (with or without particular format). -- Asclepias (talk) 21:59, 19 June 2024 (UTC)Reply
@Jmabel and Asclepias: - The problem with {{Other version}} is that it doesn't make clear which is the original or "parent" version. Particularly if I'm uploading a modified version of an existing image, I like to be clear that mine is the "derivative" version (in the more general sense) and to be able to make that relationship obvious in a manner that's clear and consistent for both users and automated processing.
Ditto simply displaying a thumbnail in the "other versions" field- it has no semantic meaning.
@Asclepias: - I honestly haven't come across anyone complaining about my use of {{Derived from}} until now, and I've been editing here for a long time. I'm still not 100% convinced that "derivative" in this sense *was* necessarily required to include/imply "distinctly copyrightable" input?
The fact that there isn't a template more specific to the case I described suggests otherwise. Ubcule (talk) 22:31, 19 June 2024 (UTC)Reply
{{Other version}} allows a freeform comment to explain the relationship. But I have no problem with {{Derived from}} here. {{Other version}} is certainly the one to use when discussing (for example) different prints from the same negative. - Jmabel ! talk 23:39, 19 June 2024 (UTC)Reply
Note that freeform also means "unrecognisable relation between things to computer systems". —TheDJ (talkcontribs) 07:33, 20 June 2024 (UTC)Reply
Merely reminding that the documentation of the template "Derived from" says that it is specifically for derivative works, which has a precise meaning legally and in the Commons official guideline on the matter. If you want to use the template in a broader sense than what that says, do what you want. But then you could hardly complain when Mewhen123 uses the template "Extracted from" in a broader sense than what it says. -- Asclepias (talk) 00:39, 20 June 2024 (UTC)Reply
There's also {{Retouched picture}} which allows you to indicate a different Commons image as the original that you retouched. - Jmabel ! talk 02:56, 20 June 2024 (UTC)Reply
This is a better choice I feel. —TheDJ (talkcontribs) 07:33, 20 June 2024 (UTC)Reply
@Jmabel and TheDJ: - Apparently you are technically correct that- by its own definition- the Commons' {{Retouched picture}} template covers anything "which [..] has been digitally altered from its original version". By that definition, this would count anything up to and including even (e.g.) a re-saved JPEG with no visible difference as "retouched"(!)
Regardless, I suspect that the majority of people would take "retouched" to mean an image which had undergone more serious and active modification of the fundamental content itself beyond (e.g.) trivial brightness, contrast, colour balance tweaks etc., even if that wasn't actually the case (Note this redirect on English Wikipedia).
You'll understand why I might feel this to be misleading, whether or not it falls within Common's (own) definition.
Regardless, it seems odd- and frustrating- then that we don't at least have a proper "most general case" root template to indicate that one file is based or derived (in the more general sense) another "parent" image and nothing more than that.
And, as TheDJ already indicated above, hacking such information non-systematically into "freeform" fields is no use to to automated systems, Wikipedia's included. Ubcule (talk) 13:47, 20 June 2024 (UTC)Reply

June 20

edit

Category:Engraved illustrations from Iconographic Encyclopedia of Science, Literature and Art, Published in 1851

edit

Why are all images in Category:Engraved illustrations from Iconographic Encyclopedia of Science, Literature and Art, Published in 1851 labeled with "Illustration from Brockhaus and Efron Encyclopedic Dictionary (1890—1907)" and, therefore, with wrong date and copyright templates? As I see, all of them are indeed from Iconographic Encyclopedia... published by Rudolph Garrigue, New York, 1851-1852, see here: [2]. Who can check this and correct if needed? AndyVolykhov (talk) 12:01, 20 June 2024 (UTC)Reply

Notifying Butko. -- Asclepias (talk) 13:13, 20 June 2024 (UTC)Reply
Похоже, была ошибка атрибуции в источнике, который использовался при загрузке. Наверное, был образ диска, где эти иллюстрации були смешаны с иллюстрациями из ЭСБЕ. Нужно ботом описания исправить. Займусь задачей, только нужно сначала сверить действительно ли все ли они из Iconographic Encyclopedia --Butko (talk) 15:34, 20 June 2024 (UTC)Reply
Возможно, путаница связана с тем, что Брокгауз немецкую версию этой иллюстрированной энциклопедии Bilder-Atlas zum Conversations-Lexicon. Ikonographische Encyklopädie der Wissenschaften und Künste издавал, даже чуть раньше, чем Гарриг в NY, но не в России и не в 1907 году, а в Лейпциге в 1849-м. Правда, я не вижу пока иллюстрированной версии немецкого издания, чтобы можно было сравнить и понять, откуда в точности картинки происходят. Возможно, если исходный диск брокгаузовский, то всё оттуда. AndyVolykhov (talk) 16:13, 20 June 2024 (UTC)Reply

Approval for PDF

edit

Need approval for uploading Venn diagram PDF, which is useful for teachers. UDAYA ADHAN (talk) 12:44, 20 June 2024 (UTC)Reply

You will be able to upload PDF files when your account is automatically confirmed. Please wait a few days and try then again, it’s simple as that. --Geohakkeri (talk) 15:17, 20 June 2024 (UTC)Reply

June 21

edit