Commons:Village pump/Proposals/Archive/2024/10

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

Commons:Deletion requests/mobile tracking

Is Commons:Deletion requests/mobile tracking still necessary?

  1. how many active users watch or use it occasionally?
  2. any developers use it? (supposedly to check upload quality so they can tweak the software to reduce problematic files?)

i dont have stats, but i guess the proportion of uploads from mobile devices must be much higher than the page started before 2013. what's the percentage of commons users who mainly use mobile versions? 40% (my rough guess)? is this page still meaningful when a substantial number of users use mobile?

i propose the DR gadget stop listing new DR on this page. RoyZuo (talk) 15:43, 2 October 2024 (UTC)

@Alachuckthebuck: I don't see anything in the information for the bot saying it has anything to do with this. Can you clarify exactly how it helps the bot track things? --Adamant1 (talk) 21:38, 3 October 2024 (UTC)
It's used for analyzing bot edits after the fact, and also can help with RFCU and LTA detection. All the Best -- Chuck Talk 21:42, 3 October 2024 (UTC)
Uploads from mobile devices will still be tagged in logs. Disabling the automatic edits to the mobile tracking page won't change that. And I still don't understand how this relates to that bot. Omphalographer (talk) 03:30, 4 October 2024 (UTC)
I stand corrected, I thought that would remove the log tag. All the Best -- Chuck Talk 03:46, 4 October 2024 (UTC)

distributed_by

Can we add "distributed_by" to structured_data? It currently gives the message: "The property distributed by should not be used on this type of entity, the only valid entity type is Wikibase item." We have over 1,000 news articles that were published_by newspapers, but they were distributed by the Associated Press or United Press International. We have even more images from both entities. RAN (talk) 18:21, 8 October 2024 (UTC)

I removed the constraint Trade (talk) 00:39, 16 October 2024 (UTC)

Please upload PD images from picturethepast.org.uk

File:Glossophall.jpg is from picturethepast.org.uk. Others such as Glossop Hall, Glossop, c 1910s are also useful. ..... 69.181.17.113 09:19, 14 October 2024 (UTC)

Not with the watermarks they have on images now. Better scans probably can be found elsewhere. Carl Lindberg (talk) 13:03, 14 October 2024 (UTC)
Better than not having them at all Trade (talk) 00:58, 16 October 2024 (UTC)
Better copy at [1], for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:00, 17 October 2024 (UTC)

Is this the right place to ask this?

If this is the right place to ask this, then please close my deletion nomination in File:Hakurei Shrine Reitaisai in Taiwan 3 (1).jpg. I withdrew it nearly 20 days ago. AuroraANovaUma ^-^ (talk) 20:42, 21 October 2024 (UTC)

Administrators regularly review deletion requests (DR's), so all you would probably have to do is wait. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:46, 21 October 2024 (UTC)
By the way, if you don't know something about anything I'd advise you to go to "Commons:Help desk" for general questions, "Commons:Village pump/Copyright" for copyright-related questions, and "Commons:Village pump/Technical" for technical-related questions. This village pump is usually for policy and / or guideline proposals. -- Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:49, 21 October 2024 (UTC)
Ok, well hopefully my nomination gets closed soon. AuroraANovaUma ^-^ (talk) 21:30, 21 October 2024 (UTC)
This section was archived on a request by: --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:39, 13 November 2024 (UTC)

Template:Private land

Because of these discussions: here and here, I created this template. My recollection is that we've never removed photographs simply because they were obtained by trespassing (we didn't in the 2000s and it appears like we don't now). But I do see no harm in providing a notice on those images, partially in courtesy to those on whom were trespassed and partially so that future viewers know to avoid "updating" those photos without contacting the property owners. I did have to copy another template, so there might be goobers and mistakes, and I have yet to provide documentation for the template. Any help or suggestions are very much welcome. Bastique ☎ let's talk! 18:47, 19 October 2024 (UTC)

I don't really see the need for this, but if we keep it, can we please tune it down a notch? 1) This does not need to go above all other content on top of the page. 2) Color scheme should follow that of other non-copyright restrictions like Template:Personality rights (which seems to be based on Template:Non-copyright restriction). Let's keep the high alert type colors for the really important things, otherwise they wear out even more. El Grafo (talk) 08:02, 20 October 2024 (UTC)
Many photos here are from events where accessing a place is only possible if you are a guest of the event. We should not put a warning on all these photos. An exception where something similar could be useful would be an information at photos of for example protected areas where accessing the are is only allowed with permission from an authority. For WLE we have this often and currently it is written into the description but it could be nice to have it in a template. GPSLeo (talk) 08:28, 20 October 2024 (UTC)
Landowners are the ones to put up "no trespassing" signs. It is not the duty of everybody else, including law enforcement. The landowner can give permission or not based on his own decision. I recommend something else when you are allowed on private property to take photos with the consent of the landowner. I give a notice on my photo: "The photographer thanks the landowner for the kind permission to access the property and take pictures." This is how you do it. Otherwise, when you are there by accident, came through an open gate, hiking through the woods or whatever, you just shut up and feign ignorance. You explain what you are doing and leave the property if you are told to.--Giftzwerg 88 (talk) 09:05, 20 October 2024 (UTC)
I don't see any need for this at all. For example, we host tons of official photos of the president of the U.S. photographed in areas of the White House that are not open to the public. I see no need to tag them to that effect. Similarly, I've done plenty of photo shoots in buildings where I had to seek permission to go onto the property and/or into the building; most of the photos in Category:Lochkelden are examples of this. I see no reason these should be tagged. - Jmabel ! talk 13:08, 20 October 2024 (UTC)

Proposal for Image guidelines: Focus and DoF

(This was originally posted to Commons talk:Image guidelines and has been slightly reworded for clarity).

On the page Commons:Image guidelines, at the section "Focus and depth of field" I would like to propose a third bullet point be added below the two that are already there. So the section would read as follows:

  • Every important object on the picture should be sharp, considering the idea of the image.
  • The overall image should have clearly defined focus, for example, the main subject is in focus and the foreground and background are out of focus, or else, the whole scene is in focus.
  • Some allowances should be made for macro photography, which often involves a very shallow depth of field. While focus stacking can be used to overcome this for static subjects, it may not be practical for dynamic subjects like insects.

The example photograph in this section File:Butterfly Luc Viatour.JPG is described as having correct focus and depth of field. However, by today's standards, it would not meet QI criteria, as the left edge of the butterfly's wing is out of focus. This seems to go against the intent of the first bullet point, so it would be beneficial to make the guidelines more explicit. ReneeWrites (talk) 20:20, 17 October 2024 (UTC)

Agree. At a minumum. And "important" in the first bullet point strikes me as odd. Obviously, if I photograph a person in a group at F/1.8, they will be in hard focus and probably no one else will be. It doesn't mean they are less important, just that they are not particularly the subject of my photo. - Jmabel ! talk 17:05, 18 October 2024 (UTC)
In your example, the other people would not be "important" for that photo. For my understanding, this doesn't mean that they are unimportant people. Maybe re-word "Every important object" to "Every object important for the composition". Plozessor (talk) 18:16, 22 October 2024 (UTC)

File:Owl WTP.jpg

The image file, File:Owl WTP.jpg, must be uploaded onto either Wikimedia or Wikipedia, preferably Wikimedia, by someone who has an account. Oh, and in case you're wondering, it must be a picture of Owl from the Disney Winnie the Pooh franchise. There aren't any images of Owl from the Disney Winnie the Pooh franchise on Wikipedia, nor Wikimedia, for that matter. I need it for my draft article I'm working on Owl from "Winnie-the-Pooh". I need an image of Owl from the Disney Version of Winnie the Pooh. 2601:401:4300:3720:4012:96F7:7F93:BA7A 16:37, 22 October 2024 (UTC)

Oh dear. This could be problematic. This is Wikimedia Commons which only hosts freely licensed files. I am presuming that as Disney holds the copyright to the Owl character we can't host the photo here.
Category:The Many Adventures of Winnie the Pooh (film) is what we have so far and Commons:File requests is really the most appropriate place for your request if you are looking for a free file.
Some Wikipedia projects like English Wikipedia do host Non-free content, eg at the top of w:Gopher (Winnie the Pooh). But an article needs to exist, not just as a draft, before a fair use file can be uploaded there (as far as I know). I recommend you wait until your draft is made an article then request for the upload on English Wikipedia. Commander Keane (talk) 17:30, 22 October 2024 (UTC)

Limit page moves in "File talk"-namespace to users who can move files

This proposes to limit page moves in "File talk"-namespace to users who can move files (file movers and admins). For other users, there isn't really a reason to move pages in file talk namespace. Usually file movers move them when renaming files.

If accepted, a good way to implement this needs to be found (abuse filter or through user rights in Mediawiki).

This would have avoided confusing moves of file talk pages we had recently.
 ∞∞ Enhancing999 (talk) 21:35, 16 October 2024 (UTC)

 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:21, 17 October 2024 (UTC)
 Support. Easy solution to the problem.--Giftzwerg 88 (talk) 06:37, 17 October 2024 (UTC)
 Support - Jmabel ! talk 19:45, 17 October 2024 (UTC)
 Support - that makes sense --Msb (talk) 21:53, 26 October 2024 (UTC)

Style guide for templates

I want to propose that we create a style guide for templates. All regular templates must follow this guideline. User templates (when used in non user namespace) should follow this guideline.

Here is the draft for the rule set:

  • Templates must only use the predefined colors for the style codex with a fallback for legacy skins. Exceptions are possible if there are good reasons for.
  • Red and yellow background and border should only be used for templates they are usually only temporary on a page except for talk pages.
  • Text color should not be changed. Supplementary information can be in a more subtile gray.
  • Templates must not alter the default font-family. Font size should only be altered if the template contains a heading for the heading. Text decorations should only be used if really necessary.
  • Margins between box content and box border should never be more than 1.5 text height on top and bottom.

Are there any suggestions for changes of these rules or additional rules? GPSLeo (talk) 07:01, 26 October 2024 (UTC)

What does the following mean "Font size should only be altered if the template contains a heading for the heading." and how would it impact {{Wikidata Infobox}} that does alter the text size?
 ∞∞ Enhancing999 (talk) 09:37, 26 October 2024 (UTC)
The Wikidata Infobox is a very special case where I would make an exception. GPSLeo (talk) 10:43, 26 October 2024 (UTC)
Can you still explain how it would impact that infobox? There isn't really a point in drafting a "style guide" if no category follows it.
 ∞∞ Enhancing999 (talk) 10:48, 26 October 2024 (UTC)
It is only a guideline and not a strict binding policy. If we think one template that is not conform with the guideline is fine we do not have to change it. Except from the use of the predefined colors most templates already follow this guideline and the most widespread templates are also already adapted to use the predefined colors. This is just to make the de facto guideline and official written guideline. GPSLeo (talk) 11:15, 26 October 2024 (UTC)
I asked you about the font-size, not colors or the binding nature (which you forgot to include in the draft). If you can't explain how the "heading" thing is meant to work, I think we should remove it from the proposal. It will only create problems if we have to sort it out later and someone insists on some "must"-guideline that wasn't even understood when proposed.
 ∞∞ Enhancing999 (talk) 12:36, 26 October 2024 (UTC)
@GPSLeo: "must" is a bit strong (and a bit passive). What are the consequences for failing to do this? - Jmabel ! talk 11:00, 26 October 2024 (UTC)
I just wrote "must" as I think "should" would be a bit weak, but maybe adding a sentence that exceptions are possible would solve this. I would say the users have to accept that their templates are changed by others if the template does not follow the guideline. We should not sanction anyone for accidental or minor violation of the guideline. The only reason to punish a user for not following this would be if they do not accept the changes done to the template and start and edit war. GPSLeo (talk) 11:09, 26 October 2024 (UTC)
I want to go back to the idea that everybody can contribute with your own creativity without unnecessary restrictions. There is no real need to regulate the creativity of our contributors just to satisfy the special taste of one or some users that prefer a certain look or way of doing business. I think it is not helpful to have some kind of rule book hanging over your head when you want to find a way to improve or simplify the process of presentation of information. So we need to allow new creative styles and different ways of doing things. Then we as a community have a look at it and can see how it works, if it works and what the advantages and disadvantages are. Then we come up with possible incremental improvements or we can reject it as a result of the discussion. We should rely on our strength as a collective intelligence and let play out the group dynamics as far as possible. So, when you come up with rules there must be a necessity to do so. We do not want to end like some home owners associations where everything needs to be regulated, with rules how high the fence must be and what colour the mailbox and what you can plant in your garden and which kinds of signs are allowed. So we need to let users try out their ideas and aesthetics, their fonds and styles or whatever and let the community decide if we need to put limits or boundaries if it gets somehow disruptive or if we need some cut back or containement. We need to have different options and make our choices. Wikipedia and commons alike only exist, because we believe in incremental improvement instead of a preexisting solution to everything. So rules should be discussed and implemented based on the solution of a problem. So this answer is "bigger potatoes", but what was the question?--Giftzwerg 88 (talk) 11:42, 26 October 2024 (UTC)
The main reason why we should have some guidelines is the dark mode that is already available. When we offer a dark mode templates with a fixed white background should not exist as on them the text will not be readable anymore. And even if the text color defined in a way visible the large white box on the page will look disturbing. The other parts of the proposal are to write some unwritten rules down. We never had problems with users putting a large red box on ever of their uploads. But if this would happen we would not have a good basis to stop the user from doing this. The other argument is that end-users expect a consistent design over a hole website and will have problems to find what they are looking for when every page looks totally different. GPSLeo (talk) 16:27, 26 October 2024 (UTC)

Deleting empty categories

I recently asked whether there is a page about empty categories and since apparently there is no I created Commons:Empty categories. Please comment or edit if there's anything to add.

I'd like to propose that all empty categories older than several months (3, 6, or 12) are deleted. This would need some bot or script doing this large-scale as there are many thousands of them. Could this please be done?

Excluded would be:

  • Redirects
  • Disambiguation pages
  • Maintenance pages
  • Pages soon to be populated such as cats that are part of a natural series with a cat for every year or for campaigns set up before the campaign because the category would still be empty after 3-12 months

All of these pages could be excluded in the query. Moreover, even if a small number of empty categories are being deleted in accordance with SC2 despite being not unlikely to be populated soon then it's simple to just recreate them while these empty categories are a problem and the benefits of deleting them clearly outweigh that a handful of recreatable categories have been deleted which could have been tagged for speedy deletion anyway.

A main issue with empty categories is that they don't have a NOINDEX magic word and so could be indexed – and maybe frequently would be if WMC cat pages were indexed better in general like they should be. This is one of the main problems with empty categories. Other issues include that they make pages harder to oversee / clutter pages and that when linked to Wikidata items give the impression that there's media here about the subject but lead to just an empty page. They can also cause category cycles. I don't see any good reason to keep them which is probably also why it's a speedy deletion criteria.

Proposed steps:

  1. Identify any potential complications with implementing this other than the ones already in "Special types of empty categories" in the page linked (maybe some maintenance categories do not have {{Maintenance category}} and/or {{EmptyCatGood}} set which should soon put them into Category:Maintenance categories) and fixing these issues
  2. Adjust the Quarry query for empty categories below so it returns all empty categories that should be deleted
  3. Use the query output to then delete them in some way, maybe with a bot adding the speedy delete notes a week before deletion and then deleting all the still empty ones or deleting them directly with some mass-delete tool/script

How could each of these steps be done? Especially the third one seems to need some work (technical development).

Here's the Quarry query for all empty categories (without redirects and disambigs): Quarry:query/7200. It shows there are really many empty categories.
Prototyperspective (talk) 16:11, 26 October 2024 (UTC)

I would say that every category that has a Wikidata item linked should not be deleted if empty. This does only not apply when it is not simple to make photos to populate the category. This is the case for:
  • Past events
  • Events further in the future than 1 year
  • Dead people
  • Artworks still in copyright
  • Not photographable with regular equipment (e.g. most asteroids, planets)
All empty categories they are not linked to Wikidata for more than one week should be deleted. We have a huge problem with new users failing to add proper categories. Having empty categories linked to Wikidata could make this much more easy for new users. A category linked form Wikidata should not give we impression that there might be files about the item when the item has no photo linked. If there are photos in the category but no photo on the item that is a different problem that is easy to solve with tools already existing. GPSLeo (talk) 16:45, 26 October 2024 (UTC)
Aren't empty categories linked to Wikidata items even more problematic: they give users the impression that there's media on Commons when that isn't the case. If they come here and don't know the site well they'd be confused and see an empty page wondering why that Wikipedia linked to it. I think empty categories linked to Wikidata items are more problematic than empty categories not linked to from anywhere other than their parent categories. Btw, there are many cases where there's files in the WMC categories but none of them is suitable for being linked in the Image property of the Wikidata item which should contain only somewhat representative/useful files. Whether it should is not relevant to whether or not it does. Prototyperspective (talk) 16:51, 26 October 2024 (UTC)
Not really, there are lists at Wikipedia that help users upload photos directly to the correct category.
 ∞∞ Enhancing999 (talk) 16:54, 26 October 2024 (UTC)
These cases are excluded by all empty categories older than several months (3, 6, or 12) are deleted. Moreover, these tools (link?) could also set a redcategory and/or create the category automatically/request its creation after there is a file. I don't think empty categories are used for that anyway. Prototyperspective (talk) 16:56, 26 October 2024 (UTC)
I don't see how the creation date has anything to do with that. Not sure how doing maintenance on red categories instead is an advantage.
 ∞∞ Enhancing999 (talk) 17:16, 26 October 2024 (UTC)
If you argue (still without any substantiation) that these help users upload photos directly to the correct category then there would be files in them after 3, 6, or 12 months. Well then create the category at upload but I don't think this is an actual scenario, not even a niche rare one. Prototyperspective (talk) 17:36, 26 October 2024 (UTC)
But then we need a way to store the intended category name and the parent categories for this category on Wikidata. And we need an automated process that creates it and links it when added in the UploadWizard. GPSLeo (talk) 17:51, 26 October 2024 (UTC)
It seems to be already stored if an existing category is selected so it wouldn't really make a difference. In any case this varies or depends on the actual thing discussed so a link would be needed. I still think nothing of this sort actually exists. Prototyperspective (talk) 20:39, 26 October 2024 (UTC)
I think the main problem are malformed empty categories (we deleted hundreds of them). Once categories are linked to Wikidata, this is considerably less problematic. I think the current speedy deletion policy captures the situation fairly well.
 ∞∞ Enhancing999 (talk) 16:51, 26 October 2024 (UTC)
Why would it be less problematic? See my comment above: it leads users to a useless empty page by being linked from Wikipedia and possibly search engines. There is no use in having a Commons category that is empty linked to a Wikidata item. Prototyperspective (talk) 16:52, 26 October 2024 (UTC)
You could easily navigate to parent categories and find files there.
 ∞∞ Enhancing999 (talk) 17:17, 26 October 2024 (UTC)
Often times the files are for things that the person isn't looking for to begin with though. So how exactly is that helpful? --Adamant1 (talk) 17:36, 26 October 2024 (UTC)
Good point. Users on mobile still do not even see these however. Also I think for these cases something other could and should be done. For example, in Wikipedia pages there may be several images and one can open them and then navigate to their categories. Prototyperspective (talk) 17:37, 26 October 2024 (UTC)
We know we need to fix categories for mobile users, but that isn't really a reason to delete all categories before.
 ∞∞ Enhancing999 (talk) 17:39, 26 October 2024 (UTC)
In such cases it would be better to link to the parent category on WMC directly in the Commons category template. Prototyperspective (talk) 20:37, 26 October 2024 (UTC)
  •  Support I don't really get the argument for keeping empty categories just because there's a Wikidata item associated with them either. For one it makes it seem like we have media for subjects that we don't and secondly it puts the onus for it's do things in Commons or not on Wikidata users. Which wouldn't be that much of an issue, but there's absolutely zero standards what-so-ever on Wikidata's for what deserves to have an item or not. So essentially anything could have a category on Commons regardless if there is or ever will be media related to it on our end simply a random user of Wikidata decided to create an item for it. No one on here is served by hundreds of thousands of empty categories that will never be used to organize media and/or can't be deleted. If anything there should be more rules on when and under what circumstances it's OK to create categories, not less. --Adamant1 (talk) 17:36, 26 October 2024 (UTC)
    But where do you propose to store the information about the relevant parent categories if the category itself should not exist until it is used? GPSLeo (talk) 17:59, 26 October 2024 (UTC)
    Parent categories are not hard to find and it's not important to store parent cat info of cats that are empty anyway and would be deleted on sight by a user who thinks of speedy-delete-tagging it. There can be innovation around media requests (as in please create a category about x; suggested parent cats: yz) and this would be enabled or boosted by deleting empty cats. Prototyperspective (talk) 20:36, 26 October 2024 (UTC)
    I am admin on Commons and for me it is often complicated to find the correct parent category. In most cases I use Wikidata to enter the category tree near the place I am looking for. From my patrolling work and when talking to new users I know that they do not know how to handle the category system. If we have a Wikidata item about something we should use this data. This could of course all be done by some fancy software. But we do not have this at the moment and the WMF will definitely not help us getting such a tool. Or we just use empty categories to solve this problem. The long term goal is to replace categories by structured data anyway. GPSLeo (talk) 20:47, 26 October 2024 (UTC)
    If we have a Wikidata item about something we should use this data Sure, agree. After creating a category, contributors can check the wikidata item if it has relevant data. This could of course all be done by some fancy software. It's already done by the Wikidata Infobox and I supported a current proposal to make it auto-add more categories and there could be more cats that it auto-adds. we just use empty categories to solve this problem Empty categories don't solve any problem whatsoever. Their categories are often flawed anyway and they may never be populated ever or are empty because they are flawed to begin with and shouldn't be populated. Structured data is not used and not nearly as useful as categories. Where structured data exists, it's usually because categories were copied to structured data or because the uploader entered the same data twice once for categories and once for SD. Less often but still very often they contain flawed or overly broad data such as depicts "building" or depicts "human". And in nearly all cases it contains not even 3/4 of the metadata specified in categories. Prototyperspective (talk) 21:15, 26 October 2024 (UTC)
  • @GPSLeo: Maybe I'm just being dumb here but I can't image an instance where that would be a problem. Like if someone is looking for a category related to brown cars and it doesn't exist the obvious thing is to look for a category based on cars by color or just cars. Although I will caveat that by saying there some instances where categories take abrupt right turns sometimes but that's an issue with how people create categories more generally and doesn't really have anything to do with this IMO. So can you give an example of what your talking about? --Adamant1 (talk) 00:22, 27 October 2024 (UTC)
 Question what problem are you trying to solve? Category cycles aren't possible with empty categories.
 ∞∞ Enhancing999 (talk) 17:56, 26 October 2024 (UTC)
The main thing was that these pages are not no-indexed and the spiders may not distinguish between categories that are empty and those that aren't which could cause issues for the presence of WMC in search results overall. There are further things like empty categories filling backlog reports and HotCat autocompletes. Some of them may also fill category pages making things hard to see and such cases would be solved by this even when there's usually only a small number of empty cats in a cat if any.
I'd say it's not important to me at all and it may not be worth doing or not now despite that there's no good reason not to...but then please make empty categories noindexed. It's not a priority issue but reducing the noise and reducing the really large number of categories by a significant number seems like a good thing to do.
Good point about the category cycles, e.g. categories containing just an otherwise empty subcategory containing itself wouldn't be considered empty. Prototyperspective (talk) 20:30, 26 October 2024 (UTC)
You want to hide the missing content. But the information what is missing is the most important as we want to fill these gaps. GPSLeo (talk) 20:53, 26 October 2024 (UTC)
Exactly. And this is why we need a proper media request system. No, I don't want to hide that and empty categories are not the right way for that (including being entirely ineffective in regards to that). Prototyperspective (talk) 21:05, 26 October 2024 (UTC)
 Question how do you intend to make the thing about 3-12 months work? Consider the following scenario: Category:Night markets in Singapore was created in2009 and has 17 photos. Let's say a vandal removes the category from all of those photos. How does the bot know this is a recently emptied category rather than a 15-year-old category that has never been used? - Jmabel ! talk 18:40, 26 October 2024 (UTC)
Good point. It's because vandals don't know that and when such a trimming would occur and the very few cases where something like this happens the category can simply be recreated (in this case: 1. revert that user's diffs 2. notice the redcat 3. recreate it using the similar Category:Night markets in Cambodia). Prototyperspective (talk) 20:33, 26 October 2024 (UTC)
On rare occasions I created a category that I intended to fill but forgot to use when later uploading the photos. Sometimes empty categories are duplicates to other categories, then they should be turned into a redirect. I have never experienced a problem with an empty category whatsoever. On the other hand you can give pictures a category that does not exist and when you click the link you still see all the pictures in that category. I wonder how many of these exist and they are hard to detect, because you can not find them with the search tools or in the category tree. I consider that a problem--Giftzwerg 88 (talk) 20:44, 26 October 2024 (UTC)
Deleting empty categories would help there in making people add the actual category instead of the empty duplicate one. Empty categories are not a big problem. Many thousands of them exist. Nonexistent categories is a different separate subject. One can also create a query to see these but those containing more than x (14 I think it was last time I checked) number of files are in Special:WantedCategories. Prototyperspective (talk) 20:51, 26 October 2024 (UTC)
The duplicate category problem is solved by the requirement of linking them to Wikidata. Then there are only duplicates if there is a duplicate on Wikidata. GPSLeo (talk) 20:55, 26 October 2024 (UTC)
An estimated 90% of categories are not linked to wikidata. If the remainder, that is tens of thousands of categories, were linked to a Wikidata item, then the problem would simply exist on both sites rather than just on one which is not an improvement. Secondly this is unrelated or at most tangential to the subject/thread. Prototyperspective (talk) 21:08, 26 October 2024 (UTC)
What is the current policy about Wikdata items? Is it desirable to have an item for each commonscat? I am a fan of infobox wikidata and use them often but not for all categories. For example I would not use it for something like Category:Rivers of Landkreis Böblingen or Category:Automobiles at Motorworld Region Stuttgart but definitely would use it for each individual river or water body. A lot of these categories are just to divide the material by administrative boundaries or by years or other artificial criteria.--Giftzwerg 88 (talk) 00:06, 27 October 2024 (UTC)
Totally personal preferences here, but IMO there should be a Wikidata item for "main subjects" (however you want to define that). It would be super pointless and obtuse to have a Wikidata item for every single minor category and/or subject on here though. Especially when if your talking about intersectional categories involving multiple characteristics. Generally though, I'd say the more obscure and less likely to be stable a category is then there's less point in having a Wikidata item for it. There's zero point in having Wikidata items for categories that have a large chance of just being deleted. --Adamant1 (talk) 00:35, 27 October 2024 (UTC)
  • @GPSLeo: I run into instances all the time where a category is empty due to the media that was previously deleted as either COPYVIO or OOS. Plenty of them had Wikidata infobox to. Regardless, what would be your solution in an instance like that? In both cases there's essentially zero chance of there ever being media to put in the categories. So should we just keep inherently empty categories for subjects that are clearly COPYIO and/or out of scope simply because they are notable enough for a Wikidata item? --Adamant1 (talk) 00:29, 27 October 2024 (UTC)
    The first case was already in my list of exceptions where a category should be deleted. In the second case the Wikidata item is out of scope and therefore there will be no Infobox after the item is deleted. And I also would nominate the item for deletion and delete the category with its content in parallel. GPSLeo (talk) 05:41, 27 October 2024 (UTC)
Hm. Useful empty categories were removed as a speedy deletion reason a while ago; discussion at Commons talk:Criteria for speedy deletion/Archive_2#Speedy_deletion_of_**empty**_categories. There can be categories with substantial content in them (categorized in other places, or some researched text) that seems callous to just delete, if there is a reasonable chance that the categories will be re-populated again (maybe once the files once inside have their copyright expire, or other ones found -- undeletions happen too). There are likely many ship categories in that state, and I'm sure many other examples. I'm sure there are many examples of empty categories which should be deleted, but also many examples of ones which should be kept, and not sure automated deletion is a good idea. Maybe if there is minimal content in empty categories -- but then again, that older discussion lists several reasons to keep certain empty categories and not sure there is a way to really automate those distinctions. For duplicate categories, definitely prefer redirects to deletion, unless there was an outright mistake in the category name. For the most part, I have not seen big issues with empty categories. They are mildly annoying but deleting other people's work for the sake of a little cleanliness does not seem like the right approach. The argument that they are easy to recreate falls flat to me -- some of them have quite a bit of categorization or text on them. A report showing old, empty categories for more careful human review may make some sense. If the wiki software could be made to no-index them when there are no files and no visible text, I could see that. Carl Lindberg (talk) 01:20, 27 October 2024 (UTC)

Create a noratelimit user group

This group would have the noratelimit user right per COM:BN#Rollback rate limit increase for Alachuckthebuck.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:00, 30 October 2024 (UTC)

I have some concerns:
  1. who will be granted this right and when?
  2. who will be able to grant this right?
  3. if this is for a one-time case or a rare-issue, don't you think it is odd to have this group created when "bot" can be utilised?
As such I don't think this would be a good-to-go idea. Regards, Aafi (talk) 14:14, 30 October 2024 (UTC)
@Aafi: The group membership would be granted to applicants by Bureaucrats, or possibly by Admins if the community deems that advisable.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:26, 30 October 2024 (UTC)
and "when" - I mean what are the factors that would determine the need of such a user right? To override rate-limit means only to do things at a bulk rate which is otherwise impossible for a human editor. There is a visible collision between a bot's job & the noratelimit edit's being done by a human! Regards, Aafi (talk) 15:35, 30 October 2024 (UTC)
What are the cases for having no rate limit they do not require bot approval? In the given case I also think that massively correcting bad bot edits should also be marked as a bot edit. GPSLeo (talk) 14:14, 30 October 2024 (UTC)
+1 Krd 14:20, 30 October 2024 (UTC)
@Krd: Does your "+1" apply to my proposal or to GPSLeo's reply?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:28, 30 October 2024 (UTC)
@GPSLeo: Would the bot need approval for the use case presented by Chuck? If so, he should file a bot request. If not, I can use my bot for this use case.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:23, 30 October 2024 (UTC)
Yes as doing many thousand automated edits is the definition of a bot. If it is about fixing around 3000 files waiting for 30 minutes would also be fine. GPSLeo (talk) 14:29, 30 October 2024 (UTC)
I would argue that the best way to handle this would be having something similar to the Flooder right, but for non-admins.
The userright (Flooder) has only one permission: the addition and removal of the (Flooder Flag) userright. The permissions of the Flag are edits marked as bot, and the removal of rate limits. The flag is removed automatically after 24 hrs. Usage of the right is only allowed after a bot request (or similar) with approval for the exact task the flag is used for. Running a bot along the lines of what took me 5 hrs (without ratelimits) would be impractical, and also take even longer than cleanup already took. All the Best -- Chuck Talk 15:54, 30 October 2024 (UTC)
Flooder seems doable. Regards, Aafi (talk) 16:16, 30 October 2024 (UTC)
If we have a bot request, we can assign the bot flag. This discussion is about a non-problem. Krd 16:18, 30 October 2024 (UTC)
@Krd, doing 35k rollbacks took me about 5 hrs. programming a bot, getting approval, debugging, then doing the run, and likely handling cleanup, is a 3-5 week project, assuming no problems with programing or regex. And once the run starts, it would still take 5 days at 6 epm. Or we create the Flooder right and do it in 5 hours. All the Best -- Chuck Talk 16:24, 30 October 2024 (UTC)
Which we did, didn‘t we? So what exactly is needed in addition? Krd 16:42, 30 October 2024 (UTC)
You wanted mass fixes like this to be bot edits, so I proposed a way to have the benefits of it being done by a user (being done in 5 hrs), and the beniefits of the bot flag (easy filtering, not breaking RTRC). My proposal would allow me to have the flag for the reverts, and remove it when done. Everything's under one account, and done in a fraction of the time a bot would take. All the Best -- Chuck Talk 16:58, 30 October 2024 (UTC)
I would have liked to avoid bringing up the point, but a question IMHO way more relevant than the details how it actually was rectified, is why a bot operator can do 35k wrong edits and is not able to fix them by his own bot, and if is this is a good situation. Will this happen again? If not, why can't we just stop and go back to business? Krd 17:26, 30 October 2024 (UTC)
This whole saga is over using the word "the" in the category titles of a Danish GLAM. The were uploaded without "the", then WLKBot added "the" to all categories, and created needed categories, I rolled back to no per the AN thread, and when I finished, a not was posted to my talk, informing me that consensus has changed, and I was requested to undo my edits. I declined, as cat-a-lot will work for this purpose, and if not, AWB can handle it. @Kim Bach, You have some explaining to do. All the Best -- Chuck Talk 21:07, 30 October 2024 (UTC)
Indeed, a user had opposed the naming convention, "in the" instead of "in" that is commonplace for a number of other GLAMS. I decided, completely wrong, to run a mass edit to fix this problem, when I discovered that this was in error, I requested the rollback, which I think was the right think to do.
I realise that this has wasted a lot of time, this is indeed a fiasco, and 100% my mistake. Kim Bach (talk) 11:22, 1 November 2024 (UTC)
If we talk about such a group, I think flooder is a doable job. On Wikidata, Flooders have the "bot" permission alongside the ability to remove themselves from the group. Regards, Aafi (talk) 16:24, 30 October 2024 (UTC)
Automated tools would need to follow mw:API:Etiquette. For example mass editing bots will need to follow if there is load on the server and slow down if there is. For example when en:User:Writ Keeper/Scripts/massRollback was used to revert the 35k edits in yesterday was doing it in unlimited rate, which was 50-100 edits per second, without slowing down when server could not keep up. This is way too high and could cause similar problems than what for example Cat-a-lot did before it was changed. --Zache (talk) 18:56, 30 October 2024 (UTC)
The script was meant to Mass rollback edits made by vandalism only accounts (50ish edits) and be used once a day. I used it to roll back 35k edits in batches of 1500(give or take 300 edits due to page creations) . I ran a batch every 60-90 seconds. I will modify my local copy of the script to slow down to a more reasonable speed. I also don't see this method of rollback being used at this scale ever again, as a bot to do this kind of cleanup is needed. That doesn't change the need for this right, and the legitmiate points raised by @Krd and @Aafi. All the Best -- Chuck Talk 20:45, 30 October 2024 (UTC)
Most of usecases are such as it feels to me that it would be used workaround ratelimits in a way that it should not be done. Most clearest examples are tasks would be using Help:VisualFileChange.js to editing large amounts of categories in highspeed. Another note is that admins and bots have noratelimit already and it is actually little bit hard to see what would be the use cases where it would be used (and if the idea is to allow rollbacks to be done in higher speed why not just bump up the rollback limits) --Zache (talk) 05:59, 31 October 2024 (UTC)
If rollbacks are being done in any quantity near the rollback limit (100 per minute), there should already be consensus for the action. If you need a higher rollback limit, then there should be another request and comment period, that's how we avoid another situation like this. I'm working on a solution to the problem, should be ready to go in the next few days, and is adaptable to do future fixes, and slowly. Sorry for wasting everyone's time with this mess. All the Best -- Chuck Talk 16:33, 31 October 2024 (UTC)
  •  Oppose Per Zache, Aafi, and others. This mostly just seems like a workaround to rate limits and from what I can tell most or all the people who benefit from it already have other avenues to get around the limit if they really want to anyway. --Adamant1 (talk) 20:04, 31 October 2024 (UTC)
 Oppose per above arguments Bastique ☎ let's talk! 20:22, 31 October 2024 (UTC)
 Comment: I bit the bullet, and with some help from @Schlurcher, Have a bot request at com:bot requests#chuckbot. All the Best -- Chuck Talk 06:16, 1 November 2024 (UTC)
  •  Oppose a separate group, but  Support deprecating account creator in favor of this.
ACC is already a back door version of this – only two ACCs mentioned account creation when asking for/being granted it (emphases mine).
  • Alachuckthebuck – I'm working on cleaning up User:WLKBot's contribs using massrollback, but am running into the (normally gracious) 100 rollbacks per minute limit. Is there a way to remove this limit on my account for the next 3 days or so?
  • Alexis Jazz – I need the account creator (noratelimit) right. I simply can't do my work anymore due to Phabricator: Ratelimit on Commons is way too aggressive/broken.
  • D. Benjamin Miller – Dear bureaucrats: I am a filemover and would like to be given the status of account creator; I find that when working through rename queues I often run into the ratelimit and would like to get around this restriction, please.
  • Effeietsanders (granted by a steward) – for bypassing email rate limits and account creation related to WLM
  • QueerEcoFeminist – I frequently move pages and I have got stumbled upon ratelimit several times. (Sorry I don't know if there is any log to check it!) And I am also involved in real life wiki activities like trainings around wikimedia projects including commons. So account creator right would be great help to me.
  • Sandro Halank – noratelimit per request (don't know where said request was, don't see anything in BN archives)
  • Xaronim – That can be done as well but might need a flag that has a higher rate limit, tried 120 edits and was stuck for a good 15 minutes. (alternative account of Minorax, initially planned to be a bot but became a semi automatic account)
Queen of Hearts (talk) 08:36, 1 November 2024 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2024/10&oldid=964535791"