Commons:Village pump

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

Shortcut: COM:VP

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

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

Please note:

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

Purposes which do not meet the scope of this page:

Search archives:

   
 

Start a new discussion

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 How many files and/or subcategories should a Commons category at least have? 64 14 Joshbaumgartner 2023-08-31 00:56
2 Redundancy 'Wikidata Infobox' and 'Object location' in category descriptions 13 4 Herzi Pinki 2023-09-02 13:29
3 uploading photos I took but have published elsewhere 10 4 C.Suthorn 2023-08-28 22:57
4 Fæ's talk page 11 10 C.Suthorn 2023-09-02 21:19
5 Mirrored image 4 3 Omphalographer 2023-08-28 18:39
6 Review the Charter for the Universal Code of Conduct Coordinating Committee 1 1 RamzyM (WMF) 2023-08-28 15:34
7 Splitting up a tram type category 1 1 Smiley.toerist 2023-08-29 10:22
8 Best way to have images reviewed(?) and permission made clearer 8 3 Ubcule 2023-09-03 16:38
9 Commons and the upcoming Wikimedia Summit 2 2 RZuo 2023-09-01 08:23
10 Cropping 13 7 Sitacuisses 2023-09-01 12:05
11 Barriers to Cross-Platform Collaboration - Wikipedia / Commons 3 3 Maplestrip 2023-09-04 07:36
12 Croptool 8 4 Richard Arthur Norton (1958- ) 2023-09-01 18:00
13 Odd thumb/display problem 5 2 Jmabel 2023-09-01 03:23
14 Cats for lit lamps 7 3 Jmabel 2023-09-01 15:17
15 Commons Gazette 2023-09 1 1 RZuo 2023-09-01 08:00
16 Extra text in category 4 3 JotaCartas 2023-09-01 18:57
17 Request for temporary ui-admin and sysop right for Adiutor integration 7 4 Vikipolimer 2023-09-04 06:17
18 Category:First Ladies by year 2 2 Jmabel 2023-09-01 21:05
19 Category:Women wearing nail polish 2 2 Nosferattus 2023-09-03 00:27
20 Swedish page on Radom (city in Poland) 1 1 Ruslik0 2023-09-02 20:04
21 Category:2022 Russian invasion of Ukraine 3 3 Adamant1 2023-09-03 20:47
22 "OAuth" tool for "Find images for Wikidata" of "PetScan" 1 1 JotaCartas 2023-09-03 23:00
23 Different pictures, one file 9 5 Enyavar 2023-09-04 21:33
24 Guidelines for naming visual arts works 10 4 Carnby 2023-09-04 21:42
25 misscategorization and overcategorization 3 2 9pm 2023-09-04 20:18
26 Degrading of a postcard by a blocked? user. 4 3 Jmabel 2023-09-04 20:01
27 Please help with file move (reversion) 3 2 Laura1822 2023-09-04 20:23
Legend
  • In the last hour
  • In the last day
  • In the last week
  • In the last month
  • More than one month
Manual settings
When exceptions occur,
please check the setting first.
Broadwick St, Soho, London: a water pump with its handle removed commemorates Dr. John Snow's tracing of an 1854 cholera epidemic to the pump. [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive
Template: View   ■ Discuss    ■ Edit   ■ Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

August 11[edit]

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

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

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

The question is what's sufficient? 1 file or more then that? --Adamant1 (talk) 05:05, 9 August 2023 (UTC)Reply[reply]
Well, I could not find a guideline for it and I think the opinions may vary a lot. This discussion (about the independence of Commons) does not depend on the outcome of this new question and therefor I suggest to address it in a separate discussion. JopkeB (talk) 05:34, 9 August 2023 (UTC)Reply[reply]
I'm aware that's not what the discussion is about. I just thought I'd ask since it was brought up. I'm fine with starting a separate discussion about it if you prefer that though. --Adamant1 (talk) 05:40, 9 August 2023 (UTC)Reply[reply]
I agree that there is no solid guideline, and I'd hate to create something rigid. My own personal rules of thumb:
  • Never create an empty category unless you are about to use it (within a few hours).
  • The only time to create a category for a single photo is when it is part of a sequence or systematic breakdown of another category (e.g if we have Category:PERSON by year and we already have categories for most dates in the 1940s but have only one photo of them for 1947, I'd probably create the Category:PERSON in 1947.
  • For two photos, I'd sometimes create a category if there is already a Wikidata item or Wikipedia article.
  • Otherwise, three is a bare minumum, and I probably wouldn't do less than four (usually five) if they already group together (sorted next to one another) as part of an existing category with less than 200 images. I'd be more likely to do the four or five with no Wikidata item or Wikipedia article if I either anticipate a future article, or I think we will have a lot more such photos.
I suppose I've pushed that a little sometimes when I have a lot of information about a person from roughly 100+ years ago and only a couple of photos; usually that also calls for making a Wikidata item, but I'll admit to sometimes being lazy about the latter when it's all stuff I can express via parent categories. - Jmabel ! talk 15:26, 9 August 2023 (UTC)Reply[reply]

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

@JopkeB: this was a response to "18:01, 8 August 2023 (UTC)". now the context is lost.--RZuo (talk) 07:31, 11 August 2023 (UTC)Reply[reply]
I am sorry. But I thought this part would fit better here. --JopkeB (talk) 09:01, 11 August 2023 (UTC)Reply[reply]
I really have to disagree. That just sounds like a bad recipe for having thousands of empty categories because someone decided to pre-create them ahead of time and then dodged out half through their project or something similar. I much rather administrators delete a category 5 times over as many years then the inventible massive mess your recommendation would create. --Adamant1 (talk) 07:48, 9 August 2023 (UTC)Reply[reply]
Empty categories they are liked to Wikidata are very useful for tools and especially new users. They can also speedup the workflow of experienced users. This of course only applies to topics like protected areas, mountains, or members of a parliament, where we expect to get photos of in the near future. We should not create empty or nearly empty "by year" categories. GPSLeo (talk) 07:14, 11 August 2023 (UTC)Reply[reply]
Wikidata has essentially no notability guidelines outside of the entry needing to have a single external reference. So there's no guarantee that just because something has a Wikidata entry that it will every have images related to it uploaded to Commons. In fact, most never will. That's not even accounting for the fact that there needs to be someone willing to upload images related to it in the first place, which there often isn't.
I'd probably support either creating empty categories or ones with single images in cases where it's a clearly notable subject and there's a guarantee someone will upload images of it in the near future though. I just don't know how it would be enforced or tracked. Maybe we could create a special category system or template just for those types of categories like there are for DRs. I don't think they should be mixed in with normal categories though. At least not in mass. Otherwise it could easily make parent categories hard to browse through and/or maintain. --Adamant1 (talk) 08:53, 11 August 2023 (UTC)Reply[reply]
Full agreement with Adamant on empty categories. As an addendum: A few rare times I have created Commons categories about notable people, where the images later got deleted, so the category is now an empty remnant. As long as it's about notable things and connected with an entry via Wikidata, I see no problem keeping such a category. --Enyavar (talk) 12:22, 11 August 2023 (UTC)Reply[reply]

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

  1. Standards:
    1. Categories should only be created for unique concepts. (RZuo)  Agree We should avoid composite categories with concepts that are parent-child or siblings.
    2. Three files and/or subcategories is a bare minumum to create a new category.  Agree
  2. Exceptions:
    1. Four or five files is the minimum if the files already group together as part of an existing category with less than 200 images.  Neutral
    2. Two files if they have three or more parents in common. This is to avoid multiple overcrowded categories with the same files and to create better overviews. (added by JopkeB)
    3. Two files or subcategories if there is already a Wikidata item (note: there should always be a Wikidata item if there is a Wikipedia article)  Agree
    4. One file or subcategory when it is part of a sequence or systematic breakdown of another category.  Agree
    5. One file if it is expected that more photos come easily, e.g. living celebrities, buildings. It makes it much easier to categorise new files with an established category.  Agree
    6. One file or subcategory if you are a user with knowledge of a concept and it is a notable subject.  Agree
    7. Should we allow empty categories? For instance because they are useful for tools and new users, and they can also speedup the workflow of experienced users, for subjects where we expect to get photos of in the near future, created by users with the knowledge of a concept, "by year" categories.  Oppose I am not a supporter of creating and keeping empty categories. I can see the advantages but I doubt whether they outweigh the cons such as the mess described by Adamant1 on August 9. They should be very scarce and they always should have a note or template, like Adamant1 suggests, why they exist.

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

That sounds reasonable to me. Except with the caveat for number 4 that we shouldn't allow for one file or subcategory when it is part of a sequence or systematic breakdown of another category if either one is "by year" or has anything to do with "by year" categories. I agree with it other then that though. --Adamant1 (talk) 10:30, 11 August 2023 (UTC)Reply[reply]
With the empty categories we maybe could make a guideline that they have to be maintained by an active WikiProject or by an annual photo competition. GPSLeo (talk) 10:52, 11 August 2023 (UTC)Reply[reply]
  • Of course it is and should remain allowed to create a category with only 1 file, or just with a non-empty subcat. And if this category can be linked with a Wikipedia article and a Wikidata item via WD infobox, this is not only allowed, but also encouraged. Regards --A.Savin 12:17, 11 August 2023 (UTC)Reply[reply]
Hi, in my opinion the answer to the question is very much: "it depends". I would split possible categories into two kinds: specific (about 1 event/object/person: these categories should be allowed to be as tiny as needed) and non-specific (about any event/object/person that fits the criteria)
  • For the first:
    • there are very useful category structures where I create a new category just for a single picture, to complement the other branches of the same category tree. (Category:1977 elections in Morocco, which is part of "1977..in Africa", part of "..in Morocco by year", etc. I hope we will get more stuff in it, but one file suffices already.)
    • there are well-defined categories, like about one special book title. (Category:Stalky & Co. is perfectly fine with just 2 files. Although: If it's just one file from/about a book, I'd still prefer that file being properly categorized, without a new category.)
  • For the second:
    • I find three images on Commons depicting "Porcelain vases with horse paintings". That may seem to be a very clear category definition, possibly falling under "Porcelain vases with paintings" and "Horses in art", but it's still an arbitrary definition and with too few files matching the criteria. I'd rather supper "Horses in porcelain art", and then splitting that further as soon as the category grows too large, probably first dividing into statues and paintings. 6-10 files should be a minimum for such groupings.
    • this also goes for "location in time"-categories. Any event/work/building/map/photo/person/etc related to the history of Krakow, and created/photographed/happening/died/etc in 1879, may go into "1879 in Krakow". The definition is vague and arbitrary in a different way here, but still: There is currently one file. (Category:Kraków in the 1870s holds 7 files in total, but uses four categories to do so.) So for "history of location"-categories, I'd prefer "by decade" over "by year" and only create the latter once the decade-category gets overcrowded.
    • I sometimes find categories that are too small and if I am invested enough, I actively seek dissolution. Category:1840s maps of Lithuania now has 9 files which have previously been spread over 8 subcategories. I moved the files to the parent cat, and will at some point in the future ask for the deletion of the (now empty) sub-cats. As long as we don't suddenly get an influx of dozens more 1840s maps of Lithuania, these by-year-subcats are just too granular to be useful.
    • In other cases I often find categories that are "too small", but I'm not invested enough to start a debate: Category:Voting lines in India is granularly sub-divided by states of India, sometimes with just 2 pictures. That is in my opinion not how it should be, but it fits into "<theme> in India by state", so I'm not complaining.
These are my thoughts, I think my opinions overlap a lot with Jmabel and Jopkeb --Enyavar (talk) 12:22, 11 August 2023 (UTC)Reply[reply]
 Comment Empty categories are useful for "year maps of country" (Category:1850 maps of India) or "year books from country" (Category:1550 books from France), as if the category is missing, it breaks the navigation via the template. These cases there are many potential files for them. Yann (talk) 12:33, 11 August 2023 (UTC)Reply[reply]
Thanks for the comment, and I fully agree on "year books from country", but...  Comment "year maps of country" stops being useful the further you go back into the past: Maps were drawn years after the surveys, maps were reproduced unchanged for years, decades and even centuries, maps were dated wrong by authors, archives and later by the uploaders, etc. So, I support navigation templates, but for most maps before the 20th-century, we shouldn't do breakdowns by year, but by decades instead. With exceptions for when there is lots of material of course. This whole thing is slightly off-topic here and I have pages more cases and material to discuss, so I leave it at that until me make it a whole own topic. --Enyavar (talk) 19:40, 11 August 2023 (UTC)Reply[reply]
For named entities - specifically notable people - single file categories should be accepted and their creation should be encouraged. Even if it contains just one file, an individual category provides links to corresponding articles, increases the chance that further uploads are fully categorized and keeps the topical category pages tidy. Why would it be better if a category like Category:Members of the 11th German Bundestag contained 73 single files instead of the additional 73 single file categories for the respective persons? --Rudolph Buch (talk) 18:21, 11 August 2023 (UTC)Reply[reply]
Take a more zoomed out perspective on this. The main purpose of Commons is for people to find media related to a subject, Not information related to it. To the degree that we do provide such information that's what file descriptions are for. In your example someone is either going to want to find "Members of the 11th German Bundestag" or an individual person who was a member. So in that case they will either search for Members of the 11th German Bundestag" which will give them the category so find images of multiple members, or they will search for a specific name and go the file for that person. If you create a category for each individual member your just create pointless intermediary steps that people looking for "members" have to go through to get the images. Like if I want images of five of them, I now have to go to the main category, click into the individual category, click the image, download it, click back into the individual category, click back into the main category, and do it all over again multiple times. It's just obtuse and creates browsing dead ends.
Whereas the person who wants in image for a individual member can already do that using the search box and clicking on the image of the person. So the category adds nothing. Same for the infoboxes since the information will (or at least should) already be contained in the file description. At least IMO the point in infoboxes is to provide general information about a subject people are browsing images related to. It acts as an orientation point. It's less about providing the raw facts to people who are looking for them because we aren't Wikipedia. It's not like we can't just link to Wikipedia or Wikidata in the file description either. But you want browsing images to be intuitive and have as little end points as possible. The ability to find out someone's birthdate in an infobox shouldn't come at the cost of adding 5 more levels of clicking to the user interface. You see that with "nested" categories that only contain a single category and no images a lot. There's instances out there where it turns into a game of clicking through 12 empty nested categories just to get to the a single image. At which point the person looking for said image has probably long wondered off out of frustration and found it through Google Image Search. --Adamant1 (talk) 19:28, 11 August 2023 (UTC)Reply[reply]
You are right, single files should (usually) not get their own category, and I'm also a skeptic when it comes to empty categories. But once there is a second photo of a notable person, they are eligible for their own category (as per here), in order to have all media related to the person in the same place, and that includes removing them from other categories. Commons' categories are not curated image galleries, and "Members of the 100th U.S. Senate" has the same "problem" as the 11th BT above. Cheers, --Enyavar (talk) 20:58, 11 August 2023 (UTC)Reply[reply]
@Adamant1: These issues are the same whether there´s a minimum of one, two or ten files for an individual category. With any minimum number you still have personal categories, just not for all of the files. And a mix means you got to look in two places instead of one. Mostly you describe a different problem: In many categories we do not distinguish between "feature of the related entity" and "feature of the actual motive". Our rules stipulate to categorize the image of a dinner plate under category "Mayors of New York" if the owner was one of those. I prefer to have the plate (or tombstone, residence, pencil sharperner etc.) in the specific mayor´s named subcategory, even it´s the only file there. Apart from that I agree that we have too many non-essential and non-reliable categories relating to people.- --Rudolph Buch (talk) 22:33, 11 August 2023 (UTC)Reply[reply]
I prefer to have the plate...in the specific mayor´s named subcategory, even it´s the only file there. I have to disagree there. It's probably good to assumepeople will be looking for images of the mayor if they are searching for their name. Not some random plate that they eat dinner off of once. Whereas, people who are looking into plates will be interested in the image regardless of whom owned it. I could maybe see it for members of higher office, but we usually have other images of them in that case anyway. More broaderly though categories shouldn't be created unless the category will contain at least one image directly related to the subject. Otherwise the image should just go somewhere else. I don't think we should be creating categories for every person that we happen to have an image related to though. Otherwise we'd be creating single file categories for every non-notable person we have a passport, letter, gravestone, or whatever for. Which clearly wouldn't be useful. So you have to draw the line somewhere. --Adamant1 (talk) 22:57, 11 August 2023 (UTC)Reply[reply]
@Rudolph Buch: I suspect your use of "motive" here is a false cognate from another language. I don't know what you mean by it. "Motive" in English means a reason for doing something. - Jmabel ! talk 23:47, 11 August 2023 (UTC)Reply[reply]
Maybe "motif" was meant? -- Tuválkin ✉ ✇ 23:56, 11 August 2023 (UTC)Reply[reply]
Right. ("Motiv" in German can have two meanings: Reason for doing something, same as motive in English, or "what is depicted in a picture". Deepl tells me I should have used "subject" or "motif" instead - which seems strange as the "Sujet" and the "Motiv" of a picture mean very different things in German.) Rudolph Buch (talk) 00:25, 12 August 2023 (UTC)Reply[reply]
@Adamant1: the issue presumably isn't creating single-file categories for non-notable people where we have one artifact related to that person. I suppose there is someone who would consider doing such a thing (I've seen some seriously useless categories) but the issue there would be more about having an artifact related to a notable person when we don't actually have a picture of that notable person. I could easily imagine that happening with someone reclusive who doesn't like having their picture taken. For example, we happen to have pictures of Thomas Pynchon from the 1950s, but he's pretty much avoided having his picture taken since; we'd want Category:Thomas Pynchon even without those. If we ever had an image related to Elena Ferrante, we'd probably want a category for her, even if we still lacked a photo of her. - Jmabel ! talk 23:55, 11 August 2023 (UTC)Reply[reply]

Conclusions and questions[edit]

Since there was no addition for a few days, I think it is time to draw conclusions and decide what next steps to take.

Conclusions

  • There is no guideline yet.
  • Opnions vary a lot. What do we agree on?
    • Standards:
      • Three files and/or subcategories is a bare minumum to create a new category.
    • Exceptions: the minimum should be:
      • Four or five files if the files already group together as part of an existing category with less than 200 images.
      • Two files if they have three or more parents in common.
      • One file or subcategory if there is already a Wikidata item.
  • We do not agree on:
    • Allowing empty categories. So I suggest to keep the current policy of not having empty categories.
    • Categories with only one file or subcategory in special cases, and there is no Wikidata item yet. I suggest to allow them to be created scarcely and leave it to the judgment of the editor whether to create one. Though often it would be better to have such single files and subcategories in a more general category.

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

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

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

I have no problem with any of this, as long as it is understood to be a guideline, not a rigid standard. There will always be some reasonable exceptions. - Jmabel ! talk 15:42, 15 August 2023 (UTC)Reply[reply]
I did not take part in the discussion, but was reading along and I also think these are all good points that could be included as a guideline in some way. Kritzolina (talk) 15:58, 15 August 2023 (UTC)Reply[reply]
Commons:Categories is an official policy though, and this appears to be a significant change if we were to place it on that page. I don't think it fits there, but rather into Category:Commons_guidelines, where we can even create a longer abstract, or examples/cases. --Enyavar (talk) 16:01, 15 August 2023 (UTC)Reply[reply]
Yes, I agree, also with a longer abstract and examples. So it will have a page of its own, something like Commons:Amount of elements in categories? I am open for a better name. Then there could also be a paragraph about the maximum amount, with long lists as an exception, but that is another discussion.
Questions:
  1. Do you agree to have a guideline for this matter with our conclusions?
  2. What would be a good name for such a page?
  3. How do we implement this? Should we discuss the content of the guideline here, or does someone make a proposal and shall we discuss it on the Talk page of the new page?
@Adamant1, Jmabel, RZuo, GPSLeo, Enyavar, A.Savin, Yann, Rudolph Buch, Tuválkin, and Kritzolina: What do you think? JopkeB (talk) 04:15, 16 August 2023 (UTC)Reply[reply]
I say implement it. Adding some examples would be helpful to but they can always be added after it's implemented. --Adamant1 (talk) 04:37, 16 August 2023 (UTC)Reply[reply]
If we call it „Best practice“ and not a strict guideline or even policy I would be fine. And the {{Prospective category}} should still be usable. GPSLeo (talk) 05:14, 16 August 2023 (UTC)Reply[reply]
What's wrong with it being a guideline? If we just call it a "best practice" then there's no reason anyone would follow it. Plus there would just be the same kind of arguing over when to create categories or not that already exists and this is suppose to hopefully solve. The whole point in this is to figure out standards that can (and should) actually be followed. Not just to write a toothless essay about "best practices" that will just be ignored. --Adamant1 (talk) 05:36, 16 August 2023 (UTC)Reply[reply]
Strict guidelines for a category system that has to handle complex edge cases could lead to disputes on cases where following the guideline is not the best solution. GPSLeo (talk) 11:28, 16 August 2023 (UTC)Reply[reply]
I don't really see how it's strict to allow them to be created in some cases or to leave it up to the judgment of users whether to create the category or not. Especially if the guideline includes examples. That's essentially how things are done now. It will just be more formal. As to it increasing disputes, there's plenty of disputes already that are caused by there not being a guideline. I don't think there will be more if there is one because a person can just use their judgement and create the category if they want to. Baring a few specific instances that will covered by the guideline, but they already can't create categories in those instances anyway, or at least they will receive push back and be blocked if they do. This just makes it more formal so it doesn't take them re-creating the categories and people leaving them multiple warnings not to create the categories before it's can be dealt with. --Adamant1 (talk) 12:01, 16 August 2023 (UTC)Reply[reply]
1. Yes, I think it is a good idea
2. Commons:Minimal requirements for categories
3. I think we should create a page and discuss on the talkpage of the Commons:Categories page where to link it Kritzolina (talk) 06:19, 16 August 2023 (UTC)Reply[reply]
Thanks, Kritzolina, for your input and clear answers to my questions. Only, "Minimal requirements" is much broader than only the amount of files and subcategories, and is already largely covered by Commons:Categories. JopkeB (talk) 16:19, 16 August 2023 (UTC)Reply[reply]
  • I don't think we should have a rule on minimal number of files in a category, apart from disallowing empty categories. Whether a category is useful or not, is seldom a matter of the number of files in it, but much more frequently of its scope, naming, formal correctness, and quality of its media content. As Enyavar correctly pointed above, it depends. Thanks --A.Savin 12:06, 16 August 2023 (UTC)Reply[reply]
There's cases where its clearly not good to create categories that only contain a single file or category. For instance by year categories where there's only one file for a single year in the decade. There's currently nothing stopping people from doing that. In fact a user recently did it in mass for "stamps by year" categories where the stamps from the years he was created categories for were copyrighted, and refused to stop until he was eventually blocked. Maybe I'm being naive, but I'd like to believe things like would be curbed or at least easier to deal with if there was a guideline making it clear not to create categories in such an instance. --Adamant1 (talk) 12:19, 16 August 2023 (UTC)Reply[reply]
 Agree I prefer a guideline as well. There are 96 million files now, and perhaps hundreds of editors (or more). To let them categorize more or less the same way, let them not make a mess of the categories and to avoid disputes over and over again, we should have enforceable rules/guidelines. JopkeB (talk) 16:32, 16 August 2023 (UTC)Reply[reply]
  •  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 not policies 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).
JopkeB (talk) 09:30, 22 August 2023 (UTC)Reply[reply]
@JopkeB: Well stated. I was not aware of that specific exception. I stand corrected. Josh (talk) 00:56, 31 August 2023 (UTC)Reply[reply]
  • 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.
  • Provisional name for such a guideline: Commons:Amount of elements in categories.
  • 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.
    • The {{Prospective category}} should still be possible.
    • See also: Commons:Category inclusion criteria (essay).

Questions
@Adamant1, Jmabel, RZuo, GPSLeo, Enyavar, A.Savin, Yann, Rudolph Buch, Tuválkin, Kritzolina, King of Hearts, and Joshbaumgartner: :

  1. Is this a correct summary of those remarks?
  2. Would Commons:Amount of elements in categories be a good name for this guidline? Do you know a better one?
  3. Who would like to start this page?

--JopkeB (talk) 10:17, 22 August 2023 (UTC)Reply[reply]

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]
Should be Commons:Number of elements in categories, not Commons:Amount of elements in categories. It's hard to explain the subtlety to a non-native speaker, but "amount" is wrong here. - Jmabel ! talk 18:13, 22 August 2023 (UTC)Reply[reply]
Thanks, Jmabel, I did not know. Perhaps this is something you can count and "amount" is more for piles? JopkeB (talk) 08:57, 24 August 2023 (UTC)Reply[reply]
@JopkeB: something like that. Plus "amount" would almost never be preferable to "quantity" in a context like this, it's just not the word one would typically use in something at all formal. - Jmabel ! talk 15:28, 24 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)...)
there have been two files of Category:Albers Brothers Mill (Tacoma, Washington) since no later than 2014, but the cat was only created by me, and while creating it i was only aware of the existence of 1 file. who's to blame for the lack of categorisation of File:UNION DEPOT, TACOMA. LOOKING SOUTHEAST TOWARDS PLATFORM AND TRACKS. - Union Depot Area Study, Tacoma, Pierce County, WA HABS WASH,27-TACO,6-11.tif for 9 years?
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]

My final conclusions:

  1. We still do not agree on the minimum number of files/subcategories a category should have.
  2. If we now would make a guideline, it would not be the document that at least I had in mind when we started this discussion. It would become a toothless, non-binding document that cannot be used or referred to in discussions and deletion requests. I will not start such a guideline.
  3. It is useless to continue this discussion, because we'll never agree, no matter how many viewpoints we will add or how long this discussion will last. The positions are too far apart.

So it looks like we'll continue to use our own personal standards. --JopkeB (talk) 06:29, 27 August 2023 (UTC)Reply[reply]

August 24[edit]

Redundancy 'Wikidata Infobox' and 'Object location' in category descriptions[edit]

Hi, there is a general redundancy in many categories having two coordinates, one from WD via {{Wikidata Infobox}} and the other via local {{Object location}} (~175.000 matches). Besides redundancy there is sometimes a layout problem with {{Object location}} below {{Wikidata Infobox}} (e.g. Category:56 Wiśniowa Street in Warsaw, ~1500 matches).

In many cases coordinates in {{Object location}} are

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.

--Herzi Pinki (talk) 05:07, 24 August 2023 (UTC)Reply[reply]

In principle, that's reasonable. The problem is that I think there are more eyes watching Commons for vandalism than watching Wikidata, so at this time getting rid of explicit coords in Commons probably makes us more vulnerable to vandals. But we've already accepted that risk for birth & death dates, so I guess we've crossed the bridge. - Jmabel ! talk 15:47, 24 August 2023 (UTC)Reply[reply]
 Support. I have often wondered about this situation, but rarely dared to remove {{Object location}} due to a lack of relevant guidelines/precedence. Personally, I think coordinates attract less vandalism than other data on Wikidata, so I am not too concerned. --HyperGaruda (talk) 23:35, 24 August 2023 (UTC)Reply[reply]
@HyperGaruda: but, like changing a date, it is very insidious vandalism when it happens, because it is so hard to tell a legitimate correction from vandalism. - 02:24, 25 August 2023 (UTC)Reply[reply]
At least changes in coordinates are fairly easy to doublecheck with map services like OpenStreetMap or GoogleMaps. --HyperGaruda (talk) 05:49, 25 August 2023 (UTC)Reply[reply]
@HyperGaruda: Only if there are landmarks to go by. If we have (for example) an old picture of someone hiking in a forest, and someone changes the coords, it is very hard to tell a correction from vandalism. - Jmabel ! talk 17:09, 25 August 2023 (UTC)Reply[reply]
Would the categories in question not almost always be for landmark-type features? At least I have a hard time coming up with other categories that need coordinates and I don't think Cat:Hiking in forests will be one of them. How would you tell the difference in the current Commons-based situation anyway? --HyperGaruda (talk) 08:15, 26 August 2023 (UTC)Reply[reply]
@HyperGaruda: You are right, I am wrong. I was thinking of an issue that has arisen for photos (moving coords into the SDC), not categories. (There might be the occasional category for an event that has a particular location, but that's an edge case.) - Jmabel ! talk 16:50, 26 August 2023 (UTC)Reply[reply]
Ah, now I understand where you were coming from. --HyperGaruda (talk) 05:18, 30 August 2023 (UTC)Reply[reply]
if vandalism is the concern, and hinders us removing / consolidating duplicate and eventually contradicting coordinates, we are done. I do it manually anyway. Wasn't there a feature planned to protect some properties by special rights? I check the compactness of coordinates on WD from time to time using something like this query. BTW, if there is an infobox with a map, I do not have a look at other coordinates (unless I'm there for checking purposes).
Some bots do copy coordinates from the descriptions to SD and nobody seems to care for the messages when the redundant information is not in sync any more. I suppose, we have a much bigger problem with wrong coordinates than with vandalism on coordinates. --Herzi Pinki (talk) 18:18, 25 August 2023 (UTC)Reply[reply]
 Oppose: Ever since Wikidata and SCD were inflicted on us, I have solved countless «discrepancies» between the geolocation data in a file’s {{Object location}} or {{Camera location}} or a cat’s {{Object location}} and the geolocation data transcluded thereon from Wikidata via {{Wikidata Infobox}}. In all those cases, the latter was wrong — that maybe due to Wikidata’s porosity to spammers and vandals, to its smaller community, to its own workflow… I don’t know and I don’t care: What I care about is accurate geolocation data in Commons’ file and cat pages, and that can be achieved by {{Object location}} and/or {{Camera location}}. Should a discrepancy occurr, it should be manually fixed by human users who actually know the subject, and Wikidata is very welcome to syphon off that sanitized info back to its GIGO machine (as it did and does with with so much of Commons’ content), to be therat eventually mangled and confused again at which time rinse and repeat. -- Tuválkin ✉ ✇ 02:32, 1 September 2023 (UTC)Reply[reply]
Do you synchronize back to WD discrepancies you have found, @Tuvalkin: ? Or don't you care for the discrepancy and fix only the commons location? (Until someone comes around and fixes it the other way round).
If the commons coordinates are much more reliable than the WD coordinates, and we can agree on that, we could as well remove the coordinates from the Wikidata Infobox instead for the purpose to solve the redundancy. My process is to fix the coordinates on WD and than remove the {{Object location}} here on commons. I admit, I do not care for the location copied to SDC. Your point Tuválkin is about data quality and not about vandalism (if we assume good will for all those automatized copy-pasters). {{Camera location}}, btw, is something completely different and not in the scope of my proposal. --Herzi Pinki (talk) 09:24, 2 September 2023 (UTC)Reply[reply]
I do attempt to synchronize every time I notice one of those distance/discrepancy notices in a file or cat. When Wikidata and global login are working properly (so, about 90% of the time), I successfully enact that synchronization. There might have been cases when that correction was later undone on the WD side, but right now I cannot track any example.
While I’m no friend of Wikidata, even I can see how having that discrepancy warning can be beneficial to both projects. Is it confusing for the casual browser? Maybe, but Commons is a wiki, we don’t hide the wrinkles: «Hey look, right now two repositories curate this item’s geolocation with different values, it will be fixed.» The casual browser should become used to this kind of things.
-- Tuválkin ✉ ✇ 11:08, 2 September 2023 (UTC)Reply[reply]
ok. thanks. My primary proposal was to remove {{Object location}} when the location is identical or nearby to the WD location (or even just taken from WD by using parameter wikidata=). In this case either both are correct of both are wrong, but wrong location will not jump into your eyes. Then as a second step to manually consolidate divergent locations. There is no sense in keeping them just to make readers get used to this kind of discrepancy. I think, this does not in any way contradict your intentions. best --Herzi Pinki (talk) 13:29, 2 September 2023 (UTC)Reply[reply]

August 25[edit]

Fæ's talk page[edit]

User:Fæ is long departed, and User talk:Fæ is breaking under the number of template transclusions. Can anyone see why a bot is not archiving it, as is supposed to happen? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:48, 25 August 2023 (UTC)Reply[reply]

It's getting bot-archived just fine – last archive was a few hours ago, at 07:55, 25 August 2023‎ by User:ArchiverBot. The oldest thread there is only five days old. The problem is that ~ 270 different deletion notices have been served in the past week or two. Jdforrester (WMF) (talk) 19:06, 25 August 2023 (UTC)Reply[reply]
Wait what happened to him Trade (talk) 23:46, 25 August 2023 (UTC)Reply[reply]
@Trade: After the Nth time that they (Fæ's preferred pronoun, though I'm sure I've also slipped and used "he" at times) were a target of what they, at least, perceived as homophobic remarks, they quit. Some of the remarks were definitely exactly that. Oddly, the one that put them over the edge was something I think they misconstrued, but I can see how they read it that way in the context of what had gone before. - Jmabel ! talk 02:11, 26 August 2023 (UTC)Reply[reply]
That's really horrible! :( -- Ikan Kekek (talk) 23:41, 26 August 2023 (UTC)Reply[reply]
Too bad User:Fæ/Civility, Commons:Civility, Commons:Harassment, and Commons:No personal attacks never went anywhere. Nosferattus (talk) 06:20, 27 August 2023 (UTC)Reply[reply]
Oh, all that went somewhere. It was used to get rid of other “undesirables”, such as AlexisJazz (blocked at 1st strike over a transparently bogus accusation), while it was pointedly not used in order to keep around someone’s darlings like INeverCry (finally blocked after their 3rd serious meltdown). Fæ had almost always managed to present a formidably thick skin against all those slings and arrows, but it eventually become too much. It’s a huge loss for Commons, but we know that both the WMF and even some of our admins have the goal of seeing the end of this project, or at least its transformation into something most of us would not want to be a part of. -- Tuválkin ✉ ✇ 02:44, 1 September 2023 (UTC)Reply[reply]
To be exact, Fæ left the project so abruptly that at the time a batch of them was running, which was then cancelled. Fæ takes the view that the reasons for them departure are open for all to see, if only they wanted to see it. There has been doxxing and death threats and no active help or solidarity. Fæ would perhaps return if these problems were acknowledged and addressed by the community. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 22:38, 28 August 2023 (UTC)Reply[reply]
@C.Suthorn, you wrote, "Fæ would perhaps return if these problems were acknowledged and addressed by the community."
Toward that purpose, in what form could action(s) be taken at this time? -- Ooligan (talk) 10:14, 2 September 2023 (UTC)Reply[reply]
For a start, the person who doxxed Fæ, could be repremanded. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 21:19, 2 September 2023 (UTC)Reply[reply]
From what I can tell of the bot configuration on that page, it will all be swept away within a week. —Justin (koavf)❤T☮C☺M☯ 00:02, 27 August 2023 (UTC)Reply[reply]

August 29[edit]

Splitting up a tram type category[edit]

I split the Category:Bombardier Flexity Outlook Cityrunner (Linz) up in two: see Trams_in_Linz

I suspect that in other Category:Bombardier Flexity Outlook Cityrunner places, there are distictions to be made between “Flexity 2 Outlook” and “Cityrunner”.Smiley.toerist (talk) 10:22, 29 August 2023 (UTC)Reply[reply]

Best way to have images reviewed(?) and permission made clearer[edit]

I came across some files I later realised were part of the Miles Glendinning Tower Block archive. Although many were good-quality images, it wasn't at all clear to me whether the source link supported the claimed CC-BY-SA-4.0 license. (Since this is the default license, it quite often appears on copyvios).

A bit of checking showed that they were indeed legitimate and part of a collection. The site says:

The images on the site are made available under a Creative Commons Attribution licence, meaning they may be distributed and re-used as long as credit is given to the original creator, Prof. Miles Glendinning.

However, I don't think all this is sufficiently clear on the image file pages themselves.

My thoughts were that we should have these formally reviewed and possibly the description amended with a link to the permission page and others. But I don't want to jump in and bulk edit all 167 images(!)

Any thoughts?

I'd like to thank Crowsus (talk · contribs) for the upload of these useful images and make clear that no criticism is intended here, I just want to help make the status of these images clear so we don't run into any problems in the future. Ubcule (talk) 18:26, 29 August 2023 (UTC)Reply[reply]

Additional; Category:Tower Block Archive appears to be an alternate upload of the same material in Category:Miles Glendinning Tower Block archive, but with far more files and a dedicated template that makes the source and status clearer. Not sure how this affects what I said above...! Ubcule (talk) 19:20, 29 August 2023 (UTC)Reply[reply]
You can link (and quote) https://www.towerblock.eca.ed.ac.uk/about/archive in the "permissions" section of {{Information}}. - Jmabel ! talk 20:13, 29 August 2023 (UTC)Reply[reply]
@Jmabel: - That's one idea, thank you. As I mentioned, I'm not sure how finding out that there seems to be a separate and much larger upload of the same archive- partially overlapping with this one and with its own dedicated template- changes what should be done. My gut reaction is that the two categories should be combined anyway. Ubcule (talk) 21:41, 29 August 2023 (UTC)Reply[reply]
The two categories can merged, they are exactly the same thing, I just uploaded ones I wanted in 2018 (those are in the Miles Glendinning folder) whereas the other is a bulk upload of everything in the collection 3 years later (obviously I'd not have gone to the trouble had I known that was in the pipeline!) Obviously the higher quality images should be retained and the more formal (original from site I think?) labelling and permissions should be used too. I would like the categories of 'my' versions to be retained if possible as they are much better than the bulk set's generic ones. I don't even mind copying them over manually before mine are overwritten - if that is what is to happen - if someone could give me a heads up when that is likely to take place. Crowsus (talk) 22:12, 29 August 2023 (UTC)Reply[reply]
@Crowsus: - Yes, I noticed that the categorisation of your images was more comprehensive, so we'd want to keep that. (Also, your filenames are more descriptive as to the specific details, e.g. File:Trottick.jpg vs. File:Tower Block UK photo sc 1141800.png. The bulk uploads all include the original literal filename but nothing descriptive, so they're less clear in that respect.)
However, the example above also draws attention to the fact that the versions of the images in your upload aren't identical to those some of the files in the bulk upload by PaulineDataWard (talk · contribs). I notice that yours come from towerblock.eca.ed.ac.uk (e.g.) whereas the bulk ones come from datashare.ed.ac.uk (e.g.).
The example above:-
  • is a PNG (rather than JPG) file,
  • has higher resolution, and
  • has noticeably different colour rendition- while the bulk version appears more saturated (vivid), its colour also looks distinctly less natural in the sky and especially the grass (i.e. it's not just the same as your version with the saturation turned up).
(Side note on that last point- which those not interested in the technicalities can ignore!- my gut reaction was that this looked more like a colour space issue than colour balance or saturation. And lo and behold when I loaded up the bulk version- whose profile was "Adobe RGB"- and assigned the standard "sRGB" profile to it it then looked identical to yours other than the higher resolution.)
tl;dr - The versions of the files from the two sources are different, higher resolution versions are probably better though there may be some minor issues with colour? A few of the bulk upload images are different, most are not(!)
Ubcule (talk) 19:45, 30 August 2023 (UTC)Reply[reply]
Edit above; it appears that this only applies to a small proportion of images in the bulk Tower Block Archive category (see [this page onwards]) rather than all of them. Ubcule (talk) 19:57, 30 August 2023 (UTC)Reply[reply]
@Crowsus: - I've looked into this and there are a few points:-
  • Turns out that none of your original uploads are exact duplicates of files still on Commons. Any files within the bulk upload which were identical to any of yours were deleted and redirected to your (older) upload (e.g. this edit by Túrelio (talk · contribs)).
  • Only problem is that your original uploads (i.e. the ones that were retained) don't have the full descriptive text scraped from the website that the bulk uploaded versions did. It'd be good if there was an easy way to recover and combine that with your upload automatically (while keeping your categorisation), but I can't think how.
  • I've partially renamed your uploads in Category:Miles Glendinning Tower Block archive for greater consistency with the bulk upload names, but retained the descriptive parts (e.g. "Airdrie 1988-2.jpg" became "File:Tower Block UK photo cl1-07 (Airdrie 1988-2).jpg") and everything else. (They remain within your original category for now until I've double-checked that each of them have been correctly added to Category:Tower Block Archive or one of its subcategories.)
  • Ignore what I said above about the .png/.jpg versions as this only applies to circa 20 images (all associated with Dundee for some reason) so likely isn't worth worrying about.
Ubcule (talk) 16:38, 3 September 2023 (UTC)Reply[reply]

Commons and the upcoming Wikimedia Summit[edit]

Wikimedia Summit 2024 will be happening in April, and will probably be the last meaningful chance for input to the Movement Charter, which will probably determine a great deal about Wikimedia governance going forward, including (indirectly, but almost without a doubt) a lot about how money and resources are allocated. Because the "community" (vs. Foundation) involvement for the conference is entirely through affiliates and user groups -- not through "projects" such as Commons -- there is no overt representation for Commons at the Summit. When I raised this question, someone pointed out that there will be a representative of the Commons Photographers User Group (I'm not sure whom, and there is no indication on that page), but of course the focus (so to speak) of that group is much narrower than that of Commons as a whole.

If we, as a community, have concerns that we would like represented in Berlin in April, we would do well to identify those concerns, and either (1) organize them in a way that they can be brought into the discussion by one or more of us who are already attending, or (2) see if we might be allowed belatedly to form a Commons User Group and be represented that way. I think a lot of Commons' likely concerns are different than those of the various Wikipedias, and may be very underrepresented in what is largely a gathering of geographical and topic-based groups.

Just in general, it concerns me that the basis for representation at the Summit seems to completely ignore the many users, probably the majority of users, whose involvement is strictly on-wiki. I raised that issue in today's "engagement session," and while some other participants clearly shared my concern, the response from those running the session was somewhere between "the train already left the station" and a massive shrug. I don't question their good intentions, but it appears to me that if Commons as a community has concerns about the Charter, we are going to have to make a very active effort to bring those forward, we will not be pro-actively consulted. (Similarly for anyone not involved in affiliates or user groups, and whose participation is strictly on-line.) - Jmabel ! talk 20:46, 29 August 2023 (UTC)Reply[reply]

thx for the tipoff.
as i saw the location could be conveniently reached, i jumped to the page you linked, only to find out, as you did, that users without any affiliation are not eligible at all. there're not even any wildcard or first-come-first-serve walk-in places. seriously? it appears not only commons but also wikidata doesnt have affiliate groups? so the two most important cross-project wikis cannot have representation? what the fun...
without your tipoff, i'm totally unaware of such things taking place either, even though i'm active on-wiki almost daily. yet this is the sort of the things that make decisions about wiki projects?
with all that money spent on talking shops, when will wmf finally put aside a bit for developing essential tools like video2commons. RZuo (talk) 08:23, 1 September 2023 (UTC)Reply[reply]

Cropping[edit]

I noticed people cropping (particularly automobile) photos a lot over the last few years. Sometimes it is beneficial, where the subject otherwise only occupies a small section, but sometimes it seems wholly unnecessary and just makes for pointless additional files. See a few examples. Are there any relevant guidelines for when it's worthwhile to create new crops? Thanks, mr.choppers (talk)-en- 03:20, 30 August 2023 (UTC)Reply[reply]

  • Original

    Original

  • Crop

    Crop

  • Original

    Original

  • Crop

    Crop

The first is such a minimal crop as to be a bit bizarre; hard to see why anyone would care about the few pixels difference, but apparently the person putting it in an article did. I see you are the original uploader: did you ask the person who did this why they did it? The second: well, I probably wouldn't have uploaded that photo if I'd taken it -- hard to see a use for it -- but the cropped version is probably a bit better composition.
Do keep in mind: storage is cheap. I believe the only downsides to additional files are possible clutter in categories, and possible dual maintenance issues if further edits are to be made to the files. - Jmabel ! talk 05:56, 30 August 2023 (UTC)Reply[reply]
Totally agree with the sentiments made here, these particular croppings are as good as downgrades. As an aside we shouldn't be blurring out license plates on cars, rather we should upload the original with the plate, and then overwrite them with a smudged version. After 25 years revert them, the plates are historical items in their own right. I also don’t hold with the right to privacy bollocks that comes out about blurring the plates either, I doubt very much whether the owners would even know or even care. I'm guessing they would be as pleased as punch to see their car here. Broichmore (talk) 09:57, 30 August 2023 (UTC)Reply[reply]
The first example makes a difference of 2% in pixel dimensions. I think crops should only be exeucted to show a detail inside an image or to crop out irrelevant space like white paper without content. The thing with the license plate is that unfortunately there is no option to publish an image 25 years later right now. --PantheraLeo1359531 😺 (talk) 20:59, 30 August 2023 (UTC)Reply[reply]
See also Commons:CROP --PantheraLeo1359531 😺 (talk) 21:07, 30 August 2023 (UTC)Reply[reply]
Sometimes very slight crops make sense (e.g. to get rid of some inconvenient artifact very near an edge of a photo), and if you don't have the original uploader's/photographer's permission it is probably best to do that under a new filename. But here I see no obvious good reason. PageOrganizer, can you explain why you made this crop? - Jmabel ! talk 22:44, 30 August 2023 (UTC)Reply[reply]
Thank you all, I feel the same way. Broichmore, I always blur the license plates as that is what I tell people when they catch me photographing their cars. You'd think people would like having their car on WP, but I have been threatened on many occasions (and it's not just Americans, a German once was upset that I uploaded a picture of her car with her face blurred and demanded 200 Euro), a guy showed me a gun once (upstate NY), so if it makes car owners more comfortable to have the plates blanked then I will certainly do so - FOP be damned. Look here for another unhinged example. I believe they think that I will take a piece of their soul by photographing their publicly parked vehicles. If I upload the original and then overwrite, someone could always revert it and make a liar out of me. I have twice gotten out of uncomfortable situations by showing my WP uploads with anonymized photos. mr.choppers (talk)-en- 10:58, 31 August 2023 (UTC)Reply[reply]
@Mr.choppers, @XRay, @Ralf Roletschek: for situations with upset Expats there is the project v:de:Fotorechte DACH, that aims at creating a brochure to give to people not familiar with the legal situation in Germany, Austria and Switzerland. It is unfinished and everyone is invited to contribute to it. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 11:51, 31 August 2023 (UTC)Reply[reply]
For Germany: As far as I know, it is not necessary to make license plates unrecognizable if no information about private persons is disclosed via the license plate. The plate itself is therefore usually not a violation of privacy or data protection, since it usually does not reveal any information about the owner. However, the location of the car with a license plate may reveal something if the vehicle is parked on private property. In short, an identifiable license plate is a violation of privacy rules only under certain conditions. Only the police can look up who the owner of a car with the corresponding license plate is. See more here (German): https://www.anwalt.de/rechtstipps/autokennzeichen-auf-fotos-erlaubt-update-17-11-2022-203209.html --PantheraLeo1359531 😺 (talk) 15:31, 31 August 2023 (UTC)Reply[reply]
See also: https://www.gutschild.de/blog/kfz-kennzeichen-fotografieren-und-veroeffentlichen-was-ist-erlaubt/ --PantheraLeo1359531 😺 (talk) 15:35, 31 August 2023 (UTC)Reply[reply]
Hi Jmabel, the reason I had made two crops is because when I made the first crop, it was squished (it was only squished for me, which I didn't realise until later), and I didn't know how to revert it back to original, so I had made a copy of the image. Sorry about this PageOrganizer (talk) 11:30, 31 August 2023 (UTC)Reply[reply]
@PageOrganizer: Your crops are too tight; a little bit of background makes it look more natural. Thanks. mr.choppers (talk)-en- 12:34, 31 August 2023 (UTC)Reply[reply]
Images sometimes take up too much vertical space on wiki pages (desktop), so I tend to remove as many pixels as possible above and below the subject. --Sitacuisses (talk) 12:05, 1 September 2023 (UTC)Reply[reply]

August 31[edit]

Barriers to Cross-Platform Collaboration - Wikipedia / Commons[edit]

In The Signpost an interesting article based on interviews with editors on Commons and (English) Wikipedia:

Perhaps we can start some action on reducing the barriers. Ellywa (talk) 08:51, 31 August 2023 (UTC)Reply[reply]

After a cursory reading, it seems that categories is the culprit. Heh, not even in my most dishevelled curmudgeonly of rants I would resort to hyperbolize that the WMF would try to mask their failiures in Commons by pointing a finger to “power users” and our work with categories. And yet, here we are. -- Tuválkin ✉ ✇ 02:07, 1 September 2023 (UTC)Reply[reply]
One of the main solutions suggested in the article is to increase our use of Wikidata. I hope as it becomes more prominent, it will indeed help us in the ways suggested. Regarding the Boeing 777 section, I don't think there's actually a problem there needing solving. It is overwhelming, but there's lots of positives to our extensive collection of pictures of Boeing planes. I think our "Good Pictures" system, though a bit hidden away, can be a great system for letting users find the quality pictures for general usecases. ~Mable (chat) 07:36, 4 September 2023 (UTC)Reply[reply]

Croptool[edit]

Is croptool failing by timing out for anyone else? --RAN (talk) 23:06, 31 August 2023 (UTC)Reply[reply]

@Richard Arthur Norton (1958- ): WikiShootMe is also failing. --ŠJů (talk) 23:31, 31 August 2023 (UTC)Reply[reply]
The problem stil persists. --ŠJů (talk) 10:29, 1 September 2023 (UTC)Reply[reply]
+1 --Sitacuisses (talk) 11:42, 1 September 2023 (UTC)Reply[reply]
Funny thing, a minute before the above reply, Croptool worked neatly and efficiently for one of my pictures of Brooklyn.Jim.henderson (talk) 13:09, 1 September 2023 (UTC)Reply[reply]
Seems to work again now. --Sitacuisses (talk) 14:14, 1 September 2023 (UTC)Reply[reply]
​​ For WikiShootMe, the problem stil persists. But at night I noticed an interesting phenomenon: while a new window with WikiShootMe could not be opened using the link, the window open before was still working and loading the current data. --ŠJů (talk) 14:23, 1 September 2023 (UTC)Reply[reply]
  • Back to working today, looks like several tools stopped last night. --RAN (talk) 18:00, 1 September 2023 (UTC)Reply[reply]

September 01[edit]

Odd thumb/display problem[edit]

File:Ketchikan, AK - Fire Engine No. 1.jpg: underlying image seems fine, but no thumbnails for me. Duly purged & it won't let me re-upload as a new version, says it's an exact duplicate, so I don't see much I can do from my end. Is this failing for others or just for me. - Jmabel ! talk 00:49, 1 September 2023 (UTC)Reply[reply]

@Jmabel: I can see all thumbnails of that. --ŠJů (talk) 01:45, 1 September 2023 (UTC)Reply[reply]
And now so can I. Guess it was a short-term glitch. - Jmabel ! talk 02:00, 1 September 2023 (UTC)Reply[reply]
But now I'm having the same problem with File:Ketchikan, AK - taxidermied wolf in entrance to a shop on Water Street.jpg, and this time I can't even see the underlying image (instead I get "File not found: /v1/AUTH_mw/wikipedia-commons-local-public.60/6/60/Ketchikan%2C_AK_-_taxidermied_wolf_in_entrance_to_a_shop_on_Water_Street.jpg"). Commons obviously has it, because I can't upload a "duplicate". I'm guessing there is some sort of server-synch'ing issue.- Jmabel ! talk 02:10, 1 September 2023 (UTC)Reply[reply]
& a similar problem for File:Ketchikan, AK - waterfront along Water Street 05.jpg. Click-through for full image gives "File not found: /v1/AUTH_mw/wikipedia-commons-local-public.ba/b/ba/Ketchikan%2C_AK_-_waterfront_along_Water_Street_05.jpg" - Jmabel ! talk 03:23, 1 September 2023 (UTC)Reply[reply]

Cats for lit lamps[edit]

This photo shows a lamp turned on during the day. I wanted to categorize it as such, but we seem to lack even a cat for lamps (or any lighting fixture) in on state, ans also in off state. Seems like a glaring absence, pardon the pun. -- Tuválkin ✉ ✇ 05:19, 1 September 2023 (UTC)Reply[reply]

@Tuvalkin: If no one has yet created such a category at any level, it means that users have not yet considered such a category necessary, and they did not consider it appropriate to complicate the categorization with this distinction. Even with many other machines and devices, we do not have separate categorization branches for on (functional) and off (non-functional) state. However, Candles have a subcategory of Category:Burning candles. --ŠJů (talk) 10:27, 1 September 2023 (UTC)Reply[reply]
Yes, I suspected that such a category does not exist because it was never created, as one could say about… well, most anything. I suspect that the paucity of contents in cats like Category:Vehicles in motion is that Commons deals mostly with static images, whereon the on or off state of most devices cannot be easily (or usefully) ascertained — a glaring exception (heh) being exactly lighting devices. Therefore I do think that such a new cat is warranted.
What I meant with the o.p. is to stirr up ideas about the new cat’s name and categorization; mentioning Burning candles as part of Candles is a useful analogous, and a good candidate for a subcat.
In terms of English, what would be the suitable wording?
(Of course, the new cat I originally sought will be the one chosen from above +" in daylight" or somesuch, with {{See also cat}} to Category:People wearing sunglasses at night, with some shared parent cats.) -- Tuválkin ✉ ✇ 11:19, 1 September 2023 (UTC)Reply[reply]
@Tuvalkin: Such a category would certainly be useful, but we probably have to assume the fact that no one will be enthusiastic about sorting thousands photos of all subcategories.
I'm not very good in English, however, if there is a choice of more synonyms, preference should be given to the term that is as internationally comprehensible and unambiguous as possible. According to my vocabulary, the word "lit" is a bit ambiguous - it can mean both, shining object and (passively) illuminated object. Another requirement is that it should be possible to attach the relevant criterion in the same way and in the same form to the names of all subcategories, including categories with long descriptive names, e.g. "Exterior lighting fixtures at train stations" or "Luminous road signs". --ŠJů (talk) 14:08, 1 September 2023 (UTC)Reply[reply]
Good point about "lit". Maybe "alight", then? The most generic cat should not be constrained to electrical lamps, so "on" might not be ideal.
I cannot share your concern about the possibility that «no one will be enthusiastic about sorting thousands photos of all subcategories», though: That’s what many of us do every day, and love it. -- Tuválkin ✉ ✇ 14:19, 1 September 2023 (UTC)Reply[reply]
I came across the interpretation that the word "alight" is inappropriate for electric lights. The available online dictionary does not even indicate this possibility.
If you are willing to sort photos of lamps and light objects into a deep categorization, I wish you a lot of perseverance. --ŠJů (talk) 15:16, 1 September 2023 (UTC)Reply[reply]
"Lit lamps" is probably the most colloquial English. - Jmabel ! talk 15:17, 1 September 2023 (UTC)Reply[reply]

Commons Gazette 2023-09[edit]

Volunteer staff changes[edit]

In August 2023, 1 sysop was elected. Currently, there are 186 sysops.

Edited by RZuo (talk).

Commons Gazette is a monthly newsletter of the latest important news about Wikimedia Commons, edited by volunteers. You can also help with editing!

--RZuo (talk) 08:00, 1 September 2023 (UTC)Reply[reply]

Extra text in category[edit]

See: Category:Anne Roselle where "c:Category:Anne Roselle" appears. Where did it come from? Did I turn on something by mistake in my preferences? Anyone else see it? RAN (talk) 17:44, 1 September 2023 (UTC)Reply[reply]

I am seeing the same text appearing in every category. It appears to be coming from Template:Wikidata Infobox or one of its subpages. From Hill To Shore (talk) 18:36, 1 September 2023 (UTC)Reply[reply]
it looks like the bug has been fixed JotaCartas (talk) 18:57, 1 September 2023 (UTC)Reply[reply]
I have started a discussion at Template talk:Wikidata Infobox#Template inserting page name as plain text on every page. From Hill To Shore (talk) 18:51, 1 September 2023 (UTC)Reply[reply]

Request for temporary ui-admin and sysop right for Adiutor integration[edit]

Hello everyone, I hope this message finds you well. I am writing to request temporary interface administrator and administrator rights for the purpose of integrating and deploying the Adiutor tool to Wikimedia Commons. I would like to have these privileges for a duration of one week. You can find comprehensive information about Adiutor through this link. I believe that having these privileges will greatly assist in the successful adaptation and deployment of Adiutor, and I am committed to ensuring a smooth and efficient process throughout the integration. Thank you for considering my request. I look forward to your positive response. Best regards. 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 ℣ 17:56, 1 September 2023 (UTC)Reply[reply]

@Vikipolimer, Thanks for notifying us. Your contributions for Adiutor improved many Wikis. We can use this tool here also, it would be very beneficial because tagging and reporting process is hard in Commons. I am pinging bureaucrats in order to evaluate this request: @99of9, @Ellin Beltz, @EugeneZelenko, @Jameslwoodward, @Krd, and @Odder. Kadı Message 18:11, 1 September 2023 (UTC)Reply[reply]
Context for those who (like me) had no clue what Vikipolimer was talking about: meta:Adiutor. - Jmabel ! talk 21:02, 1 September 2023 (UTC)Reply[reply]
I notice that all existing rollouts are on Wikipedias, and that Commons is a bigger project than the existing venues. Are we confident that it is well suited to Commons? For example, has the list of speedy deletion reasons been customised to suit Commons deletion reasons? --99of9 (talk) 05:48, 4 September 2023 (UTC)Reply[reply]
@99of9, yes you can test the gadget. Commons:Adiutor I've already start the adapting process. If you want new features for commons, I can add lovely. 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 ℣ 05:56, 4 September 2023 (UTC)Reply[reply]
Thanks. I have enabled the gadget and will try to test it out a bit (so far I've found that things like: "CopyVio check" means only checking some text on the page, nothing to do with the image, so does not hit 99.9% of Copyvios on Commons). If the gadget already works, what is it that you need to edit with interface administrator rights? --99of9 (talk) 06:12, 4 September 2023 (UTC)Reply[reply]
@99of9, I am currently in the process of adding templates and configuring settings that will be applied universally across the gadget files. Authorization for this task was granted a couple of hours ago, and I have just completed the initial setup. There are only a few minor tasks remaining, and once I finish those, my work will be complete. 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 ℣ 06:17, 4 September 2023 (UTC)Reply[reply]

Category:First Ladies by year[edit]

Good evening forum users! How do you feel about sorting by year the first ladies of states? The wives of presidents and monarchs are very often put in the same row. --MasterRus21thCentury (talk) 18:01, 1 September 2023 (UTC)Reply[reply]

Category:Women wearing nail polish[edit]

What would be the best way to connec this category to Women?--Trade (talk) 19:12, 1 September 2023 (UTC)Reply[reply]

Put it under Category:Women wearing make-up. Nosferattus (talk) 00:27, 3 September 2023 (UTC)Reply[reply]

September 02[edit]

Swedish page on Radom (city in Poland)[edit]

On the Swedish page about the town of Radom, not a word is mentioned about the 33.000 jews living in the city at the time of ww2. They nearly all got killed in Treblinka.

This is Commons, not Swedish Wikipedia. Raise this issue there, though the article is just a short stub there. Ruslik (talk) 20:04, 2 September 2023 (UTC)Reply[reply]

September 03[edit]

Category:2022 Russian invasion of Ukraine[edit]

User:Cactinites recently moved Category:2022 Russian invasion of Ukraine to Category:Russian invasion of Ukraine with a justification of "As per the Wikipedia page". Was this discussed? Is Cactinites perhaps unaware that Russia also invaded Ukraine in 2014? Or that many Wikipedias (including both Ukrainian and Russian language projects) still use the title with "2022" included?

I think the move, and all the associated recategorisation, should be reversed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:42, 3 September 2023 (UTC)Reply[reply]

Concur. If this was done without a CfD or equivalent, then it should certainly just be moved back, and if someone wants to move the category they need to develop a consensus to do so. This is obviously not an uncontroversial move, and no one should be making controversial moves unilaterally. - Jmabel ! talk 18:51, 3 September 2023 (UTC)Reply[reply]
Not that I think the files should have been moved, but at least the description in the inbox for Category:Russian invasion of Ukraine says "ongoing military conflict in Eastern Europe since 2022." It's also a sub-category of a lot of other ones for events that took place in 2022. So as things currently are it seems like Category:Russian invasion of Ukraine doesn't include the pre-2022 conflicts. Again, that's not to say files should have been moved, but the description in the infobox at some of the parent categories at least need to be removed or changed in the process of restoring things so it doesn't seem like Category:Russian invasion of Ukraine is just for things that happened after 2021. --Adamant1 (talk) 20:47, 3 September 2023 (UTC)Reply[reply]

"OAuth" tool for "Find images for Wikidata" of "PetScan"[edit]

When I want to add an image in WDFIST tool linked from "PetScan" (Find images for Wikidata) a get the following message "E1:You haven't authorized this application yet! Go <a target="_blank" href="/wdfist/query.php?action=authorize">here</a> to do that, then reload this page.", bu the link is not working (at least for me). Does anyone know how to go to the "OAuth" tool?? --JotaCartas (talk) 23:00, 3 September 2023 (UTC)Reply[reply]

Different pictures, one file[edit]

A user has packed several different images into one file. Not sure what to do with that. --2003:C0:8F0C:7F00:F4DB:9305:33F3:9ECD 19:18, 3 September 2023 (UTC)Reply[reply]

There are five separate files. Ruslik (talk) 19:41, 3 September 2023 (UTC)Reply[reply]
Nothing wrong with a quasi-gallery like that, but it belongs in the description, not in "other versions". "Other versions" is for other versions of the same image, not other images of the same object. - Jmabel ! talk 19:50, 3 September 2023 (UTC)Reply[reply]
Pinging @Zoerides, and I'll fix that placement. - Jmabel ! talk 19:51, 3 September 2023 (UTC)Reply[reply]
That's an extremely narrow interpretation of the "other versions" field I don't agree with. As the documentation says "Links to files with very similar content or derived files;". Having photos of the same car in other versions is no problem at all and shouldn't be moved to the description. Multichill (talk) 21:53, 3 September 2023 (UTC)Reply[reply]
@Multichill: But they are not "very similar". They are just of the same vehicle. File:Aeolus Haoji 006.jpg is so different you wouldn't even guess it had any relation unless it were linked like this. "Very similar" is thing like a colorized postcard based on a particular black-and-white photo, or two shots from the same camera position taken seconds apart. I've absolutely never seen "other versions" used the way it was on this photo. I see you've reverted, and I won't edit-war, but I think you are wrong. - Jmabel ! talk 00:04, 4 September 2023 (UTC)Reply[reply]
For objects like sculptures it's common to have the other views also in the "other versions". Just a different view of the same object, just like with this car. Multichill (talk) 18:11, 4 September 2023 (UTC)Reply[reply]
@Multichill: Never seen it, but then I don't do a lot of work here on other people's photos of sculptures.
Question: why isn't that (multiple images of the same sculpture) just done as a category? That's certainly what I would do. - Jmabel ! talk 19:54, 4 September 2023 (UTC)Reply[reply]
As long as it's open ended, yes it makes much sense to create a category for a sculpture, or for a vehicle model. Most importantly, you don't need to update each of the other versions whenever a new version is made. A big plus for categories! But I can't see any harm in creatively using the "other version" parameter like in this case. Naturally, editors should be discouraged from making really extensive galleries that way, but a couple photos of the same object from a different angle... well that is (imo) what may be expected right there. Just compare the crop-feature, it allows the embedding of hundreds of cutouts from the original file, in the original file's description-block: and yes, as "other versions"! Prime example I encountered today: this PDF with 160+ other versions. Another one is this JPG with 60+ other versions. Yes I think this many cutouts are annoying and counterproductive, but someone made them.) --Enyavar (talk) 21:33, 4 September 2023 (UTC)Reply[reply]
It's the same car, at the same time, and in the same place. These photos are more closely related to each other than they would be to photographs of other cars of the same model; linking them to each other like this seems like a reasonable thing to do, and it certainly doesn't harm anything. Omphalographer (talk) 03:51, 5 September 2023 (UTC)Reply[reply]
I agree with the linking, just would have put it in "description" not "other versions". At File:Ferry approaching Seattle August 2023 - 01.jpg I did something just like that the other day. - Jmabel ! talk 04:35, 5 September 2023 (UTC)Reply[reply]

September 04[edit]

Guidelines for naming visual arts works[edit]

I've found some works by Félix Vallotton that are misspelled ("Valloton"). Is there a guideline for naming works of this kind or is ot completely up to the uploader/renamer?

For example:

or:

--Carnby (talk) 05:06, 4 September 2023 (UTC)Reply[reply]

--Carnby (talk) 11:59, 4 September 2023 (UTC)Reply[reply]
Again, I stand by my statement that changing the language of a filename is a way to start a war. If you insist on doing it I won't stop you, but I certainly won't participate. - Jmabel ! talk 17:31, 4 September 2023 (UTC)Reply[reply]
@Carnby: No, don't go there. File names should only be renamed when incorrect and never to just improve them. See Commons:File renaming: "In general, Commons aims to provide stable filenames as there might be external file clients and file moving involves significant human and computing resources. Thus renaming should be used with caution."
You're welcome to add a correct caption. Multichill (talk) 18:17, 4 September 2023 (UTC)Reply[reply]
So just correct Valloton in Vallotton?-- Carnby (talk) 18:19, 4 September 2023 (UTC)Reply[reply]
I wouldn't even do that because the sources seem to mix both variants. Multichill (talk) 18:28, 4 September 2023 (UTC)Reply[reply]
AFAIK "Valloton" is just a common mispelling. Another mispelling is "Valloiton".-- Carnby (talk) 21:42, 4 September 2023 (UTC)Reply[reply]

misscategorization and overcategorization[edit]

It is ok to fill up a category with files which is not the main subject causing the whole category to appear another category while having better categories for the images to be allocated to ?

Here is the problem. a user fill up the category with bridges from a pedestrian perspective Category:2023 in rail transport in Catalonia while having another category which is way more suitable to be categorized for Category:Bridges in Catalonia photographed in 2023

Problem 1: a railway bridge from a pedestrian view has barely anything to do with year rail transport

Problem 2: the category now looks like bridges photographed rather than a year rail transport category 9pm (talk) 13:21, 4 September 2023 (UTC)Reply[reply]

In conclusion: I think the images should to be moved from Category:2023 in rail transport in Catalonia to Category:Bridges in Catalonia photographed in 2023

@9pm: I can't make any sense of "the category appears now more to bridges photographed than a year rail transport category". Just doesn't parse. Can you reword (either in English or some other language)? - 17:34, 4 September 2023 (UTC)Reply[reply]

I just rewrote the whole sentence , I hope it makes sense now and thanks for the corrections 9pm (talk) 20:18, 4 September 2023 (UTC)Reply[reply]

I'd probably put them in both (though I doubt I would ever have created something as narrow as Category:2023 in rail transport in Catalonia). These are not big enough categories for additional images to be a real problem. - Jmabel ! talk 19:59, 4 September 2023 (UTC)Reply[reply]

Degrading of a postcard by a blocked? user.[edit]

This so called upgrading of a postcard is a comprehensive degrade, and should be uploaded as a different image. The label in the bottom left is not a watermark, the yellow sky is typical of the house style printing back in 1890-1905. I have contacted @Jan Arkesteijn: about it.

Apologies too him, but this issue is too important to leave, just on his talk page.

Also when you edit his talk page a pop up appears indicating this user was blocked on 8 November 2018. Is this some unwanted artefact? It certainly took me by suprise. .Broichmore (talk) 12:11, 4 September 2023 (UTC)Reply[reply]

Embarrassingly enough, I just noticed the edit was back in 2008. However nobody has reverted this type of work it would seem. Broichmore (talk) 12:25, 4 September 2023 (UTC)Reply[reply]
@Broichmore: that user was blocked for unwanted behavior which included overwriting files with horrible versions, just like what happened here. These files are tracked in Category:Image overwrites by Jan Arkesteijn for independent review. Why did you remove it without reverting it to the original file? By removing the category and not reverting you're saying the current version is fine. If you encounter such a horrible overwrite by another user you can just undo it with a link to COM:OVERWRITE. Multichill (talk) 18:23, 4 September 2023 (UTC)Reply[reply]
Now reverted to original file. - Jmabel ! talk 20:01, 4 September 2023 (UTC)Reply[reply]

Please help with file move (reversion)[edit]

I am trying to revert (move) a file to a its original filename. The new filename is breaking links on Wikisource. I can't just undo the file move/rename because a bot has performed another edit since then.

Although I have removed the redirect on the original filename, and it shows as not existing, the page mover won't let me rename it to the original filename because it says it already exists. I have tried purging both files.

The current filename is Blessed Be God, A Complete Catholic Prayer Book (1925).pdf

The original filename is Blessedbegodcomp00call.pdf

Can anyone help? Or tell me where else to post my request? Thank you. Laura1822 (talk) 20:09, 4 September 2023 (UTC)Reply[reply]

@Laura1822 ✓ Done. Because the redirect had a history, it needed to be deleted by an admin. —‍Mdaniels5757 (talk • contribs) 20:20, 4 September 2023 (UTC)Reply[reply]
THANK you!!! I have been beating my head against the wall over this! Thank you for fixing it so promptly. Laura1822 (talk) 20:23, 4 September 2023 (UTC)Reply[reply]

September 05[edit]

Elon Musk family tree removed[edit]

This edit https://commons.wikimedia.org/w/index.php?title=Category:Elon_Musk&oldid=726496691 removed the Elon Musk family tree from his category. The remover described it as clutter, but for people with extensive family trees, we do have trees embedded in the category. It is a visual navigation device to move through the family. We don't take a screenshot and post it, because it is dynamic. People are currently working backward and adding to it. We have these trees for almost everyone with an extensive tree with Wikidata/Commons entries. I have no objection to it appearing collapsed with a click to open, but I do not remember how to add a collapse feature, can anyone help? --RAN (talk) 02:08, 5 September 2023 (UTC)Reply[reply]

Multiple better quality duplicates nominated for deletion by bot.[edit]

I left a message on the bot owner's talk page, but I wanted to let someone here know before they get deleted.

See File:Bellaire, Belmont County, Ohio, 1915 - DPLA - 6e29900fcb6f1fa78b41d0729043b82a (page 18).jpg and more map files here: https://commons.wikimedia.org/wiki/Category:Duplicate

The bot applies the "duplicate" tag to delete the most recent duplicate file. However, in this instance, the newer file are actually better because they give details about "Sanborn maps." The other file does not have this valuable information. Also, the file nominated for deletion has better licensing as well. What is the best way to delete the older files instead (reverse the tagged file)? There are many of these files like this. Thanks, --Ooligan (talk) 02:32, 5 September 2023 (UTC)Reply[reply]

Iranian copyright law[edit]

We have a large list at https://commons.wikimedia.org/wiki/User_talk:GTVM92 where the nominator is questioning whether Iranian copyright law applies to images of The Shah and his family. Can we aggregate them into one list? I can see where a few that are attributed to non-Iranian news agencies would not fall under PD-Iran, like File:Iranian and British royal families.jpg, we can eliminate them from the list. RAN (talk) 03:53, 5 September 2023 (UTC)Reply[reply]

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