This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2023/08.
Please note:
If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.
Purposes which do not meet the scope of this page:
I keep finding images of lithographic plates from old books, which are misattributed to the authors or editors of those books.
For example File:Biolcam.jpg was attributed to "Eds Godman and Salvin" until I recently corrected (and categorised) it to "Robert H. F. Rippon" - note his name, suffixed "Del et lith" ("drew and lithographed"), bottom left on the plate.
This makes it harder to document lithographers and artists, and excludes their works from categories linked from their biographies on Wikipedia articles, and makes their reuse on those projects less likely.
This is a problem right across the board for art, I seem to do little else, than correct or fill in this information. Part of the problem is the uploading portals are just not up to the job. Broichmore (talk) 13:27, 14 August 2023 (UTC)Reply[reply]
@Broichmore, could a [Category:Media needing proper attribution] or other category name help? If there are files that need correction, but volunteers do not have the time, experience or inclination to correct these files could use it. I would be willing to visit that category to help make corrections. Pinging, the winged porcine @Pigsonthewing -- Ooligan (talk) 17:10, 15 August 2023 (UTC)Reply[reply]
Why not Category:Panama color photographs of Coleoptera taken on 2020-05-26 with Nikon D40? Surely, that's not too specific! Seriously, though, what is the point of these categories (most of which only have 1 or 2 images)? Is it just to make the database servers melt? It looks like these categories were created and populated by RudolphousBot (run by Rudolphous), although I can't find any discussion where this task was approved by the community. Can someone point me to it? If it wasn't approved by the community, I would like to request that all 8 million of these categories be deleted. Nosferattus (talk) 04:40, 6 August 2023 (UTC)Reply[reply]
Rudolphous appears to have taken a cue from categories (millions?) that already existed when Commons:Bots/Requests/RudolphousBot (extra) request was filed and discussed. However, the way it is worded, and with the edit examples, Rudolphous appears to assert that he intends to insert "|location=xxx" into templates, while taking date cues from existing categories. I see nowhere that adding such categories by bot is discussed.
There are already 18 million files in these categories. The categories already exist a very long time and on daily basis multiple users add pictures to them and spend hours and hours to categorize them. If we want to delete categories I know some more specific examples to start with Rudolphous (talk) 06:54, 6 August 2023 (UTC)Reply[reply]
my opinion is that "country by date"-kind of cats are ok but the current name is bad. should have been like "photographs of Panama taken on 2020-05-26" or "photographs of Panama (2020-05-26)".--RZuo (talk) 08:58, 6 August 2023 (UTC)Reply[reply]
This template was created in 2014. So 2014/2015 was indeed the time it started probably. About your proposal: The first option looks indeed a better name to me. Rudolphous (talk) 09:45, 6 August 2023 (UTC)Reply[reply]
Well, no, not really. The categories already existed before that and I simply followed what at the time, seemed to be an already established standard. My edit was to implement automatic categorisation into appropriate categories when using the {{Taken on}} template. The preceding discussion can be found on the template talk page. The intention at the time, was to use this for country level categorisation by date, which I feel can be useful. TommyG (talk) 07:37, 7 August 2023 (UTC)Reply[reply]
"proliferance"
between oct 2015 and apr 2018 (2.5 years) only roughly 20000 such cats were created. now there're 500000. RZuo (talk) 13:51, 7 August 2023 (UTC)Reply[reply]
"country-by-date" seems to me to be an acceptable compromise between those who don't want to do anything of the sort and those who would do "city-by-date" categories.
And we don't want to rename categories affecting 18 million files unless there is a serious problem. A comprehensible but less-than-optimal category name is not a serious problem. - Jmabel ! talk 15:32, 6 August 2023 (UTC)Reply[reply]
+1. These "by date" categories are just needlessly excessive. The same goes for "by year" categories in a lot of cases and depending on the subject. "country-by-date" categories are probably fine though. --Adamant1 (talk) 20:28, 6 August 2023 (UTC)Reply[reply]
I don't see any reason to reject "city-by-date" and have "country-by-date". Panama is 4.3 million people, and there are over eighty cities that are larger than it. Countries vary so much, from the enormous to the tiny, that they aren't a useful dividing line.--Prosfilaes (talk) 19:26, 12 August 2023 (UTC)Reply[reply]
I truly dislike participating in siloed micro-discussions which avoid acknowledging the bigger picture. However, to address the example originally offered, Category:May 2020 in Panama doesn't exist, with three valid categories underneath. This appears to violate our policy, which is to create categories in a hierarchy. There was an admin who took exception to my fixing the problem of "Births in XXX" when "People of XXX" didn't exist by means other than creating scads of un(der)populated intermediate categories. The same issue applies: why were these categories created in the first place without regard for maintaining the integrity of the hierarchy? There's still plenty of broken trees lying around due to this admin's interference with my efforts, which caused me to quit bothering with it. Bot/script editing may make things "easier", that is, until it's not "easier" when someone else has to come along and clean up the messes.RadioKAOS (talk) 02:36, 7 August 2023 (UTC)Reply[reply]
@RadioKAOS: I suppose the bigger problem is people bot-creating hundreds of thousands of categories without bothering to have a community discussion about it first. I also recall someone bot uploading something like 1,000,000 photos of clouds taken automatically by the International Space Station without any discussion. Just try clicking "Random file" for a while and you'll probably see one (except the ones taken at night are black). Can Commons please have an enforcable bot policy? Nosferattus (talk) 22:38, 10 August 2023 (UTC)Reply[reply]
Are the ISS photos related to this category discussion? Why are we having a category discussion outside of CfD?
If there are hundreds of thousands of categories, and they have an identifiable purpose, and they stem from a reasonable design decision, then I don't see why we should disallow them, just because they've grown to six digits' worth. If they are creating software problems at scale, if they are unwieldy for bots to manage, if they are causing heartburn for MediaWiki software in some way, then by all means we should rethink them. But surely we could have envisioned that categorizing works by the intersection of place/date would certainly grow, like grow a lot.
I was initially confused about why Rudolphous' bot request did not explicitly say it was going to add categories, and then I realized that the categories are automatically generated by the template when RudolphousBot adds a parameter to them. I think that as the project grows, we will have more instances of hundreds of thousands of whatevers, and so I think this simply puts a stress test on the limits of MediaWiki software, and also creates opportunities for bot developers to find ways to efficiently, programmatically process category trees that can barely be comprehended by humans. Elizium23 (talk) 00:01, 11 August 2023 (UTC)Reply[reply]
I do not have a problem with the 'photographs taken on date' series of categories existing more-or-less as it is structured, but there are some real hazards that it causes by how it is implemented. The naming is problematic for some...what are "Panama photographs"? If we mean Photographs of Panama, then fine, that is what is should be named (see Universality Principle). Also a problem is the one alluded to by some above, that there are photographs sorted here that are not in their analogous topical categories. People sort their picture of Panama into this category and then it turns out if someone looks for May 2020 in Panama, they don't find it. 'Photographs of' categories are in the Media types tree, not the Topics tree (see major category policy for info on these). Thus any files in one of these categories should also exist in a topical category. Certainly, any case where a 'photographs of' category exists and the analogous topical category does not even exist is a huge problem. If these categories are being added by a template on the image, it means that often users will never drill down beyond the 'photographs of' category to discover this and these will be left without topical links en masse. All of these categories should be marked as non-topical categories (specifically as 'media type' categories) so that less-experienced users are not duped into thinking images are properly categorized because they see them in a 'photographs of' category. Josh (talk) 19:41, 18 August 2023 (UTC)Reply[reply]
When can we on Commons create a new category? Only when there are sufficient files for. JopkeB (talk) 05:00, 9 August 2023 (UTC)Reply[reply]
The question is what's sufficient? 1 file or more then that? --Adamant1 (talk) 05:05, 9 August 2023 (UTC)Reply[reply]
Well, I could not find a guideline for it and I think the opinions may vary a lot. This discussion (about the independence of Commons) does not depend on the outcome of this new question and therefor I suggest to address it in a separate discussion. JopkeB (talk) 05:34, 9 August 2023 (UTC)Reply[reply]
I'm aware that's not what the discussion is about. I just thought I'd ask since it was brought up. I'm fine with starting a separate discussion about it if you prefer that though. --Adamant1 (talk) 05:40, 9 August 2023 (UTC)Reply[reply]
I agree that there is no solid guideline, and I'd hate to create something rigid. My own personal rules of thumb:
Never create an empty category unless you are about to use it (within a few hours).
The only time to create a category for a single photo is when it is part of a sequence or systematic breakdown of another category (e.g if we have Category:PERSON by year and we already have categories for most dates in the 1940s but have only one photo of them for 1947, I'd probably create the Category:PERSON in 1947.
For two photos, I'd sometimes create a category if there is already a Wikidata item or Wikipedia article.
Otherwise, three is a bare minumum, and I probably wouldn't do less than four (usually five) if they already group together (sorted next to one another) as part of an existing category with less than 200 images. I'd be more likely to do the four or five with no Wikidata item or Wikipedia article if I either anticipate a future article, or I think we will have a lot more such photos.
I suppose I've pushed that a little sometimes when I have a lot of information about a person from roughly 100+ years ago and only a couple of photos; usually that also calls for making a Wikidata item, but I'll admit to sometimes being lazy about the latter when it's all stuff I can express via parent categories. - Jmabel ! talk 15:26, 9 August 2023 (UTC)Reply[reply]
cats should be created for unique concepts that are expected to get photographed easily, e.g. living celebrities, buildings. cats can be hooked up with wikidata which record lots of info. sooner or later more files will be uploaded. it makes it much easier to categorise those files with an established cat. if users with the knowledge of a concept cannot create the cat because of these stupid rules, then chances are the files will become mis- or uncategorised when they come. look at this bureaucracy https://commons.wikimedia.org/w/index.php?title=Special:Log&page=Category%3AMia+Khalifa . RZuo (talk) 07:13, 9 August 2023 (UTC)Reply[reply]
@JopkeB: this was a response to "18:01, 8 August 2023 (UTC)". now the context is lost.--RZuo (talk) 07:31, 11 August 2023 (UTC)Reply[reply]
I am sorry. But I thought this part would fit better here. --JopkeB (talk) 09:01, 11 August 2023 (UTC)Reply[reply]
I really have to disagree. That just sounds like a bad recipe for having thousands of empty categories because someone decided to pre-create them ahead of time and then dodged out half through their project or something similar. I much rather administrators delete a category 5 times over as many years then the inventible massive mess your recommendation would create. --Adamant1 (talk) 07:48, 9 August 2023 (UTC)Reply[reply]
Empty categories they are liked to Wikidata are very useful for tools and especially new users. They can also speedup the workflow of experienced users. This of course only applies to topics like protected areas, mountains, or members of a parliament, where we expect to get photos of in the near future. We should not create empty or nearly empty "by year" categories. GPSLeo (talk) 07:14, 11 August 2023 (UTC)Reply[reply]
Wikidata has essentially no notability guidelines outside of the entry needing to have a single external reference. So there's no guarantee that just because something has a Wikidata entry that it will every have images related to it uploaded to Commons. In fact, most never will. That's not even accounting for the fact that there needs to be someone willing to upload images related to it in the first place, which there often isn't.
I'd probably support either creating empty categories or ones with single images in cases where it's a clearly notable subject and there's a guarantee someone will upload images of it in the near future though. I just don't know how it would be enforced or tracked. Maybe we could create a special category system or template just for those types of categories like there are for DRs. I don't think they should be mixed in with normal categories though. At least not in mass. Otherwise it could easily make parent categories hard to browse through and/or maintain. --Adamant1 (talk) 08:53, 11 August 2023 (UTC)Reply[reply]
Full agreement with Adamant on empty categories. As an addendum: A few rare times I have created Commons categories about notable people, where the images later got deleted, so the category is now an empty remnant. As long as it's about notable things and connected with an entry via Wikidata, I see no problem keeping such a category. --Enyavar (talk) 12:22, 11 August 2023 (UTC)Reply[reply]
I like the proposal of Jmabel, here my comment and additions
Standards:
Categories should only be created for unique concepts. (RZuo) Agree We should avoid composite categories with concepts that are parent-child or siblings.
Three files and/or subcategories is a bare minumum to create a new category. Agree
Exceptions:
Four or five files is the minimum if the files already group together as part of an existing category with less than 200 images. Neutral
Two files if they have three or more parents in common. This is to avoid multiple overcrowded categories with the same files and to create better overviews. (added by JopkeB)
Two files or subcategories if there is already a Wikidata item (note: there should always be a Wikidata item if there is a Wikipedia article) Agree
One file or subcategory when it is part of a sequence or systematic breakdown of another category. Agree
One file if it is expected that more photos come easily, e.g. living celebrities, buildings. It makes it much easier to categorise new files with an established category. Agree
One file or subcategory if you are a user with knowledge of a concept and it is a notable subject. Agree
Should we allow empty categories? For instance because they are useful for tools and new users, and they can also speedup the workflow of experienced users, for subjects where we expect to get photos of in the near future, created by users with the knowledge of a concept, "by year" categories. Oppose I am not a supporter of creating and keeping empty categories. I can see the advantages but I doubt whether they outweigh the cons such as the mess described by Adamant1 on August 9. They should be very scarce and they always should have a note or template, like Adamant1 suggests, why they exist.
That sounds reasonable to me. Except with the caveat for number 4 that we shouldn't allow for one file or subcategory when it is part of a sequence or systematic breakdown of another category if either one is "by year" or has anything to do with "by year" categories. I agree with it other then that though. --Adamant1 (talk) 10:30, 11 August 2023 (UTC)Reply[reply]
With the empty categories we maybe could make a guideline that they have to be maintained by an active WikiProject or by an annual photo competition. GPSLeo (talk) 10:52, 11 August 2023 (UTC)Reply[reply]
Of course it is and should remain allowed to create a category with only 1 file, or just with a non-empty subcat. And if this category can be linked with a Wikipedia article and a Wikidata item via WD infobox, this is not only allowed, but also encouraged. Regards --A.Savin 12:17, 11 August 2023 (UTC)Reply[reply]
Hi, in my opinion the answer to the question is very much: "it depends". I would split possible categories into two kinds: specific (about 1 event/object/person: these categories should be allowed to be as tiny as needed) and non-specific (about any event/object/person that fits the criteria)
For the first:
there are very useful category structures where I create a new category just for a single picture, to complement the other branches of the same category tree. (Category:1977 elections in Morocco, which is part of "1977..in Africa", part of "..in Morocco by year", etc. I hope we will get more stuff in it, but one file suffices already.)
there are well-defined categories, like about one special book title. (Category:Stalky & Co. is perfectly fine with just 2 files. Although: If it's just one file from/about a book, I'd still prefer that file being properly categorized, without a new category.)
For the second:
I find three images on Commons depicting "Porcelain vases with horse paintings". That may seem to be a very clear category definition, possibly falling under "Porcelain vases with paintings" and "Horses in art", but it's still an arbitrary definition and with too few files matching the criteria. I'd rather supper "Horses in porcelain art", and then splitting that further as soon as the category grows too large, probably first dividing into statues and paintings. 6-10 files should be a minimum for such groupings.
this also goes for "location in time"-categories. Any event/work/building/map/photo/person/etc related to the history of Krakow, and created/photographed/happening/died/etc in 1879, may go into "1879 in Krakow". The definition is vague and arbitrary in a different way here, but still: There is currently one file. (Category:Kraków in the 1870s holds 7 files in total, but uses four categories to do so.) So for "history of location"-categories, I'd prefer "by decade" over "by year" and only create the latter once the decade-category gets overcrowded.
I sometimes find categories that are too small and if I am invested enough, I actively seek dissolution. Category:1840s maps of Lithuania now has 9 files which have previously been spread over 8 subcategories. I moved the files to the parent cat, and will at some point in the future ask for the deletion of the (now empty) sub-cats. As long as we don't suddenly get an influx of dozens more 1840s maps of Lithuania, these by-year-subcats are just too granular to be useful.
In other cases I often find categories that are "too small", but I'm not invested enough to start a debate: Category:Voting lines in India is granularly sub-divided by states of India, sometimes with just 2 pictures. That is in my opinion not how it should be, but it fits into "<theme> in India by state", so I'm not complaining.
These are my thoughts, I think my opinions overlap a lot with Jmabel and Jopkeb --Enyavar (talk) 12:22, 11 August 2023 (UTC)Reply[reply]
Comment Empty categories are useful for "year maps of country" (Category:1850 maps of India) or "year books from country" (Category:1550 books from France), as if the category is missing, it breaks the navigation via the template. These cases there are many potential files for them. Yann (talk) 12:33, 11 August 2023 (UTC)Reply[reply]
Thanks for the comment, and I fully agree on "year books from country", but... Comment "year maps of country" stops being useful the further you go back into the past: Maps were drawn years after the surveys, maps were reproduced unchanged for years, decades and even centuries, maps were dated wrong by authors, archives and later by the uploaders, etc. So, I support navigation templates, but for most maps before the 20th-century, we shouldn't do breakdowns by year, but by decades instead. With exceptions for when there is lots of material of course. This whole thing is slightly off-topic here and I have pages more cases and material to discuss, so I leave it at that until me make it a whole own topic. --Enyavar (talk) 19:40, 11 August 2023 (UTC)Reply[reply]
For named entities - specifically notable people - single file categories should be accepted and their creation should be encouraged. Even if it contains just one file, an individual category provides links to corresponding articles, increases the chance that further uploads are fully categorized and keeps the topical category pages tidy. Why would it be better if a category like Category:Members of the 11th German Bundestag contained 73 single files instead of the additional 73 single file categories for the respective persons? --Rudolph Buch (talk) 18:21, 11 August 2023 (UTC)Reply[reply]
Take a more zoomed out perspective on this. The main purpose of Commons is for people to find media related to a subject, Not information related to it. To the degree that we do provide such information that's what file descriptions are for. In your example someone is either going to want to find "Members of the 11th German Bundestag" or an individual person who was a member. So in that case they will either search for Members of the 11th German Bundestag" which will give them the category so find images of multiple members, or they will search for a specific name and go the file for that person. If you create a category for each individual member your just create pointless intermediary steps that people looking for "members" have to go through to get the images. Like if I want images of five of them, I now have to go to the main category, click into the individual category, click the image, download it, click back into the individual category, click back into the main category, and do it all over again multiple times. It's just obtuse and creates browsing dead ends.
Whereas the person who wants in image for a individual member can already do that using the search box and clicking on the image of the person. So the category adds nothing. Same for the infoboxes since the information will (or at least should) already be contained in the file description. At least IMO the point in infoboxes is to provide general information about a subject people are browsing images related to. It acts as an orientation point. It's less about providing the raw facts to people who are looking for them because we aren't Wikipedia. It's not like we can't just link to Wikipedia or Wikidata in the file description either. But you want browsing images to be intuitive and have as little end points as possible. The ability to find out someone's birthdate in an infobox shouldn't come at the cost of adding 5 more levels of clicking to the user interface. You see that with "nested" categories that only contain a single category and no images a lot. There's instances out there where it turns into a game of clicking through 12 empty nested categories just to get to the a single image. At which point the person looking for said image has probably long wondered off out of frustration and found it through Google Image Search. --Adamant1 (talk) 19:28, 11 August 2023 (UTC)Reply[reply]
You are right, single files should (usually) not get their own category, and I'm also a skeptic when it comes to empty categories. But once there is a second photo of a notable person, they are eligible for their own category (as per here), in order to have all media related to the person in the same place, and that includes removing them from other categories. Commons' categories are not curated image galleries, and "Members of the 100th U.S. Senate" has the same "problem" as the 11th BT above. Cheers, --Enyavar (talk) 20:58, 11 August 2023 (UTC)Reply[reply]
@Adamant1: These issues are the same whether there´s a minimum of one, two or ten files for an individual category. With any minimum number you still have personal categories, just not for all of the files. And a mix means you got to look in two places instead of one. Mostly you describe a different problem: In many categories we do not distinguish between "feature of the related entity" and "feature of the actual motive". Our rules stipulate to categorize the image of a dinner plate under category "Mayors of New York" if the owner was one of those. I prefer to have the plate (or tombstone, residence, pencil sharperner etc.) in the specific mayor´s named subcategory, even it´s the only file there. Apart from that I agree that we have too many non-essential and non-reliable categories relating to people.- --Rudolph Buch (talk) 22:33, 11 August 2023 (UTC)Reply[reply]
I prefer to have the plate...in the specific mayor´s named subcategory, even it´s the only file there. I have to disagree there. It's probably good to assumepeople will be looking for images of the mayor if they are searching for their name. Not some random plate that they eat dinner off of once. Whereas, people who are looking into plates will be interested in the image regardless of whom owned it. I could maybe see it for members of higher office, but we usually have other images of them in that case anyway. More broaderly though categories shouldn't be created unless the category will contain at least one image directly related to the subject. Otherwise the image should just go somewhere else. I don't think we should be creating categories for every person that we happen to have an image related to though. Otherwise we'd be creating single file categories for every non-notable person we have a passport, letter, gravestone, or whatever for. Which clearly wouldn't be useful. So you have to draw the line somewhere. --Adamant1 (talk) 22:57, 11 August 2023 (UTC)Reply[reply]
@Rudolph Buch: I suspect your use of "motive" here is a false cognate from another language. I don't know what you mean by it. "Motive" in English means a reason for doing something. - Jmabel ! talk 23:47, 11 August 2023 (UTC)Reply[reply]
Right. ("Motiv" in German can have two meanings: Reason for doing something, same as motive in English, or "what is depicted in a picture". Deepl tells me I should have used "subject" or "motif" instead - which seems strange as the "Sujet" and the "Motiv" of a picture mean very different things in German.) Rudolph Buch (talk) 00:25, 12 August 2023 (UTC)Reply[reply]
@Adamant1: the issue presumably isn't creating single-file categories for non-notable people where we have one artifact related to that person. I suppose there is someone who would consider doing such a thing (I've seen some seriously useless categories) but the issue there would be more about having an artifact related to a notable person when we don't actually have a picture of that notable person. I could easily imagine that happening with someone reclusive who doesn't like having their picture taken. For example, we happen to have pictures of Thomas Pynchon from the 1950s, but he's pretty much avoided having his picture taken since; we'd want Category:Thomas Pynchon even without those. If we ever had an image related to Elena Ferrante, we'd probably want a category for her, even if we still lacked a photo of her. - Jmabel ! talk 23:55, 11 August 2023 (UTC)Reply[reply]
Since there was no addition for a few days, I think it is time to draw conclusions and decide what next steps to take.
Conclusions
There is no guideline yet.
Opnions vary a lot. What do we agree on?
Standards:
Three files and/or subcategories is a bare minumum to create a new category.
Exceptions: the minimum should be:
Four or five files if the files already group together as part of an existing category with less than 200 images.
Two files if they have three or more parents in common.
One file or subcategory if there is already a Wikidata item.
We do not agree on:
Allowing empty categories. So I suggest to keep the current policy of not having empty categories.
Categories with only one file or subcategory in special cases, and there is no Wikidata item yet. I suggest to allow them to be created scarcely and leave it to the judgment of the editor whether to create one. Though often it would be better to have such single files and subcategories in a more general category.
I have no problem with any of this, as long as it is understood to be a guideline, not a rigid standard. There will always be some reasonable exceptions. - Jmabel ! talk 15:42, 15 August 2023 (UTC)Reply[reply]
I did not take part in the discussion, but was reading along and I also think these are all good points that could be included as a guideline in some way. Kritzolina (talk) 15:58, 15 August 2023 (UTC)Reply[reply]
Commons:Categories is an official policy though, and this appears to be a significant change if we were to place it on that page. I don't think it fits there, but rather into Category:Commons_guidelines, where we can even create a longer abstract, or examples/cases. --Enyavar (talk) 16:01, 15 August 2023 (UTC)Reply[reply]
Yes, I agree, also with a longer abstract and examples. So it will have a page of its own, something like Commons:Amount of elements in categories? I am open for a better name. Then there could also be a paragraph about the maximum amount, with long lists as an exception, but that is another discussion.
Questions:
Do you agree to have a guideline for this matter with our conclusions?
What would be a good name for such a page?
How do we implement this? Should we discuss the content of the guideline here, or does someone make a proposal and shall we discuss it on the Talk page of the new page?
I say implement it. Adding some examples would be helpful to but they can always be added after it's implemented. --Adamant1 (talk) 04:37, 16 August 2023 (UTC)Reply[reply]
If we call it „Best practice“ and not a strict guideline or even policy I would be fine. And the {{Prospective category}} should still be usable. GPSLeo (talk) 05:14, 16 August 2023 (UTC)Reply[reply]
What's wrong with it being a guideline? If we just call it a "best practice" then there's no reason anyone would follow it. Plus there would just be the same kind of arguing over when to create categories or not that already exists and this is suppose to hopefully solve. The whole point in this is to figure out standards that can (and should) actually be followed. Not just to write a toothless essay about "best practices" that will just be ignored. --Adamant1 (talk) 05:36, 16 August 2023 (UTC)Reply[reply]
Strict guidelines for a category system that has to handle complex edge cases could lead to disputes on cases where following the guideline is not the best solution. GPSLeo (talk) 11:28, 16 August 2023 (UTC)Reply[reply]
I don't really see how it's strict to allow them to be created in some cases or to leave it up to the judgment of users whether to create the category or not. Especially if the guideline includes examples. That's essentially how things are done now. It will just be more formal. As to it increasing disputes, there's plenty of disputes already that are caused by there not being a guideline. I don't think there will be more if there is one because a person can just use their judgement and create the category if they want to. Baring a few specific instances that will covered by the guideline, but they already can't create categories in those instances anyway, or at least they will receive push back and be blocked if they do. This just makes it more formal so it doesn't take them re-creating the categories and people leaving them multiple warnings not to create the categories before it's can be dealt with. --Adamant1 (talk) 12:01, 16 August 2023 (UTC)Reply[reply]
1. Yes, I think it is a good idea
2. Commons:Minimal requirements for categories
3. I think we should create a page and discuss on the talkpage of the Commons:Categories page where to link it Kritzolina (talk) 06:19, 16 August 2023 (UTC)Reply[reply]
Thanks, Kritzolina, for your input and clear answers to my questions. Only, "Minimal requirements" is much broader than only the amount of files and subcategories, and is already largely covered by Commons:Categories. JopkeB (talk) 16:19, 16 August 2023 (UTC)Reply[reply]
I don't think we should have a rule on minimal number of files in a category, apart from disallowing empty categories. Whether a category is useful or not, is seldom a matter of the number of files in it, but much more frequently of its scope, naming, formal correctness, and quality of its media content. As Enyavar correctly pointed above, it depends. Thanks --A.Savin 12:06, 16 August 2023 (UTC)Reply[reply]
There's cases where its clearly not good to create categories that only contain a single file or category. For instance by year categories where there's only one file for a single year in the decade. There's currently nothing stopping people from doing that. In fact a user recently did it in mass for "stamps by year" categories where the stamps from the years he was created categories for were copyrighted, and refused to stop until he was eventually blocked. Maybe I'm being naive, but I'd like to believe things like would be curbed or at least easier to deal with if there was a guideline making it clear not to create categories in such an instance. --Adamant1 (talk) 12:19, 16 August 2023 (UTC)Reply[reply]
Agree I prefer a guideline as well. There are 96 million files now, and perhaps hundreds of editors (or more). To let them categorize more or less the same way, let them not make a mess of the categories and to avoid disputes over and over again, we should have enforceable rules/guidelines. JopkeB (talk) 16:32, 16 August 2023 (UTC)Reply[reply]
Strong oppose any hard line on the minimum number of pages in a category above 0. Empty categories are already subject to Speedy Delete, so no change required on that. There are thousands of categories with only 1 or 2 files in them that are perfectly valid, so a policy to not allow 1- or 2-file categories anymore would be a huge problem. Categories with a well-developed set of 'by country', 'by year', 'by quantity', 'by color', etc. are a good example of this. Let's take a use case:
A user uploads an image of a green item. They see that categories exist for red, orange, and blue items of the same kind, but there is none for green items. Normally, they could simply create the green item category and add their image to it, but the proposed 3-item minimum would prohibit that action unless they additionally commit to searching around and finding an additional 2 green item images to add to the category as well. For an experienced category crawler, this is not a high bar, but for a lot of users, this is going to incentivize them to no longer sort their uploads by color (in this case) and instead just dump them in main categories, leaving the load to others to diffuse them.
I'm all for encouraging such a user to then go to the main cat and move green items into their new category, but that should merely be encouragement, not policy.
Adopting such a policy would cause all existing 1- or 2-file categories to be targeted by well-meaning users seeking to comply with this policy, either by calling for their deletion in COM:CFD or just simply taking direct action themselves to delete large numbers of existing categories on the basis that they have fewer than 3 files.
Note also, by giving a minimum number, not only are you communicating that no category should have less than that number, but also, inherently that any category with at least that number is perfectly fine. You might not be meaning that, but that is the message that many readers will take away from it. That will make this ammunition for nonsense categories to be defended on the basis they have more than 3 files in them.
Of course, I note the exception for those with WD items, but this has its own issues. Does this mean that it is perfectly fine to create 1-file nonsense categories as long as the user creates a WD item to go with it? The existence of a Commons category is on its own justification for a WD item, according to WD notability policy. So making a the existence of a WD item a justification for a Commons category just seems like a circular logic chain at that point.
I'm also not sure why this would need to be spelled out in any place different than COM:CAT itself, but since I oppose this policy period, I suppose that might be a moot point what page it is put on.
I do like some of what King of Hearts and Crouch, Swale have come up with at Commons:Category inclusion criteria, as it is more nuanced and covers more of the different use cases that exist for categories. I haven't fully digested it and might have some detail reservations before supporting adopting it as more than an essay, but it seems to be a significant improvement over the arbitrary rules proposed in this discussion.
Personally, I think whether sub-categories make sense or not has more to do with the content of the main category than on any specific number of images for a specific sub-category. If there is a product with 6 images, 4 or type A and 2 of type B, this policy would mean a category for type A is okay, but not for type B. In my mind, that is nonsensical...we should either have a subcategory for each type or a subcategory for both type. The decision should be based on the parent category and whether it is useful to diffuse that category by a given criteria. Josh (talk) 18:44, 18 August 2023 (UTC)Reply[reply]
The proposed guideline should point out that users should look for certain aspects to judge whether or not a "tiny" category makes sense for the grouping of images that they wish to apply it to. As far as I understand guidelines, they are purposefully notpolicies or hard lines, but essentially infomaterial. (Like most guidelines, most people won't read or know them, but they can be great to show to inexperienced users to explain some practical considerations around categories). I'd also like to note that we do have a category for green items. We do not have a category for "Porcelain vases with horse paintings", and I while that appears to be valid category name, I would still discourage people from creating it without overarching structures being in place (see my comment pretty much at the start, regarding specific and non-specific categories). --Enyavar (talk) 19:19, 18 August 2023 (UTC)Reply[reply]
@Joshbaumgartner: As Enyavar says, guidelines aren't hard and fast rules; they are descriptions of what is normal. Also, your hypothetical "green items" would be fine, because it is part of a breakdown into parallel categories (essentially, one of a series, even if in this case a series with no particular order). - Jmabel ! talk 20:29, 18 August 2023 (UTC)Reply[reply]
@Jmabel: I agree that there is a difference between guidelines and policies. However, the wording of this proposal, regardless of whether it is officially labeled as a policy or a guideline, is very specific and has all of the hallmarks of being a bright red line. Many users are not fully aware of semantic difference guidelines and policies, and so if it is only to be a guideline, it should be written as one. Language such "standards" and "minimum" and using exact numbers are the language of rules and are appropriate for policies. If we really want to just have a guidline, language changes should include:
Replace "Standards:" with "Guidelines:"
Replace "Three files and/or subcategories is a bare minumum to create a new category." with "It is preferable to add multiple (ideally 3 or more) files or sub-categories when creating a new category."
Replace "Exceptions:" with further guidelines for other situations. Exceptions apply to rules, in that they are a list of acceptable cases that don't fit within the predescribed rule. Guidelines don't need exceptions, just simply list any further guidelines that might apply.
For the most part, the proposals under Exceptions are too specific to be needed in a guideline,
You yourself noted that it was important that this proposal only be adopted as a guideline, not as policy. We are in agreement on that. It is important however that we not just label it as a guideline, but write it as one as well. The original proposal was not presented as being only a guideline (or at least that wasn't made clear), and it was following comments such as your own that mentioned it should be a guideline. To that end, my opposition to a hard line policy remains, and it sounds like you agree that a hard line policy should not be adopted. As a guideline, if rewritten as one, I could see some value in it, see Commons:Category inclusion criteria as a good example of that kind of thing. Josh (talk) 21:04, 18 August 2023 (UTC)Reply[reply]
@Enyavar: It is not clear whether the original proposal is intended merely as a guideline, or as a policy. The fact that it is written like a policy not a guideline doesn't help. See my note above on some ideas on how to reword it if it is to be a guideline. I'm not sure what you are going on about green items for (Category:Green items actually does not exist), my comment was not specifically about Green objects (what you actually were think of?), it was a hypothetical...replace 'green items' with 'green foos' if that is easier to get as such. It sounds like you agree with my opposition to adopting this proposal as a hard line. Hopefully, we can do some rewording to ensure that if adopted as a guideline, it doesn't get mistakenly mis-applied as a policy. Josh (talk) 21:15, 18 August 2023 (UTC)Reply[reply]
So far, I think this is an affair of shadowboxing in the ivory tower. I am unaware of any proposed text that might get included into the possible future draft of a suggested guideline page. Once I find such a text, I will gladly participate in the discussion about how to amended it, so that it won't be understood as a hard guideline: The principle of having guidelines for categories is something I support, as long as it doesn't become restrictive, which was why I dropped my 2c in the first place. I still think that we can distinguish our categories into "specific" vs "unspecific" (or however we name that concept ontologically), and build the recommendations around that. Either way, there will be divergent and special cases that I/we/you haven't even considered yet and that will mess up the first guideline draft - regardless how the guideline turns out. --Enyavar (talk) 21:44, 18 August 2023 (UTC)Reply[reply]
That's what I was going to say. No proposal is the completely, fully fleshed out guideline. Also, Jmabel said at the beginning of the discussion "I agree that there is no solid guideline, and I'd hate to create something rigid" and their comment is what the proposal was based on. No one has said they think it should be a policy or hard and fast rule in the meantime. I've actually gone out of my way several times to call it a guideline and said it should ultimately be up to the user to decide when it's appropriate to create single file categories, baring a few examples that everyone agrees on. So this is clearly an exercise in shadowboxing. Could the specific wording of the guideline be ironed out once it's implemented? Sure, that has nothing to do with the merits of the proposal though. Again, no proposal is the final, complete, document and no one is saying that specific wording can't or won't be changed once the guideline is actually written out. --Adamant1 (talk) 22:09, 18 August 2023 (UTC)Reply[reply]
Josh wrote: "The existence of a Commons category is on its own justification for a WD item, according to WD notability policy." but that is not quite right, only for exceptions, see Wikidata:Notability nr. 1.4:
Category items with a sitelink only to Wikimedia Commons are not permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as Commons-categorie category for pictures taken with equipment (P2033).
I think if there is a Wikipedia article or otherwise its likely the topic would be notable then generally only 1 page is needed. Many places like the Brosdale Island example may currently have only a few pages but obviously more can be added if more images are uploaded. If someone wants to take a few pictures of a named building and upload them I don't see why we can't have a category as it could still have more images and defining it is easy. If someone wants to take pictures of say a cloud or small plant without a name and upload then then having a category for cloud at 7 June above Summertown, Vermont for a few pages would be a bit more dubious though. Generally I'd say there are not many rules with notability as, if a topic isn't notable then its likely the images (say of a person or company) can be deleted as being out of scope and then the category deleted as empty. Crouch, Swale (talk) 08:42, 19 August 2023 (UTC)Reply[reply]
Summary of the remarks on the conclusions of 15 August + new questions[edit]
It should be a guideline, not a rigid standard.
Our conclusions should not become a part of Commons:Categories (official policy), but of Category:Commons guidelines, where we can create a longer abstract, and/or add examples/cases.
Someone can start the page with a first text, others can add examples and other remarks, we can discuss the proposal on the Talk page.
Remarks about the content:
Because it is only to be a guideline, it should be written as one, and not have words like "standards", "minimum" and exact numbers. The original proposal was written as a policy, so it should be rewritten as a guideline. At least some words and lines should be replaced:
Replace "Standards:" with "Guidelines:".
Replace "Three files and/or subcategories is a bare minumum to create a new category." with" It is preferable to add multiple (ideally 3 or more) files or sub-categories when creating a new category."
For the most part, the proposals under Exceptions are too specific to be needed in a guideline. At least replace "Exceptions:" with "Further guidelines for other situations".
The guideline should point out that users should look for certain aspects to judge whether or not a "tiny" category makes sense for the grouping of images.
as long as it's a unique concept and it can be linked to wikidata (including but not limited to instance of (P31)=human (Q5)/building (Q41176)), i will create a category even if there is only 1 element, and i will oppose its deletion even if it's empty.--RZuo (talk) 11:49, 22 August 2023 (UTC)Reply[reply]
@RZuo: doesn't that potentially become circular? You can create a Wikidata item for virtually anything that can be defined, so this could allow virtually anything to be turned into a category. For example, for an area I've worked in, Wikidata would consider it acceptable to create an item for every identifiable individual who ever taught school in Seattle Public Schools, but surely we don't want a separate category for each of those people from whom we have one photo. - Jmabel ! talk 18:13, 22 August 2023 (UTC)Reply[reply]
my personal standard is higher than what's practised here on commons. there're plenty of cats that cannot be linked to wikidata, e.g. Category:Brittany Wagner (model).
(clarifying what i mean by linking to wikidata. i would create an item only if statements about its existence on other notable websites can be added. again, my standard is higher than what's practised on wikidata. there're items that hinge on a single mention in some obscure databases, e.g. most of the "scholarly articles", most cbdb entries like Yuan Kuangfu (Q65920297)...)
i dont create items for every teacher in public high/primary schools, but every professor in a university should be eligible for a wikidata item. if someone creates those items, that's their problem.
the proposed mechanic rule would rule out perfectly normal things, but fail to prevent trivial things that would pass the rule.
i use common sense.--RZuo (talk) 19:20, 22 August 2023 (UTC)Reply[reply]
one easy way to generate enough number of elements for any category of a unique concept is uploading pronunciation of its name. you can set your number to be as much as 60 but then people just need files in 61 languages, or have both male and female recordings in 30 languages. so easily bypassed, what stupid rule is that? RZuo (talk) 19:20, 22 August 2023 (UTC)Reply[reply]
What upscaling AI are we recommending, the ones I have used previously are no longer free, they now watermark the free version output. --RAN (talk) 16:14, 11 August 2023 (UTC)Reply[reply]
In general, we recommend against upscaling photos. - Jmabel ! talk 23:59, 11 August 2023 (UTC)Reply[reply]
So long as we have the original and properly categorize the final product as upscaled, I see no problem with upscaling. It simply makes the image bigger without increasing the noise and grain. When Sir Peter Jackson applies it to historic images, he gets awards. It is no different than photoshopping out a crack in a glass negative, or even cropping an image, or removing the background, or desaturating a sepia image to black and white, or adjusting contrast and brightness. We use what tools we have available to improve an image. --RAN (talk) 03:56, 12 August 2023 (UTC)Reply[reply]
It is impossible to increase the resolution (i.e. resolving power) of an image using software (outside of lens profiles and similar methods based on technical data). The algorithm will create a new and larger image that should seem compatible with the original image, but which will feature artefacts of various sorts, such as missing smaller features that are not resolved in the original image, introduce patterns and shapes that are not real, and so on. It is thus comparable to retouching and photoshopping. Upscaling can be done on images downloaded from Commons for those who so desire, but they should generally not be uploaded to Commons unless they are marked with a template equivalent to {{Retouched picture}}. Personally, I would prefer that they are not uploaded at all, unless to illustrate upscaling technologies. --Njardarlogar (talk) 18:13, 13 August 2023 (UTC)Reply[reply]
Everything you said there would be anathema to an institution archive, or even indeed to a professional researcher. It's important to keep the original image intact, especially if it's a tiff. Tiffs are reference files that can be exorted as jpg's which are friendlier to website's and scale so much better. "Improved" copies are permissable too, but they are just that copies. Broichmore (talk) 14:02, 14 August 2023 (UTC)Reply[reply]
This Commons Project should be a resource for authentic, credible and verifiable photographs and files for its long-term viability. Artificial Intelligence ( AI ) alterations and creations will need continuous discussion (like here) and perhaps more COM:AI policy modifications.
See this current Deletion Request (DR): Commons:Deletion requests/Files uploaded by Giorgio Pallavicini found among these creations here Category:Photos modified by AI This DR includes some terrible algorithmic output. I did not realize (until I found this DR)- is that some of these AI alterations are being used instead of or substituted for the original image(s) on Wikipedia projects worldwide. Some Wikipedia editors may unknowingly choose an AI altered photo. Given a transparent file name that clearly states it is an AI modified file, editors may choose an unaltered, non-AI photo instead.
For instance, File:Aspasia Manos 3.jpg, this file name does not mention that it has been altered by AI, modified by AI or a "retouched picture." This AI modified file was created from the non-AI File:Aspasia Manos 2.jpg. Many persons do not click to open and read the full file page, nor check the categories to find out if an image has been modified by AI or non-AI.
Perhaps, a proposal is needed to require that file names clearly state that the file has been "altered by AI" or "modified by AI." -- Ooligan (talk) 20:19, 15 August 2023 (UTC)Reply[reply]
The so called original of this Aspasia Manos is from pinterest, it's also likely to be faked. In any event its a candidate for deletion as there is no attribution or reliable source here. It contravenes many of wikipedia's policies, and criteria. Broichmore (talk) 14:41, 17 August 2023 (UTC)Reply[reply]
Category:Nude men with visible pubic hair (and of course many will not want to click on that) has five nonexistent parent categories, one extant parent category (Category:Men's pubic hair), and a navigation template show 12 hypothetically related categories, none of which exist. I discovered this category only because a picture I took of a naked cyclist in a parade got placed in the category.
I'll say it straight out: I'm done trying to clean up sloppy work in categories related to naked people, including but not limited to some categories that seem to me to be of only fetishistic interest (e.g. Category:3 women with nude men, which has similar problems with nonexistent parent categories). Would someone who values these categories please take on the work of cleaning them up?
I'm also probably done with licensing photos of things like the Fremont Solstice Parade in ways that are compatible with Commons, because I find it very disrespectful to the subjects of these photos that their images are ending up in these fetishistic categories. Nothing against Commons covering fetishism, but a good deal against mixing nudism and fetishism as if they were the same thing. - Jmabel ! talk 00:14, 12 August 2023 (UTC)Reply[reply]
How is "3 women with nude men" fetishistic and disrespectful? If I was to ask an AI to describe the image, that is what I would get. --RAN (talk) 04:02, 12 August 2023 (UTC)Reply[reply]
@Richard Arthur Norton (1958- ): because it is hard for me to imagine anyone particularly looking for that of they didn't have a CFNM fetish. But if that's not a good enough example, how about Category:Topless men showing chest hair? (These are just a few examples out of dozens, and of course there are far more objectifying categories about women than men.) And if you consider these categories fine, then you can feel more than free to be the one who addresses issues like having five nonexistent parent categories and a navigation template show 12 hypothetically related categories, none of which exist. - Jmabel ! talk 16:52, 12 August 2023 (UTC)Reply[reply]
Why not talk to the creator of the navigation template? Trade (talk) 18:03, 12 August 2023 (UTC)Reply[reply]
The Category:Topless men showing chest hair is a very curios one as visible chest hair requires to be topless. And the {{People nav}} template on the page is even more useless. "Topless babies (female) showing chest hair"? Really? Category links should at least make sense on a biological basis. GPSLeo (talk) 18:06, 12 August 2023 (UTC)Reply[reply]
(Parenthetically, it is certainly possible for a man who is not topless to nevertheless have some tufts of chest hair poking out of the top of his t-shirt.) -- Ikan Kekek (talk) 17:08, 14 August 2023 (UTC)Reply[reply]
Unfortunately we dont live in a world where templates understand context Trade (talk) 18:12, 12 August 2023 (UTC)Reply[reply]
But it is possible to set a parameter in the template. GPSLeo (talk) 19:27, 12 August 2023 (UTC)Reply[reply]
Here's another example, in this case about "depicts" rather than categories. File:2019 Fremont Solstice Parade - cyclists 40.jpg has three "depicts": naked man (Q80223335), male pubic hair (Q90418373), and human penis (Q8124). When I look at the picture (which I took) I mostly notice that it is a bunch of body-painted people on bicycles and roller skates, including a man on roller skates playing a ukelele. Yes, there is one visible penis in the picture, but you practically have to play "Where's Waldo" to find it. - Jmabel ! talk 17:30, 12 August 2023 (UTC)Reply[reply]
Why can not we just remove red category links from the files? Or is there something I possibly misunderstand? Ymblanter (talk) 18:56, 12 August 2023 (UTC)Reply[reply]
@Ymblanter: feel free, at least as far as I'm concerned. I'm just saying I'm not taking on polishing these particular turds. - Jmabel ! talk 21:35, 12 August 2023 (UTC)Reply[reply]
@Trade: may I ask why, on a photo that shows an entire human from the knees up (several, actually, but only one appears to be male) and where a penis makes up less than 1% of the area of the photo, you choose to add human penis (Q8124)? The picture also depicts a face, a chest, arms, body paint, and also a ukelele, all far more prominently than the penis. Why is this a good use of depicts (P180)? At best this is as if I said File:Donald Trump (53066688047).jpg (Cropped).jpg depicts incisor (Q273543). - Jmabel ! talk 21:47, 12 August 2023 (UTC)Reply[reply]
Probably some bias that has to do with unhealthy relationship of many people to their own body and the human body in general: they may think that every picture of a nude person where genitalia is visible was actually nothing more than a picture of genitalia (in other word(s), pornography). --A.Savin 21:59, 12 August 2023 (UTC)Reply[reply]
@A.Savin: Do you have any evidence to back up these rather demeaning charges as to the motivation of User:Trade? Josh (talk) 00:51, 18 August 2023 (UTC)Reply[reply]
No. But I find it laughable at least, to add merely the "Penis" statement and/or category to this picture, given the fact that there are lots of topics fitting here just as well, such as: "Man", "Woman", "Bodypainting", "Demonstration", "Ukulele", "Bicycle", "Leather", "Hair", "Chest", "Breast", "Nose", "Legs",... --A.Savin 09:33, 18 August 2023 (UTC)Reply[reply]
Discussing the de minimis threshold on categorization of an image is a perfectly valid one to have. However, declaring that a health disorder or bias is the probable motivation for another user's good faith edits without evidence is completely out of order and irrelevant to any valid discussion on the subject matter. Even if you had evidence, it would be at best an ad hominin argument. Josh (talk) 18:59, 18 August 2023 (UTC)Reply[reply]
Im just following the categories listed Trade (talk) 08:23, 18 August 2023 (UTC)Reply[reply]
We mark nudity so that people can filter out nudity in Google results. Google will blur nudity by default, so our categories and depict statements aids in those endeavors. --RAN (talk) 18:07, 13 August 2023 (UTC)Reply[reply]
@Jmabel: I can't speak to the motivations of the user in question. I can speak to the use of depicts (P180) in the structured data to add something seemingly only a minimal part of the image. depicts (P180) is described as a property to link any item "visually depicted in an image, literarily described in a work, or otherwise incorporated into an audiovisual or other medium" with the work it is depicted in. This is a pretty broad definition. It is worth noting that the more specific main subject (P921) also exists which is for the primary item(s) depicted in a work. This would seem to indicate that regardless of the amount of the work dedicated to depicting an item, so long as the item is depicted at all, depicts (P180) is a valid property for describing this relationship. Note also, that the option exists to mark any item under depicts (P180) as prominent. This adds weight to the idea that non-prominent items are valid to be added with depicts (P180), otherwise, there would be no need for such an option. All of the items you listed for both images may well be valid additions under depicts (P180). They may seem incidental to many users, but are perhaps consequential to others. As RAN points out above, these statements are not only used to find images of a particular item, but also to filter out images with particular items. Josh (talk) 19:16, 18 August 2023 (UTC)Reply[reply]
@Joshbaumgartner: that would be fine with me if someone were adding a good number of relevant categories, including far more relevant categories. I myself am still going to stop uploading images like this, given that they appear to be an excuse for a game of "where's Waldo, penis division". I think it's insulting to the person who is the subject of a photo of a body-painted man in a parade playing a ukelele when the image is described simply as depicting a naked man and his [barely visible] penis. - Jmabel ! talk 20:36, 18 August 2023 (UTC)Reply[reply]
Well, if he would only wield his ukulele more strategically, it could better emphasize the relative importance of the instrument. Elizium23 (talk) 20:49, 18 August 2023 (UTC)Reply[reply]
@Jmabel: I think there is a bit of conflation between adding categories and adding depicts (P180) in the structured data. There is certainly a relationship there, but each is its own distinct thing. I think if we are going to get into the nitty gritty, we need to be clear which process we are discussing.
That said, I would like to know more about your comment, "I think it's insulting to the person who is the subject of a photo of a body-painted man in a parade playing a ukelele when the image is described simply as depicting a naked man and his [barely visible] penis." I don't know that whether or not people are insulted by how their images are categorized is really all that relevant to our categorization scheme. Obviously, we should never be categorizing for the purpose of denigration or to cause offense, and if a non-derogatory option is available for naming or such that still meets the needs of categorization, then by all means, that would be preferable. Also, it sounds like one of your concerns is that we have categorized this image by a particular body part being in evidence, while not bothering to categorize by other depicted elements. I can certainly agree with the sentiment that most of us do not wish to be reduced down to our most sexualized body parts at the exclusion of the rest of what we are and do. However, in the scope of categorization, it would seem that what is wrong is that this image is not in Ukeleles (diffused appropriately of course), or other various things depicted in the image.
We have no control over how people will use the images they access on Commons. We do of course control how we categorize those images, but our categorization scheme can't make special allowances for how individuals feel about how images depicting them or created by them are presented. This is not because those individuals' feelings are not valid, but because it just isn't workable in a standardized system to do so. That said, releasing your copyright by contributing your works to this project is a choice. If you are uncomfortable with how certain images you have uploaded are curated, then as regrettable as it may be, I fully support your decision to cease uploading certain images. Hopefully though, it will become clear that the project (I can't speak to the motives of individual users, nor do I think they matter) is not seeking to demean or degrade either your works nor their subjects, so hence why I am interested in learning more about exactly what your thoughts are on this. Josh (talk) 21:39, 18 August 2023 (UTC)Reply[reply]
I feel that reducing an image of a human being to being an image of an array of body parts is objectifying and demeaning. Pretty much end of story, especially for me. And, yes, I see this done mainly in a sexualizing or even porn-ifying way. No one singles out that an image of a whole person shows an ear or a nose or an elbow. - Jmabel ! talk 01:48, 19 August 2023 (UTC)Reply[reply]
Thanks for doing the moves related to images of campuses — I've noticed a bunch on my watchlist, and it seems helpful! To help keep the categories organized, I was wondering, do you have any standards for how to define what is a picture of a campus vs. just a picture of a college?
Personally, to take a stab at it, I might define it as a picture where the physical built environment of the institution is the main focus. This would mean that most outdoor pictures would go in the campus category, unless there's some activity happening in them that is clearly the focus (e.g. as here).
I'm not quite sure how to deal with indoor photos. This dining hall pic is plausibly a photo of the campus, or maybe it's not because the focus is the dining hall rather than the campus at large. And if you zoom in a bit, this seems like it's not.
How do you propose we go about this? If we don't define some standards (and then articulate those standards at the category pages), they're going to get hopelessly muddled over time.
The problem is to find a definition for campus. Does a campus need more than one educational or research institution? Or can a singe university form a campus? If a single institution can form a campus what is needed to make it a campus and not just the area of an institute. What types of educational or research institutions can form a campus? A useful definition for our categorization system could be that an area is a campus if there are at least two categories for buildings on these area. GPSLeo (talk) 15:56, 13 August 2023 (UTC)Reply[reply]
Very interesting to me, because of Category:Campus maps which I always understood to be the plans/maps of multi-building institutions for education that have outer spaces larger than a mere schoolyard. (Which is why campus maps exist in the first place, a university/school/institution that doesn't require a campus map, doesn't have a campus. Mere floor plans for a single building don't count, btw.)
Now, en:Campus says that one might include non-educational campuses as well, which is not my understanding and should be a different category - maybe "company campus" or something. Anyway, interior shots should in my opinion be categorized according to the function of the rooms: Library, dining hall, lecture rooms, floors, etc. The "Campus area" that would be tagged as such, is outside the buildings. If you want to have all pictures in one category: that's why one needs to categorize by name of the institution, too. All the best, --Enyavar (talk) 07:14, 14 August 2023 (UTC)Reply[reply]
You have raised some interesting questions. I do not have definite answers to them. I believe subcategories are used for organizing files rather than defining the meaning of the term "campus". They are similar to the folders on your computer. That being said, having some criteria which files to be put under the campus subcategory is useful. For now, I put any file that the main topic of an image is a static physical object within the campus of the institution. It may be too board. Hence, a picture of a display may not be considered. Here are my tentative classification criteria:
Yes:
Outside of buildings
Sculptures
Open Spaces
Aerials
Maybe:
Inside of buildings
Paintings or murals
Experiment facilities or equipment
Displays or postings
No:
Protestings
Talks or presentations
Other activities
Feel free to move items from one category to another.
Regarding if a single institution can form a campus. I believe the answer is yes. However, it should consist of at least a few buildings, like @Enyavar said. It may also have multiple campuses. Here I use the meaning of a physical area of one or more institutions, rather than the individual institution of a multi-campus university system. For the latter, I refer them as institutions.
For interiors of buildings, there could be some dilemmas here. Since the subcategory of a specific building will be placed under the campus category, and inside the building category there will be some interior images, that may indirectly imply that those interior images are under the campus category as well. However, removing either the images from the building category or removing the building category from the campus category may also be problematic. That's why I put them in the Maybe classification above.
For the company campuses, there is at least one non-educational campus under category:Campuses in the United States. If there is a need (e.g. when there are too many subcategories), we can always split it into more specific ones. Xeror (talk) 09:44, 14 August 2023 (UTC)Reply[reply]
Some of the points are problematic. If "Talks or presentations" should not be categorized as campuses they could not be categorized to the building where they take place as the building is part of the campus. It is very common to categorize events in the location they took place. GPSLeo (talk) 12:27, 14 August 2023 (UTC)Reply[reply]
That'd be a question on whether the events should be categorized in the building or just a general category of events at that institution, and reserve the building category only for the images of the building. The first approach would not only create the same dilemma as the interior images problem, but also make most of the images fall under the campus category or its subcategories. Xeror (talk) 14:11, 14 August 2023 (UTC)Reply[reply]
I disagree with the direction this is taking. Some colleges and universities (e.g. Antioch College, originally only in Yellow Springs, Ohio, but now in multiple U.S. locations) and the University of Washington (originally in Downtown Seattle, later moved to the present University District, and still later with additional campuses in Bothell and Tacoma) are both examples where a single university has multiple campuses, which for many purposes function as separate institutions. We would want to put a protest or an official activity under the relevant campus. In fact, almost anything other than a photo of a person, symbol, etc. associated with the broad institution would probably belong with a campus as one of its ancestor categories. - Jmabel ! talk 15:17, 14 August 2023 (UTC)Reply[reply]
That makes sense for institutions with multiple campuses, but I think the simplest example is something like Category:Endicott College, which clearly only has one campus, but still has the separate Category:Endicott College campus as a subcategory. "Campus" there doesn't mean that an image falls relates to some subconcept of the college located in a different place (since no such subconcept exists), but rather that it relates to the college's physical environment, i.e. its campus. That seems like the better way to use "campus" for our categorization purposes, and to be consistent, that should apply even to institutions that have multiple locations. {{u|Sdkb}}talk 15:59, 14 August 2023 (UTC)Reply[reply]
Right, but still, if a protest takes place on a campus that's recognizable, the campus should be one of the categories for the image. -- Ikan Kekek (talk) 17:11, 14 August 2023 (UTC)Reply[reply]
It may entirely depend on the category tree in question. I have seen Category trees that have "Cat:Uni" with the subcats "Cat:Campus", "Cat:Buildings", "Cat:Staff" and so on. In that case, images showing just one Building from the outside, or its interior, don't really fall into "Campus", but "Building X". But all images of a student fair/presentation/protest/etc. in the open - those would be "Campus", as long as you can recognize the place as such. Pictures showing the entirety of Building A and Building B together with the trees in between, would go into "Cat:Campus", "Cat:Building A" and "Cat:Building B".
In another possible case where the category tree has the "Cat:Buildings" as child nodes of "Cat:Campus", I'd place the same picture just under "Cat:Campus", to avoid redundant categorizing. For both such cat-tree structures however, "Entrance hall of Building C" has to be placed in "Cat:Building C", not under "Campus" (as long as Building C has its own category). Of course, if a bland lecture room cannot be distinguished from any other, it would be placed under "Cat:Campus" or even the largest parent, "Cat:Uni".
I've studied both in a place with one large distinct campus, as well in a place with faculty buildings strewn all over the city, and only four of them somewhat grouped together. In my latter case, I would say that there is rather no campus at all, just various separate Uni-buildings. Jmabel's description of two distinct campuses just means (to me) that there should be two categories for them. Or seven, for seven Campuses, like the case of Category:University_of_São_Paulo. And extra-cats for all off-campus buildings of course.
The idea to harmonize categories is good, but I don't think we can define the ultimate criteria here, just rough guidelines. Not all unis have a full category tree, not to mention that they rarely have the same structure. Best, --Enyavar (talk) 18:30, 14 August 2023 (UTC)Reply[reply]
In my view, a campus is a contiguous piece of land which accomodates the buildings and associated facilities of an institution. Ideally the institution itself should use the name campus to describe the various pieces of land and associated facilities. Translating this to Commons, we could have
Category: University of ABC
Category: University of ABC, PQ Campus
Category: University of ABC, XY Campus
The latter two would be sub-categories of the first. They themseves would have further sub-categories. Images would be slotted into the appropriate category. From the point of view of categories, think of ABC as a country and PQ and XY as provinces of that country. I don't see the problem, or am I missing something?. Martinvl (talk) 20:14, 14 August 2023 (UTC)Reply[reply]
There is also "Category: University of DEF, PQ Campus" for shared campuses. And campuses shared by educational institutions and other organizations. GPSLeo (talk) 15:23, 15 August 2023 (UTC)Reply[reply]
In this case there would be a number of options, depending on how the campus is shared. Are all the facilities shared between the two institutions or are only some facilities (eg student accomodation, parking and sports facilities might be shared, but accademic buildings separate)? Such cases houd be handled on a case-by-case basis using common sense, otherwise the rules will become unwieldy. Martinvl (talk) 20:17, 15 August 2023 (UTC)Reply[reply]
Part of what I'm seeing in this discussion (which doesn't seem to be approaching much of a universal consensus) is the issues inherent in having a giant category tree, where we need to consider not just what it means for a category to have an image but what it means for all the categories above it. Someday we'll be using structured data to organize our content rather than traditional categories, and I hope that day isn't too distant. {{u|Sdkb}}talk 20:37, 15 August 2023 (UTC)Reply[reply]
The problem with Chinese unis is different universities used the same buildings in the campuses in different period of time. Haha, messier than spaghetti.
I largely agree with Martinvl's suggestion. To put it simply, treat university as an organisation and campus/building as a location/building. An organisation is a more abstract concept. It can have multiple locations and move from place to place. A building is fixed. It's a physically existent concept. Roy17 (talk) 12:31, 22 August 2023 (UTC)Reply[reply]
Okay, so taking stock of everything, I'm seeing several different viewpoints, but not much movement toward a consensus definition, let alone one we could enforce. Anyone have thoughts about how we could move toward something that'd concretely help us to keep these categories better organized? {{u|Sdkb}}talk 02:41, 24 August 2023 (UTC)Reply[reply]
I recently uploaded (via flickr2commons) around 180 images from the Flickr account of the U.S. Army's 3rd Infantry Regiment. Their images carry the Public Domain Mark (PDM) which is insufficient as proof of public domain on Wikimedia Commons, thus the files now have a warning template reflecting that.
I usually replace the warning template with the more specific PD US Army tag (as the 3rd Infantry Regiment is a U.S. Army unit). However, it will be extremely time-consuming to manually replace the tags on my uploads. Is there a more efficient way of replacing these tags that I am not aware of? SuperWIKI (talk) 04:45, 14 August 2023 (UTC)Reply[reply]
Seconding what C.Suthorn says. I do this sort of thing all the time. - Jmabel ! talk 15:19, 14 August 2023 (UTC)Reply[reply]
How can you best define which are the affected files? A range on your upload log? A category?
Especially if this is a simple category set, this is easy to do. Just ask, but please ask precisely (state the change, and to which files) as that makes it easier. Andy Dingley (talk) 15:24, 14 August 2023 (UTC)Reply[reply]
A consistent range on my file uploads. All of them start with "CSA SMA Change of Responsibility Ceremony, Aug. 4, 2023" with a bracketed number afterwards. SuperWIKI (talk) 15:31, 14 August 2023 (UTC)Reply[reply]
Question Why is a public domain mark insufficient proof of an image being in the public domain? Sometimes, I think we make too much work for ourselves on this site. -- Ikan Kekek (talk) 17:12, 14 August 2023 (UTC)Reply[reply]
@Ikan Kekek: because we try consistently to use license templates that indicate why each particular image is in the public domain, both in its country of origin and in the U.S. Just a statement that it is PD isn't enough for that. - Jmabel ! talk 20:30, 14 August 2023 (UTC)Reply[reply]
@Jmabel: The one exception is the license tags in Category:PD per authority, where we consider a third-party organization to be as rigorous as or more rigorous than we are at determining PD status, so we simply rely on that declaration without necessarily being able to independently verify why. -- King of ♥ ♦ ♣ ♠ 22:28, 14 August 2023 (UTC)Reply[reply]
@King of Hearts: Agreed, but I think you will find that each photo in the subcats there has a template of some sort that effectively explains the rationale for PD, even if that rationale amounts to "we accepted someone else's authority." - Jmabel ! talk 00:32, 15 August 2023 (UTC)Reply[reply]
Pardon my lack of understanding of VFC (I used it for the first time yesterday), but wouldn't that affect files that already have that and don't need appending? Or does that function include selecting individual files in said category? SuperWIKI (talk) 13:43, 16 August 2023 (UTC)Reply[reply]
you could simply use "Append everywhere (categories etc.)" when you were using flickr2commons. RZuo (talk) 22:18, 17 August 2023 (UTC)Reply[reply]
Separate from what follows: if the current rationale/tag is wrong, you should be using "replace", not "append". But back to the case where you are not concerned with that...
If you are using VFC to add a category to files you find as a result of a search, you can use "-incategory:" in the search to avoid including files already in the category.
If for one or another reason that won't work (e.g. not finding them by a search, or the string in question is about something other than a category), you can first use VFC to get rid of the string/category wherever it occurs, then use VFC a second time to add it to everything, so the result is that you end up with one instance on each file.
By the way, don't forget that when you are appending rather than replacing, you almost always want to start your string with a newline.
Commons Upload Wizard currently allows users to upload images from Flickr, where the licence used there is compatible with Commons. But there are many images on Flickr, with more restive licences applied, but where the content is in reality PD by dint of age, or ineligibility through simplicity. An example is File:Postcard Drawing of Marble Arms 1907 Gladstone Michigan.jpg, a 1907 postcard tagged here as {{PD-US-expired}} but with a by-nc-nd licence on Flickr.
Currently these can only be uploaded by a tedious process of downloading images to the user's machine, and uploading from there. Metadata then needs to be transferred manually.
I have suggested in the above ticket that trusted users should be given a right to use the tool wizard to upload such images (and then apply a suitable PD template), and have been asked to demonstrate consensus for this.
What is the criterion for a user to be "trusted" for this kind of uploads? For example there are many users with large upload counts who got this count by using the LinguaLibre tool (uploading recordings of their own voice), technically they are experienced users, but actually they may have no knowledge of copyright questions at all.
Also: Any programmer could create an external tool that makes upload by URL available to everyone (only limited by the positive/negative lists for allowed websites) C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 07:08, 17 August 2023 (UTC)Reply[reply]
Just my opinion as someone who does a lot of work with postcards and browses eBay for them a lot, but usually images of postcards and ephemera on eBay are either of extremely low quality or watermarked to the point that aren't worth uploading to Commons even if the actual image is actually good. So providing an easy way for people to easily import images from eBay just seems like a recipe for disaster. I like the idea of making it easier for "trusted" users to upload images from Flickr though. At least the image are usually pretty quality in that case. --Adamant1 (talk) 07:52, 17 August 2023 (UTC)Reply[reply]
The Upload Wizard is not intended for all cases. This will make the uploadwizard too complicated and increases the risk a lot of copyright violations to flow in. Would be better to have a simple tool on for example Toolforge that. A bit like https://www.geograph.org.uk/photo/3068937 having a direct link to upload the image. A tool like Commons:Flickr2Commons could support this. Multichill (talk) 10:36, 17 August 2023 (UTC)Reply[reply]
General response:
The meaning of "trusted" is to be decided by the community, as with any user-right. It is unlikely that the community would equate it to "experienced at making and uploading audio files"
This will not "increase the risk a lot of copyright violations", because only trusted users will be able to use it. In fact, the use of a tag in edit summaries will reduce the risk, because manual uploads such as those that occur at the moment are not tagged.
I suggested a separate tool, and the devs at the Wikimania hackathon responded that updating the wizard would be preferred.
Those devs have not raised any concerns that "This will make the uploadwizard too complicated "
We have well over 6000 images in Category:Images from eBay (and no doubt more that are not in that category). There is clearly a need to be able to upload images from the site.
I have previously asked eBay to add this functionality at their end (I know it was discussed at executive level) and had no response. Similarly, Flickr are unlikely to add it.
That said a browser-user script to add the functionality would meet my need, albeit maintenance requirements may be harder to satisfy.
I agree that we should have a tool, at Flickr you choose your default license when you create your account. I have hundreds of obituaries that are in the public domain in my Flickr accounts, I imagine other people are not even aware of their default license. --RAN (talk) 17:35, 19 August 2023 (UTC)Reply[reply]
Is this really a common enough scenario to justify creating a new workflow in UploadWizard rather than just uploading them manually? I'm skeptical. Nosferattus (talk) 00:21, 23 August 2023 (UTC)Reply[reply]
CommentThere is clearly a need to be able to upload images from the site. Just to clarify, I never said there isn't a need to be able to upload images from eBay. I upload them myself and the process could for sure be easier. Users having to go through the process of uploading images to their machine, re-uploading them to commons, and then adding the Metadata manually all (at IMO) act as important guard rails that keep low quality images being uploaded to Commons in mass. Otherwise people just browse a few images from specific sellers, assume all of their images are fine "because PD", and hit the easy import button regardless of the quality or if the images are in scope. That already happens to a degree with the Flickr to Commons tool. It's also important to point out that a lot of eBay sellers are extremely hawkish when it comes to images of their listings being copied. The fact is that the easier we make it for people to upload images from eBay the more likely it will be that sellers start watermarking said images, which doesn't benefit us in the long run. A slow, semi-tedious upload process makes sure that won't happen though. --Adamant1 (talk) 09:41, 23 August 2023 (UTC)Reply[reply]
Original discussion here was about Flickr. I don't really get why we are now talking about eBay.
Seems to me that if we wanted to do something like this it should be through Flickr2Commons or its proposed successor Commons:Flickypedia, not through the Upload Wizard. - Jmabel ! talk 16:27, 23 August 2023 (UTC)Reply[reply]
Lua error in Module:Autotranslate at line 72: No fallback page found for autotranslate[edit]
I'm having the Lua error in Module:Autotranslate at line 72: No fallback page found for autotranslate error message in both this template and a reserve one I made in order to fix the problem, but it repeats again.
I know it's a missing page I didn't create, but I've been creating templates for campaigns for years and never found such a persistent error like this one.
The "-base" thing is inherited from older templates I used as a model. Now I don't want to change anything for fear of breaking a template TaronjaSatsuma (talk) 17:06, 17 August 2023 (UTC)Reply[reply]
@TaronjaSatsuma: I am not afraid of that and cleaned up the three (!) interlinking templates to only have:
This image was provided to Wikimedia Commons during Wiki Loves Cosplay 2023 photo contest.
{{Autotranslate}} looks for a subtemplate <base>/<lang> with ultimate fallback to English. Base should always set to the name of the template, so "Wiki Loves Cosplay 2023" in this case so the default will be Template:Wiki Loves Cosplay 2023/en.
The /layout template is used used as a base template so all languages look the same
The /lang template is used for navigation between languages and can be filled with {{Lle}}
This sentence, “A South African work that is in the public domain in South Africa according to this rule is in the public domain in the U.S. only if it was in the public domain in South Africa in 1996, e.g. if it was published before 1946 and no copyright was registered in the U.S. (This is the effect of 17 USC 104A with its critical date of January 1, 1996.)” is not supported by the cited US law which applies only to restored work; thus, it should be removed or reworded to avoid confusion.
The law stipulates that "A) Copyright subsists, in accordance with this section, in restored works, and vests automatically on the date of restoration." and
"(B) Any work in which copyright is restored under this section shall subsist for the remainder of the term of copyright that the work would have otherwise been granted in the United States if the work never entered the public domain in the United States."
The confusion stems from including the “A South African work that is in .." in the template, which means any images that meet the South Africa PD 50 years criteria can be deleted or considered copyvio when they are not. OR the wording should be amended to align with US law by specifying that it applies to "restored work" FuzzyMagma (talk) 09:41, 19 August 2023 (UTC)Reply[reply]
I don't understand your point; all South African works in copyright in South Africa on 1/1/1996 with no US connection (as detailed in the law) are restored works, and the US doesn't have the rule of the shorter term for any works that were in US copyright on that date.--Prosfilaes (talk) 09:51, 19 August 2023 (UTC)Reply[reply]
@Prosfilaes maybe I’m confused, but if there is South African image from 1979 without an author is it public or not in the US? FuzzyMagma (talk) 20:13, 19 August 2023 (UTC)Reply[reply]
Why would it be? Assuming you meant something that's PD in South Africa now, like an anonymous work from 1972, then it would have been in copyright in South Africa in 1996 and would have had copyright restored in the US, and then it would be treated like a US work (that fulfilled all formalities) from then on, c.f. the Hirtle chart.--Prosfilaes (talk) 14:13, 20 August 2023 (UTC)Reply[reply]
The argument keeps coming up as to using "author=unknown" versus "author=anonymous" and whether Commons makes any legal distinction between the two. The argument has been made by someone that "author=anonymous" should only be used when someone makes a legal declaration of anonymity, such as for the first publication of Primary Colors. I don't see it used that way at Commons. So, is there a legal distinction at Commons in the way it is used? Should a bot harmonize all usage to make a distinction? RAN (talk) 16:16, 19 August 2023 (UTC)Reply[reply]
The point being that saying a work is "anonymous" means that the author name was not stated. "Unknown" just means "we don't know". For example, when you have one side of a postcard or one arbitrary page of a book, you can't say the work is "anonymous," because the author's name may well have been stated in a portion of the work that we don't have access to. - Jmabel ! talk 19:59, 19 August 2023 (UTC)Reply[reply]
Hello RAN, maybe the image to the right here helps to understand. It is part of an album with cartes de visite. These cartes de visite became rather populair in the 1860's for wealthy people. In this case you see 6 cartes de visite were (still) inserted. Quite often the name of the photographer was on the backside, sometimes it was (also) on the bottom of the front side. When inserted in an album that name is usually no longer visible. When you turn to the next/previous page, you might see that name on the backside if there is no carte de visite at that specific location (as is the case for the two empty slots where a name is printed immediately before the word 'photographer' in French and Dutch). If I crop an image of a album page like that to have a picture of one specific person, I usually don't know the photographer's name. The fact that I don't know the name doesn't mean the carte de visite was anonymous; it is just something I don't know. - Robotje (talk) 10:54, 20 August 2023 (UTC)Reply[reply]
And there might be a difference in copyright: in some countries "Anonymous" works are in the public domain 70 years after the first publication of a work, while for "author = unknown" it might take much longer (in Commons: 120 years after first publication). --JopkeB (talk) 02:46, 22 August 2023 (UTC)Reply[reply]
which is named "Image 4 of Sanborn Fire Insurance Map from Tacoma, Pierce County, Washington"
then the server will suggest a filename "service-gmd-gmd428m-g4284m-g4284tm-g4284tm_g09345189602-09345_02_1896-0051R.jp2"
this filename contains the correct plate number (51) and indicates that this is a dual page plate, "R"ight subpage.
Additionally, the filename now used on commons does not include the publishing date and the volume number, both also part of the suggested filename.
It does include a LOC-internal serial number (004), but the (Sanborn offical) release year and volume number are more useful to identify a map set. Given two serial numbers, 004 and 009, conveys less information than the respective year+volume (1896 Volume 2 and 1950 Volume 2). Also the year is currently just not part of the commons filename.
Is there a way to find out how many links exist between wikipedia and this map collection? I think a small fraction of people who should know about it do know about it. It is not really used much, that is my impression.
Finally there are plenty more maps available for download. Is there a reason except that nobody is doing it?
PS: what is the point of downloading 100mb+ tiff images. The jp2 versions of these files have 10% of the file size.
considering that there are plenty more maps to come in the future and that these maps are a tremendously useful resource, i think these problems should be addressed.
There is also another opportunity: the indices to the maps include a lot of company names. These indices could be given an OCR treatment and be made searchable. With the right kind of expertise OCR could also be applied to the maps themselves, which contain useful clues, for example the words "foundry", "ship yard", "warehouse" and so on, which do not appear in the index. Nowakki (talk) 18:53, 19 August 2023 (UTC)Reply[reply]
@Nowakki: Interesting maps indeed. FYI JPEG2000 format is not currently allowed on Commons, although there is an open request for that. Yann (talk) 19:54, 19 August 2023 (UTC)Reply[reply]
high quality jpg files can be created from jp2. There is no point to include either tiff or jp2 files on commons though when they are so easy to obtain elsewhere. Nowakki (talk) 20:33, 19 August 2023 (UTC)Reply[reply]
FWIW, I use these (and the Baist maps) for Seattle regularly. - Jmabel ! talk 23:47, 19 August 2023 (UTC)Reply[reply]
1 result for a search that tries to guess the links to commons. It's you. Nowakki (talk) 00:53, 20 August 2023 (UTC)Reply[reply]
@Nowakki: you are identifying how many articles use these, not how many references they make. For example, look at List of structures on Elliott Bay, you'll see I used these heavily (though generally for Seattle I prefer Baist, which is more detailed for the years where it is available). - Jmabel ! talk 01:35, 20 August 2023 (UTC)Reply[reply]
@Jmabel: anyway, i am trying to solve a problem here. it is only going to get worse. somebody should pay attention to this. it is a really big data set. the flaw is obvious and easy to fix. can save a lot of future headache. Nowakki (talk) 15:25, 20 August 2023 (UTC)Reply[reply]
@Nowakki: "service-gmd-gmd428m-g4284m-g4284tm-g4284tm_g09345189602-09345_02_1896-0051R.jp2" is an awful filename, even if it contains information that is potentially useful to someone who happens to know how it is structured. If you want to propose a standard for naming Sanborn maps on Commons, I'd be fine with that, but it needs to be sanely comprehensible to a normal human; give that these are maps of North America, sanely comprehensible to an English-speaker. - Jmabel ! talk 19:57, 20 August 2023 (UTC)Reply[reply]
@Jmabel: i am proposing to use information contained in the filename, not the filename.
If i asked you now to find company/street X in town Y, you could read the correct index and get a plate number. Then you have no idea which indexed file contains the plate and you have to search through a few of them or click on one and calculate the difference. You can see where this is going when hundreds of people start using these files. The original uploader did not know what he was doing.
You work with these files, you must know what i am talking about. Nowakki (talk) 20:15, 20 August 2023 (UTC)Reply[reply]
So propose a specific pattern for filenames. - Jmabel ! talk 20:49, 20 August 2023 (UTC)Reply[reply]
"Sanborn Fire Insurance Map from San Francisco, San Francisco County, California, Vol 1, 1899, Plate 5"
"Sanborn Fire Insurance Map from San Francisco, San Francisco County, California, Vol 1, 1913-1948, Index1"
everything up to the last subindex (the plate number) would be stored in one folder, just like on the Library of Congress site. Nowakki (talk) 05:30, 21 August 2023 (UTC)Reply[reply]
I suppose these files would have to be renamed manually. Not sure if the source provides the mapping. Nowakki (talk) 11:45, 21 August 2023 (UTC)Reply[reply]
I think it is better to keep the same names within the atlas. But if anyone wants to add categories for specific places, great! Yann (talk) 14:00, 21 August 2023 (UTC)Reply[reply]
I'd be fine with User:Nowakki's proposal here, as long as redirects are retained from existing filenames. - Jmabel ! talk 18:11, 21 August 2023 (UTC)Reply[reply]
Not sure where best to raise this, but: these are currently duplicates, so according to our guidelines, one should be deleted (and indeed, for the versions with non-transparent backgrounds, the table at SVG chess pieces instructs people to just use "Chess e..." pieces when they need "Chess B..." pieces). However, the elephant File:Chess edt45.svg has, at several points in its history, depicted an elephant instead of being a duplicate of the inverted bishop File:Chess Bdt45.svg. So I want to check: should the elephant be a duplicate of the inverted bishop and thus deleted? or should we have a file depicting an elephant piece? (Another reason I'm not tagging it for deletion is that in my experience users vote to keep exact duplicate images as long as they have different names, so starting requests for deletion is pointless.) -sche (talk) 20:59, 19 August 2023 (UTC)Reply[reply]
I reverted to the elephant version per the file description and category. This seems like an upload error. —Justin (koavf)❤T☮C☺M☯ 21:01, 19 August 2023 (UTC)Reply[reply]
example colors on the left and their distortions on the right
The image on the right gives an example of the difference between intended colors and those actually shown on Commons, Wikipedia etc.
(This image is not subject to the distortion, because it is shown in its original size.)
This is probably not good for articles like Impressionism or Color vision.
But it also means, that graphics intended to show pale colors look rather gaudy.
The Phabricator ticket is open since February, and there is no indication that this might soon be solved.
Is this supposed to remain like this for the next years? Can anyone help? --Watchduck (quack) 22:36, 19 August 2023 (UTC)Reply[reply]
Do you have an example with wrong renderings? These examples in the description page of the file all have the same six colours. Are you saying that you see, for example, the 110px image on the left differently than your 220px image? -- Asclepias (talk) 00:06, 20 August 2023 (UTC)Reply[reply]
Yes, the small image on the left is wrong. And the right one of the three thumbnails is wrong. See screenshot below.
(I moved the small image into the collapsed box, because left-aligned images mess with the indentation.)
Did you check your observation by making a screenshot and using a color picker? (I checked it in GIMP.)
I would be surprised, if different people get different thumbnails. The one I see is at this URL. (.../7/7b/...)
screenshot showing the thumbnail on the right with distorted colors
@Watchduck: I took a screenshot of the image and I see a very small distortion in the 110px thumb but not anything like your example. A screenshot in Paint.net color picker tool shows FF5454/00CD00/5454FF for the 110px version and FF5555/00CC00/5555FF for the bigger image. MKFI (talk) 08:25, 20 August 2023 (UTC)Reply[reply]
@MKFI: What is the URL of your 110px thumbnail? Also the one with .../7/7b/...?
I would also be interested how the #f55 in this SVG looks for you. For me it is #ff2044. --Watchduck (quack) 10:37, 20 August 2023 (UTC)Reply[reply]
All of these examples are scaled on browser side and use the same original file. So the problem is in the browser and not in the thumbnail renderer as the renderer is not used in this case. GPSLeo (talk) 08:33, 20 August 2023 (UTC)Reply[reply]
@GPSLeo: It would be terrible for loading times, if large images like this were loaded in original size, and scaled in the browser. That is, why the server sends thumbnails in the requested size. Above I have linked the URL of the 110px thumbnail. --Watchduck (quack) 08:55, 20 August 2023 (UTC)Reply[reply]
In this case with the small file and relatively big thumbnails there is not server side down scaling. I had a look at a server side scaled version of the file [1] and there the colors are correct. GPSLeo (talk) 13:06, 20 August 2023 (UTC)Reply[reply]
The "screenshot" version shows what you describe. It is not reproduced with thumbnails generated from the original image. It may be something with your system. -- Asclepias (talk) 12:38, 20 August 2023 (UTC)Reply[reply]
That seems to be true. My browsers show me some thumbnails with wrong colors. But after downloading them, I can can confirm, that they contain the correct colors. Sorry for the false alarm. --Watchduck (quack) 13:12, 20 August 2023 (UTC)Reply[reply]
Dear Wikimedians - I would like to bring to your attention a general Wiki Loves Pride international camapign that would like to encourage you to create LGBT+ related content in your language and more specifically to those in or traveling Malta to join Wiki Loves EuroPride 2023 campaign by contributing media (photo, video and audio recordings) as Valletta is hosting EuroPride soon.
If you are interested to collaborate in any way and help us with promotion, outreach or other aspects please get in touch! --Zblace (talk) 10:28, 20 August 2023 (UTC)Reply[reply]
I see you are mayor contributor of photos of Malta and I wonder if you would be interested to contribute to this cause and towards documentation of events in Malta next month @User:Continentaleurope @User:Marika Caruana
"G. Duf[?????]". No double-f, the given name just starts with G - that could indeed be a George, or also Gina, Guillelme or Gaston. The final characters are all x-height and increasingly small, so your reading as "Paris" might be correct, but it could also be part of a longer name petering out, like "Dufunnene". --Enyavar (talk) 09:32, 21 August 2023 (UTC)Reply[reply]
@Richard Arthur Norton (1958- ): There appear to be three lines of text. The first is cursive and looks like a signature. The second is in block capitals and looks like "MARNE-". I can't make out the third line but it might be "Paris." However, MARNE is outside of Paris, so that would be a logical connection. From Hill To Shore (talk) 18:16, 22 August 2023 (UTC)Reply[reply]
Yes, User:Fæ did millions of mass uploads from large sites such as LoC. Files from mass uploads often need refinements and corrections or sometimes deletions. Sources are there, it can be done, although it is tedious. -- Asclepias (talk) 20:39, 20 August 2023 (UTC)Reply[reply]
You can report errors to the LOC through their Flickr Commons account, they eventually respond and appreciate corrections. They are currently crowdsourcing context and dating of the Bain Collection at Flickr Commons. See: https://www.flickr.com/photos/library_of_congress/52768575793 for an example. --RAN (talk) 01:59, 21 August 2023 (UTC)Reply[reply]
Assistance wanted: Confirming IA scans as Public Domain...[edit]
The Template {{IA}} was recently updated to allow for scans to be marked as reviewed as being in the public domain, or under a "free" license.
It would be appreciated if some experienced contributors (most likely license reviewers) were able to start adding the relevant parameter to the uses of the template, and to add appropriate catalog data to the files concerned such as {{Book}} or {{Artwork}} as appropriate, converting between them as needed.
Unreviewed scans/items will appear in the hidden category :, which once the reviewing process is completed should contain as few files as possible.
Reviewing most of the files should be straightforward, as the vast majority of the scans ARE under Commons Compatible licensing.
How do we handle personality rights around here, especially when it comes to children? I have my doubts about these two images. One might argue that this is a problem only if the children are clearly identifiable. Well, their parents would certainly recognize them, or anyone who knows them.
I personally don't think these are great photos anyway that are an asset to Wikimedia Commons or to any Wikipedia article. So are these worth keeping?
There are other issues with these images, like: How do we know that the uploader is identical with the copyright holder? I see no indication of that. --2003:C0:8F16:2100:79CF:D018:617C:C4E 05:46, 22 August 2023 (UTC)Reply[reply]
I don't know enough about French law to say what the personality rights issues would be there. I know France is tighter on this than most countries. In the U.S., the first image would be completely unproblematic (because it is a clearly public space by any reasonable definition, and in the U.S. that is enough). The second might raise some issues.
Why would you doubt that this person is uploading their own work? She identifies herself in the "author" field as associated with the museum. - Jmabel ! talk 18:20, 22 August 2023 (UTC)Reply[reply]
To the first question, the fact that there are identifiable persons might be a problem. However, considering that the former children are now about 25 years old and that the photos have been on Wikimedia for fifteen years, I'm not sure if the fact that those adults were children in 2006 is, as such, an additional problem now. To the second question, the photos are in use in Wikipedia and that determines that they are deemed in scope and worth keeping, if they are legal. To the third question, there is indication but no proof. The uploader might seem to claim to be the holder of the copyright through the use of the prefix in the licensing section, but that's sometimes a mistake and not a proof in the absence of verification. The uploader does not claim that the photos are own work. The source is said to be the Musée. In that context, the name in the author field does not seem a self-identification, but an attribution to the author different from the uploader. -- Asclepias (talk) 19:39, 22 August 2023 (UTC)Reply[reply]
I've prevously seen scans of real ID's with personal information, filled out tax forms or job applications, etc. Those are in real need to get deleted. The same applies to revenge uploads (of the classmate the underage uploader hates, with an unflattering description.) Full names and adresses in case of non-consenting or accidental uploads are a no-no. Don't keep. Doxxing is a real issue, and steps need to be taken to prevent obvious cases, delete images or revision-delete unwanted information.
These two photos are (imo) in no way harmful, the children are not easily identifiable, and we don't get high-resolution portraits that could be used in face recognition (arguably the worst case of non-obvious doxxing in our AI times now). There are also no names given - I'd say they are save. Myself, I blur out identifiable details of bystanders in my photos, unless they're the subject of interest - But not everyone does.. In the case you present here, the children playing with objects is the interesting part.
And then there's this, this, this, this, this, this ... Yup. I'm saying Commons has hundreds of thousands of photos depicting children, or people in general not being aware they are photographed and about to be uploaded to Commons. Some may have been asked for permission, others might not. We generally want to keep such pictures (preferabbly anonymous, etc.). Exceptions have to be discussed in individual deletion requests.
An adult may wish his baby picture to get deleted, since he never gave informed consent, and I think we would grant the request, depending on circumstances. But given that most pictures are uploaded anonymously, few will come here 15 or more years after the fact and file the request.
A former soldier may come here and request that an image taken as part of their official duty is to get deleted: Essentially revoking the informed consent given many years prior. [that is a point of heated contention].
I can think of many more cases, usually revolving around "harm done?" "consent given?" "consent inadmissable?" "laws violated?" "is it in-use?" "quality?" that can be used to decide whether or not images of a photographed person can be deleted based on personality rights. Best --Enyavar (talk) 22:42, 22 August 2023 (UTC)Reply[reply]
I haven't found a place to ask and I don't know if this is the best one. There is a user on Flickr named "Laura Buononome" https://www.flickr.com/photos/195828402@N06/ who violates the Italian copyright laws, publishes not open and non-free images on his account with "false new" a free license which are then washed and recycled here on commons by some years (see for example on this talk user all notifications of deletion https://commons.wikimedia.org/wiki/User_talk:Corvettec6r). Therefore I beg you to take the due and necessary measures, to blocking uploading of this photos. 5.91.94.67 10:43, 23 August 2023 (UTC)Reply[reply]
I know there is a "Flickr blacklist" but I've never dealt with it. Can someone help out here? - Jmabel ! talk 16:30, 23 August 2023 (UTC)Reply[reply]
It could be useful as a hidden maintenance category to help identify photos of buildings known to be in that town that have a visible "10" on them. But that's about it. - Jmabel ! talk 16:32, 23 August 2023 (UTC)Reply[reply]
House numbers are used to identify a building, these cats help you locate a building from a bunch of similarly named streets, roads, crescents, places, closes, etc, etc, etc and also if you are not sure which borough your structure or street is located under. Thus these cats help you locate a particular structure. Your links only show the last time the Categories were edited not when they were created giving a false impression of how old they are/not Most of the London ones are from around 2015. I don't see any harm these cats do, if you don't wish to use them just ignore them. Oxyman (talk) 17:18, 23 August 2023 (UTC)Reply[reply]
"most appear after 2018"
to be exact, at least (3051-394)/3051=87% were created after june 2018. RZuo (talk) 18:52, 23 August 2023 (UTC)Reply[reply]
No that is incorrect you are misunderstanding what your links are showing, they show the last edit not time of cat creation. Oxyman (talk) 19:03, 23 August 2023 (UTC)Reply[reply]
or copied from somewhere and identical (with a certain precision) to the wikidata coordinates. Often a legacy problem, as {{Object location}} was there before {{Wikidata Infobox}}.
Bots are cleaning up stuff shown in the {{Wikidata Infobox}} elsewhere in the category description, but not for {{Object location}}. I'm consolidating redundant coordinates and removing {{Object location}} manually when I stumble accross. But in general it would make sense to
remove {{Object location}} per bot in the two cases above (where nearness of coordinates due to rounding should be used instead of identity)
and afterwards consolidate coordinates wherever necessary. Let's see what is left after first step. Coordinates should be corrected on WD and {{Object location}} should be removed from the category description.
). Also a problem is the one alluded to by some above, that there are photographs sorted here that are not in their analogous topical categories. People sort their picture of Panama into this category and then it turns out if someone looks for May 2020 in Panama, they don't find it. 'Photographs of' categories are in the Media types tree, not the Topics tree (see major category policy 
Agree We should avoid composite categories with concepts that are parent-child or siblings.
Neutral
Oppose I am not a supporter of creating and keeping empty categories. I can see the advantages but I doubt whether they outweigh the cons such as the mess described by Adamant1 on August 9. They should be very scarce and they always should have a note or template, like Adamant1 suggests, why they exist..svg/15px-Pictogram_voting_comment_(orange).svg.png)
Comment Empty categories are useful for "year maps of country" (Category:1850 maps of India) or "year books from country" (Category:1550 books from France), as if the category is missing, it breaks the navigation via the template. These cases there are many potential files for them. Yann (talk) 12:33, 11 August 2023 (UTC)
Strong oppose any hard line on the minimum number of pages in a category above 0. Empty categories are already subject to Speedy Delete, so no change required on that. There are thousands of categories with only 1 or 2 files in them that are perfectly valid, so a policy to not allow 1- or 2-file categories anymore would be a huge problem. Categories with a well-developed set of 'by country', 'by year', 'by quantity', 'by color', etc. are a good example of this. Let's take a use case:
.jpg_(Cropped).jpg){kind=link}
Moved from User talk:Xeror#Campus categories 
Question Why is a public domain mark insufficient proof of an image being in the public domain? Sometimes, I think we make too much work for ourselves on this site. -- Ikan Kekek (talk) 17:12, 14 August 2023 (UTC)
.jpg){kind=link}
.jpg){kind=link}
![[1]](https://upload.wikimedia.org/wikipedia/commons/thumb/7/7b/Red_f55%2C_green_0c0%2C_blue_55f_and_their_distortions.png/30px-Red_f55%2C_green_0c0%2C_blue_55f_and_their_distortions.png){kind=link}
