This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Ok, this is getting a bit ridiculous, but this rename request has been at some sort of limbo state for 5 months so I'm bringing it here so it can gain more attention. Should we rename the file to File:Air Force Ensign of India.svg? I quote Fry1989's reasoning:
"This flag is currently in use, so the year of introduction should not be included in the file name. This is as per Commons' long-standing practice of naming flag images "Flag of XXX.svg" without a year of introduction unless the flag has been retired from use. It also can be confused for implying this flag was only used in 2023, as per the naming styles for flags such as File:Flag of Burundi (1966).svg, File:Flag of Zimbabwe Rhodesia (1979).svg, and File:Flag of Jamaica (1962).svg, which were only used for 1 year or less and for that reason include both their year of introduction and year of retirement as a single year."
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Stuck in category redirects
At Special:Permalink/880570764 a list of category redirects with files (or subcategories) that aren't moved.
Normally, there shouldn't be any category on that list. If one is there it means RussBot tried to move the files or subcategories, but couldn't. If the category is empty now, it means it has been fixed.
User:SteinsplitterBot is back in service rotating files. User:Steinsplitter explained that it was out of service because ' the so called "Toolsforge" does not provide enough ressources (RAM, CPU, Storage and binarys) to run Rotatebot '.
We have several pictures from WWII concerning Croatian area that are described wrongly or incorrectly given that this is what the secondary sources who comment or talk about these pictures say. The source that took picture from a Yugoslav archive is United States Holocaust Memorial Museum. It is also a factual source, however, it has a description of the image that is not in accordance with modern sources, which mark such an interpretation(regardless from whom) and as propaganda.
What to do in this case, and if nothing can be changed, can the same picture be posted but with an explanation ie description based on modern high-quality sources of historians?
Images are: Corpses in the Sava river, Sisak 1945.[1], Ustaše militia execute prisoners near the Jasenovac concentration camp[2], Glina church massacre [3] --Mikola22 (talk) 06:28, 2 June 2024 (UTC)
I don't think we can write caption/disclaimer below "United States Holocaust Memorial Museum" because this source is not an archive. It can be said that it is a secondary source. But the problem is that they took these photos from the Yugoslav Archive or sources which interpreted these photos in their own way. In modern sources of historians this method is labeled and as propaganda and with the explanation that the photographs show some other events and not the events that are presented through Yugoslav historiography. Let's say for the majority of Croats killed in Sisak, these photos are listed in the archive as pictures for Jasenovac with a note that this is how people were killed similar or the same and in the concentration camp Jasenovac, so these pictures can also be used in topics about Jasenovac, etc. Today, in fact photos of the majority of Croats killed in Sisak are placed in the context of the killing of Serbs, Jews, the Jasenovac Camp, etc. Mikola22 (talk) 14:24, 2 June 2024 (UTC)
For starters, there is {{Fact disputed}}. If (as appears to be the case here) the matter is genuinely controversial, that's a good choice: you are not simply making a correction, you are noting that two presumably scholarly sources disagree.
Also, when contradicting a presumably respectable scholarly source, it is a good idea to report the contradiction back to them. They are likely to incorporate it into their archives as well (which I see has now happened with that example I gave). - Jmabel ! talk19:02, 2 June 2024 (UTC)
Categories included due to templates frequently have issues with updating due to cache issues or the MediaWiki software updating its index (which I believe is done weekly). So while three days is a long time for it to not display, it’s not entirely unreasonable. Have you tried purging both cats and the template (I cannot on the machine I’m using presently)? —Justin (koavf)❤T☮C☺M☯22:58, 2 June 2024 (UTC)
I had purged both cats. I didn't think to try purging the template; now I've done so, and it still didn't resolve this. - Jmabel ! talk00:29, 3 June 2024 (UTC)
So I've been making a spreadsheet of all the numerical PNG files on here from 01.png to 99.png. While browsing I found that 27.png is somehow still an existing file? Here's the link: https://commons.wikimedia.org/wiki/File:27.png
I don't know what it is so I can't move it to a better file name. Hopefully someone knows what this is.
0x16w (talk) 09:59, 3 June 2024 (UTC)
I recently made this Category:Hungern bis ihr ehrlich seid 2024, then realized that that name is confusing, formed something more suitable, and duly added a redirect. That confusing name is still being shown as an auto‑completion option when filling in other more sensible categories, which could lead to wrong categorizations and be detrimental. I believe that that confusing category name is orphaned in any case.
Thanks! I looked at the documentation for Template:How to delete empty categories and it is not clear (to me at least) where to place this template. I guess that the target category is the correct location? Perhaps that information could be confirmed and added to the usage notes for that template? I have also already added a topic to the template discussion page to record my suggestion there. In addition, the template name seems confusing: is this template invoking a deletion process or merely offering passive advice. RobbieIanMorrison (talk) 07:11, 10 June 2024 (UTC)
I'm currently in something of a dispute with User:186.172.16.70 over guitars, bass guitars, and (implicitly) COM:OVERCAT. If this were a logged in user, I'd try to sort this out between just the two of us but, sorry, I'm not engaging over time with an account that might be a different person each time I interact.
If I understand correctly this edit is because bass guitars are, in a sense, a form of guitar, so there is an implicit argument that Category:Male guitarists from Austria is overcat for Category:Male bass guitarists from Austria. However, bass guitar is, in practice, a distinct instrument from a regular guitar, and we don't have something like a Category:No, really I meant a normal guitar. This particular person (unlike most bass guitarists) played/plays both a bass guitar and a regular guitar professionally, and in my opinion in that case someone should certainly be categorized under both, despite the theory of OVERCAT. Do others here, besides this one user, see it differently? - Jmabel ! talk22:18, 2 June 2024 (UTC)
There is no such thing as "regular guitar". Unless there is such a thing as irregular guitar. Do you mean Spanish guitar? Classical guitar? Ritm guitar? Of course admins are always right, this is why I chose not to be one. 186.172.16.7023:14, 2 June 2024 (UTC)
There may be an expectation by some that the guitar(ist) categories are meant to contain guitar-like instrument(alist)s as subcategories. That issue is easily solved by {{Cat see also}}. We already have Guitar family instruments as a common category. I assume bass guitarists mostly aren't also known as (or routinely professionally performing as) "normal" guitarists – if they are, then the issue is different. –LPfi (talk) 09:06, 4 June 2024 (UTC)
I would certainly be happier if, in general, bass guitars were subcatted from Category:Guitar family instruments (which should probably be hyphenated: "guitar-family" as an adjective) rather than Category:Guitars. Similarly for bass guitarists, though we don't yet have a category for players of guitar-family instruments. - Jmabel ! talk14:45, 4 June 2024 (UTC)
Invitation to participate in the #WPWPCampaign 2024
Dear community members,
We are inviting you to participate in the Wikipedia Pages Wanting Photos 2024 campaign, a global contest scheduled to run from July through August 2024:
Participants will choose among Wikipedia pages without photo images, then add a suitable file from among the many thousands of photos in the Wikimedia Commons, especially those uploaded from thematic contests (Wiki Loves Africa, Wiki Loves Earth, Wiki Loves Folklore, etc.) over the years.
In its first year (2020), 36 Wikimedia communities in 27 countries joined the campaign. Events relating to the campaign included training organized by at least 18 Wikimedia communities in 14 countries.
The campaign resulted in the addition of media files (photos, audios and videos) to more than 90,000 Wikipedia articles in 272 languages.
Wikipedia Pages Wanting Photos (WPWP) offers an ideal task for recruiting and guiding new editors through the steps of adding content to existing pages. Besides individual participation, the WPWP campaign can be used by user groups and chapters to organize editing workshops and edit-a-thons.
The organizing team is looking for a contact person to coordinate WPWP participation your language Wikipedia. We’d be glad for you to sign up directly at WPWP Participating Communities page on Meta-Wiki.
Thank you,
Reading Beans / readthebeansgmail.com)
Project manager and coordinator
Wikipedia Pages Wanting Photos 2024
Though the former discussion about Cat-a-lot was archived yesterday because the problem would supposedly have been resolved, for me the problem is still the same: it still does not work for subcategories with at least one subcategory. So can this discussion be restarted and can the problem really be solved? JopkeB (talk) 03:56, 6 June 2024 (UTC)
@JopkeB: you should always feel free to "necromance" a recently archived VP section back from the archive and continue the discussion. Just be sure that your edit summaries make it clear that is what you are doing. - Jmabel ! talk05:35, 6 June 2024 (UTC)
@Jmabel: How do you do that? To me it looks like a next level action. Just moving/copy-paste it and mention it in the edit summary? JopkeB (talk) 04:14, 7 June 2024 (UTC)
@JopkeB: yes, though in this case cut-and-paste is more appropriate. Mention it in the edit summary both on the archive page and where you restore it. If you have something to add, this is perfectly appropriate. - Jmabel ! talk04:43, 7 June 2024 (UTC)
It would also be nice if it worked on the conventional search rather than only special search. Yesterday I noticed it displays 1000 when only 500 items have been selected. I think this should be discussed and pointed out at the Cat-a-lot talk page. And how to solve it would be the same as for most technical issues: 1) more WMF priority/spending in that area and, more importantly, 2) things to get more volunteer onboard and have them implement/solve the most important issues such as those of tools widely used like cat-a-lot, video2commons (currently dysfunctional), or the Upload Wizard which still makes people add categories that are redirects. Banners for volunteer devs on software-related Wikipedia articles as well as a campaign with things like leaderboards, badges, gamification, internal attention, possibly external reporting, prizes (maybe also anonymous bounties), and prioritized weighted issues would be a straightforward way to implement that. One can only speculate why the WMF isn't doing things like that, could be incompetence, related to techcompany donor funds, a general lack of a sense of community wishes, and/or something else. I don't think just merely asking about any particular major technical issue on VillagePump does anything. I don't think this particular problem is large though: just refresh and move the remaining subcategories using HotCat. Prototyperspective (talk) 13:15, 6 June 2024 (UTC)
Hello,
I have noted Al-Hilali Z uploads what is designated as flags of Arab tribes. None of the files has an indication of a source on which the file design has been based. When queried about this though the talk page, it is confirmed the great majority are the user's personal design. Is this not an issue, especially when these flag images end up being displayed in Wikipedia articles and presented as recognized flags when this is not accurate? Moumou82 (talk) 20:41, 5 June 2024 (UTC)
I found this too for made up coats-of-arms for obscure royal families, and then websites using them. --RAN (talk) 21:50, 5 June 2024 (UTC)
Hello,
Arabs Tribes flags are very different of other flag, they dont respect vexilollogy codes, everyone is free to create Tribal flags, there are no Official flags, except in rare cases, but they are inconsistent and free to create your own design. Al-Hilali Z (talk) 08:11, 6 June 2024 (UTC)
No, they are completely legitimate, the majority of the flags that I make are made with the approval of members of the tribe and are adopted by them, there is no connection with the oos. Al-Hilali Z (talk) 10:48, 7 June 2024 (UTC)
Is it okay if I force category using Cat-a-lot rather than wait?
Hi everyone. I made this category: Category:ONCHI to track the files we have uploaded as a part of our project in Indonesia. It is included via this template User:RXerself/ONCHI but I put the category later than when the files were uploaded, so the category is now still only has 3 files which, 2 of which were "forced" in which one was edited manually and saved without changing anything and the other one using Cat-a-lot. MediaWiki help page on this explains that: "when changing the categories applied by a template in this fashion, the categorization of the pages which include that template may not be updated until some time later: this is handled by the job queue." [5] But it's now more than a week already and it still only has 3 files. Is it okay if I "force" the files by using Cat-a-lot? Not okay as in I would break anything, but as in if I am allowed. RXerself (talk) 22:30, 7 June 2024 (UTC)
Is there any agreement on which categories should be placed here? This honestly feel very random. Like why are Femboy, Incest, Incel and Skoliosexuality even located here?--Trade (talk) 22:55, 8 June 2024 (UTC)
I'm not convinced this category should exist at all. Whether a topic is "controversial" is not a judgement call which Commons should be making; it's not essential to the identity of the topic. Omphalographer (talk) 00:12, 9 June 2024 (UTC)
I have to agree with Omphalographer. Most, if not all, sexual and gender identities are controversial to some degree and depending on the time period or location. So the category is essentially meaningless. --Adamant1 (talk) 00:24, 9 June 2024 (UTC)
One of the files in the category is directly related to zoophilia. Considering this is a subcategory of both Gender identity, Sexual orientation and LGBT i'm not really a fan of what this is implying.--Trade (talk) 01:39, 9 June 2024 (UTC)
Yesterday I overwrote an image, when I went to crop out details from the new image, croptool wanted to goto the original image to do the croppng. Had to resort to GIMP to do the job. It wasn't a cache problem. Broichmore (talk) 10:54, 3 June 2024 (UTC)
Good. Doing some back-of-the-envelope math, someone can plausibly do three of these a minute, so with 23,000 images, that means 128 person-hours of work, which is a lot for one person, but reasonable for a small group. —Justin (koavf)❤T☮C☺M☯20:54, 3 June 2024 (UTC)
Just to say, the museum source has not cropped them, why would they not? There seems to be some kind of mania, here, in cropping out borders to satisfy OCD urges. Margins prove the extent of images, they confirm that images are indeed complete. Any source museum would consider this vanadalism. I have to say that certain museums employ prestigous decals on their images, claiming source, the Imperial War Museum, The British Library, the Bundesarchive in this case. Cropping out these details, deny them the opportunity of advertising, which is cheeky when you consider they curate these images for us for free. These Bundesarchiv decals that are being cropped out deny 'end users' easy attribution of where these images come from. Wikipedia in particular is bad for not only referencing the source museum, but also even the artist. Furthermore, in the new world of AI, these decals go some way to prove authenticity. At this point their discreet enough, not to worry about. This is not a good use of our resources, and is wrong. Broichmore (talk) 08:24, 4 June 2024 (UTC)
@Broichmore: I don't necessarily disagree. If I had my way I'd probably just remove the crop requests, but I didn't add them to begin with and I try to respect what other users want. It would at least be less work to just not crop the images to begin with though. --Adamant1 (talk) 09:35, 4 June 2024 (UTC)
Indeed, the thing is that every so often editors discover the crop tool and see it as an easy pastime. When in fact it's a tool that should be rarely used, and with great caution. The average original uploader is more than capable of cropping their images prior to uploading, their wishes should be respected.
Even in these images, the Bundesarchiv logo, tell us so much. Date, German origin, the importance put on collecting the image by the German government, and that they consider it being worthy of preservation, & etc. Broichmore (talk) 09:53, 4 June 2024 (UTC)
This misunderstands how Wikipedia/Commons attributes images. The sources and authors are listed on the image's descriptions pages, not in the text on Wikipedia itself (this also to discourage using Wikipedia as a tool for self-promotion). With regards to this collection specifically, the information listed in the image is also listed on the page (the bild ID (and a link to the ID on the archive), the year it was taken, the name of the photographer, if one is known, the archive itself). This is where that information is supposed to be; there is no need to have it be visible on the image too. This kind of visible watermarking is discouraged. Invisible watermarking on the other hand is encouraged because it doesn't interfere with the contents of the images themselves. Every single one of the images in this collection has invisible watermarking too (the EXIF data if you scroll to the bottom), which contains the same information that's visible in the margins, and is wholly unaffected by the crop tool. ReneeWrites (talk) 13:31, 4 June 2024 (UTC)
@ReneeWrites: I don't misunderstand anything. While attribution is optional on Wikipedia; not every source is notable. However, many, and most are!
Discerning casual readers (who are, who Wikipedia aims itself) want to know the source of artwork or notable photographs.
I am yet to see an encyclopaedia, or source book which does not attribute at the front end. Children's books don’t attribute. Hiding attribution as you describe, is a successful way of withholding information from Wikipedia’s readership. The majority of which, are in computing terms illiterate.
As an incentive, the secret to successful Wikipedia writing is creating ''links'' to other articles on the project. There is an ongoing opportunity to link, to articles, about ''said'' notable artists and photographers. Those players, in turn, are often part of the stories themselves.
If you want the image info to be visible directly in Wikipedia articles, then try to create a policy on Wikipedia recommending attribution in the caption. The info in the image border isn't visible in the thumbnails actually shown. You need to click at the image anyway to be able to read that information, and it is much more prominent in the actual file description than in the tiny text on the border. Now, clicking may get you to the image viewer instead of the image description page, but even then, clicking "more info" (and searching for that link) isn't unreasonable if you want to get to that info. (Many books attribute images in a separate list instead of "at the front line"; if you want the info, you have to look for it.) –LPfi (talk) 06:58, 9 June 2024 (UTC)
Unfortunately Ancestry would guillotine the books to ease scanning then discard the originals. I used to buy them at book sales and see if it was on their list of needed copies, but stopped when I learned their policy. Having them online is absolutely awesome. --RAN (talk) 21:48, 5 June 2024 (UTC)
in germany you can find a list of full names and a group photo of students doing abitur in a certain year on the newspaper and its website. XD
This is probably just my lack of understanding of French law but, @Kontributor 2K: given that this appears to have been a published document, how is this "private data"? - Jmabel ! talk17:46, 5 June 2024 (UTC)
I don't think it's been published (like a book); it's just been printed. In general, this type of document is given to families at the end of the school year, or after the ceremony. It's not a public document. --Kontributor 2K (talk) 17:58, 5 June 2024 (UTC)
Under international copyright law that does constitute being "made public", also lists of names are not copyrightable. To be eligible for a copyright a work must have unique creative elements. If you asked a dozen people to compile the list of names, each person would create an identical list. If you asked a dozen people to compile a list of the best music of all time, each list would be different and copyrightable, that is why the Time 100 list each year is copyrighted, or the Fortune 500 list. --RAN (talk) 21:44, 5 June 2024 (UTC)
You mean the Berne convention? Anyway, is privacy law coordinated with copyright terminology? In Finland, we have a lot of material that is public (you will get it if you ask), but still publishing it in a newspaper or similar is illegal unless there is sufficient public interest or other specific reasons to. This includes tax records and court cases. –LPfi (talk) 07:16, 9 June 2024 (UTC)
Any procedures for seeking and archiving explicit consent when subject is identifiable?
Michael Winter in skeleton suit lying outside the German chancellor's residence to protest the lack of action on climate policyClimate activist Tessel Hofstede from XR Netherlands speaks to Letzte Generation in Berlin in 2023
I took the photograph shown and have had a clear and unequivocal discussion with Michael Winter, the subject, that I can upload that and similar images to Wikimedia under CC‑BY‑4.0. Michael also provided me with his email address on my request and I was intending to follow up with a proper "release form".
That event occurred in Berlin, Germany of course and German and European privacy law would prevail.
I have had a reasonable look around this site and could not find mention of any formalized processes like this. The notion of "asserted consent" is traversed. So I take it that Wikimedia does not wish to provide support for written agreements of this nature? I guess that position is understandable? Particularly given the large number of legal jurisdictions involved and also changing statutes and evolving case law.
So I suppose the best thing to do in this particular case is to undertake some email traffic with Michael and leave that exchange on my hard‑drive as a kind of insurance policy? Any assistance welcome. RobbieIanMorrison (talk) 17:54, 6 June 2024 (UTC)
Thanks GPSLeo and Jmabel. I did once use that process for another image in relation to consent. In that case, my associated email traffic was somehow stored out of public view and linked backed to the particular image. I also presume that my earlier assumption that the concept of release forms is not supported by Wikimedia due to the legal complexities present. Thanks both for your quick responses. RobbieIanMorrison (talk) 19:17, 6 June 2024 (UTC)
Maybe we could add a param to consent, so that people can reference a document id, link or VRT/OTRS id. That might be worthwhile! —TheDJ (talk • contribs) 19:51, 6 June 2024 (UTC)
For what it is worth, the accompanying image of the woman in yellow uses the following field "permission={{VRT info|1=2024050810008791}}" as part of the 'Information' template. RobbieIanMorrison (talk) 21:21, 7 June 2024 (UTC)
Only the VRT agents can see what info that ticket includes, so whether it is relevant to this discussion is unclear. But yes, that's the way to link to such correspondence. You could reference it in the permission field if you want reusers to know something about what privacy issues are covered. –LPfi (talk) 08:35, 9 June 2024 (UTC)
Placement of recurring terms in sets of subcategories
Are pre- or postmodifiers preferable in cases like those that are being discussed in Commons:Categories for discussion/2023/12/Category:Old women sitting? I.e. when the option is semantically appropriate and linguistically feasible, do we want e.g. sitting-related subcategories to be called "Sitting x, Sitting y, Sitting z" or "x sitting, y sitting, z sitting"? As per my post in the category discussion, I think the latter makes the most sense, but perhaps there is more information and/or user consensus to be found somewhere. Sinigh (talk) 14:07, 8 June 2024 (UTC)
Makes sense but "Old women" is also a recurring term so the optimal solution both this and items where the former term is a nonrecurring one would be to have redirects so that e.g. Old women sitting redirects to Sitting old women or the other way around. Would be good if there was a bot/script that did so / created redirect proposals one could quickly confirm or add to a list of likely inappropriate proposed redirects. (The same could maybe also be done for category names in languages other than English but that's another topic.) Prototyperspective (talk) 15:35, 9 June 2024 (UTC)
EK 318 flight Dubai Tokyo 11 may 2024
I was seated close to a window and have taken some pictures: The camera time is the time in Amsterdam, not the local time. The route is trough Pakistan and China. There where no delays.
I've done this sort of thing a lot. I strongly recommend plunging into Google Maps looking for similar landforms. (BTW, for the future: much easier if you take a lot of pictures, even if you don't plan to use them all.) - Jmabel ! talk14:59, 3 June 2024 (UTC)
Also useful is if you are listening in-flight to the pilots talk to Air Traffic Controllers, making a note of which Air Traffic Controllers' areas the pilots are told to switch to (the next area on the flight plan); for flights arriving here, that is typically "New York Approach". The frequencies are not necessary for this purpose. It will help if you can listen in English, as that appears to be the standard language of air traffic control worldwide. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:09, 3 June 2024 (UTC)
De official times are Dubai departure 02:40 am local time and arrival at Tokyo 17:35 pm local Japanese times. Camera time Amsterdam GMT + 1 (+ 1 summertime); Dubai GMT + 4; Japan GMT + 9. 7 hour difference between Japan and Amsterdam. China is GMT + 8). From what I remenber the plane avoided India went trough Pakistan and then took a more or less straight line trough China and South Korea passing trough large Chinese dessert areas. So the Himalayas would be at de western end by the Pakistan / Chinese border, but could also be inside China.Smiley.toerist (talk) 16:52, 3 June 2024 (UTC)
@Smiley.toerist: At least the city on last three images should be relatively easy to identify e.g. with Google Maps satellite mode; provided you know at least approximately what area and/or what country had been overflown at that timepoint, as otherwise this would be a search for the "needle in a haystack".
In general, it's quite tricky and common landforms are difficult to identify afterwards, likewise in flight because from my experience, GPS on your phone seldom works well in flight. --A.Savin16:27, 3 June 2024 (UTC)
The solution to have and keep a GPS connection in fast moving vehicles with a smartphone is to activate a constant tracking before you start moving. For these photos case it might be the best solution to look at the Flightradar24 data for the flight and then matching the capture time. But that requires a paid account there. GPSLeo (talk) 16:43, 3 June 2024 (UTC)
The last picture must be in Japan, about 15 minutes before landing. With the long shadow of a western sun, this must be an east coast. Smiley.toerist (talk) 17:02, 3 June 2024 (UTC)
(EK 318 flight Dubai Tokyo 11 may 2024 4) is close to JR station Izumi and (EK 318 flight Dubai Tokyo 11 may 2024 5) is close to Otsu port (found on GE). I have problems finding the correct location categories. Narita airport was approached from the north along the coast.Smiley.toerist (talk) 17:56, 3 June 2024 (UTC)
, by doing some time and distance calculations and finding out that the village must be about 3.258 km from Dubai. The scharp dark green fields contrast with the more dessert like image from Google Earth. The most dificult to lokalise images must be the two mountain images where I wil probably be using ADSB data.Smiley.toerist (talk) 10:21, 4 June 2024 (UTC)
Calculating that the mountain views 71 minutes before the dessert village, places the mountains within Pakistan. (13,03 km by minute)Smiley.toerist (talk) 10:36, 4 June 2024 (UTC)
The ADSB data of past fligths indicate that the plane usualy crosses Chinese border halfway between the Afganistan border and the Indian border (line of control). Close to the line, a bit to the East is the K2 mountain. However it is complicated to find the rigth mountain.Smiley.toerist (talk) 19:59, 4 June 2024 (UTC)
ADSB for flight that took off Sunday 02:45:00 AM UTC+04
Thanks for the info. The positions are estimations and imprecise. I was on a seat on the left side. By the landing (4, 5, 6) the plane was clearly flying over land and not over the sea. The details of picture 3 match with the GE satelite picture. As the plane was flying around 10 km heigth and the village has a low altitude of 1017 meter above sealevel the plane must have been someway south of that position.Smiley.toerist (talk) 09:36, 5 June 2024 (UTC)
First, a jetliner cruises at about 1000 kmph or 16 km per minute. An error of 5 minutes is 80 km.
I did not interpolate the position from the ADSB data; instead I just chose a close time. Interpolation would be better if we know the times are accurate.
The error for the village is large. To match the longitude, I had to advance the time by 7.5 minutes, but the ADSB plane position was still well north of where it should be. The issue is partly resolved by the position being estimated because there is no actual ADSB data during that part of the flight.
The ADSB data that is not estimated should be accurate. The numbers I used do put the plane over water when it should be over land. However, you can look at track as it approaches the airport and see that portions of that track do align with the pictures.
That error may just be a time offset. You might see how accurate your camera clock is right now. Alternatively, you could try to figure it out from a reasonable track position for a particular image. That's what I was trying to do with the 7.5-minute village offset until I realized the track didn't fit and noticed the ADSB data for that time was only an estimate.
The EXIF data also has a quantization error of 1 minute.
I expect the ADSB times to be derived from the GPS satellites.
Is it actually useful for structured data to mark my own file that I copied from my own Flickr account as authored by Flickr user Joe Mabel, as against Commons user Jmabel (both me)? - Jmabel ! talk15:04, 3 June 2024 (UTC)
I would say so. Most Commons users upload their files here directly, not via Flickr. And most of the time when people upload files from Flickr with the Flickr2Commons plugin they are not the original author of those images, so it makes sense (and is imo useful) if that credit line is automatically attributed to the Flickr profile the images are from. For your own images you could always edit the credit line to your Commons profile if you prefer to be credited that way. ReneeWrites (talk) 20:27, 4 June 2024 (UTC)
I agree that the SDC should point to the named photographer if known, and not the Flickr user.
I think the bot’s behaviour is fine.
It didn't delete or replace the information in the Wikitext. It only added a creator (P170) SDC statement because there wasn’t one on this file before.
If there's already a creator (P170) statement, the bot leaves it as-is. I could point you to literally thousands of examples where the bot has looked at a file, seen a P170 with more specific information, and left it as-is.
If the file is edited to add a more specific statement, the bot will leave it as-is. I’ve done a manual edit to replace the Flickr user statement with one that points to Frank H. Nowell (Q26202833), and if/when the bot processes that file again, it won’t make any changes to P170.
I'd say it's widespread. It is going to happen literally any time a user first uploads their own content to Flickr and than imports it to Commons, and literally any time a third party posts historical content to Flickr and someone imports that. - Jmabel ! talk17:50, 10 June 2024 (UTC)
Notification of DMCA takedown demand — Autobiography of Banbhatta
Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.
Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. Follow their work on Meta-wiki.
@Jmabel and AntiCompositeNumber: Good points. @RamzyM (WMF): It does seem rather misleading to talk about U4C starting its work without mentioning that the U4C is sub-quorum and is limited to only carrying out actions that do not require votes. Boud (talk) 20:15, 11 June 2024 (UTC)
Can I use this picture
I have found this on flickr[6]. It is a photo of an original picture held in the Royal Library, Copenhagen. It is described, in: Niklas Eriksson & Johan Rönnby (2017) Mars (1564): the initial archaeological investigations of a great 16th‐century Swedish warship, International Journal of Nautical Archaeology, 46:1, 92-107, DOI: 10.1111/1095-9270.12210 [7] as "Illustration from a Danish manuscript, signed Rudolf van Deventer 1585".
The flickr version claims copyright – but presumably that is only copyright of the photograph. The illustration itself is clearly over 400 years old.
Is there any route through the various copyright laws that would allow a version of this picture to be uploaded to commons? Obviously, as well as the flickr version, there is the one in the paper listed above. There is also a cropped version in Niklas Eriksson (2019) How Large Was Mars? An investigation of the dimensions of a legendary Swedish warship, 1563–1564, The Mariner's Mirror, 105:3, 260-274, DOI: 10.1080/00253359.2019.1615775 (Open access[8]) Other pictures of the wreck of this vessel look to be heavily protected in copyright law, so this old picture would be of real value. ThoughtIdRetired (talk) 19:28, 10 June 2024 (UTC)
What's the cost of this rename to WMF? Do we really need to spend resources on this rather than actually doing some development? Enhancing999 (talk) 19:01, 11 June 2024 (UTC)
Naming of concert photography categories
Do we have any guidelines on how to name categories on Commons for specific concerts? I feel like there is a lot of freedom. Maybe it would be worth developing a scheme such as: Artist name - Place - Date or different in a specific format?
Example of diversity in naming: c:Category:2013 concerts in the United StatesGower (talk) 05:47, 11 June 2024 (UTC)
It probably depends on the artist and concert but I don't think the place or date needs to be in the name of the category in a good perecentage of cases. That's what parent categories are for. --Adamant1 (talk) 13:07, 11 June 2024 (UTC)
a lot of times categories for events are just titled according to their official names. sometimes when that name is not special enough a year, a date or a location is appended in parentheses, e.g. (2024) or (London).
it certainly helps if you choose to name your categories in a very detailed format. imo, a format of "concert name (yyyy-mm-dd)" is good enough, because quite rarely there would be two concerts of the same name on the same date? if the concert has no name, then "artistname's concert (yyyy-mm-dd)". if there are multiple artists involved then "Concert at venuename, city (yyyy-mm-dd)". RZuo (talk) 07:20, 12 June 2024 (UTC)
When I name a file on my Windows PC in a folder, and then upload using the wizard, underscores and or dashes appear in the file name. How to stop it from doing that? -Broichmore (talk) 14:45, 12 June 2024 (UTC)
@Broichmore: Spaces get converted to underscores (if necessary) for URL purposes, but both are stored as spaces and can be used either way (I find the underscores ugly, and so does AutoEd). What is getting converted to dashes for you? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:09, 12 June 2024 (UTC)
MediaWiki will generally convert characters not allowed in filenames to dashes. Typically that means : / \ < > [ ] | # { } but can also include more obscure characters, such as control characters. Bawolff (talk) 19:12, 12 June 2024 (UTC)
That is by design, it can be annoying when you want to download, and then reupload to another website and use the filename as a description of image. You then have to remove the underscores by hand. --RAN (talk) 19:03, 12 June 2024 (UTC)
The final text of the Wikimedia Movement Charter is now up on Meta in more than 20 languages for your reading.
What is the Wikimedia Movement Charter?
The Wikimedia Movement Charter is a proposed document to define roles and responsibilities for all the members and entities of the Wikimedia movement, including the creation of a new body – the Global Council – for movement governance.
Join the Wikimedia Movement Charter “Launch Party”
Join the “Launch Party” on June 20, 2024 at 14.00-15.00 UTC (your local time). During this call, we will celebrate the release of the final Charter and present the content of the Charter. Join and learn about the Charter before casting your vote.
Charter refers some "community leadership" as teh accountable body for each Wikimedia project, without defining what it means (the whole community, some specific members?);
Charter rules over all Wikimedia project policies, but not over those of the Wikimedia affiliates and the WMF;
Charter leaves WMF out of the Global Council (community + affiliates), as an independent body at the same power level;
While the whole community, including affiliate people, get to elect 12 seats out of 25 in the Global Council, affiliates themselves get an additional 8 seats for themselves, which I considere a severe and totally unjustified unbalance of power towards affiliates;
I don't think this is acceptable, and will certainly vote to block this charter. I advise you to read it carefully, and eventually block it as well, as I don't see how this could favor our community. DarwinAhoy!16:06, 13 June 2024 (UTC)
Why was this picture deleted with speedy deletion criteria? There is an article in the Hebrew Wikipedia about Yuval Karniel. This is a very puzzling deletion. See Category:Yuval Karniel. I am a VRT volunteer, and the photographer User:Pinhas stern contacted VRT system and asked why it was deleted. Hanay (talk) 05:03, 13 June 2024 (UTC)
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)
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)
& @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)
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)
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)
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)
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):
Is the June 2024 Ukraine peace summit logo copyright-free?
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.
@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 ! talk22:35, 11 June 2024 (UTC)
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)
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 ! talk23:18, 11 June 2024 (UTC)
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?
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)
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)
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)
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. — billinghurstsDrewth23:37, 14 June 2024 (UTC)
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)
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)
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) (talk • contribs) 15:08, 17 June 2024 (UTC)
@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)
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)
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)
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) (talk • contribs) 18:49, 17 June 2024 (UTC)
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)
Uploading while editing wikipedias: beneficial or problematic?
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).
@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)
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)
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. — billinghurstsDrewth01:06, 16 June 2024 (UTC)
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)
@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 continueto remindFilipinos 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)
@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)
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)
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)
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)
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)
@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)
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)
Comment based on some of the recent commentary on the files that have been uploaded that should have been rejected, I have made a minor mod to the filter to slightly increase the file size to disallowed. There is probably a little more we can do to look to challenge files where they add a url within the "uploaded while editing ...". — billinghurstsDrewth02:26, 16 June 2024 (UTC)
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)
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. — billinghurstsDrewth03:32, 16 June 2024 (UTC)
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)
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)
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)
RFC: Automatic categorisation both bane and gain; work needed to identify source of categorisation
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:
direct category in the page
template that has local data
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. — billinghurstsDrewth00:22, 9 June 2024 (UTC)
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)
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 ! talk01:00, 9 June 2024 (UTC)
@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)
The same way we decide anything else of the sort. It does seem odd for the decision to be hidden in a template. - Jmabel ! talk01:44, 9 June 2024 (UTC)
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. — billinghurstsDrewth02:18, 9 June 2024 (UTC)
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)
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 ! talk01:48, 9 June 2024 (UTC)
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)
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)
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)
@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. — billinghurstsDrewth02:27, 9 June 2024 (UTC)
@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)
@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. — billinghurstsDrewth01:21, 10 June 2024 (UTC)
@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)
@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)
@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. — billinghurstsDrewth04:02, 11 June 2024 (UTC)
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)
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) — billinghurstsDrewth04:27, 11 June 2024 (UTC)
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)
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:
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).
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).
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?
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? — billinghurstsDrewth00:56, 12 June 2024 (UTC)
Solution mode
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. — billinghurstsDrewth00:50, 12 June 2024 (UTC)
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)
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)
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)
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)
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)
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: 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)
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)
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)
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)
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)
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)
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)
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)
I think not. That could as easily mean fictional flags of real countries as flags of fictional countries. - Jmabel ! talk01:10, 14 June 2024 (UTC)
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)
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)
@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)
@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 ! talk19:17, 17 June 2024 (UTC)
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)
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)
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)
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)
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)
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)
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.
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 ! talk18:35, 18 June 2024 (UTC)
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.
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)
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?)
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)
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)
@Asclepias: - Okay, so we're both agreed that the use of "extracted from" for such images is misleading and incorrect regardless.
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)
@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?
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)
@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)
Category:Engraved illustrations from Iconographic Encyclopedia of Science, Literature and Art, Published in 1851
Похоже, была ошибка атрибуции в источнике, который использовался при загрузке. Наверное, был образ диска, где эти иллюстрации були смешаны с иллюстрациями из ЭСБЕ. Нужно ботом описания исправить. Займусь задачей, только нужно сначала сверить действительно ли все ли они из Iconographic Encyclopedia --Butko (talk) 15:34, 20 June 2024 (UTC)
Those seem like a bit of a special case. Those categories are less of an intersection by date, more photos of an event which is known primarily by its date. I would hesitate to generalize from there. Omphalographer (talk) 19:43, 17 June 2024 (UTC)
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)
The question of intersection categories is a constant one on COM:CFD. Essentially, nearly every topic category is an intersection category. Thus I don't think how we treat discussions on intersection categories is really that different from how we approach topic categories in general. There are sometimes calls to arbitrarily limit the amount of sub-categorization of a topic (essentially a process of intersecting categories), but these rarely gain consensus as it usually involves unintended consequences and lots of exceptions. Essentially, the basics are that there ought to be enough media to support an intersection category, that the intersection be sufficiently distinguishable to make a distinct category, and there it offer some meaningful sub-division of its parent categories. If any of these are in question, the issue is raised and discussed at COM:CFD (or other appropriate forum) and consensus for that particular use case is implemented. Basically, if a user creates a category, so long as it does not violate Commons category policies, until there is a consensus that it is not useful, it is presumed useful and kept.
As for tools we need, better and more accessible search tools that obviate the need to use categories as search criteria would be high on my wish list. There are some good SPARQL query tools and gadgets that are helpful for those users with the initiative to learn and apply them, but they are not available to the mainstream and most users I would presume are not interested in learning to code just to view the media they are looking for. User-friendly interfaces built directly into the Commons interface (not requiring opt-in gadgets or third-party sites) are a must to make these useful for more than a small group of users.
Clearly, involvement beyond volunteer contributors will be needed for at least some of these tools, and I have absolutely no clue how to push that cart. I'm not politically minded, nor am I steeped in the inner circle workings of the project, so I wouldn't even know how to start such a drive, but I'll gladly sign on to voice support for valuable tools. I added my name to several items on the wishlist a while ago...not sure if that did anything.
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)
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)
Chronological categorization seems to be coming under increased scrutiny lately. As the number of hosted files continues to grow and topical categories get larger, there seems to be increasing efforts to diffuse topics by date, and by increasingly precise dates at that. Beside appearing to be a benign effort to diffuse bloated topic categories, there can be specific technical value to categorization by specific date for maintenance, curation, and some specific research efforts. However, the unintended consequence is that topic files become buried in layers of date-based categorization, frustrating most users looking for images of that topic who are not concerned with exactly when the image is of. I think it is fair to conclude that the vast majority of users looking for images of snow in Massachusetts do not care if happens to be January or February of 2012, or if it is February of 2012 or 2013. Maybe one might want to focus on more recent times vs. pictures of yore, and some may indeed be interested in January vs. February for seasonal differences (not caring which exact year), but most don't probably care about the exact year even, much less month or day. Requiring them to select one particular moment in time to see images is very frustrating for most. This also makes normal diffusion more difficult, as files moved to specific dates are less likely to correctly get diffused to more appropriate sub-categories (e.g. a pic already moved to Snow in Massachusetts in February 2012 is less likely to ever be correctly be put into Snow in Boston as it no longer appears directly under Snow in Massachusetts).
The solution to this dilemma would be one where the files are available in the main topic category for users to look through without requiring they select a specific date to be limited to, while also permitting the images to be collated by date to whatever level of specificity is meaningful for the topic. We have the same issue with categorization by media type. Most users are not looking for images of a precise type to limit their browsing to, but such categorization does have a lot of technical value to specific users. What we have done is make the Category:Media types tree separate from the Category:Topics tree. Files can be added to the Category:Media types tree and be diffused to whatever exact media type specification they fit, however, they are not to be removed from the Category:Topics tree (i.e. the main topic categories for the file). The Category:Media types categories are to be "__HIDDEN__" which puts them in a separate list of categories (only visible to users who elect to see non-topical categories).
We could adopt this approach for date-based categorization, creating Category:Chronological categories as a separate non-topical tree. This would allow continued categorization by specific date without diffusing topical categories. For example, in the case of Massachusetts snow, all files regardless of date would be present under Category:Snow in Massachusetts, a topical (visible) category. The files themselves can be additionally categorized by date under Chronological categories to whatever level of precision those involved feel is warranted. They could be accessed from the main category via Snow in Massachusetts by period which would still appear under the main category for all users. Josh (talk) 17:44, 17 June 2024 (UTC)
Is there a reason specific dates can't be off loaded to structured data? I think that would be a better way to do things since we are already having issues with the amount of needless categories in general. Really most categories could, and probably should, be off loaded to structured data at this point. --Adamant1 (talk) 19:54, 17 June 2024 (UTC)
To query for images from a certain date, just use inception date (wdt:P571) in a structured data query at https://commons-query.wikimedia.org/. We need to stop treating categories like a query language. They are ill-suited for that purpose. And if using structured data queries is too difficult, we should get the WMF to add more capabilities to Special:MediaSearch, for example, filtering by date. Nosferattus (talk) 20:48, 17 June 2024 (UTC)
@Nosferattus, structured queries are great, and you are right that categories are not queries! Unfortunately, requiring users to have SPARQL knowledge in order to search for files is, I fear, a bridge too far. We need tools to bridge that gap and bring query functionality to a broader user base before we can point to that as the answer to the problem. Josh (talk) 16:08, 18 June 2024 (UTC)
@Adamant1 That is absolutely the way it should be done, but right now the structured data just isn't there yet to make this an accessible option for a lot of users and use cases. I'm all for moving that forward. In the meantime, this issue will persist. Josh (talk) 16:05, 18 June 2024 (UTC)
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.
@JopkeB: We have a tool that allows you to find whatever you want without abusing catagories. Want to see all the photographs of snow taken on January 1, 2009? Here you go: https://w.wiki/ARP$. Just click the Run button. Frankly though, I think the use case of needing to find images of a certain subject at a certain location on a certain date is entirely made up. Who has ever actually needed this? I certainly haven't. And if we're going to diffuse by location and date, why stop there? We could also diffuse by file type, license, aspect ratio, color vs. black and white, photographer, etc. The point is, categories are a poor substitute for search queries and are not what they were designed for. But when all you have is a hammer, everything looks like a nail. Fortunately, we now have other tools, so we don't have to keep abusing categories. And if writing queries is intimidating, just ask Magnus or the WMF to create whatever type of search interface you want. The data is there. We don't need categories to redundantly encode it. Nosferattus (talk) 14:39, 18 June 2024 (UTC)
@Nosferattus, we do diffuse by many of the things you list, such as photographer, color, file type, and a hundred other criteria, depending on the topic. Scoffing at those who aren't prepared to create SPARQL queries to view what they need is not the answer. Also, no, the structured data is not all there yet, so queries are rarely complete. In theory you are not wrong...in fact a good enough database with a good enough search interface may make categories completely obsolete. We aren't there on either the data or the interface yet. If it is as easy as you claim it is, then go forward, get WMF to create the interface and demonstrate how the average user can easily use it in lieu of category browsing and maybe then you will have a valid argument to not use categories. Until then, we need categories to work for the broad user base that continues to need them. Josh (talk) 16:25, 18 June 2024 (UTC)
You do have a good point that the data and interface are not complete. However, in my opinion, they are a lot more usable than our terrible category system which is only getting less and less useful by the day, mainly due to over-diffusion. Nosferattus (talk) 17:02, 18 June 2024 (UTC)
@Nosferattus And I agree that over-diffusion is a serious issue. This is why I've floated the idea, at least in the case of the date diffusion, to remove that from the topic category tree and make it a separate tree, leaving the files undiffused in the original topic category. I see search tools as a valuable adjunct to this, in fact. I am not personally well versed in our third-party interfaces, but I would like to build a template (or bit to include in existing templates) that invokes a search to identify any files in a non-topical category that are not still present in the related topic category. This would permit easier maintenance reversing incorrect removals from the topic category. Josh (talk) 17:09, 18 June 2024 (UTC)
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)
@JopkeB, as you can probably guess, I'm in agreement of most of what you've written here as many of these ideas are things that have come op in CfDs and other forums we've participated in. I am not a fan of placing hard arbitrary lower or upper limits on category size because I find topics and structures where very large or small categories do make sense within the scope of the topic and the available media. Of course, truly bloated categories do need to be diffused into meaningful sub-categorization, preferably by multiple different criteria. They don't even necessarily need to get to 200 files to warrant this in many cases. I do see you accept some exceptions though, which is good. One issue is stating 'subcategories should preferably be topic categories, not date categories.' I think I get what you are trying to say and I agree, but the root of this discussion is based on the fact that 'date categories' are 'topic categories' at the moment, at least structurally. The main effect of this is that, per COM:OVERCAT it is in fact required to remove a file from the main topic category when adding it to a date category. This is why I'm floating the idea of breaking date cats away from the topic tree and making them their own tree, akin to media type cats, thus reversing that requirement and making it a requirement to keep the media in the topic cat when adding it to a date cat. Josh (talk) 16:38, 18 June 2024 (UTC)
I'm not a big user of date categories, though I've had to work on several of them as part of being a broad-based maintainer. Commons doesn't have an exact analogue to Enwiki's non-diffusing categories, but we do have major category trees (see major category policy) which are similar in effect, in that categories under one major category do not diffuse categories in another major category (e.g. a file in a Media types category does not diffuse from the related Topics category; the file should exist separately in both). This is why I presented the idea of creating Category:Chronological categories as a major category and making all 'by date' categories fall under this, prohibiting diffusion of the original topic category. I understand that nuking date categories would be your first choice, but appreciate your understanding that at least making them non-diffusing is an improvement that should be made if they are to be retained. Josh (talk) 17:21, 18 June 2024 (UTC)
I also support this idea. Whether we ultimately keep these date-based subcategories or not, infusing their contents back into parent categories is a clear step in the right direction. Omphalographer (talk) 17:21, 18 June 2024 (UTC)
Support the idea in absence of a better option like moving dates to structured data. The whole thing just seems circular though. We don't fully embrace SDC. So it's not properly implemented, naturally leading to lower adoption rates Etc. Etc. I'd like to at least see a realistic plan with some implementable steps to move in that direction. Along better guidelines and enforcement around these kinds of things. Although admittedly both are tangential to the current problem and I have no issue with Josh's idea in the midterm. --Adamant1 (talk) 21:20, 18 June 2024 (UTC)
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. DarwinAhoy!17:50, 19 June 2024 (UTC)
@Ghouston You were more visionary I guess. It is indeed a problem that isn't always apparent until it has grown into a real monster. Regardless, I've seen it really come to a head in a lot of different topics over the last year or two and while we can't go back to 2013 and fix it then, we can do something now. I've created Category:Chronological categories as a base and a corresponding CfD to get input over there, but it sounds like a lot of support for not allowing diffusion by date to remove the files from non-date topical categories. Josh (talk) 17:42, 21 June 2024 (UTC)
What to do in this case
While we continue to discuss broader issues, I'd like to get some consensus as to what should be done in this specific case. AnRo continues to create hyperspecific categories such as Category:Spring 1951 in Boston, many of which have very few files, and they have not responded here nor at their talk page since this discussion began. To my mind, this is now an administrative matter - disruptive editing and a refusal to communicate - that needs action. Pi.1415926535 (talk) 18:03, 18 June 2024 (UTC)
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)
The comment in support of this proposal was: "I would like to replace it with this icon being more modern and slightly more accessible" by Manjiro5
As the template talk page is unlikely to get much traffic to comment on this, but the template is widely used, I am putting it out here on the VP for comment before we move forward with the edit request. Josh (talk) 17:33, 21 June 2024 (UTC)
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 ! talk06:05, 5 June 2024 (UTC)
Now up to 1165 categories. I have the feeling almost no one is addressing this. I've done literally thousands, probably over 5000, and while I still try to do 50 or so per week, that is not enough to keep up. - Jmabel ! talk17:53, 10 June 2024 (UTC)
@Jmabel: I did a few today and about once a month a small portion.
Question Is it a good idea to have the numbers next to the categories, like in other pages? Then you can see at a glance which are empty and not bother about them (for none admins like me) or to be able to remove them in quick succession (for admins). JopkeB (talk) 07:50, 15 June 2024 (UTC)
Wouldn't that be nice? As it is, in case you haven't noticed, you can hover over the link and see whether there are files in the category. - Jmabel ! talk14:56, 15 June 2024 (UTC)
No I did not notice and I still do not see it. When I hover over a link, I see only the category name, for instance Category:Activité supplémentaire bibliothéquaire, but nothing else. JopkeB (talk) 07:31, 18 June 2024 (UTC)
Weird that you get a different behavior than I do. So you don't get a thing like this in the popup?
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
The nice thing about this SVG is that the text is actually stored as text and not as image, lines or separate characters. Enhancing999 (talk) 16:49, 23 June 2024 (UTC)
Redlinks to existing pages
Sometimes links to existing pages lead to a Creating page, as if the page did not exist. Currently I have a case like that in Template:GDR propaganda navbar, namely the military link. It should lead to Category:GDR Propaganda; military. But when I click on it, I am told, that I can create the page. (Not sure what would happen if I do.) The other links also turn black, when they lead to the current page. This one does not. Can that be fixed? Watchduck (quack) 17:14, 23 June 2024 (UTC)
The color is reserved at WMF sites for a specific type of wikilink. Apparently here the color scheme even confused its creator. Enhancing999 (talk) 18:50, 23 June 2024 (UTC)
MIDI file transcoding
Hi, I've uploaded some MIDI files of chords to Commons (e.g. File:3-4A set class on C.mid) which I need for en:List of set classes, and I gather that eventually Ogg and MP3 audio files are generated. How long do I have to wait? Or, is there some arcane incantation I need to perform that I've missed? Or do I need to add it to a queue somewhere? Is there some documentation somewhere that I can read about it if so? I have so far not found anything. — Jonathanischoice (talk) 22:06, 24 June 2024 (UTC)
Who actually belongs in this category? Looking at the images placed here it looks completely random and quite frankly arbitrary. Most of the people located here are not even working in media Trade (talk) 08:42, 22 June 2024 (UTC)
Personal opinion: It is limited value trash, though it is long existing trash that seems to have been accepted and have subsidiary categories. — billinghurstsDrewth12:33, 22 June 2024 (UTC)
Depending on the definition every person who is notable for a own category on Commons could be in that category making it completely useless. GPSLeo (talk) 13:32, 22 June 2024 (UTC)
My preference is for Category:People. Looking at the setup of both categories it's where you can reasonably find what you're looking for. When I think celebrities I think actors, athletes, even influencers. All of those are categorized elsewhere. This is like having two sock drawers but one doesn't even have any socks. ReneeWrites (talk) 16:13, 22 June 2024 (UTC)
Comment I think that it can be argued that the category should have no people listed directly as they would fall into a specific subsidiary category, and probably no images. If they are that much of a celebrity they get their own category which is linked to wikidata. If they are not that much of a celebrity, they are failing. — billinghurstsDrewth14:15, 22 June 2024 (UTC)
Hi, I support deletion of this category, although it is useful as a honeypot to catch copyright violations and vanity images. Yann (talk) 16:19, 22 June 2024 (UTC)
this strange way of creating a "street (Berlin)" has one bad effect. if i type "cat:Schillerpromenade", uploadwizard/hotcat will show me both Schillerpromenade (Berlin-Neukölln) Schillerpromenade (Berlin-Oberschöneweide) as well as Schillerpromenade (Berlin), which confused me (why is there a cat for berlin when there are also two more specific cats?). RZuo (talk) 20:31, 23 June 2024 (UTC)
"having the same name as" is probably kind of a Berliner specialty, as Berlin is probably world's one of few (if not the only one) capital where certain street names are being used more than once.
The only practical usefulness of this scheme is (IMO), that it can be sorted in parental categories which refer to the name itself (such as Category:Schiller streets in Germany) as a whole, instead of putting each street category into it (usually with the result that some streets are in and some not). Regards --A.Savin12:18, 24 June 2024 (UTC)
Plenty of these in NYC (where numbered streets in Manhattan and Brooklyn are completely unrelated; I believe the ones in the Bronx do relate to the Manhattan grid). I suppose it's technically not a capital, but it's a bigger city than Berlin.
Seattle, where I live, is loaded with streets that are distinguished only by a directional, and may or may not be closely related. First Avenue S is a continuation of First Avenue, but First Avenue NW and First Avenue NE are not. Burke Ave N is basically a line on the map and refers to 7 unconnected streets that fall on that line; there is a Ravenna Ave NE (in two unconnected pieces), Ravenna Pl NE, and an (also discontinuous) NE Ravenna Boulevard (none of which intersect each other, and one of which -- Ravenna Ave NE -- is mostly not in the Ravenna neighborhood). There's a rather famous corner of Pike Place and Pike Street in the heart of Pike Place Market, but it's beaten for sheer confusion by the corner of Bellevue Avenue E, Bellevue Place E, and Bellevue Court E. - Jmabel ! talk18:56, 24 June 2024 (UTC)
I am using MacOS and Safari, and have tested in Chrome too. I also had a friend test on their Linux machine who confirmed the mp4 files had no sound when streamed or downloaded.
These were originally mp4 files, converted to webm using HandBrake before uploading. The originals play fine for me, but the mp4's on Commons seem to have lost their audio. — Preceding unsigned comment added by Jimmyjrg (talk • contribs)
It may be worth noting that on 19 June, @Jimmyjrg began uploading many video tutorials claiming "own work" and releasing as CC-BY 4.0, when indeed these are derivative works which depict live Wikipedia pages, including text, WMF logos, and images, some of which are in the Public Domain. The latter PD status clearly overrides any ownership, license claim, or Creative Commons licensing. I am concerned, but given their veteran status, perhaps Jimmyjrg can independently rectify the license status for these videos (I count 27 as of this writing). I am unsure of which templates/licenses are applicable, apart from {{Copyright by Wikimedia}}. Elizium23 (talk) 04:42, 24 June 2024 (UTC)
@Elizium23: I'm not sure what you are saying here. I haven't looked at the videos. Insofar as the videos incorporate (without licensing) images that are not public domain the licenses need to be indicated, but a video can incorporate public domain content to whatever degree its creator wishes. That is the nature of public domain (although a few countries recognize "moral rights" independent of copyright that require giving credit for some public-domain content). Public-domain status is not "viral". I could make a video that consisted of juxtaposing a series of 100 public-domain images each shown for one second; my video would certainly be eligible for copyright, even though no one image in the video is copyrightable. In other words, to paraphrase but reverse you: PD status of images in a video does not override a copyright claim for the video as a whole. - Jmabel ! talk05:22, 24 June 2024 (UTC)
@Jmabel, you're correct, of course. I certainly did have that backwards. I've struck out the offending remark. But I stand by my claim that these videos are derivative, and incorporate plenty of content that belongs to the WMF and to other Wikipedians, and all content demands attribution by their applicable, existing CC licenses. Elizium23 (talk) 05:28, 24 June 2024 (UTC)
Hi @Elizium23: thanks for bringing this to my attention. It looks like I have completely misunderstood how licensing works for instructional videos. I'll reach out the WMF team members I've been talking with about this project, and I'll amend the licenses asap. Jimmyjrg (talk) 00:01, 25 June 2024 (UTC)
@Koavf I uploaded webm videos, but on the Commons file under 'Transcode status' there are links to mp4 files to stream or download. These are the ones I have found have no sound. Jimmyjrg (talk) 23:56, 24 June 2024 (UTC)
Can anyone say what is the equipment in the background here? I'd like to add further description and appropriate categories. - Jmabel ! talk23:32, 24 June 2024 (UTC)
@Glrx: Yeah, that's a bit like what it looked to me as well, though you have a much more closely matching example. If it's correct, it raises a question of what two Seattle City Light employees were doing posing in front of telephony equipment, rather than equipment involved in the generation of transmission of electricity. But if we can be confident that is the case, I guess we don't have to solve the "why". - Jmabel ! talk05:01, 25 June 2024 (UTC)
Voting to ratify the Wikimedia Movement Charter is now open – cast your vote
The voting to ratify the Wikimedia Movement Charter is now open. The Wikimedia Movement Charter is a document to define roles and responsibilities for all the members and entities of the Wikimedia movement, including the creation of a new body – the Global Council – for movement governance.
Voting commenced on SecurePoll on June 25, 2024 at 00:01 UTC and will conclude on July 9, 2024 at 23:59 UTC. Please read more on the voter information and eligibility details.
After reading the Charter, please vote here and share this note further.
If you have any questions about the ratification vote, please contact the Charter Electoral Commission at cec@wikimedia.org.
New changes to the "Depicts" step in UploadWizard available on Beta Commons
Hi all! I wanted to announce that on Beta Commons a new version of the "depicts" step of UploadWizard is available for testing.
A brief note about the changes:
basic "depicts" annotations (and other statements set up in campaigns) without qualifiers or references can now be added on the same page where the user is entering captions, locations, etc
the separate extra page for adding structured data is removed from UploadWizard
qualifiers and references can still be added on individual File pages as before (and that will take only one extra click)
The reason for us doing this is that we're hoping that by simplifying depicts annotations we'll make it easier to spot copyvios (and in particular FoP violations). The drawback from a user perspective that we already know of is mostly for users who might be uploading multiple images at once with non-depicts statements and/or qualifiers and references, and copying those from the first image to all other images in the upload. This functionality is no longer available - as far as we can tell it's not used much, but if there are people using it then we'd like to hear from those users who use it.
Why does the Main subjects visible in this work (optional) label have a “pointer” cursor? Clicking it doesn’t seem to do anything (it doesn’t focus the input field).
Why will this only be available until Monday afternoon?
It'll be available until Monday afternoon because we have to revert it by Monday evening, otherwise it automatically goes to production. If there's demand for more testing we can re-enable it on beta on Tuesday (until the following Monday) CParle (WMF) (talk) 14:09, 19 June 2024 (UTC)
I think this change has a lot of potential!
Regarding adding more structured data with "one extra click", I think there should be a button for that on the last page of the wizard (next to each uploaded photo).
Why do you call it "Main subjects visible in this work" when the values are used in a depicts statement? I think inconsistent terminology creates confusion.
I think the created depicts statements could be automatically marked as prominent ("The most prominent subject(s) depicted in this work").
Do you (or do you plan to) suggest categories based on the chosen Wikidata items?
There's a link to the File page for each image on the last page, and that's where you can click the "structured data" tab and add extra structured data. We actually talked on the team about adding another link directly to the structured data tab, but weren't convinced that the extra clutter on the page was worth it
We're calling it "Main subjects visible in this work" because we weren't sure if new uploaders would understand "depicts" (we had a lot of discussion about the exact wording). Open to other suggestions if you have them
I'm not sure this is really necessary, but if there's community demand for it we can certainly do it
It's an interesting idea, but likely to be a lot of work to figure out how to do that (and it's not on our roadmap atm)
@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. DarwinAhoy!17:37, 19 June 2024 (UTC)
@DarwIn you actually can still copy "depicts", just not other statements (or qualifiers/references)
Freedom of panorama copyvios are the most common reason for deletion requests on commons (see here https://phabricator.wikimedia.org/T340546). What we're hoping is If someone uploads a picture of, for example, Burj Khalifa then they'll add depicts:Burj Khalifa, and we'll be able to spot the FoP violation automatically
Note that we don't propose to take any automatic action right now, but we're working towards better automatic detection of files that are likely to get deleted CParle (WMF) (talk) 13:58, 20 June 2024 (UTC)
@Sannita (WMF): I tested out the changes and it seems like an improvement. Two tangential issues though:
Why is UploadWizard only setting the depicts statement? Why not also set inception, media type, and copyright status? You can get those for free from the existing fields.
Phabricator bug T261764 makes using the depicts interface error-prone and confusing, especially for newbies. Is there any chance that the Wikidata folks could help fix that?
@Nosferattus Hi, thanks for your messages. Sorry it took me so long to answer, but I was caught in other urgent stuff, my bad.
We're working on adding inception (phab:T362328) and coordinates of the point of view (phab:T368381) to the properties that users can add, it's going to need some time but it will be done. Other properties are already added automatically via bot, so they could be added, but since this is already taken care of by a bot we're not considering them a priority -- that is, unless there is consensus from the community to make them available.
I don't know, I'll try to contact them and ask them about it, but I can't promise you anything about this. I know for a fact that scientific articles will be split from the main graph when doing queries, but I don't know if this will affect Structured Data too.
Is there something like TinEye or Google Image Reverse Search for Wikimedia Commons?
Does Wikimedia Commons have a function where I can input image files and search if any similar-looking images have been uploaded on Commons? --MaplesyrupSushi (talk) 02:24, 23 June 2024 (UTC)
I don't see a duplicate search button there, is enabling a gadget needed for that? I just have a firefox addon by which one can right click to reverse image search. However, the proper approach to this would be, as suggested earlier, create a script/bot that scans through all the WMC files to find likely copyvios and e.g. put them all in a category for them to be reviewed rather than a huge time-sink of reverse searching individual images manually. Prototyperspective (talk) 09:11, 23 June 2024 (UTC)
Any reason not to just use Google Image itself and look for images on Commons?
It might help if you said what is the issue you are trying to solve for which you want this tool. There may be a way to solve it other than the specific way you are suggesting. - Jmabel ! talk18:17, 23 June 2024 (UTC)
If I understood you correctly, that is only about duplicate files within Commons but I was saying there needs to be a Tineye/GoogleImage reverse search bot that identifies files that are likely copyvios needing manual review.
Also I don't know why Jmabel replied beneath my comment because he seems to to address Maplesyrup, not anything I wrote if I'm not mistaken. Prototyperspective (talk) 12:38, 24 June 2024 (UTC)
I see, thanks, the Category:Duplicate besides being a hidden cat, is put there by a human. So it doesn't help anyone on this thread.
Interestingly the very first such image I looked at, was wrongly catted, as a duplicate. This file is anything but a duplicate, I have reverted that edit. - Broichmore (talk) 10:33, 24 June 2024 (UTC)
@MaplesyrupSushi: For the kind of artwork, you’re doing, its essential to attribute the artist/s, the publisher, and the true originating owner museum (the true source of the image) that's step 1.
Next, it's search through commons, using different search terms, and variations on the artists name, till you have the category for the particular artist complete. Should you have missed an image it’s not a problem.
This is because 18th and 19th century Lithographs and engravings are all unique, even if they come from the same book and edition, they are different, that’s why provenance and ownership is important, they are different in terms of condition and hand painting, and they should not be overwritten by anything other than the exact same print, from the same book, in the same museum.
Ranjeet Singh and his bolster image discussions are proof of that.
Your problem is not really solved by using google and TinEye, very often the exact original title searched for using simple SQL syntax will uncover more of the same item, here and on the internet. As the images are unique, as described, the checksums differ to, they can be too difficult for even google to cope with.
Variations of the same print are something we want! Degraded duplicates of the same image are not.
I have to say that engravings from Victorian newspapers, and 18th and 19th century lithographs on commons are routinely uploaded regularly with scant regard for any of the above. If they were obviously modern images they would be deleted on sight.
As we discussed before, quality of the source of the image is critical, I can't think of a worse source than the Panjab Digital Library, and because most of the images are PD, there's a multitude of real honeys out there. Broichmore (talk) 20:23, 23 June 2024 (UTC)
@MaplesyrupSushi I forgot to mention two concepts to you, that enable search in commons.
Firstly, all these files (we have of paintings, engravings, historical photos) need the Artwork template. The essential fields to fill in, are: the artist, the title (as given by the publisher or artist), the date (of publication, creation, in the description field all of the available captions or at least the relevant keywords from it, the institution owner. Nice to have's are the medium, and dimensions.
Finally, secondly, the museums Accession number, (for the British Library that's the shelfmark number). Any other given numbers can just go into the description field.
This last item the Accession number is critical, because commons has bots, that occasionally scrape museum sites, and it looks for that number, if the bot cant find it, it will upload a duplicate. The minimum cats are the artist, and engraver (or publisher if not available). Nice to have's are the museum source collection, and the most pertinent descriptive cat.
Sikh images and Indo, Pakistani original art can be a problem, for these images you can only fill out what you know, but I think you'll find that on finding an image, you will find variants elsewhere that will provide the bits and pieces you need. Be aware that some sites strip this information out, they are in the business of selling prints for decorative purposes, academia means nothing to them, they don't pay out against copyright claims unless challenged. Their defence being that to the best of their knowledge the items are PD, something which they don’t highlight on their sites.
It goes without saying that licencing is essential for uploading, for your stuff that will come with PD USA. The uploader is not the author, the license is always an art one.
I have been working with indexing commons photos images using imagehashes. Current status is that I have 70% of jpg/png/webp/tiff images indexed and there is REST api for querying hashes. However, currently there is no web interface for querying commons images by files or urls as my focus has been on indexing and publishing the database and not yet in the web UI. (see proposal, github). In any case if you have immediate need I could add minimal web form interface for querying commons images using files/urls to toolforge if there is need for that. --Zache (talk) 12:16, 24 June 2024 (UTC)
@MaplesyrupSushi I wrote a minimal web ui for Imagehash.toolforge.org (example queries: 1, 2, 3) It also allows to upload files but that is little bit slow. Another caveat is that it works better with larger files (ie. over 800x800px than with very small thumbnails.--Zache (talk) 08:35, 26 June 2024 (UTC)
I'm unable to use CropTool at File:1983. Febrero, 22. Recibimiento del cardenal José Alí Lebrún.jpg. When clicking directly from the toolbar, I'm directed to CropTool's main page, being asked to enter the file's URL or name, after which I'm confirmed that the file exists but I'm not able to crop it. The tool works perfectly in any other file I have found.
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)
It could be used to artificially cause a scope loop between Commons and Wikidata. AFAIK, Wikidata is the only Wikimedia website where an item can be in scope for no other reason than because it links to a page on Commons. A file about a person can be in scope on Commons if the file can be potentially useful to someone somewhere in a very broad educational sense, even if there is no page about that person on any other Wikimedia website. But that doesn't go so far as to include photos of non-notable persons in non-relevant contexts. Of course, a file about a person can be more easily assumed to be in scope on Commons if another Wikimedia website has a page about that person. (N.B.: that question is different and independent of the question of whether a file is in use or not on another Wikimedia website.) That makes sense based on the assumption that the other website has independent notability criteria. But that does not make sense when the only inclusion criterion being met on Wikidata by a person is that the Wikidata page links to a page on Commons. -- Asclepias (talk) 15:16, 16 June 2024 (UTC)
'Wikidata, has nothing to do with defining scope for Wikipedia or commons. Look to the policies for both projects separately to ascertain what is scope. There are differences, minor ones perhaps. Generally speaking, if it passes the scope test for Wikipedia. it will be okay for commons too, as the latter is marginally more liberal. As far as we are concerned, Wikidata is a tool, and nothing more. Broichmore (talk) 16:35, 16 June 2024 (UTC)
I'd think yes. I noticed in a recent cleanup exercice some stuff got tossed that was in use there, but that seemed relatively marginal. Enhancing999 (talk) 22:29, 16 June 2024 (UTC)
It seems to me that the only times an image that is used to illustrate a Wikidata item would be appropriate to delete on a "scope" basis would be (1) the Wikidata item shouldn't exist, which should first be dealt with on Wikidata or (2) the image does not meet Wikidata's criteria for images illustrating an item, which should first be dealt with on Wikidata. And, no, I wouldn't defend the case where the only justification for the Wikidata item is that the Commons image exists and vice versa.
@Broichmore: are you saying (above) that it would be appropriate do delete an image that is legitimately in use on Wikidata, or just that the presence of a Wikidata item is insufficient to justify having other images of the subject in question? I'd agree with the latter: I believe there are cases where there are Wikidata items for every name on a war memorial or every person buried in a particular graveyard. That would merit hosting a single image of any of these people to support Wikidata, but would not mean that we would want an open-ended number of images of each such person. - Jmabel ! talk23:44, 16 June 2024 (UTC)
As your all too aware, criteria for uploading images on commons centres on copyright (we want only PD), modified by notability, the emphasis on the former.
In Wikipedia, it's possible to upload a non-PD item (using, the fair use parameter), if there's no other image (of even dubious suitability) available. Even so, the item then needs to be degraded so it's worthless commercially. Only items, most representative, are entertained. A pix of the ship. The person's face. an LP cover. An actual passport style portrait of the item.
Wikidata says it wants an image of (the) relevant illustration of the subject; if available, use more specific properties (sample: coat of arms image, locator map, flag image, signature image, logo image, collage image);only images which exist on Wikimedia Commons are acceptable. In other words only PD and no fair use.
Briefly, again, wanted images for the Wikipedia infobox and wikidata are passport only portraits, in that spirit I've been known to crop out portraits for that purpose. This example was used for both projects. That portrait will be replaced, only when better surfaces.
Wikipedia carries only one pix in its infobox, and so should Wikidata, however the latter can carry more. Perhaps a persons facial image, representative from different stages of their life. There's no real limit. I don’t think this has actually been tested, by abuse yet, the tacit acceptance is, use only one image, perhaps two, following Wikipedia guidelines.
Wikidata’s scope for inclusion is immense in comparison to WP and commons. Briefly an item should be represented by at least one valid sitelink to a page on Wikipedia, Wikivoyage, Wikisource, Wikiquote, Wikinews, Wikibooks, Wikidata, Wikispecies, Wikiversity, or Wikimedia Commons. ’’Note it refers to itself, it’s a bit woolly. But it wants to tag everything useful in the world. Read the policy here.
As I see it, Wikidata has three uses for us, first our infobox, containing the variables that dictate licensing, secondly (for an artist, if there's no WP article); locations of work by time period, useful for correct attribution, and third, disambiguation of artists or place names. Broichmore (talk) 11:07, 17 June 2024 (UTC)
It doesn't help there that the user whose contributions are largely at issue keeps cycling back and forth between reasonably serious arguments, ad hominem remarks, and remarks that seem entirely intended to derail the discussion. But I stand by what I wrote above: circular justification doesn't cut it; a Wikidata item can justify keeping one photo on Commons that would otherwise be deleted, to function as an image for that item; and it isn't up to us on Commons to decide whether the item meets Wikidata's (generally lower) threshold of notability. - Jmabel 01:09, 17 June 2024 (UTC)
The "scope loop" breaks on the Wikidata side. Per d:Wikidata:Notability, "Category items with a sitelink only to Wikimedia Commons are not permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as category for pictures taken with equipment (P2033)". Commons can expedite the cleanup of objects involved in these loops by ignoring media uses on Wikidata which only refer back to Commons. Omphalographer (talk) 23:56, 16 June 2024 (UTC)
Concur. WD item creation that is involved with the uploader/creator in sequence within the same timeframe, and otherwise fails their notability (articles or independent linkage) is not "in use" (image or category). If it is borderline, or where I am in doubt, I will nominate there for deletion with appropriate commentary, and then nominate the image here with a DR, so we can do some follow-up (our DR review takes longer than theirs). That is pretty much what I will do for a draft article where it is dodgy and reeking of COI at the WPs. — billinghurstsDrewth04:38, 17 June 2024 (UTC)
@Omphalographer: that seems more of a technicality about WD than something germane here. It's specifically about Category items. That just means that if you are making up (for example) an item about Person FOO and the only Category:Person FOO is on Commons, you can make an item about "Person FOO", but not about "Category:Person FOO". - Jmabel ! talk06:38, 17 June 2024 (UTC)
@Jmabel, actually, you could, if "Person FOO" is sustainable itself. The item for "Category:Person FOO" is allowed per criteria #3 as structurally required as the topic's main category (P910) for the former item. What is not allowed is if "Person FOO" does not exist on Wikidata, and you solely wanted to create an item for "Category:Person FOO" with the only sitelink being to the Commons category. That would fail all three of the criteria for notability there. Of course, as you stated, this is all applicable to Wikidata alone and has no real relevance to Commons, except that you probably shouldn't add {{Wikidata infobox}} to "Category:Person FOO" without a valid corresponding Wikidata item. If that category is a valid Commons category, we certainly should not delete it just because it does not support a Wikidata link. Josh (talk) 17:08, 17 June 2024 (UTC)
@Joshbaumgartner: No. I have no idea of your level of experience on Wikidata (and feel free to correct me if that experience is extensive, and you can provide examples of something I've never seen), but in my experience no one goes around creating a "category" item just to use it within Wikidata for a topic's main category (P910). Otherwise, every item would get a corresponding "category" item. Hell, every category item could get a corresponding, totally useless "Category:Category" item, etc. ad infinitum. Until a "category" item is justified by the existence of categories on some sister project other than Commons or Wikidata itself, it should not be created. - Jmabel ! talk19:29, 17 June 2024 (UTC)
Why in the world would anything require a "Category:Category" item? That doesn't make any sense. I honestly have no idea what tangent you are off on here. Wikidata supports an item for the Topic (with sitelinks to articles and galleries) and an item for Category:Topic (with sitelinks to category pages). The Category:Topic item doesn't need any more than the sitelink to its Commons category to be valid according to WD:Notability. By the way, I wouldn't make any personal claim of being especially experienced at Wikidata, I only have 750,000+ edits there and have been a property creator since they were still in double-digits, but my lack of experience is moot, WD's notability guidelines don't require an experienced editor to understand. Josh (talk) 01:41, 28 June 2024 (UTC)
@Joshbaumgartner: Please don't take my reductio ad absurdum for a serious proposal! Quoting the very page you mentioned, wikidata:WD:Notability: "Category items with a sitelink only to Wikimedia Commons are not [emphasis mine] permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as category for pictures taken with equipment (P2033)." - Jmabel ! talk02:29, 28 June 2024 (UTC)
@Jmabel Fair enough, but I'm curious why you are intentionally re-quoting that section out of context. Why are you not indicating honestly that the section you quoted is only a sub-section of criteria #1 in the notability test and additionally that an item only needs to pass 1 of the 3 notability criteria to pass Wikidata's notability guidelines? Re-quoting this section without that context as if it were some overarching rule that applied to all notability tests is misleading in the extreme. I was a bit disappointed at seeing this from you, as I expect a higher standard from you, Jmabel. I'm assuming good faith in that you did not intend to be misleading, but hopefully you are willing to correct this oversight? Josh (talk) 02:41, 28 June 2024 (UTC)
@Joshbaumgartner: I don't believe that was out of context; I certainly wasn't going to quote the entire page. I normally respect your work, but I honestly cannot work out what you mean here. Are you saying that every Wikidata item A should have a corresponding Wikidata "category" item B just so B can be linked from A with topic's main category (P910), when B serves no other use? If so, then we are back to the absurd infinite regress I laid out: by that same logic B can also have a topic's main category (P910) linking a (ridiculous) "Category:Category" item C, etc., etc., etc. If you were saying neither that nor that the Commons category is enough on its own for Wikidata notability, I honestly cannot see what else you could have meant, but please feel free to elucidate. - Jmabel ! talk03:27, 28 June 2024 (UTC)
@Jmabel You do seem fond of trying to reduce things to absurdity instead of dealing with what is actually being said. No one asked you to quote the whole page, and no one has proposed or done creation of "Category:Category:Cate..." items. Do you really think that no "category item(s) with a sitelink only to Wikimedia Commons" can ever pass notability, or do you agree that clause only applies in some circumstances, and that in many instances, "category item(s) with a sitelink only to Wikimedia Commons" are perfectly valid per WD:Notability? You quoted the clause as if you believe the first case, that it is an absolute rule, as you intentionally (per your admission) omitted providing any context to the quote. Which is it? Josh (talk) 03:54, 28 June 2024 (UTC)
@Joshbaumgartner: Here's my understanding. Again, I may be wrong, but I haven't seen a counterexample. As noted within what I quoted there are two cases where there can be a valid category item where the only corresponding category is on Commons. (1) There is a corresponding Commons gallery (in addition to the category). (2) There is a structural need for the category for a Commons-related statement (but the example you gave of topic's main category (P910) does not constitute such a structural need). But that's it. Other than that, a "category" item is justified only by having a category on a sister project other than Commons. Or to put it another way, there are exactly three cases that justify creation of a "category" item:
There is a corresponding category on a WMF sister project other than Commons.
There is a corresponding category and a corresponding gallery on Commons.
There is a structural need for the category for a Commons-related statement.
If there is a valid "category" item that does not meet one of those three criteria, I'm not aware of it. Can you give an example? - Jmabel ! talk04:15, 28 June 2024 (UTC)
Or are you just talking about things like the item for the separate category for the name of a ship? Yes, of course those are OK, because the Wikidata modeling approach requires them. - Jmabel ! talk05:09, 28 June 2024 (UTC)
So yes, you can have a Category item where the only sitelink is to a Commons category. Thank you for agreeing on that point. Your assertion that somehow topic's main category (P910) doesn't count as a structural need is rather silly and made up, but whatever, it doesn't matter for this conversation. All we care about on this side of the fence is that yes, sometimes a Wikidata category item will exist with the only sitelink being to a Commons category and so if we are going to base our scope policy in any part on the existence of such an item (I disagree with doing so, for the record), then we have to keep that in mind. Josh (talk) 05:14, 28 June 2024 (UTC)
@Omphalographer, note that only applies if attempting to sustain notability under criteria 1 (i.e. solely on the basis of a sitelink). If an item qualifies under criteria 2 or 3 (i.e. is a "clearly identifiable conceptual or material entity that can be described using serious and publicly available references" or "fulfills a structural need"), the exclusion of 'items with a sitelink only to Wikimedia Commons' is not applicable. Josh (talk) 16:58, 17 June 2024 (UTC)
For people, I think it'd be acceptable to declare as in scope those items with an identifier that may presume the subject is notable or relevant, such as those of National Libraries. Bedivere (talk) 20:41, 20 June 2024 (UTC)
@Bedivere That's an issue for WD to decide. I am pretty sure anyone with an ID from a recognized authority (i.e. one with a relevant ID property) is going to be considered in scope on WD. Josh (talk) 01:44, 28 June 2024 (UTC)
@Omphalographer The "scope loop" ought to be broken in Commons policy too so that we can achieve the right result on a file here without having to wait for an action in another project. Consigned (talk) 23:21, 21 June 2024 (UTC)
@Consigned: strongly disagree. Legitimate use on a sister project should be sufficient reason to consider an image to be in Commons' scope, and we should not be in a position to dictate to other projects what we consider legitimate for them. Commons is, as much as anything else, a repository for images required by other projects. Wikidata, for example, does not host images itself, and completely relies on Commons to be its image host. - Jmabel ! talk02:03, 22 June 2024 (UTC)
You could argue that images are tangential, if not completely at odds, with the purposes of Wikidata as a project though. I don't think the same could be said for Wikipedia since encyclopedias historically included images, but there's nothing about tabled or linked data that has anything to do with media. In most cases it has absolutely nothing to do with Wikidata being a "knowledge base of structured data" or whatever. I don't think we are obligated to host an image of something, let alone specific types of media, just because someone creates a Wikidata property or item for it either. --Adamant1 (talk) 02:26, 22 June 2024 (UTC)
@Jmabel: If item on WD is within their scope and the notability, then yes, any image is reasonable. That said, there are many who upload an image, then create an item there as self-promotion, so in those cases it is not reasonable to retain. Solely having an item there, and having an image here used there, should NOT be the sole criteria, we need to have a little investigation. We cannot have each site be a blocker to the other resolving spam and self-importance. — billinghurstsDrewth12:38, 22 June 2024 (UTC)
@Billinghurst: agreed on the problem, but Wikidata, not Commons, is where you have to fight to say something on Wikidata is not valid use. Yes, every sister project is in this sense a "blocker" because we are here, among other things, to serve those projects. Again, we can consider something spammy, but it is up to Wikidata to make their own determination about their notability threshold, which is a low threshold. Having an item exist on Wikidata isn't an argument to keep 14 photos of that subject; it isn't an argument to create a category for that subject; but it is an argument for keeping the photo Wikidata is using. If Wikidata decides that the subject is above their threshold of inclusion, then the are entitled to have one photo of it, and Commons is the only place that can be hosted. - Jmabel ! talk16:54, 22 June 2024 (UTC)
@Jmabel: Please do not make this into a Gordian knot or an ouroboros; WD is also here with a level of serve the projects, hence their first point in d:Wikidata:Notability. NOTABILITY 1a) For an item to be notable at Wikidata there are numbers of hoops, and the main one for that is that a SITELINK exists. NO files at Commons are sitelinks at WD, that is only to galleries and categories, and that is the zone that we control. [Note that having an image is not a notability criteria.] 1b) The item has to have a range of other criteria including links to other items, and links to the item. 2) We are all editors at Commons and Wikidata, so I am more than comfortable identifying an abuse of process of the two, and ask for the file to be deleted, and for the WD item to be deleted. At this end, I have more investment in the deletion process and involve myself from both sides, and both methods DR and Speedy; whereas I leave things up to them for their processing. 3) If there is a level of wait for their processes to flow, then I nom there, and DR here with comment about awaiting resolution at WD and we have enough lag that it will resolve one way or the other. Imperfect, though it gets rid of most dross. At that point, if they make the decision to keep, then so do we. It doesn't prevent us having some rigour and challenge the dross. — billinghurstsDrewth23:43, 22 June 2024 (UTC)
This is (or at least started out being) a discussion about deletion of files, not about categories. Of course we can get rid of a category even if it corresponds to a Wikidata item. Similarly, in theory, we can get rid of a category even if it corresponds to an article in the English-language Wikipedia, or in any number of Wikipedias, though we seldom do, even for categories with only one photo. But (barring copyright issues) we should not be the ones to get rid of a file that is being used by a sister project without first resolving that use on the project in question. And, yes (give or take a few people who are blocked) people here on Commons may participate in whichever of these sister projects they choose, but these projects are distinct overlapping communities that do not always reach the same consensus on everything. - Jmabel ! talk00:16, 23 June 2024 (UTC)
Wikidata has what they concurred to be a "common sense" conflict of editing policy. They are regularly deleting conflicts of interest, and components of self-importance. An image uploaded here and an item created at WD by the same person and neither has an editing history at Commons or WD, clearly aligns with the F10 criteria here, and there should be a deletion process. There is no 100% purity, so applying good sense to interpreting our clear principles here and there, and let the community manage attempts to abuse us. The UDR process is here to be used by anyone who thinks that there is a mistake, so we can have resolution as required. We are never going to be perfect, and we have a resolution process. — billinghurstsDrewth01:47, 23 June 2024 (UTC)
"Stained glass" versus "stained-glass"
It seems like the usage of a hyphen for categories having to do with images of stained glass is all over the place. The main category and Wikidata are named without a hyphen but then it seems to quickly break down from there with a good portion of sub-categories using one. Personally I prefer no hyphen, but there seems to be a consensus at least in how many use it versus don't that it's the preferred way of naming things. Anyone have a preference or know which is better? Adamant1 (talk) 22:26, 26 June 2024 (UTC)
"stained glass" as a noun, "stained-glass" as an adjective (e.g. "stained-glass window"). We had this discussion a few years ago, and that consensus was pretty clear. - Jmabel ! talk04:45, 27 June 2024 (UTC)
@Adamant1: No. The category Category:Stained glass is correct: a single adjective ("stained") modifying the noun "glass". There is no ambiguity about what "stained" modifies: it modifies the noun "glass". The category Category:Stained-glass artists is correct. The adjective "stained" should modify "glass", and that is signaled by using the hyphen. If there were no hyphen, then "stained" might modify "artists". Glrx (talk) 02:59, 29 June 2024 (UTC)
Community Wishlist Survey is now Community Wishlist
Thank you everyone who has participated in the restructuring and rebranding conversations of the Wishlist so far.
Regarding the renaming, based on your feedback, we will keep the 'Community Wishlist' and remove 'Survey'.
Please read more about the renaming, check out the vote results and learn more about the re-opening of the Community Wishlist on July 15, 2024, in our latest update. –– STei (WMF) (talk) 20:20, 28 June 2024 (UTC)
License template request: AGPLv3 only
Could someone create the license template Template:AGPLv3 only? We currently only have Template:AGPL, and that's not acceptable for files that don't use the "or any later version" clause.
I'd create the template myself, as I need to upload a an AGPLv3-only file, but I have no experience with template creation (or even mimicking in this case; inspecting the source didn't help me much).
It also occurred to me that there might be some files incorrectly marked as AGPL, since the correct license tag doesn't exist and apparently never has, so the logical step for the lazy is to just use the AGPL template and be done with your upload (which I'll also do, though I'll change the license to the correct one once someone creates the template). --Veikk0.ma (talk) 23:58, 28 June 2024 (UTC)
A new research report on Cross-wiki uploads have been published
Hello all! I'm happy to announce the publication of the UX research report called "Cross-Wiki Uploads on En and Ar Wikipedias". The research, conducted in collaboration with the Structured Content team, was aimed at understanding how users were interacting with the Visual Editor upload tool. We hypothesized that the UI may contribute to users uploading files as "own work" when the work is not theirs. What we found is, indeed, users are erroneously uploading files as "own work".
Some of the findings of the report are:
14 of 16 users interviewed from English and Arabic wikis uploaded others work as their own, and only a few of those files had been moderated. So the problem is much larger than documented.
This is partly because users interpret "own work" differently, so many believe they have the authority to upload when, according to copyright rules, they do not. This is also because the UI does not present alternative options in a way that users understand (the text on the UI is very confusing to them).
There is widespread confusion about what is/isn't allowed to be uploaded, what constitutes copyright, who holds the copyright, and how does that relate to Creative Commons licenses. The image policy is not accessible or known to users.
Interestingly, we found that most uploaders were either marketers (editing/uploading on behalf of another entity such as their employer), or they were self-promoters (creating pages about themselves, unaware of the "notability" requirement).
@Sannita (WMF) a good research! It is timely, considering that I opened a similar issue regarding some problematic cross-wiki uploads (also through the regular VP forum, I think it is still here – not archived as of this posted comment).
Some two thoughts of mine. Re: "The 'upload page on Wikipedia' statement is the most confusing of all," I think it is due to the general public perception that both Wikipedia and Wikimedia Commons are same, as a single platform for educational content, even if both are different websites that happened to be under the umbrella of Wikimedia Foundation. No matter how we try to educate people about the differences in policies and scopes of the two websites, a layman will still treat both as identical; or, as one website. Even the anti-Wikipedia group ADAGP who opposes FoP does not use "Wikimedia Commons" in their presentation to the EU Parliament in 2015; they used "Wikipedia" instead. Perhaps the upload forms should use understandable, layman's language.
Re: "Participants don't know what to do with files that are not their own creation," I guess a massive copyright education campaign is needed. Explanations should not use excessive legalese or technical terms. For Wikimedia groups and affiliates, reforms to copyright laws must be pushed to simplify things. Much of the complexity of copyright for an average layman is due to the complex copyright laws. JWilz12345(Talk|Contrib's.)16:42, 24 June 2024 (UTC)
10 out of 11 English users were promotional - 5 self-promotion and 5 marketing. Only one of those 10 was notable enough to be in scope, and even then it appears there were copyright issues. The problem here is not the UI; the problem is that the entire cross-wiki upload system makes it much easier for spammers without providing much benefit to anyone else. At minimum, cross-wiki upload needs to be turned off from the User: and Draft: namespaces (where most of the spam comes from). Pi.1415926535 (talk) 18:52, 24 June 2024 (UTC)
I would also say before investing much time and therefore money in improvements for the cross-wiki upload we should discuss if we want to give cross-wiki upload a chance or if we want to block it entirely to not approved (autopatrol or similar on other wikis) accounts. GPSLeo (talk) 18:59, 24 June 2024 (UTC)
Second in motion to @GPSLeo's suggestion. Cross-wiki uploading had good intentions, but is easily abused. Perhaps only allow cross-wiki uploading to users who are among one of these user groups: admins/sysops, license reviewers, and autopatrolled users. Cross-wiki feature should be treated as a right with burden of responsibility to the uploader. I'm not in favor of axing out the feature entirely. JWilz12345(Talk|Contrib's.)02:44, 25 June 2024 (UTC)
We really, really need some process and tools such that, when files are cross-wiki uploaded and don't remain on the page they were uploaded for (e.g. because the edit adding them was reverted, the page was deleted, or the user never completed an edit adding the image), those files can be identified and deleted from Commons with a minimum of hassle. Right now, there's no good way to spot those images, and deleting them will usually require a DR. That's a lot of overhead to get rid of a file which the uploader may not have ever expected to persist on Commons. Omphalographer (talk) 19:11, 24 June 2024 (UTC)
The problem isn't the process, the problem is the backlog of likely millions of files that violate existing, sensible policy (no copyvios, no unusable personal photos) scattered around the project. Identifying these and checking for prior usage/checking user contribs takes time. Gnomingstuff (talk) 05:27, 26 June 2024 (UTC)
cross-wiki upload should probably just be blocked outright at this point. As it's clearly an issue that has no easy, implementable, solution. At least not in the short-term. IMO there really needs to be a more clear separation between the projects for something like cross-wiki uploading to work. It's never going to "fixed" if everyone using it just thinks Commons is a glorified subdomain of Wikipedia though. --Adamant1 (talk) 22:28, 24 June 2024 (UTC)
Just about the logo question: maybe the study sees this too much from a Commons' perspective, despite studying English Wikipedia and people contributing to articles there: personally, I think the default recommendation should be to upload a logo for "fair use" directly at enwiki. Enhancing999 (talk) 22:46, 24 June 2024 (UTC)
Yup. Possibly combined with a "logo" branch in a Wizard that tries to work out what is the relevant country, then describes the relevant threshold of originality and asks whether it is clearly above (keep it local), clearly below (go to Commons) or just plain unclear (keep it local, which is safer). Also, logo + "own work" is almost always wrong, though of course it is very occasionally correct. - Jmabel ! talk23:08, 24 June 2024 (UTC)
It doesn't seem like English Wikipedia wants to host images of logos going by the number we have, but that would be the better solution. Although it would then screw over the ability of other projects to use the files in a lot of cases. So maybe it's not the best way to go about this. --Adamant1 (talk) 23:16, 24 June 2024 (UTC)
en-wiki routinely hosts logos that are over the threshold of originality, if they have an article about the organization in question. - Jmabel ! talk23:29, 24 June 2024 (UTC)
Sure, I was mainly saying it in jest, but we do host a lot of logos that have been sent over from Wikipedia for one reason or another. --Adamant1 (talk) 09:11, 26 June 2024 (UTC)
About the "personal images": not sure how the study gets to that conclusion of it being a big issue. If in a sample group people were writing autobiographies about their not-Wikipedia notable selves, why should they consider that their image isn't suitable to be uploaded despite serving as an illustration to the article? If the article actually exists, the image can be uploaded. Also, the subject of an article is the most likely person to have access to correctly licensed or licensable images. Obviously "personal images" can be an issue at Commons, but this may be unrelated to enwiki articles. - Enhancing999 (talk) 09:30, 25 June 2024 (UTC)
@Enhancing999 may be because images that show the uploaders themselves are only falling within the house rules of Commons, if they serve real purpose like Wikimedia-related activities, uses on user pages in all wiki sites, and in an article (if the article survives the review process of other editors). Assuming an image does not have the purpose of documenting Wikimedia-related events, and it is not used on a userspace page, and it is being used in an article on English Wikipedia. The article is then slapped with AfD request. The article is found to not comply with w:en:WP:GNG (especially on BLP house rules there) and is "sentenced to death". With the article deleted, the image then becomes an "out of scope image" or "unused personal image". JWilz12345(Talk|Contrib's.)12:15, 25 June 2024 (UTC)
Comment I hate to have a hot take here, but this (and the whole thing with using AI to identify logos) assumes uploading COPYVIO is even a problem to begin with. It's not like we can't (or don't) delete copyrighted images pretty regularly. Maybe it's secondary to the core principles of Commons, but doing so has the benefit of being able to document artists and dates works become PD. There's as much value in that IMO then automating to the point of stopping people from uploading COPYVIO or really anything because they are so turned off by the warnings. Regardless, we are here to document, preserve, and "maintain" a media repository. Which inherently to some degree depends on people uploading COPYVIO once in a while (if not regularly). The important thing, and I'd argue the current issue that things like this are getting at, is that we should be able to deal with it in a timely manor. Not that it shouldn't exist in the first place. --Adamant1 (talk) 06:05, 26 June 2024 (UTC)
I get what you're saying, but we're very much at "regularly" and arguably at "frequently." The copyvios that are uploaded, and certainly the ones talked about this thread, are usually recent enough that they won't enter public domain within any of our lifetimes. Gnomingstuff (talk) 18:58, 26 June 2024 (UTC)
Similar but not identical. {{Categorise}} is a request that files be diffused out of a broad category (like, say, Category:History); having files in such a category isn't necessarily wrong but could be improved. {{CatCat}} is a stronger statement that a category should only contain other categories by definition (like Category:Categories!), so any files in that category are miscategorized and should be removed. Omphalographer (talk) 21:18, 30 June 2024 (UTC)
Engravings and Lithographs etc.
We have a gigantic epidemic of people overwriting existing Engravings and Lithographic images with different versions of the same image. Also, the same for cropping off captions and border, without creating new files.
18th and 19th century Lithographs and engravings are all unique, even if they come from the same book and edition, they are different, in terms of condition, printing, edition source, and hand painting, and they should not be overwritten by anything other than the exact same print, from the same book, from the same museum or owner.
Lately, I try and protect them with Template:Border is intentional, but I'm overwhelmed at the amount of damage done. It's a losing battle.
These images need the artwork template and we need to some means of ensuring that files are not overwritten with similar, but different images. Are there other templates that can be used.
Can we put in bot measures to protect them, from these oafs? It's bad enough with these people omitting descriptive detail, using dubious sources (that steal images from elsewhere in the net), and claim false ownership. Not to mention all the AI crap, that’s, no doubt on its way.
That's not the point, if they are overwritten, they are unavailable for use! Also, they cannot be easily assessed, for use, as they are hidden and require drilling down to see.
Most likely it depends on uploader and tool used as most GLAM databases are different in terms of content, interfaces etc. Afaik most uploads are made by custom scripts and and solutions are made in upload tool level. Wiki commons itself doesn't have functionality to sync with external GLAM repositories. --Zache (talk) 18:56, 27 June 2024 (UTC)
Repeated uploads from the same GLAM are quite common. Synching is actually a bit trickier than you might think. I have some experience with this from the point of view of curating the content brought in from a GLAM by a bot. I'll try to get back here and share my thoughts in that in a day or two if no one else has something solid. @Wakelamp, feel free to hit my up if this slips my mind. - Jmabel ! talk23:50, 27 June 2024 (UTC)
A few considerations:
In deciding whether to upload automatically, you don't just want to consider whether the file is on Commons. You should track what has already been uploaded, because if the bot uploaded it before and it is not on Commons now it was probably deleted and, rather then upload, you would want a report to a human who can make an informed decision.
If metadata has changed at the GLAM and the original upload has never been touched on Commons, then it is reasonable to bring the corresponding data on Commons up to date. However, if the corresponding data on Commons has been modified in any way, again we are into a situation where a human should make a decision. It is possible that the change/correction on Commons is better than the one at the GLAM. For example, a GLAM may have made a minor correction in a description where someone on Commons has done a good job of fleshing it out.
This one gets complicated if another bot is (for example) copying data from wikitext to SDC, one of many reasons why it is good if the upload bot can fill in both wikitext and SDC where both make sense to use.
I would recommend always having at least two hidden categories added to every file uploaded by a bot from a GLAM:
User:Dominic has done a fair amount of uploads along these lines. I don't know how well his uploads conform to what I've written above, but I imagine still that he will have some useful things to say if he chooses to weigh in. - Jmabel ! talk04:26, 1 July 2024 (UTC)
@Wakelamp btw, why do you ask? (ie. do you have some specific use case like you would like to do uploads or are you just curious to know what kind infrastructure there is) --Zache (talk) 19:16, 1 July 2024 (UTC)
As mentioned above, be careful not re-upload already deleted files. Also, you might need to keep track of file renames and possible tags for problems on these files (some may be about trivial issues, others not). Enhancing999 (talk) 20:07, 1 July 2024 (UTC)
Japanese figures/mask in trains
By using Google lens I find similar pictures (mostly with Japanese text and not out of the Commons) but not with any English explanation. I am looking for the correct category. Smiley.toerist (talk) 10:12, 30 June 2024 (UTC)
If this is considered artistic work. This is a traditional depiction of a Tengu. This is mass produced en put in several trains of the compagny. Mounting the mask on a board and mounting it in an unusual position on a train does not make it an art work. By the way: art work such as emblems etc on moving objects are usualy not protected. The figures in a carnaval procession can be freely photographed, while it is certainly the artistic work of (many) individuals. Can we photograph an individaul wearing an 'artistic' made mask?Smiley.toerist (talk) 09:22, 2 July 2024 (UTC)
Someone had to come up with and design this particular version of a tengu mask and its composition. Posters are also mass-produced and mounted everywhere, but they are most of the time still copyrighted. Regarding art work on moving objects like masks: see COM:COSTUME. You may be free to photograph a lot of things, but keep in mind compatibility with derivative works. --HyperGaruda (talk) 19:47, 2 July 2024 (UTC)
SVG 1.1 uses xlink:href. WMF uses an SVG 1.1 rasterizer, so SVG elements such as use must employ the xlink namespace.
SVG 2.0 allows either xlink:href or href. Most browsers are compliant with SVG 2.0, so viewing the SVG directly in a browser will work with either form.
I'm curious about the image on the right: do we have a privacy guideline about photographs of employees in their workplace, without an indication that the employee has given their consent? I didn't find an answer in COM:IDENT, though maybe I missed something. Marnanel (talk) 11:39, 29 June 2024 (UTC)
This totally depends on the situation. In most cases I would say you can make and publish a photo of someone who is working if this would also be fine if the person would be there without working there. The given example that looks like someone hit the shutter button accidentally should definitely become deleted. GPSLeo (talk) 11:59, 29 June 2024 (UTC)
FWIW, doesn't look problematic to me. And no, it doesn't look like someone hit the shutter button accidentally. It does a good job of showing what it's like to have to carry a tray of drinks in a chaotic environment. - Jmabel ! talk19:02, 29 June 2024 (UTC)
I suppose it's an interesting depiction, but the subject matter is mundane in the extreme, and this scene could easily be recreated at any place with anyone at any time, basically. Also, this image is technically of low-quality in a low-quality album, from a Flickr user of low-quality consumer-oriented point & shoot equipment.
Why even bother keeping this? If there's any question of personality rights or consent, why not delete it, and hold out for a properly-documented image of respectable quality? That would be so easy to obtain, whether it's candid or staged: simply obtain consent from the waitress and use high-quality equipment.
On enwiki we routinely reject low-quality images, and problematic or questionable images. It only makes sense to hold out for something that's really good, because, in the end, this is a very easy type of image to create. It doesn't depict a celebrity, an event, or anything special: just a night out drinking at a casino.
Apparently, the image is currently in use on exactly one article, on enwiki, regarding "complimentary drinks". The image itself really isn't connected to that particular topic at all: whether the waitress is charging for those drinks or not, we can't tell from the image itself. So I say, if we have any doubt of her consent to use this image according to Commons policies, let's delete it and hold out. Surely, some Commons user can go to Vegas this very weekend and make a dozen great photographs along with a signed model release? Elizium23 (talk) 02:16, 30 June 2024 (UTC)
In terms of legality, it's probably legal. Casino-specific rules aside, the public areas of a restaurant or casino wouldn't bring with them a reasonable expectation of privacy. That said, this is a low quality image of someone which looks like it was taken surreptitiously while she was just doing her job. I don't know why someone would've uploaded this to Flickr. From the way it's used, I guess I understand why it was transferred to Commons (for a photo of a Vegas casino cocktail waitress), but there's probably a good case for COM:DIGNITY if not quality-based COM:SCOPE. Tough one, though. Courtesy ping to Belbury. — Rhododendritestalk | 21:00, 2 July 2024 (UTC)
Thanks, the context here was just that the en:Comps (casino) article needed an illustration and from memory this was literally the only image I could find on Flickr that conveyed the concept, it seemed better than nothing. Belbury (talk) 06:46, 3 July 2024 (UTC)
Why are we doing this? (Reasons why WMC is useful)
In the context of discussions relating to Commons:Media knowledge beyond Wikipedia I created an initial version of a list of reasons why Wikimedia Commons is useful or ways it could be used for. You're invited to participate at Commons:Why Wikimedia Commons is useful and add any usecases/reasons that are currently not on the page.
Adding more concrete illustrative examples or barriers usefulness-types would also be helpful.
I think such a list could make WMC more useful than it already is, communicate the value of it to relevant people (e.g. people considering freeing their collections or contributing), and raise awareness/activities of users that eventually raise WMC's value and our work here to the world. Things can also be discussed on its talk page. Prototyperspective (talk) 14:26, 24 June 2024 (UTC)
It has grown a lot recently and probably needs subsections now. Maybe another place would be better to ask about this. I think identifying and improving upon reasons for usefulness is pretty important so it would be best if more users contributed to the list. Prototyperspective (talk) 10:09, 28 June 2024 (UTC)
@Prototyperspective: I'm not exactly sure where to put it on your list or if it's already been covered, but I've been using galleries to create catalogs of postcards by particular publishers. For instance Postcards published by Edward H. Mitchell. I think this might be the only website doing anything like that. As well the only one where it would even be fusible due to it being a repository of media from a large number of multiple sources across the globe. I guess there's similar things on here like galleries of stamps, but I think the ones for postcard publishers are fairly novel. Logos of postcard publishers is a similar project. It's possibly the biggest gallery of logos for postcard publishers in the world and I'm sure it couldn't have been created anywhere else. --Adamant1 (talk) 11:19, 28 June 2024 (UTC)
I think it's covered mostly by "Central repository of collaboratively organized structured media" and also "Enabling finding lots of or highly specific media". In general the subject is how what people are doing or making available is useful, not that itself (as in aggregation and organization).
So one would have to think about and specify how such galleries/catalogs may be useful to users (that could be entertainment, research, educational purposes, and so on)...e.g. this is not about unique valuable things available or enabled by WMC but how (why) these are useful. The usefulness of the two mentioned ways is elaborated next to these points and probably still needs further expansion, these are not as clear/specific as many of the other cases such as "Finding media for illustrating a given Wikipedia article". Prototyperspective (talk) 11:33, 28 June 2024 (UTC)
There are sections now and sooner or later I'll (most likely) will also add some studies there. Uncommon use-cases however will be hard to identify so if you ever used in WMC in some way not included there please add it or describe it on its talk page.
I think the more media there is on WMC, the more gaps of media are filled (especially various illustrations or simple things like brief videos/animations of how to execute particular fitness exercises) and the more organized it is, the more usecases there will be or the more valuable these will become. Prototyperspective (talk) 11:57, 4 July 2024 (UTC)
I have just found today that YouTube changed the page layout and CC lincenses are no longer being displayed. --トトト (talk) 06:42, 28 June 2024 (UTC)
Uugghh well that sucks. I think I nominated a couple of videos for deletion a few days ago because the link to YouTube didn't say they were CC licensed even though that was the claim. Great. --Adamant1 (talk) 06:48, 28 June 2024 (UTC)
What do you mean? I still see the license just like before at the bottom of the video description next to License and one can search for videos with that license using filters.
On a related note, sometimes I think youtube deboosts videos with CC-licenses (maybe because they aren't monetized as much) but nobody knows since the algorithms are not transparent. If that's the case, it discourages users to license their videos this way and I think some articles on this suggest first uploading nonCCBY videos to first get popular before licensing any under CCBY. Please let me know if anybody has any sources/info on this. Prototyperspective (talk) 09:54, 28 June 2024 (UTC)
I clicked on a video from Commons a while ago that was supposedly CC Licensed and nothing showed uo for me. Maybe its a bug on their end or I just missed it though. --Adamant1 (talk) 10:01, 28 June 2024 (UTC)
Sometimes the license gets changed. CC-licensing can't be revoked but there are many cases where removal of that license should mean the video also needs to be deleted here...for example the video may contain nonCCBY clips that the uploader only became aware of later or the account was under control of somebody else. When uploading with V2C, there is an link to the archived site so one can check if it was CCBY at time of uploads and its adds a License review needed template so a user checks the current video (people don't seem to be doing this anymore). Prototyperspective (talk) 10:06, 28 June 2024 (UTC)
Yes, it annoys me a lot... But it depends on if you're logged in afaik. Anyway, you can retrieve the CC-BY note by looking into the website source code and by searching for "Creative Commons". This is where V2C gets his information from. It sucks and I assume there will be several deletion requests because of this misunderstanding --PantheraLeo1359531 😺 (talk) 18:24, 28 June 2024 (UTC)
Internet Archive versions of Youtube links since 2023 have been unable to load the full description to display the CC license. If we had more reviewers, or at least a bot to note the status, this issue would be more manageable. Joofjoof (talk) 23:05, 3 July 2024 (UTC)
Alternative Youtube frontends can be a solution to display status, as long as Youtube does not try to block them. Joofjoof (talk) 23:09, 3 July 2024 (UTC)
I can see the license (example). Maybe video2commons shouldn't add a link to the archive.ph archived site since it doesn't task it to actually archive it and the IA page seems to be sufficient. Prototyperspective (talk) 23:11, 3 July 2024 (UTC)
It proposes to "Implement a mechanism to verify uploaded files" – I would think a technical mechanism would be better than having people manually review lots of files, in particular archiving the source page at upload. This is already done for uploads made via video2commons as described above, what about adding this to other uploads? (Another thing is that only the description needs to be archived, apparently IA even archives the video file itself for a while). There's so much things to do where people's time is needed so I think things like this shouldn't be added on top (especially since even currently there's not enough reviewers, I think nearly none of my V2C uploads have been checked so far) but rather there could be bots that do the opposite of this: flag (e.g. categorize) items as "Likely copyvios to review manually". Prototyperspective (talk) 10:57, 4 July 2024 (UTC)
Yes, probably the exact proposal could be better, and that's why it didn't receive many votes. I mean that I think that some kind of mechanism (better if it's automatic, of course) is needed to avoid losing content due to mistakes. There are many files in Commons, with very different quality levels, and randomly losing some of them is very sad, I think... this is as a kind of library, it's really sad to think that knowledge about some particular fact or document can be lost forever due to a change in YouTube's layout or similar seemingly minor reasons. Also think about the usage of images in Wikipedia: it's terrible to think that some decades from now, people may not be able to know how certain street of some relatively unknown city looked alike in 2001, because somebody stole a photo from Commons and uploaded it elsewhere under a non-free license, so it got deleted from here. I think these things are not being taken seriously enough. We have to think about next week's users first, but without neglecting those of 20 years from now. After all, Wikipedia was already there 20 years ago, and we continue to enjoy images that have been there ever since then, thanks to the fact that they have been preserved for all this time. MGeog2022 (talk) 12:17, 4 July 2024 (UTC)
Is there any way to do a sane query for files that I've uploaded (and/or for files where my account name occurs as part of the wikisource text on the file page) and where the {{Published}} template is on the talk page? - Jmabel ! talk20:17, 28 June 2024 (UTC)
PETScan would be the obvious idea, and why it can find files whose talk pages contain certain templates, it does not seem to be able to find files uploaded by certain users. Maybe this is the kind of application that a hidden user category of your photos would be useful for? Felix QW (talk) 15:25, 5 July 2024 (UTC)
@Felix QW: I want to do this precisely so that I can mark these published files with a hidden category.
No, I do not particularly want to place all of my 70,000 or so photos here on Commons in a single hidden category. I can't even think of a way that would be done without the process of doing so becoming a problem. - Jmabel ! talk16:08, 5 July 2024 (UTC)
New York Public Library
Does anyone know what accession number we should be using for items from the Collections of the New York Public Library? I'm using this image as a template example. -Broichmore (talk) 11:06, 28 June 2024 (UTC)
https://archives.nypl.org/mus/24078#c1553136 gives IDs like "b. 164 f. 25" and "b. 110 f. 9-10"; it would not surprise me, though, if those were strictly IDs within the Lou Reed papers, and not in the NYPL collection as a whole, especially given the low numbers.
Looking at this, I'd be surprised if they have a single system that spans their entire archive.
I suspect, that like the Library of Congress (LOC), this was one of the first GLAMs uploaded en-masse, consequently, it varies in the templates employed. So far, I've discovered that the accession number might be the NYPL catalog ID (B-number), think that's their shelf number.
There is a source template, I stumbled on, based on the image ID. Also, a default sort based on that NYPL catalog ID (B-number) again. See image for an example. - Broichmore (talk) 21:18, 28 June 2024 (UTC)
@Broichmore: I work at NYPL and am happy to help make sense of the identifiers as much as I can, although as Jmabel suspected there is a lot of variation in cataloging practices and identifiers between libraries, curatorial divisions, and systems.
Does Commons have a specification for "File information" metadata where "Accession number" is described? I was unable to find any documentation, but my initial sense is the call number (displayed as "Shelf locator" on NYPL Digital Collections records and "Research Call Number" in NYPL Research Catalog records) is the most akin to an "accession number," which is a term more common to museums than libraries/archives.
Some of the other identifiers mentioned by Jmabel are external to NYPL (RLIN/OCLC), system-specific (NYPL catalog ID (B-number)), or are not identifiers (the "b. 164 f. 25" and "b. 110 f. 9-10" displayed at archives.nypl.org is a box number and folder number that describes the location of a folder within a larger archival collection).
UUIDs and Image IDs are automatically assigned to any individual file available on NYPL Digital Collections and are (for now) the most reliable way to link back to the source of an file.
For accession number I'm now using the UUID number.
I have used a template for source/photographer employing the IMAGEID number. Clicking on it takes you only one step away from the PERMALINK url. So, I've added the PERMALINK url. It's not exactly ideal, but will do me for now.
Someone in the past has added a defaultsort using the b number with NYPL as a prefix, and the plate number or sequential number in a set as a suffix.
Where is the "Accession number" field specified for Wikimedia Commons? I would not consider a UUID to be an accession number, but I don't know the context within Wikimedia Commons. --Infopetal (talk) 15:13, 8 July 2024 (UTC)
For the physical item or the digital item? UUIDs only correspond to digital objects (which can represent a collection, container, item, or image) and are generated by the software used for NYPL Digital Collections. Based on the template you linked, my sense is the `ID_uuid` parameter should be used for an item UUID. The call number (displayed as "Shelf locator" on NYPL Digital Collections records and "Research Call Number" in NYPL Research Catalog record) would be a more permanent, system-agnostic identifier for a physical object akin to the library/museum/archive definition of an accession number, but there may be multiple digital objects (each with their own UUID) that correspond to a call number. --Infopetal (talk) 20:15, 9 July 2024 (UTC)
New designs for logo detection tool
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.
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 ! talk22:25, 11 June 2024 (UTC)
@Jmabel Our impression, to be fair, was quite the opposite: that it was something that could be useful in dealing with the third-most frequent rationale for requests for deletions (the first two being copyvios and FoP, which we found it was impossible to tackle in an automated way). There was more difficulty in defining how this could be implemented, but not on its usefulness. This is why we are re-opening the feedback period, to understand how it could be implemented. Sannita (WMF) (talk) 10:36, 13 June 2024 (UTC)
@Sannita (WMF) "third-most frequent rationale for requests for deletions (the first two being copyvios" - This doesn't make sense at all. The only reason we would delete a logo is because it's a copyvio, not because its a logo. There are scores of logos which are in the public domain, either by age or by lack of creativity, while others get licensed under free licenses. I'm not sure why we should discourage people of uploading that specific content with such a warning, when those exact same rules apply to everything else. As it is, I tend to not support that implementation. And as JMabel mentioned, it's disheartening to see that resources were wasted developing such an apparently useless tool, when there are clearly established priorities (see the old wish lists, for instance). DarwinAhoy!16:16, 13 June 2024 (UTC)
@Sannita (WMF), Jmabel, and DarwIn: I'll leave others to decide on the best or most suited UI for the logo detection. As for the feature, I am supportive of this, but conditionally. Suggest this feature should be mandatory for users who do not have the appropriate user rights; I suggest users who are not admins/sysops, license reviewers, and/or autopatrolled. Users who are under these three tiers of user groups are free to upload logos and should not be slapped with this filter, since they are already aware of copyright issues and TOO considerations for logos. If possible, the feature should effectively block uses of "FileExporter" and other cross-wiki file transfer tools. And one more thing, I suggest the filter can prohibit new users (those who are not autoconfirmed) from uploading or importing logos (even photos showing logos that are non-de minimis/non-incidental). Hopefully, this will trim down at least a third or less (my guess) of deletion requests that contribute to the perennial backlogs. There are many more areas in Commons that also need attentions and resolutions, like Commons:Categories for discussion/Older (some open discussions were from before the lockdown era of 2020). JWilz12345(Talk|Contrib's.)08:30, 14 June 2024 (UTC)
@JWilz12345: I think the plan is for this to become a secret feature. It has no effect on the upload itself and nobody but the uploader will know about the warning. Possibly, the same effect could have been achieved by merely editing the current interface and noting "if it's a logo, follow logo guidelines". Enhancing999 (talk) 08:43, 14 June 2024 (UTC)
Just my opinion, but having a specific warning to the uploader saying the image might be a logo seems rather pointless. If not borderline condensing towards users. People generally know what they are uploading images of. The less clear thing is what license to use in any specific instance and I don't really how this deals with that. A better thing would probably just be a specific checkbox for logos that automatically adds a license and puts the image in a specific category for images that need reviewing on upload. Otherwise people are just going to just ignore the warning just like they are already ignoring guidelines by uploading the image to begin with. What we really need is better ways to review and deal with problematic images on our end though. Not try to unload that on uploaders by over complicating the UploadWizard with a bunch of warnings, extra boxes, and the like. --Adamant1 (talk) 20:52, 15 June 2024 (UTC)
@Adamant1: anything related to copyright is already complicated enough. That's perhaps a price to pay for establishing/creating a free media repository site like Commons, or more so, Wikipedia itself way back more than 20 years ago. Something that founders Wales and Sanger likely did not forseen or anticipate. (Note: just a part of my thoughts, and not a representative of my general perspective on Wikimedia movement, which I still support in the context of mandating global FoP). JWilz12345(Talk|Contrib's.)21:12, 15 June 2024 (UTC)
Thanks everyone for your comments! @Adamant1 about the checkbox, we thought of that option too, but ultimately decided against, because we didn't want to clutter too much the UploadWizard and make it more complicated for legitimate uploaders to upload a legitimate logo or fall into the "I'll just ignore that" kind of case. Anyway, our scope is to get to a better and more seamless way of uploading medias, but this will take more designing, prototyping, and testing, so it won't happen overnight.
To everyone, we're open to ideas for eventual moderation of logos in general, given that we don't want to unload a new bunch of work on volunteers without there being consensus. Sannita (WMF) (talk) 14:08, 20 June 2024 (UTC)
I just want to provide some context on @Sannita (WMF)'s post above ... what we're working towards here is an automatic process by which we reliably estimate the likelihood that an uploaded image will be deleted for any reason
If we had that process we'd be able to inform users that their upload is likely to be deleted (and why) during the upload process, which would be a better (and more educational) user experience than we have now. Also moderators would be able to find (and deal with) potentially problematic uploads much more easily
Our initial experiments with machine learning showed we can detect logos reliably, and they're a pretty common reason for DRs, so logo detection seemed like a promising place to start CParle (WMF) (talk) 14:36, 20 June 2024 (UTC)
There may be a misunderstanding here: being a logo is not a reason to delete. We have tens of thousands of logos legitimately on Commons. Laying aside logos that are PD because they are very old, or created by certain governments that don't claim copyrights, etc., an enormous number of logos are below the threshold of originality for copyright, especially in countries like the U.S. where that threshold is quite high. False positives -- discouraging or (worse) preventing upload of content that could legitimately be hosted on Commons -- is at least as bad, and arguably worse than false negatives, letting a "bad" file through. We can always delete a bad file; we cannot conjure a file we don't get to see. - Jmabel ! talk19:36, 20 June 2024 (UTC)
> being a logo is not a reason to delete
Absolutely, but being a logo is a signal that the upload is more likely to get deleted. We're not proposing to prevent logo uploads, just to alert the user if what they've uploaded looks like a logo, and attempt to educate them about the copyright implications (and also flag possible logos so that patrollers can check them) CParle (WMF) (talk) 10:56, 21 June 2024 (UTC)
I'm not sure logos are actually among the things where the highest percentage get deleted. But maybe they are. Do we have any available statistics on this? - Jmabel ! talk19:24, 21 June 2024 (UTC)
@Sannita (WMF): I may be missing something, but I don't readily see anything there that even suggests what percentage of logos are deleted, compared to what percentage of uploads in general. Is it there and I'm missing it, or is it just not there? - Jmabel ! talk18:22, 24 June 2024 (UTC)
@Sannita (WMF): yes, I saw that. It says, in effect, "lots of logos are deleted" but with no indication of how many are kept, and how that ratio compares to other categories of files. - Jmabel ! talk21:42, 26 June 2024 (UTC)
@Jmabel, DarwIn, JWilz12345, Adamant1, Enhancing999, Alachuckthebuck, and SCP-2000: First of all, thank you for your comments, and apologies for pinging you directly. Considering the possibility of moving forward on this topic, we have a couple of questions to ask you about it:
Do you think the user interface notice in the UploadWizard about detecting a potential logos should be limited only to certain classes of users (i.e. exclude explicitly autoconfirmed users and higher)?
Do you think a template should be created and added automatically when a logo detected by the logo detection system is uploaded to Commons with an “own work” option selected for the ease of moderation?
@Sannita (WMF): Hi, Just a comment regarding data from phab:T340546 (P49530 Commons deleted pages most frequent edit messages, only the 20 most frequent reasons). I summed up the deletions by reason, and I get: 94,459 for copyright violations (lines 3+10+12+13+14+16+17), 76,385 for "Personal photo by non-contributors (F10)" (lines 2+5+9), and only 6,693 for logos. So logos are far down among the reason for deletion. This also reflects my personal experience as an admin. "Per COM:SPEEDY" usually means empty categories. Yann (talk) 10:41, 2 July 2024 (UTC)
@Yann Thanks for your consideration. Logos might be down among deletions, but they can also be a stepping stone towards finding a solution to other, more frequent reasons for deletion. For now we decided to focus on a limited but easily detectable part of the deletion process, and we got a tool that can provide a more than decent result at that. With the experience built on this section, we can try to tackle other reasons for deletion. Sannita (WMF) (talk) 16:48, 2 July 2024 (UTC)
@Sannita (WMF): IMO there is an even easier target for detecting copyright violations: all files with an external link as source (or anything like Google, Facebook, etc.). They should be included in a category for checking if the uploader is not an experienced user. Yann (talk) 17:05, 2 July 2024 (UTC)
What we would need is some kind of AbuseFilter that adds categories or templates after the upload process. One of the many parameters the filter can use could then be the result of the logo detection tool. Many parts for already exist the only the ability of the AbuseFilter to make edits would be needed and the new logo detection tool needs to hand over the information the AbuseFilter. GPSLeo (talk) 18:12, 2 July 2024 (UTC)
@Yann Hey, just to follow up on your comment about external links: we got some statistics on phab:T369273#9965672, that show that a high percentage (90%+) of medias showing an external link get deleted. They account for ~7k deletions in 2023, compared to ~8.5k for logos. Sannita (WMF) (talk) 13:33, 11 July 2024 (UTC)
Technical needs survey proposals
As somebody asked here, it would be fine to have any news about the plans for implementing the proposals selected in technical needs survey months ago. Seemingly, nothing new is publicly known after the survey finished. MGeog2022 (talk) 21:03, 29 June 2024 (UTC)
Interesting. In the meantime, the annual plan for 2024/2025 was discussed and I don't think any of this was brought up. Enhancing999 (talk) 22:59, 29 June 2024 (UTC)
Not sure if that would work well. For the next annual period, you could try to prepare something that can fit into the plan (with the level of generality required by the plan up to the level of detail that can bring actual change to the Commons community). Rather than requesting specific tools (which is a technical implementation question for devs), I'd attempt to phrase it in terms of functionality that should be available (users don't really care how it's done), highlighting how that fits into the general objectives.
Once that prepared (ideally before the end of 2024), you could send it to the WMF board (a Commons contributor sits there) so they can request the staff at WMF to include it in the plan. Enhancing999 (talk) 07:53, 5 July 2024 (UTC)
Maybe it would help if phabricator issues were created for the proposals.
.jpg/220px-Seattle_City_Light_communications_staff%2C_circa_1960_(53799326997).jpg)
Support as proposer. —Matrix(!) {user - talk? - 
gmail.com)
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)
.svg/15px-Pictogram_voting_comment_(orange).svg.png)
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)
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).
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)
Done Upload new .png/220px-FastCCI_Commons_gadget_showing_why_a_file_is_erroneously_categorized_into_a_category_(category-tree).png)
.png)
.svg){kind=link}
.svg){kind=link}
.svg){kind=link}
.svg){kind=link}
.svg){kind=link}
.svg){kind=link}
.svg){kind=link}
.svg#Discussion_about_rename){kind=link}
![[1]](https://commons.wikimedia.org/wiki/File_talk:Corpses_in_the_Sava_river,_Sisak_1945.jpg){kind=link}
![[2]](https://commons.wikimedia.org/wiki/File_talk:Ustaše_militia_execute_prisoners_near_the_Jasenovac_concentration_camp.jpg){kind=link}
![[3]](https://commons.wikimedia.org/wiki/File_talk:Glina_church_massacre.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.svg){kind=link}
.jpg){kind=link}
.jpg)
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=edit){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=history){kind=link}
.jpg&limit=999){kind=link}
.jpg&action=watch){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=edit){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=history){kind=link}
.jpg&limit=999){kind=link}
.jpg&action=watch){kind=link}
_219.jpg){kind=link}
.jpg){kind=link}
