I notice in this edit, that when you have duplicate category, if you use Cat-a-lot then both categories are renamed instead of delete duplicate category. --Smooth_O (talk) 12:49, 5 August 2012 (UTC)[reply]
Just noticed this still happens; see the history of File:Bluebells - panoramio (3).jpg for example. For some reason a bot added the disambiguation cat Newark twice. When I moved the file with Cat-a-lot and then copied it to two other cats from the new location (all without actually seeing the wikitext, of course), all three lines got duplicated.—Odysseus1479 (talk) 20:47, 17 February 2018 (UTC)[reply]
Cat-a-lot is great, but it would be greater if I could take the results of a query from Cat Scan for example, trim them down as necessary for my purposes, and use the flat file list as input to Cat-a-lot. Is it conceivable that you could add such a feature? In this case, the page that Cat-a-lot was running "on" would not be relevant; instead of selecting files on that page with a mouse, I would select "manual file list" within Cat-a-lot, and paste in my file list, in the format
Category:Charles Backofen
Category:Charles Codman
Category:Charles Osgood
Category:Edward Troye
Category:Erastus Salisbury Field
Category:Fitz Hugh Lane
Category:Francis William Edmonds
Category:Frederick R. Spencer
and then select the destination category with the current interface options. In the above example, I want to add "c:19th-century painters from the United States" without having to select each one from "c:Painters from the United States" (imagine that the list has 100 entries...). More specifically, I want to move them from the old category, which leads to a variation of this suggestion. Another way of looking at this is that I want to paste in a list of files/categories that are programatically selected from the current category page, instead of the user clicking on each one. Short version: I am suggesting one or both of the following features: "Paste a list of files/categories to be selected programatically from the current page" allowing for adding OR moving; and/or "Paste a list of files/categories to be added to any category" (so the page I'm currently on does not matter to Cat-a-lot). If I had to pick one, I would pick the programmatic selection from the current category, as it allows for moving. I just gave an example but I believe this feature has broad applicability. Thanks for taking the time to read this message. Boo-Boo Baroo (talk) 05:46, 10 December 2012 (UTC)[reply]
That might be a useful cat-a-lot improvement, though as a current work around, if you have a list of files, you can paste them as a list of thumbnails on a sandbox page and use Help:VisualFileChange.js to make almost any change you are likely to want, including changing categories. Thanks --Fæ (talk) 06:29, 10 December 2012 (UTC)[reply]
Thank you both for your replies. Rillke, I didn't see your reply there (about two weeks later) and thought my question was stale. Thanks for the info--I plan to try VisualFileChange for files--but there doesn't seem to be any solution for altering categories themselves (as you've noted). The main use I envision is dispersing categories that contain hundreds/thousands of other categories into more usable subsets (in the case of categories for people, by century, for example). Boo-Boo Baroo (talk) 19:24, 10 December 2012 (UTC)[reply]
Hi, we use this great tool in fa.wiki according to Hebrew version, the only problem is when the category exists in /doc subpage it can not remove or edit or move that template's category! for example moving fa:رده:Language icon templates members. I tried to make a hack for it but doesn't work! would you please tell me where should i change? (fa:مدیاویکی:Gadget-Cat-a-lot.js) yours, Yamaha5 (talk) 10:37, 16 May 2013 (UTC)[reply]
Is there any hope of seeing an upgrade soon that allows removing ALL categories from file(s) except a selected category? Maybe adding a small checkbox in the bottom right corner, that if checked, will do that. This would be extremely helpful in sorting large number of files that are excessively over-categorized but have their own specific category. --P199 (talk) 23:42, 11 October 2013 (UTC)[reply]
Tried it and it is very cumbersome. Not the way to go. I strongly suggest to increase the functionality of Cat-a-lot. -- P 1 9 9✉18:21, 17 October 2013 (UTC)[reply]
I don't think that is a good idea. When using cat-a-lot in a category you see the files in that category, so you can see if they fit in the category or if they should be moved or copied to other categories. But you don't see which other categories the files are in, so you can't know if all those categories are wrong or not. /Ö16:13, 18 October 2013 (UTC)[reply]
Often enough, this has to be done to all files in a certain category, then you know it, otherwise you could look.
In my opinion, it would be more (very!) helpful to be able to remove all files in the current category from a different category. For example, removing all files in the current category from the category one level higher is something that has to be done all the time (because people over-categorize that way). Also, in these cases, no file should be in the current and the superordinate category, so selection is easy and not a lot can be done wrong. — Julian H.✈ (talk/files)16:33, 18 October 2013 (UTC)[reply]
I was thinking it would be more useful for search results. For example, I often categorise images of buildings, which might well be best placed in a category for that building and no other category (except hidden categories), but are often placed in categories of the city, the county, buildings in the city, and various other higher-level categories. I also agree with Julian H.'s suggested addition. HJ Mitchell | Penny for your thoughts? 16:35, 18 October 2013 (UTC)[reply]
We do need better tools for removing things from parent categories, and it would be great if catalot did that. But I agree that we would have a problem if we automatically removed all other categories without looking at the categories and images involved. For example, if I create a category for the stained glass windows in a church and make that a subcategory of both the church and stained glass windows in that county, then when I move images from the church to the stained glass windows in that church it would save a bit of work if they also came out of the other parent category stained glass windows in that county. But if one or two of them are in a category works by Veronica Whall then it would be wrong to remove that category. To some that would look like vandalism. WereSpielChequers (talk) 11:48, 20 October 2013 (UTC)[reply]
Of course, like all other tools, such a feature should be used carefully by trusted users. But the potential for mistakes already exists for Cat-a-lot in its current state, so this is not a reason not to implement it. In fact, we need more powerful tools to keep up with the flood of images being uploaded... --P 1 9 9✉00:08, 21 October 2013 (UTC)[reply]
As you designed it can't be used carefully. If you don't make it automatic, perhaps listing the categories that would be removed then that could work. But automatically removing categories would mean undoing other people's categorisation work and slowing down the process of categorisation. We need better categorisation tools, automatically removing categories even if they are valid and useful would not be a better tool. Some of its edits would look like vandalism. WereSpielChequers (talk) 21:08, 23 October 2013 (UTC)[reply]
We're open to suggestions. I offered one, thinking it might be the way to go, but if you don't think so, maybe you can suggest something else then... --P 1 9 9✉22:51, 23 October 2013 (UTC)[reply]
OK, here are a few:
Currently we can only search by keywords. Please could we search by geocode and bring up fifty thumbnails closest to the geocode you specify and then just click on the ones you want to put them in a particular category using catalot. This would be even more useful if it included the option to exclude ones in the same category.
Sometimes I'm splitting a village category into two or three villages of the same name in different counties. This is a slow process that requires lots of individual map searches. It would be much better if I could in a slightly similar way to above, have a tool that showed all the items in a category as points on a map, and then be able to draw a line on the map and send all on one side off to foo, Lincolnshire and the rest to Foo, Suffolk. This would also be incredibly useful in processing the backlog of geograph images as we have many geocodes that contain parts of two villages
It would be good to be able to see a list of all the categories that the images in a category are in, and then be able to click individual categories and mark them remove or move to parent. So I do a lot of English church categories. If I move twenty images into a category "St Foo's church, Boston, Lincolnshire" it would be good if I could then see a list such as, Images in this category are in the following categories:
4 in Gothic churches in Lincolnshire [] move to parent, [] remove
6 in Boston, Lincolnshire [] move to parent, [] remove
1 Pipistrelle bats in England [] move to parent, [] remove
2 in Anglican churches in Lincolnshire [] move to parent, [] remove
1 in stained glass windows in Lincolnshire [] move to parent, [] remove
1 in brick churches in Lincolnshire [] move to parent, [] remove
13 in Grade I listed churches in Lincolnshire [] move to parent, [] remove
14 in Churches in Boston, Lincolnshire [] move to parent, [] remove
I could then click the boxes as follows and save an awful lot of work, but without losing the work that others have done, including identifying that one of those images has a really nice photo of a bat and another of a stained glass window.
4 in Gothic churches in Lincolnshire [x] move to parent, [] remove
6 in Boston, Lincolnshire [] move to parent, [x] remove
1 Pipistrelle bats in England [] move to parent, [] remove
2 in Anglican churches in Lincolnshire [x] move to parent, [] remove
1 in stained glass windows in Lincolnshire [] move to parent, [] remove
1 in brick churches in Lincolnshire [x] move to parent, [] remove
13 in Grade I listed churches in Lincolnshire [x] move to parent, [] remove
14 in Churches in Boston, Lincolnshire [x] move to parent, [] remove
Currently to do the above example in hotcat you need to look at twenty images and a category, hit remove 40 times, and type out large parts of five categories to add them to the parent category. WereSpielChequers (talk) 08:33, 24 October 2013 (UTC)[reply]
Since the code is currently getting reworked, I wanted to get some feedback on some thoughts I'd been having. One of the biggest user-level time-wasting maintenance problems on Commons is that there's no simple way to move images that are in Category A and Category B into Category C. Right now, in order to do this, you have to move the files twice from each of the two parent categories. That's annoying, and leads to errors where an image is missed in one category.
The easy way to do it would be to have the ability to choose images in Category A with Cat-a-lot, and be able to either a) then move or copy from Category B into Category C
or b) (preferrably) move in one shot from A and B into C.
Keep in mind that currently FastCCI has no interface to limit the intersection to a depth of zero (which is what you seem to want), instead it scans deep into subcategories and may return a lot more results than you want. --Dschwen (talk) 07:33, 8 August 2014 (UTC)[reply]
The problem, I think, is that cat-a-lot can only add categories when working with search results, when often the objective is to move them out of one or more of the other categories. (Apologies to Pi.1415926535 if this isn't what you were trying to get at.) --jnkyrdsprkl (talk) 20:34, 9 August 2014 (UTC)[reply]
I am trying to add the category Category:Taken with Sony DSC-WX70 to some 10,000 files, but Cat-a-lot hangs after categorizing a few thousand files. I tried in Chrome first, it stopped at 1,900 count. Then I tried in Firefox and it stopped at 3,400. Then I tried in Chromium and it hanged at 8,600. Maybe this happens because of the browser limitations though? -- Fructibus (talk) 22:02, 20 November 2017 (UTC)[reply]
@Fructibus: Hm, maybe, but there is also a speed cap for edits for normal users (which you should have exceeded by far). High probably your gallery exceeds the normal view limit too (it does not display for me). -- User: Perhelion23:36, 20 November 2017 (UTC)[reply]
@Perhelion: Ohh, I didn't know about the speed cap. How much is it? Can you limit Cat-a-lot speed to stay below that? Well, I must admit it's quite easy for me to ask for all kind of new features.. :D -- Fructibus (talk) 23:51, 20 November 2017 (UTC)[reply]
@Perhelion: I think such a speed limit might be already documented, shall I ask at the village pump about it?
Meanwhile I would like to ask for another feature, related to this: to add a button to select all the file links. When the user selects the files in a search result or in a category or in a gallery, they actually select file links. Therefore I think it's not a significant difference to select links too. For example I would like to select all the image links in this page: User:Fructibus/C. Then the users won't need to create a gallery - when a gallery contains thousands of images, the browser consumes a lot of memory and processor power. -- Fructibus (talk) 08:23, 21 November 2017 (UTC)[reply]
@Perhelion: There's an OOM condition here. getContent() is called with an immediate for loop in getTargetCat(), and editCategories() is only an event handler of getContent(). This causes the doAPICall()s from getContent() be effectively executed before every single doAPICall()s from editCategories(). Since browser usually has a limit of per-domain concurrent requests, no edit can be made until all the wikitext of thousands of pages are loaded, effectively breaking garbage collection. I wonder if there is a workaround. --Zhuyifei1999 (talk) 08:39, 26 November 2017 (UTC)[reply]
Currently, Cat-a-lot will preserve the previous sortkey if a page is copied from one category to another. Would it be possible to toggle this behaviour so you could use the copy function without adding the "old" sortkey? This would be useful whereever the "Defaultsort" entry is preferred over any local sortkeys. De728631 (talk) 20:48, 1 May 2019 (UTC)[reply]
Ignore all the ones in Category:Wikidata infobox maintenance
I suggest to the developers that all subcats of Category:Wikidata infobox maintenance be ignored by cat-a-lot, because they are automatically added by {{Wikidata infobox}}. They are not meant to be added manually. They are also taking up too much space in the cat-a-lot menu because almost every cat using the infobox has three or more Uses of Wikidata Infobox blah blah blah.--Roy17 (talk) 17:34, 17 June 2019 (UTC)[reply]
Hello 迴廊彼端, that would be far too much for CaL, because this requires an extra level of logic, what this picture is to be concrete. Simple removal does not seem to be an option. -- User: Perhelion07:29, 14 August 2019 (UTC)[reply]
Is it possible to make Cat-a-lot visible only in category pages? It feels quite annoying and distracting to see them in mainspace articles. --Kailash29792(talk)05:31, 1 May 2020 (UTC)[reply]
Kailash29792 this can be achieved with JavaScript. Here are instructions:
@Kailash29792, you got one too many 14s. In window.catALotPrefs = 14 , remove the 14. It should be just window.catALotPrefs = { editpages: true, subcatcount: 100 };. Hope this helps. —andrybak (talk) 18:22, 22 June 2024 (UTC)[reply]
@Kailash29792, you're missing a closing curly brace }. Open the editor on page User:Kailash29792/common.js. You should see a code editor (as on the screenshot in mw:Extension:CodeEditor). There you can hover the mouse over the error marker (a red square with a white cross inside) on line 4. It will tell Unmatched '{'. To fix the error, add the matching closing curly brace } to the if, at the bottom, as line 11.
When trying to print ANY content or category page in Commons where this gadget may be used and is visible, if we try to print, the "Cat-a-lot" box appears on EVERY printed page, over the actual content we want to print (it appears partly at top of the printed page with the shadow and bottom border of the box, and the rest at bottom, within the printable margins of the page; there's no way to hide this unwanted box).
Please add the class "noprint" to the main container of the Cat-a-loc" box, that should never be printed, even if it's visible during navigation. Or use CSS "@media print{ /*selector of the box*/ {display:none}}".
The tool shows a yellow box at the bottom of the page with the label "Cat-a-lot" in it. This label should become translatable. This is particularly useful for languages that do not use Latin alphabet (e.g. Persian, Cantonese, Hindi, etc.) Huji (talk) 18:49, 11 May 2020 (UTC)[reply]
I wonder if it possible to install cat-a-lot to other non-Wikimedia wikis. The instructions only said If Cat-a-lot is not present as gadget in your local Wikimedia project (like Wikipedia). pandakekok913:06, 24 May 2020 (UTC)[reply]
so we have tools to add categories to pages (e.g. hotcat), and cat-a-lot, which manipulate pages via the category page. so i can select an article or file from the category page, and without leaving the category, remove this article. what i'm missing is the reverse action: add page to the category, regardless of how (or even if) this file or article is categorized now. should be pretty simple - pop a new input line with autocompletion, similar to the "category" input line, except it should be for any page, not just categories, and click.
bonus points for textarea, where i could paste a multi-line list of pages, but for me, at least, this is secondary. the ability to "pull" a page into a category from the category page itself would be very useful in many cases. peace - קיפודנחש (talk) 19:45, 3 July 2020 (UTC)[reply]
Oppose 1. This would be a separate tool and not cat-a-lot so I think this discussion should be closed here and such a tool be requested elsewhere 2. I think one should only be able to add a file or gallery or category to a category from the respective page or the search results because there one sees some info on the page and otherwise people would often add unfitting pages, e.g. because they confused them or because the only have the filetitle info etc. Prototyperspective (talk) 09:04, 8 October 2024 (UTC)[reply]
On mobile devices the screens are often curved, causing part of the Cat-a-lot link to be invisible, so it only reads "Cat-a" and is difficult to click on since the very corner of the screen is not as responsive or easy to touch. The font size and size for the floating text to start the tool are also too small.
Suggestions:
Please add it to Page tools menu, rather than having to scroll to the bottom turn back up to run it
Move floating text slightly higher up, and add a border at least 2em in size
Increase the text size for both the floating text and the X to close the tool
Change the close X to be "X (close)" or add an icon so it's much larger to select
Improve the instructions by including a screenshot showing where to find the tool
I've noticed that if some of white characters is present in the code of the changed category (caused mostly by copying, e.g. left-to-right mark (): [[Category:ABC]] – see the code with CodeMirror), Cat-a-lot won't move the file to other category as the category cannot be found. The copying is not affected, though. — Draceanetalkcontrib.20:42, 19 October 2020 (UTC)[reply]
so i tried to decipher from documentation and from code, and couldn't figure it out.
it seems that cat-a-lot edits are tagged on commons, but not when loading the gadget from other projects (using mw.loader.load() ), which we do on hewiki.
is there a way to tell cat-a-lot to add an edit tag on other wikis? for reference, here is the hewiki cat-a-lot gadget source:
if(mw.config.get('wgNamespaceNumber')==14){window.catALotPrefs={editpages:true,subcatcount:500};mw.loader.using(['jquery.ui','mediawiki.util']).done(function(){mw.util.addCSS("#cat_a_lot { left: inherit !important; }");// for some reason, cat-a-lot from commons has a quirk with RLT, and this fixes itmw.util.addCSS("#cat_a_lot_settings { display:none !important;}");// preferences depend on some other gadgets,not available on hewiki, so hide linkettemw.loader.load('//commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-Cat-a-lot.js&action=raw&ctype=text/javascript');mw.loader.load('//commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-Cat-a-lot.css&action=raw&ctype=text/css','text/css');});}
In code, the tag is disabled for anything other than Commons:
// TODO: better extern project support for possible change-tag? (needs currently change after init)if(project==='commonswiki'){mw.messages.set({'cat-a-lot-using-summary':''});}else{// Resetthis.changeTag='';this.settings.redir_category='';}
So code changes would be needed, if other projects are to have their own version of the edit tag.
Also wondered why it doesn't work on the modern search and just the old special search with small thumbnails and a vertical display. Could somebody add MediaSearch support? Prototyperspective (talk) 10:28, 27 May 2024 (UTC)[reply]
This doesn't quite behave properly when categorising redirects (it edit a the redirect target). Also, I'm not sure how the preferences work (nothing happens when clicking on the button), but it says in #cat-a-lot edit tagspreferences depend on some other gadgets,not available on hewiki, so hide linkette. Presumably this is the same, though still not sure how to change it? (Please ping me, or I won't see any replies.) Qwerfjkl (talk) 21:16, 30 August 2021 (UTC)[reply]
I noticed this function that returns selected files:
mw.libs.catALot.getMarkedLabels()
But it has a strange return type! Try it in your console. An user expects an iterable array but it's not. An user also expects each element as a clean self-describing object but they are not.
How to fix that? Let's create another function for backward-compatibility. For example:
mw.libs.catALot.getMarkedLabelsArray()
This new proposal should return a clean array, with simple objects. So it's more stable and can be used from other gadgets as well!
Here the example return type:
[
{
fullPageName: "Complete title of the page with namespace",
selectedEl: "jQuery selector of the selected box",
},
...
]
Tested by moving some files in a category, and then picking more files and moving to another category (also without reloading the page) and it works --Valerio Bozzolan (talk) 09:04, 7 January 2022 (UTC)[reply]
Instead of a permalink, you can also prepare a link to Special:ComparePages, which would highlight the proposed changes, making it easier to apply them, regardless of intervening changes to the live version of the gadget. —andrybak (talk) 00:03, 15 June 2024 (UTC)[reply]
I’m not convinced this addition is worth it, to be honest. To convert the array-like object into an array you could just use Array.from( mw.libs.catALot.getMarkedLabels() ) (or even [ ...mw.libs.catALot.getMarkedLabels() ]? not sure about the browser compatibility of that); and I’m not sure how helpful the object names are – in particular, given that the selected element is a jQuery object, not a native DOM element, I’d really expect it to have a $ in the name. Lucas Werkmeister (talk) 20:14, 19 June 2024 (UTC)[reply]
I've disabled the edit request for now, because the proposed code isn't actual anymore + there isn't a consensus for this change. —andrybak (talk) 23:58, 24 June 2024 (UTC)[reply]
On enwiki (at least), I think the gadget doesn't recognise pages not in the mainspace e.g. User: - it just says "No files selected" when you try to perform an action. Qwerfjkl (talk) 18:40, 19 December 2021 (UTC)[reply]
Since a few days (since Monday?) Cat-a-lot isn't working on smartphones with Chrome browser. The reason is the user comment field displayed. Searching for another category the virtual keyboard does not display the return key. Instead of the return key tab or next key is displayed - and the search for the category name in the search field doesn't work. The cursor switches to the user comment (pressing "next" on the virtual keyboard). Here the return key is displayed on the virtual keyboard, but it has no function. As workaround I've added mw.util.addCSS("#cat_a_lot_comment { display:none !important;}"); to my common.js. I've the difficult to explain problem only on smartphone browsers. --XRay💬04:37, 17 May 2022 (UTC)[reply]
If you are not able to reproduce it, I can make Screenshots and send it. But I won't upload Screenshots (seen by public) here. --XRay💬08:00, 17 May 2022 (UTC)[reply]
I too can't use it any more on Android. Can't select a category that I've typed in. Android WebView 101 on Android 11 to be precise.--Vera(talk)18:43, 25 May 2022 (UTC)[reply]
I'm now getting this error:
Uncaught TypeError: $searchInput.autocomplete is not a function from https://commons.wikimedia.org/w/load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Coojs-ui.styles.icons-editing-advanced&skin=vector&version=ve7ok at line 52:838 TypeError: $searchInput.autocomplete is not a function at initAutocomplete (https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=MediaWiki:Gadget-Cat-a-lot.js&action=raw&ctype=text/javascript:254:17) at fire (https://commons.wikimedia.org/w/load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Coojs-ui.styles.icons-editing-advanced&skin=vector&version=ve7ok:46:934) at Object.fireWith [as resolveWith] (https://commons.wikimedia.org/w/load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Coojs-ui.styles.icons-editing-advanced&skin=vector&version=ve7ok:48:135) at deferred.<computed> [as resolve] (https://commons.wikimedia.org/w/load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Coojs-ui.styles.icons-editing-advanced&skin=vector&version=ve7ok:51:632) at <anonymous>:769:951 at Object.enqueue (https://commons.wikimedia.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:10:831) at mw.loader.using (<anonymous>:769:910) at HTMLAnchorElement.<anonymous> (https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=MediaWiki:Gadget-Cat-a-lot.js&action=raw&ctype=text/javascript:328:15) at HTMLAnchorElement.dispatch (https://commons.wikimedia.org/w/load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Coojs-ui.styles.icons-editing-advanced&skin=vector&version=ve7ok:70:260) at elemData.handle (https://commons.wikimedia.org/w/load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Coojs-ui.styles.icons-editing-advanced&skin=vector&versionVera(talk)19:46, 11 September 2022 (UTC)[reply]
Hello, I'm from ckbwiki. It's a RTL language. I just wanted to say that the Cat-a-lot gadget covers "Add links" link for non-linked pages. I think it should be fixed to the left. Thanks! Aram (talk) 15:46, 30 July 2022 (UTC)[reply]
MediaWiki “flips” the CSS rules automatically when it detects that the user interface language is different from the site language. This works well on Commons; on ckbwiki, however, MediaWiki expects the CSS rules to be aligned for right-to-left languages. This also means that left-to-right languages like English get rules that are aligned for right-to-left languages, so you can just take the CSS for English (which is flipped) and copy it to the local stylesheet. —Tacsipacsi (talk) 13:09, 31 July 2022 (UTC)[reply]
@Tacsipacsi: Thanks for the reply! I have another question. Why the preferences link are not available on Wikipedia project? I can see it just on Commons. Additionally, I think the source of L-20 in the CSS page is broken. Thanks! Aram (talk) 13:22, 1 August 2022 (UTC)[reply]
With cat-a-lot, if I have an on-screen keyboard on android I can't OK my input when I hit enter. Instead the cursor switches to the "custom edit comment" field. This makes this gadget unusuable. Vera(talk)19:31, 23 December 2022 (UTC)[reply]
I looked into this further. It seems that my on-screen keyboard tries to be helpful and replace the "enter" key with a "next field" key if the form has multiple input fields. I've for now added the code of cat-a-lot to a user page and made the comment field hidden. This fixes it for me for now. I found this StackOverflow comment that says the "next input field" key produces key event nr. 229. It wasn't as simple as adding that as an OR to the Enter key's 13. The StackOverflow comment also says it produces an "Unidentified" key event. Adding another event listener that has "Unidentified" as its event and key 229 didn't work for me. This is probably too obscure a bug to fix. Another fix would be to have an actual button that triggers the same event as hitting enter now does.
Hi, could you give me ELI5, step-by-step instructions on how to implement your work around for this issue? I also struggle with it, but I think it used to work properly until 1-2 months or so ago, so that's a rather new bug to me. Nakonana (talk) 15:33, 2 March 2024 (UTC)[reply]
If it is the bottom category being changed, any lines of spacing below the category will be removed which causes an issue when it comes to stub tags. The MOS requires two lines of spacing between the categories and stub tag. Example. Not sure if anything can be done about this? Thanks! Jevansen (talk) Jevansen (talk) 02:58, 6 June 2023 (UTC)[reply]
i dont know. it's weird. here're the lists of cats on each file right now.
Extended content
[[:File:An der Hohen Straße westlich von Kottenbrunn 4.jpg]]
CC-BY-SA-4.0
Files with coordinates missing SDC location of creation (50° N, 10°E)
Images from Wiki Loves Earth 2023
Images from Wiki Loves Earth 2023 in Germany
Images from Wiki Loves Earth 2023, DE landscape
Images from Wiki Loves Earth missing SDC depicts
Images from Wiki Loves Earth missing SDC location of creation
Images from Wiki Loves Earth missing SDC participant in
Landschaftsschutzgebiet innerhalb des Naturparks Hassberge (ehemals Schutzzone)
Pages with maps
Photos of protected areas by Stephan van Helden
Self-published work
Uploaded via Campaign:wle-de
[[:File:Aufgang zum Streifberg bei Ostheim.jpg]]
CC-BY-SA-4.0
Files with coordinates missing SDC location of creation (50° N, 10°E)
Germany photographs taken on 2017-03-26
Images from Wiki Loves Earth 2021
Images from Wiki Loves Earth 2021 in Germany
Images from Wiki Loves Earth 2021, DE landscape
Images from Wiki Loves Earth 2021, DE-BY
Images from Wiki Loves Earth missing SDC depicts
Images from Wiki Loves Earth missing SDC location of creation
Landschaftsschutzgebiet innerhalb des Naturparks Hassberge (ehemals Schutzzone)
Pages with maps
Photos of protected areas by Stephan van Helden
Self-published work
Uploaded via Campaign:wle-de-by
@RZuo I really can't get any meaningful results from this function. When I open Category 'Ermershausen', select all files and run "Check over-categorization", it highlights three files:
This is somewhat frivolous, but, after using this script for the first time (which took ten seconds), I proceeded to design a logo for it in Inkscape (which took half an hour). What do you think (you can see my weak explanation at the file description)? Edward-Woodrow (talk) 22:29, 19 August 2023 (UTC)[reply]
theoretically, to accomplish what you describe, you can do a search of deepcat:"A" deepcat:"B", then use catalot to move all search results from A to the target new cat C, then use catalot again to remove all from B.
(ec)@LaundryPizza03: When I selected all in the latter cat and clicked "Check over-categorization", the gadget found (and highlighted with a dotted border) seven overcategorized pages (but not en:Goop (company)). I see now that the two cats are connected by en:Category:Alternative medicine. Perhaps the overcategorization check only works on pages that are in two cats that are directly in a parent-child relationship, rather than grandparent-grandchild. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:11, 18 December 2023 (UTC)[reply]
When searching for categories via cat-a-lot that are not already in immediate parent-child "vicinity" (like in cases of uncategorized media), one needs to "confirm" one's search result either via kicking "enter" on mobile keyboard or by tapping on the search result to "add" the found category to the cat-a-lot list of categories to choose from. However, neither of the two ways of "confirming" the search result is currently working in (my chromium-based) mobile browser, which means that I need to open every single file individually and add the categories manually. Example: there's media on Skopje in "All media needing categories as of 2019" (let's shorten that here to "All2019"). When opening cat-a-lot on "All2019", cat-a-lot only offers options like "Uncategorized files", "Hidden categories", and "Files needing categories by year". If I enter "Skopje" in the "Enter category name" search box, there's no way for me to actually select or add "Skopje" to the list of categories to choose from. That's the bug. I'm stuck with the options "Uncategorized files", "Hidden categories", and "Files needing categories by year". The only way to get to the Category:Skopje is to manually click through the whole category tree, first moving to some parent of All2019, and from there to a child category that hopefully has Skopje somewhere down the line of the category tree. This is obviously not very feasible, so every file needs to be categorized manually in the end. Nakonana (talk) 15:25, 2 March 2024 (UTC)[reply]
Actually, it's sounds like the same issue as described in "Cat-a-lot not working for on-screen keyboards", except, it used to work for up until 1-2 months or so ago. Nakonana (talk) 15:29, 2 March 2024 (UTC)[reply]
I just had the same problem. Somehow I miraculously could select my target destination once, but when I tried to do it again I couldn't get it. How do I do the equivalent of "pressing enter key on PC" on mobile web browser? (Using brave browser.) RZuo (talk) 16:52, 13 August 2024 (UTC)[reply]
click the first clickable category underneath the search bar
now go back to search bar. When you press the -> button on your onscreen keyboard, it probably behaves like the enter key.
If it doesn't, then keep clicking any clickable item, then first clickable item, then try enter key in search bar, until you get the target category selected.--RZuo (talk) 17:32, 13 August 2024 (UTC)[reply]
It seems it works more likely if you click something that needs to "load", that is, a category that has lots of subcategories. Then after "loading" you will be able to press the enter key. RZuo (talk) 17:40, 13 August 2024 (UTC)[reply]
Can we fix cat-a-lot to NOT take up the bottom corner all the time ? It's annoying and gets in the way with the fullscreen view of videos (esp on mobile this is very annoying), sometimes the wide layout button of vector-2022, several of the fullscreen gallery options etc. I understand that if you use this tool every day it's handy, but everytime i try it, i have to disable it again because of this. Almost every other tools is launched from the Tools section, why can't this one be ? —TheDJ (talk • contribs) 17:42, 26 April 2024 (UTC)[reply]
@TheDJ: For the why: probably because there was no other option at the time. This script was written in May 2007; according to mw:RL/MGU#MediaWiki 1.16 and before, addPortletLink() appeared in 2008.
For the why not: muscle memory. Maybe there could be a preference for that (Cat-a-lot already has preferences), defaulting to the legacy placement.
(By the way, I also use it very rarely, but it doesn’t annoy me. I use Vector 2010, though, maybe it’s more annoying on Vector 2022.) —Tacsipacsi (talk) 07:55, 27 April 2024 (UTC)[reply]
Categorizing user pages using Cat-a-lot is possible – just turn on categorization of pages in "Preferences" (checkbox "Allow categorising pages (including categories) that are not files" – it's disabled on Commons by default). I don't think Commons has specific guidelines for editing of other editors' user pages. Check out enwiki's guideline, which doesn't apply to Commons (it's for a different project), but it may give you an idea of what kind of editing is acceptable.
Hello @Andrybak, I'm really interested in categorizing categories with Cat-a-lot on Commons, but I cannot find "Allow categorizing pages etc." in Preferences, in which tab is it exactly? Una tantum (talk) 08:24, 12 August 2024 (UTC)[reply]
I just made a mess because the "+" button in the interface does say "Copy" in the tooltip. Like it would copy the category to the clipboard. But I don't want to create a copy of anything. Not a copy of a file. Not a copy of a category. All I want to do is to add the files I selected to the category. The only other button I could find was the "→" arrow that says "Move", but that actually deleted something completely unrelated without giving me a chance to review or even understand how it's going to decide what will be deleted and what not. For a start, can you please fix the tooltip to say "Add this category to the selected files"? Thank you. --Thiemo Kreuz (WMDE) (talk) 07:59, 27 June 2024 (UTC)[reply]
@Thiemo Kreuz (WMDE): The "+" button copies the selected items into the category next to that button. The "→" arrow copies the selected items into the category next to that button and removes them from the currently viewed category (that is, moves them to the new category from the currently viewed category). — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:17, 19 July 2024 (UTC)[reply]
Files aren't "copied". There aren't two files after any of these actions. That terminology is incredibly confusing and doesn't align with user's expectations. What happens is that the category is added to the files, and as a consequence of that the files are also added to the category (in other words: they are now linked). I made a suggestion how this can be significantly improved without any actual change to the UI. It's just a tooltip. Expert users that know what the "+" button does can easily ignore the tooltip. Thiemo Kreuz (WMDE) (talk) 16:18, 19 July 2024 (UTC)[reply]
When selecting files to be add to a category, these are highlighted in yellow.
They get grayed out once the addition takes place, except if the file is already in the category.
In this case, the file just gets white again. I think it would be better to give them a different color, e.g. a lighter gray. This should make it easier to work on longer list that are to be added to different categories. Possibly #Select all on Special:Search needs to be fixed first. Enhancing999 (talk) 10:28, 1 July 2024 (UTC)[reply]
In depopulating a large category, I noticed that Cat-a-lot ignores edit rate limits, leading to annoyingly waiting one minute after every 45 pages. I think this should be changed so that it waits 60 seconds every time the rate limit is hit, and tries again once the limit is up. Proof of concept is the rate-limiting code in en:User:Qwerfjkl/scripts/massXFD. –LaundryPizza03 (dc̄) 23:21, 7 July 2024 (UTC)[reply]
Maybe other users of this tool have found a way for that. Sometimes I forgot to first uncheck the watchlisting of files I move with cat-a-lot but didn't intend to watch or I only did so for the first page of files.
When I perform an action with Cat-a-lot in the Special:Search mode, the performance is very slow: copying and removing 500 files takes each more than 5 minutes, while earlier it was only some seconds. What happened? Can it be fixed? JopkeB (talk) 09:21, 19 August 2024 (UTC)[reply]
The code was changed to make actions sequentially and with a small pause in between (in order to comply with the API usage requirements). Hopefully that pause can be refined at a later time, but due to problems this gadget was causing, this restriction had to be put in place for now. —TheDJ (talk • contribs) 11:13, 19 August 2024 (UTC)[reply]
"It's too slow now." I'd say it was too fast before, as it wasn't complying with the API requirements for tools. Its one of those 'with great power comes great responsibility' things... —TheDJ (talk • contribs) 14:11, 19 August 2024 (UTC)[reply]
Thanks TheDJ, for looking after it. So it might get a little bit faster, but it will "never" get as fast as before. That is something we have to learn to live with. JopkeB (talk) 15:19, 19 August 2024 (UTC)[reply]
If I may suggest an alternative: QuickCategories also lets you edit categories in bulk, but should play more nicely with the server, and can also automatically retry edits that failed if the wiki was temporarily too busy. Maybe some Cat-a-lot power users will find it useful? (Disclaimer: I made the tool, so I’m naturally biased towards it ^^) Lucas Werkmeister (talk) 18:45, 19 August 2024 (UTC)[reply]
@TheDJ, please provide the link where, "The code was changed to make actions sequentially and with a small pause in between (in order to comply with the API usage requirements)." Thank you, -- Ooligan (talk) 04:11, 20 August 2024 (UTC)[reply]
What would really be "cool"- would be this now very slow tool be returned to its former fast speed that actually made this tool an award winner in 2024. -- Ooligan (talk) 04:03, 20 August 2024 (UTC)[reply]
Agree – there shouldn't be a focus on finding alternatives for this extremely useful tool: instead, please actively try to have these rate-limits changed or make cat-a-lot become an exception in the API usage requirements (in general or when used by e.g. established users and/or specifically on Wikimedia Commons). And please link such efforts here such as a phab issue about it. Prototyperspective (talk) 18:16, 20 August 2024 (UTC)[reply]
Hi, my name is Amir Sarabadani and I work at SRE team at the foundation. Our job is to make sure the site is available to everyone at all time. We had to introduce sleep between each edit because it was making edits at such rate that it brought down all Wikis more than ten times. This phabricator ticket has more technical details. The way it operated was a clear violation of our API policy and as such can't be changed back to the previous state. Similarly, no forking shall be done as it will endanger reliability of the site. I understand this is frustrating but the options here are between a slower gadget or sites being down. If a volunteer is willing to, they can refactor the gadget to make sure the edits are done in serial and then reduce the sleep time to 0.5s which would make it slightly faster but it won't be as fast as it used to be (and it shouldn't as I explained above why). I hope this makes it clearer why such change was done. Apologies for the inconvenience but we have no other choice. Thank you ASarabadani (WMF) (talk) 11:54, 23 August 2024 (UTC)[reply]
because it was making edits at such rate that it brought down all Wikis more than ten times Wouldn't the next step after some adhoc temporary measure like limiting the tool edit rate be to change cat-a-lot so all users using it can't exceed some edit rate limit so it only becomes slow once its overall rate is too high? It also seems needed to also look into why it had the effect and which activities caused it. I think this is a rare case of a tool where it is very reasonable and somewhat needed to make it an exception allowed to make edits at rates above the API policy once the aforementioned solution is implemented albeit the sites shouldn't crash but e.g. automatically throttle all automated-tool-tagged edits like those being made with CAL. Prototyperspective (talk) 15:27, 26 August 2024 (UTC)[reply]
I came here for the same issue. Made it very slow and difficult to move files into renamed categories, or other fixes I used to do after uploads (because adding categories through the Wizard is very slow, and need a lot of copy-paste for each single category of files). Please bring back to original speed. ASarabadani (WMF) Having the website down for a few seconds was not a big issue, as it happened really rarely and for very short time. --Sailko (talk) 14:06, 23 August 2024 (UTC)[reply]
i'd say the question is, who was using it so massively that it brought down the site, and how.
the tool has been around for more than a decade? who was using it in the past few days with no regard for edit rate?
ofc, the tool should also be rate limited, but not as much as 1 or 0.5 sec between each edit? plenty more tools edit quite rapidly too. do they cause similar problems? RZuo (talk) 14:17, 23 August 2024 (UTC)[reply]
Other tools limit the maximum number of requests they'll send at one time.
Before @ASarabadani (WMF)'s patch, Cat-A-Lot would send all of its edits simultaneously, without waiting for anything at all. Some of the time, this would result in immense load on the database server, bringing down all wikis for 10-30 minutes.
The tool could be both fast and safe if it was modified to issue requests serially, not in parallel.
But that change was not easy for us to do in unfamiliar code during an emergency situation, so we made the edit that would fix the site while unfortunately slowing down the tool.
With the current performance it is not possible to make bigger changes in the categories. And sorry, you didn't answer the question why it was OK all the years but now it that bad, that you practically shut it down.Avron (talk) 20:06, 27 August 2024 (UTC)[reply]
Same for me. I used to mass-move hundreds of files under few seconds. It is taking minutes now and the tool is useless now. Quick Categories isn't a visual tool and VFC doesn't help with category tree. WMF is digging another trench between themselves and the community. --— Draceanetalkcontrib.07:18, 30 August 2024 (UTC)[reply]
@ASarabadani (WMF)@CDanis (WMF): As you can see from the comments in this thread, this is a critical tool that needs to be usable for high-volume edits. It is clear that the community is unhappy about the way this has taken place. I believe it would be appreciated by many if you could answer the following:
This tool has been in use for 17 years. Are these issues new? If so, why; if not, why was nothing done before?
Why was there no notification to the Commons community that a widely-used tool was being limited? Is there any policy for your team about when to notify communities about changes like this?
What is the timeline/path forward to refactor the tool to restore its former level of functionality? Will WMF developer time be allocated to do so, or will it have to be a volunteer?
I would also ask about the guideline. I think the API guideline is for somehow external or additional tools and not for MediaWiki functionalities itself. Of course technically it is an external tool but practically it is like a core MediaWiki feature. And then a question to the rate limiting that already exists. Why does this not prevent the problems? Or are users with ratelimit exception the problem? Generally this needs a server side solution to not impact user experience. GPSLeo (talk) 05:59, 2 September 2024 (UTC)[reply]
Regarding policy, the policy this gadget was violating is mw:API:Etiquette that is explicitly refereed to in our terms of use and must be respected. On why it hasn't caused issues before, it can be many reasons, more people are using the gadget, more people are editing Wikimedia Commons, edits are more expensive due to having more features, it can be that because of HTTP/2 more requests are being sent via browsers at the same time (I wrote in more details in phab:T370304#10072844). At the end day, it doesn't matter. The API policy is there to protect the infrastructure from harm. If it was violated and no issues were seen, it doesn't mean such violations are okay. With regards to responsibility, maintaining gadgets is the responsibility of volunteers. If you want engineering time to be allocated to this, I recommend using m:Community Wishlist. I say it again, it can be made much faster with proper rewrite of its internals but it can never be turned to its previous speed. Thank you ASarabadani (WMF) (talk) 16:07, 2 September 2024 (UTC)[reply]
Wasn't the tool reviewed by WMF and given an award? Also, edit rates at Commons were increased specifically to make this tool possible? Wouldn't one expect WMF to fix the bug identified months ago rather than deactivating it. ∞∞ Enhancing999 (talk) 16:11, 2 September 2024 (UTC)[reply]
Additionally, rules and terms of use are not an end in themselves...when a tool would greatly benefit to be exempt from these or when it would be good to change them, then I don't see why it wouldn't make sense to think about some changes that prevent issues from occurring without the speed limitation which probably needs to be done anyway sooner or later and would improve stability & performance: namely making the tool create one batch-command where the server then executes all tasks in the batch as fast as it can but not faster or slower than that (e.g. at max 5 users' queues in parallel with 0.05 sec per task at any point in time). Probably somebody else can explain it better and that wouldn't just be a very useful to get CAL up to speed again but also for various other purposes where I'm somewhat surprised that's not how such API requests are handled. Asking about this in the context of CAL me be inappropriate so one would need to look also into other advantages and needs and prior issues/discussions about something like that if that's indeed missing. Prototyperspective (talk) 16:26, 2 September 2024 (UTC)[reply]
"Wasn't the tool reviewed by WMF and given an award" No it was not. Coolest tool is an event that is facilitated by the foundation, and the committee are volunteers both from within and outside of the foundation, and often winners from previous years. They do not do code review, they just evaluate the 'coolness' of a project. —TheDJ (talk • contribs) 21:29, 3 September 2024 (UTC)[reply]
What trip ? The committee uses online communication, and the awards are handed out at events that are already being organized (either the hackathon or wikimania), by people already attending that event for other reasons. I'm not even sure if there is budget for this entire thing. I really don't appreciate this disingenuous take. Talk is easy, but you could use that same energy to do something useful or fun for other people. Like the Coolest Tool Award committee. —TheDJ (talk • contribs) 21:47, 3 September 2024 (UTC)[reply]
You know.. it is comments like these, that make it REALLY freaking difficult for me as a volunteer, to fight for attention for Commons among the foundation. Maybe it is time this community forks off. let them solve their own problems. —TheDJ (talk • contribs) 21:50, 3 September 2024 (UTC)[reply]
@ASarabadani (WMF): Please don't take this as a personal insult - this is a cultural problem with the WMF as a whole and not you/your team - but this is a perfect example of why users distrust the WMF. This is a tool that has been in use for 90% of Commons' lifespan (5 years longer than the API policy has even existed) and probably represents >10% of total edits on one of the busiest wikis. (That's likely 100M+ total edits with the tool - more total edits than all but a handful of wikis.) By any definition, that should be considered a core piece of MediaWiki functionality. Yet now it is near-useless with no guarantee it will ever be fixed.
There were multiple chances to avoid this problem. The volunteer developer (who is no longer active) should have been notified as soon as the issue was identified - which should have been 6 years ago when the code was refactored. The Commons community should have been notified when the problem was first identified to maximize the chance that another developer would step in. And the community should have been notified when the tool was limited, rather than having to ask for answers.
Given that failure by the WMF to communicate, it is insulting to the Commons community to say that the WMF can break this essential tool without any warning, yet will not but any effort into fixing it. It is equally insulting to say we should go through the Community Wishlist process, which is excruciatingly slow and has no guarantee that a request will be chosen, just to get back to the level of functionality that we had. Widely-used tools like Cat-a-lot are just as essential infrastructure to editors as the servers are. It doesn't matter to us if the servers are working perfectly if we can't properly categorize files. This problem was created by the WMF, and your team needs to be working with the Commons community to fix this gadget as quickly as possible. Pi.1415926535 (talk) 03:00, 3 September 2024 (UTC)[reply]
From the comments of @ASarabadani (WMF) we learn that there was no real problem with the tool. But then someone from WMF came and and felt a personal mission to enforce a API policy immediatly. This is not what WMF should akt like, but unfortunately it does.Avron (talk) 11:29, 6 September 2024 (UTC)[reply]
@Avron I'm not sure how you came to that conclusion, It's documented that the gadget took down commons multiple times until users from SRE brought the site back on-line. P858snake (talk) 11:58, 6 September 2024 (UTC)[reply]
OK, sorry I overreacted. You are right, there was an incident. But the gadget was used for years without known problems. If only the gadget was the cause, the problem should have happen much earlier.Avron (talk) 12:55, 6 September 2024 (UTC)[reply]
I told people it was flagrantly violating the api policy years ago. Nobody cared. Commons has nobody to blame but themselves for this situation. Bawolff (talk) 06:06, 2 October 2024 (UTC)[reply]
This drastic drop of performance did not go unnoticed from day 1. The waiting time (locking the page) feels unbearable. Pleading for reconsideration/reparation ASAP since there is lots of work to do and it should not take 30 years when it could be done in 3. Peli (talk) 10:51, 17 September 2024 (UTC)[reply]
@ASarabadani (WMF): «it can never be turned to its previous speed». Thanks for your candour. I never doubted the unfixable rottenness behind all most of the WMF actions in the past decade, but this kind of encasulated statements are more clear and simple than screenfuls of deep analysis. I hope to see really soon you and your ilk out of this job, and the WMF in the hands of people who really care for the curation of free knowledge, not for hype and buzz. -- Tuválkin✉✇01:22, 2 October 2024 (UTC)[reply]
This is unacceptable ad hominem. And you're shooting the messenger. They're not in charge of the amount of resources allocated to the infrastructure that failed because of the previous version of Cat-a-lot. Nardog (talk) 04:46, 2 October 2024 (UTC)[reply]
Been experiencing this on multiple occasions. It's not surprising that JopkeB and others are also experiencing the snail-like performance of a tool that is supposed to execute recategorizations within seconds. To illustrate, as can be seen in my contributions, I transferred 162 more or less image files of w:en:Asin Road from Judgefloro-created "Category:Anduyan-Rizal-San Pascual-Nangalisan-Asin Road (Tubao, La Union section)" (very loong category name as expected from Judgefloro's creations) to Category:Asin Road (Tubao segment). It took me around 8 minutes, between 5:57 and 6:06 pm (Philippine Standard Time/UTC+8). Before, it was possible to recategorize all in less than a minute. While the API limit concern does seem valid, I agree with users like Pi.1415926535 and Avron that the API issue should have been investigated more thoroughly and not pinpoint all blame to this useful tool that has been in use for many years – even before this API policy. Valid recategorizations, such as fixing messy categories left behind by Judgefloro or his socks (like Ramon FVelasquez and JFVelasquez Floro), are supposed to be done within seconds, not minutes. Slow recategorizations waste valuable time for many editors (including off-wiki/real world errands and works). This should be addressed. In short, very disappointing snail-like performance. JWilz12345(Talk|Contrib's.)10:21, 21 September 2024 (UTC)[reply]
Agree. Now that we're more than a month in, I have to say that this issue hasn't been handled very well so far. There are probably many organizational and resource-related constraints that I'm unaware of, but still:
Changing the tool was a highly disruptive edit, so it follows that WMF should have at least notified Commons users immediately and publicly, while also putting in some effort towards finding an actual solution, knowing that they only solved one problem by causing another. Instead, this discussion had to be started after the fact for most people to have any idea what had happened, and so far we've only been referred to the wishlist.
It was a good thing that the downtime issues were fixed, of course, but the fix had consequences that WMF should take responsibility for. There is still a problem, albeit a different and smaller one, and it was caused by WMF directly. Simply handing a problem you yourself caused to the people affected by it, along with some barely useful advice that they don't even need, is a counterproductive attitude to have in any situation, but perhaps especially towards a volunteer community.
One would at least expect some act of solidarity towards the people who build and improve WMF's projects on their own time and dime. If there is indeed tension between WMF and the community, as previous posts suggest, I now understand why, and this certainly won't do anything alleviate it.
From a technical perspective, the root of the problem lies in the gadget code. It should not have been sending all edit requests simultaneously, as this was the core issue, and the subsequent responses were merely addressing the symptoms. When we consider the role of WMF site reliability engineers, which is to ensure the site remains operational, it's easier to understand why their focus is on resolving issues that directly impact site stability and then moving on to the next task. If they were responsible for fixing all external tools, they wouldn't have the time to maintain the platform itself.
This doesn't imply that they are dismissive of or unaware of Cat-a-lot's importance—it's simply that it falls outside the scope of their primary responsibilities. Additionally, software needs to be updated over time as the environment around it evolves. Even if something worked well in the past, changes in web browsers, Wikimedia APIs, the system environment, and usage patterns all necessitate updates. It's unrealistic to expect that software will continue functioning without any ongoing maintenance.
Personally, I believe that Wikimedia communities should prioritize building capacity to maintain the tools they develop. While Cat-a-lot may be somewhat unique due to its widespread use—being utilized by 5-10% of daily Commons editors—it should ideally receive some support from the WMF, though this likely falls under a different team's responsibilities rather than the SREs. -- Zache (talk) 15:01, 23 September 2024 (UTC)[reply]
I have no objections to what you're saying, of course, but a rehashing of the general situation really doesn't address what I said. If anything, you're basically just describing the problem, as I see it. With some good suggestions added.
I believe everyone already understands that Wikimedia as a whole is incredibly complex and that responsibilities have to be structured in a reasonable way. But that shouldn't also mean that someone can expect not to be held accountable at all, simply because what they did was necessary, when their actions directly interfered with someone else's area of responsibility and caused problems for them. That way of thinking doesn't make any sense to me. Of course you help someone when you mess up their stuff, even if all you can do at first is make sure that they know what just happened and why.
I feel the need to stress that I did not say that the WMF should be "responsible for fixing all external tools," just that they should take some responsibility for this one problem, which they caused. In this case, the widespread use of the tool means that not only is this important in principle, but also very much so in practice.
@Zache is it possible to separate APIs used in Cat-a-lot instead? So that the concerns on breaking Wikimedia servers are alleviated if Cat-a-lot uses own APIs that are distinct to those used in other tools or functions. JWilz12345(Talk|Contrib's.)02:25, 2 October 2024 (UTC)[reply]
The problem, as far as I know, was that changing categories triggers an update to the category, which in turn updates that row in the database table. The row will be locked until the update is complete. This lock prevents new writes to that exact row until the previous update is finished. If there are multiple edits coming in very quickly and there is load on the database, the writes will start to pile up, eventually causing a noticeable problem. The proposed fix for this in Phabricator was that these writes wouldn't need to be performed for every edit; instead, the system could flag the value as 'dirty' and update it when there is time. However, they were not able to make these changes on the fly, so the ad-hoc limited the cat-a-lot as quickfix, and even they are fixing the server side it doesn't change that cat-a-lot should work inside the rules. --Zache (talk) 06:15, 2 October 2024 (UTC)[reply]
@Zache: I can tolerate the speed of COM:VisualFileChange though. It temporarily stops edits after the 900th edit, and need to wait for a minute or two before resuming the execution of the tool (in my case of custom replacing {{Licensed-FOP}} with {{Licensed-PD}} for files of PD-Philippine buildings). Nonetheless, the speed is acceptable for me (ensuring smooth and fast performance but not risking breaking some WMF servers). Will that speed be the same speed to be implemented in the updated/revamped Cat-a-lot? JWilz12345(Talk|Contrib's.)09:30, 12 October 2024 (UTC)[reply]
VisualFileChange uses 5 parallel edits for regular users (and 10 for sysops/bots) by default. My personal guess is that 5 could also be achieved with Cat-a-lot. However, we are starting with 2 to see if there are any problems, and will gradually increase it from there. --Zache (talk) 07:46, 13 October 2024 (UTC)[reply]
Unfortunately, after @SDeckelmann-WMF took over as Chief Product and Technology Officer, Commons seems to have become WMFs' uglyduck. Quite clearly, we are not a priority, and this is yet another blatant evidence of this.
"With regards to responsibility, maintaining gadgets is the responsibility of volunteers" - and the responsibility of WMF is to support volunteers. Looking at all funds that were wasted in the failed processes of branding and strategy, and bizarre initiatives like fostering diversity outside wikimedia (that Knowledge Equity stuff or whatever it is), I'm pretty sure it shouldn't be difficult to find some cents to put in fixing cat-a-lot and, for a change, funds would be applied in something they are meant to, instead of those reckless experiments. If they are not doing it, it's because we are not a priority. DarwinAhoy!01:09, 22 September 2024 (UTC)[reply]
@ASarabadani (WMF): Would you like to check if my version of cat-a-lot.js (diff) would be working nicely enough in terms of parallel editing so it could be used? I changed the code so that it will limit the number of concurrent edits to 5 when maxlag is under 1.5s and if it higher it drops it to 1. Currently it checks maxlag only when user starts the batch, but it can be changed so that it would check it every 50 edits or so also. 1.5s is selected as lag seems to be changing between 0.3 - 1.1s so I just selected a value which is little-bit higher than normally. --Zache (talk) 04:59, 23 September 2024 (UTC)[reply]
This solves the abort by patching the $.Ajax() function and aborting it there. This is bad practice. So, libAPI code needs to be updated so that libAPI supports the aborting the requests and use that instead. (done, but waiting that libAPI gadget will be updated)
Current version uses two parallel requests. It's idea is not to be faster but, that human can abort it if it doesn't work correctly.
There should be more testing on if it works correctly (ie. aborting, undoing, text/colors become visible in right order etc). The spinner doesn't go away after abort, but that was broken already. Spinner is fixed.
Special:Search selection should be working. (TODO: check that nothing else broke because fix)
selected number should be working after clicking "Invert". (when it broken number were inverted. (ie. 1 selected, number was 199 etc, 199 selected number was 1). --Zache (talk) 12:13, 5 October 2024 (UTC)[reply]
Hi Zache, thanks for this effort. In my test it works smooth and acceptable for a few times and than randomly fails to load the requested category branch. After a page refresh (abandoning the selection of already picked pages) it starts up with requested cat in textfield. Peli (talk) 20:34, 2 October 2024 (UTC)[reply]
@Peli Thanks for testing. Can you describe step-by-step tutorial how I can try to replicate that? (I am not regular user of cat-a-lot so I don't know how how it actually works or how people are using it so it) --Zache (talk) 21:16, 2 October 2024 (UTC)[reply]
Yes. Have the tool enabled. Go to cat:Collections of the National Museum of Finland. Bring up the tool. Select a file to test the process by clicking emty space under it. File will be highlighted. Move this file for example a medal to one of the available cats seen at the top, by pasting the cat name in the formfield of cat-a-lot or selecting a target cat in the list of CaL. Press enter twice to really set it active ready to go, double check to see if the desired action is programmed and see if the desired target is selected. Press the arrow to move or the Plus sign to add and this does the action. Press esc to clear the results panel. Now I pick another kind of object and try to move it to a different cat like Miscellany. Do this by pasting or typing another cat name in the formfield. Soon enough the tool will throw the endless-loading-error if you try to move some files back and forth between some various or unexpected cats. Peli (talk) 22:19, 2 October 2024 (UTC)[reply]
Great fix. I like that result panel seems to get ready much faster without obligatory waits when no action is needed. "The following () pages were skipped, because the old category could not be found:" - Such as removing a redundant cat from a large batch when no file uses it.Peli (talk) 01:50, 4 October 2024 (UTC)[reply]
The main function of the update is to enable submitting parallel edits without overwhelming the server. Idea is to start with 2 parallel edits and then to gradually increase it. (phab:T375355)
Changelog
Update Cat-a-lot to use libAPI for editing to manage number of parallel edits. (diff)
I assume the console.log() before the abortPendingRequests() was left over accidentally?
Has the behavior implemented in updateMaxLag() / maxSimultaneousReq been discussed here, especially with WMF people? I haven’t read through the whole discussion that took place here over the past weeks, but as far as I remember, the previously communicated acceptable edit rate is “one request after the other”, i.e. fully sequential. (In fact, what Amir wrote on 23 August was serial edits plus a shorter but still nonzero sleep after each edit.)
Okay, I chatted a bit with Amir and it sounds like this is okay, but let’s hold off on this until Monday when ops availability will be better in case the site goes down again after all. Lucas Werkmeister (talk) 18:23, 9 October 2024 (UTC)[reply]
Answers
it was there just to see when the abort was executed. In the version where $.ajax() was overwritten there was race condition on abort where last edited file was not reverted when user clicked undo. However, I haven't seen that on libAPI version. In any case I removed console.log() from the code as it was not useful without other information too.
I also tried sequential editing first. The problem with sequential edits was that each edit regularly took longer than 1 second, so making it sequential slowed it down even more compared to Amir's parallel but with a 1-second sleep between starting new edits. For this reason interactive use cases—i.e., when a user selects a limited number of images and then adds/removes from them—parallel editing will be required to have a usable user experience. (in this context I don't think true mass editing, thousands edits or ten thousands edits in a batch, is not interactive editing and would require some other approach if it is still a problem)
I looked it. It should be possible, but it is little bit more trickier than other pages as special:mediasearch list is dynamically generated using en:Vue.js so it require disabling Vue.js click handling when the Cat-a-lot is active. I will look this more after the current changes are successfully live first. --Zache (talk) 18:32, 10 October 2024 (UTC)[reply]
It looks like the performance has been improved considerably. It is a lot faster now than one item per second. So thanks for whoever is responsible for this improvement! --JopkeB (talk) 14:26, 1 November 2024 (UTC)[reply]
Bug: Cat-a-lot does not work (again) for categories and gallery pages in Special:Search mode
It is not possible again to use Cat-a-lot in the Special:Search mode for categories and gallery pages (after clicking on "Preferences", and "Allow categorising pages (including categories) that are not files"). Can this please be solved soon? JopkeB (talk) 10:33, 26 August 2024 (UTC)[reply]
If I understood the bug report about the outage a while ago, it was cat-a-lot issue mentioned at #Select_all_on_Special:Search that lead to the issue when a user tried to add "photographs by .." to thousands of files, each being hammered twice. It would be good if the bug were fixed so this can get back to normal. ∞∞ Enhancing999 (talk) 10:10, 31 August 2024 (UTC)[reply]
That is certainly not what I did. I just selected less than a dozen photos from perhaps 40 hits and tried to copy them to another category. One time 8 out of 10 were copied, another times none out of four. JopkeB (talk) 15:50, 31 August 2024 (UTC)[reply]
I think that I was able to fix the Special:Search to Modified version of Cat-a-lot (see above), please test if it works and nothing else is broken. --Zache (talk) 11:35, 3 October 2024 (UTC)[reply]
There indeed is a big improvement. Most of the times I use it all the yellow files are now copied, only now and then the very last one gives a bug, but this a big improvement to how it was two months ago (I just look which one has not been copied and change that file manually). JopkeB (talk) 14:31, 1 November 2024 (UTC)[reply]
For a while now, if I select, say, 20 files and add them to a category, Cat-a-lot will tell me it is updating 40 files. Its progress counter will count past 20, all the way up to 40. If it reports that some files were skipped, they are each listed twice.
I could not duplicate this, but I tried to duplicate the "Unselecting files on SpecialSearch broken" I noticed that invert selection shows reversed numbers (1 image selected it shows 19, 19 images selected it shows 1) --Zache (talk) 11:51, 2 October 2024 (UTC)[reply]
I’m considering the idea of adding support of moving very large editing batches to background jobs. For example, modifying the Cat-a-lot UI so that it suggests submitting the batch to QuickCategories and running the edit batch there. However, to implement this, I need to better understand how people are using Cat-a-lot for editing large batches.
I have a couple of questions for this:
What are you trying to achieve when editing over 200 files in a single batch? (ie. is there some specific task what you are doing)
On which page are you selecting the files? (ie. category, special:search, Special:ListFiles ...)
Are you selecting all the files from the list, or are you making custom selections?
I most often use it on two kinds of pages, categories and special:search.
on cat pages, the max you can select, i think, is 200 for each kind (subcats, files, pages). usually, no one does such things unless the cat is moved and contents are being moved from the old name to the new name. i think i mostly move < 100 things at once.
on special:search, the limit is of course how many results there are on a single page, which can go up to 5000 if you like. but i usually also move < 100 things at once.
only in the aforementioned case of moving everything from old name to new name might i select everything blindly. but, i dont normally do that but leave it to the bot in charge of clearing redirected cats. for other cases, i always inspect the files to see if i can better diffuse them into more suitable subcats. RoyZuo (talk) 16:10, 13 October 2024 (UTC)[reply]
The tasks where I use cat-a-lot the most:
- Move files from "review" categories to correct categories, or remove the review category, for files uploaded by my bot, on a daily basis
- Split large categories (> 1k pictures) into more precise categories (by topic, by year, etc.). This task has become a nightmare
- Create a new category for a new topic, and look for existing pictures on Commons, add all found pictures into the new category from the search result page vip (talk) 19:40, 14 October 2024 (UTC)[reply]
I usually use Cat-a-lot in recategorizations while in category pages, including:
recategorizations of multiple files by Judgefloro (talk·contribs), like dozens of images of a small segment of a Philippine road that is best recategorized to the parent category of the said Philippine road segment (as many of subcategories of road segments he created have been unnecessary forks encouraging redundancy);
after moving a category name to its more desired category name (usually those created by Judgefloro), and this involves massive transfers of his files to the desired category name, which may take several minutes due to Judgefloro's numerous files; and
I also use Cat-a-lot in recategorizing non-files like subcategories and deletion request pages under multiple FoP cases/pending categories (to FoP cases/deleted categories). JWilz12345(Talk|Contrib's.)07:21, 15 October 2024 (UTC)[reply]
1. I use Cat-a-lot in quickly recategorizing images and the categories themselves (thanks to JWilz12345, who taught me that categories can be recategorized in batch using Cat-a-lot). Currently, I am focusing on improving categories of Roman Catholic churches images in the Philippines.
2. I use Cat-a-lot in Category pages only (at least for now).
Example. Presented with 117k uncategorized files with mixed object types, I would like to move a batch of over 5k photo files by the museum itself to a prepared subcategory. I used to do this in batches of 500-1000 and the tool was fast enough to wait for it and repeat the action 5 to 10 times. Being done within an hour. In this use case I would work from special search by a quoted chain of keywords. Nowadays the tool is too slow to sit and wait for it to finish the job, so normally I will start a larger job in one tab and while it is running do small tasks in other tabs. I like the idea of giving this kind of large tasks too a bot request, beacuse there is no real hurry and in fact I will avoid these kinds of large tasks nowadays and focus more on small tasks of reviewing and moving 30-300 files to categories of artworks by creator. Most of the times from special search, sometimes by inspecting and reorganising category content. I like that the experimental version of the tool is fast enough for small tasks (~20-40 files) to finish soon enough to keep going on the same project. It would come in handy coming from special search if the tool could be able to remove the old category in the same edit, but it would require a second formfield i guess. The way it is today we have to run the same batch twice, once to add a new and once to remove the old cat. I think a button for "reselect last batch" would come in handy, especially if they are hand picked files scattered in a long list. Peli (talk) 10:02, 25 October 2024 (UTC)[reply]
There is a potential race condition where selecting stops working in newly loaded results when the user scrolls down and Special:MediaSearch page dynamically loads additional results, or when the user performs a search with a different keyword, returning new results. I would be interested to know if this issue still occurs.
Thanks, it's promising to see the cat-a-lot-box on that page.
Somehow I can't seem to select a file on [3]. to add categories: it keeps opening the preview on the right side. For me it would be sufficient to use a different tab or windows to view the file. ∞∞ Enhancing999 (talk) 21:20, 15 October 2024 (UTC)[reply]
If it opens the preview then code was not able to capture the events from Vue.js. Probably because it tries to do it before Vue is ready. Just to confirm, if I understood correctly it didn't work on any other search either and this was systematic error? Second confirmation, which browser you are using? --Zache (talk) 04:42, 16 October 2024 (UTC)[reply]
It already fails on the first tab. I still keep getting the preview. I guess I should look into updating the browser unless there is a hack that allows me to deactivate the preview completely. ∞∞ Enhancing999 (talk) 21:27, 16 October 2024 (UTC)[reply]
Example video of Cat-a-lot mediasearch. I added a video about how it is expected to work when it works:
When Cat-a-lot is active it captures click events from Vue.js and selects files. It should not show preview in this mode.
If cat-a-lot is disabled (the 'x' -button in bottom bar) Cat-a-lot will disable its own handlers and mediasearch should work normally. There should be mediasearch previews.
If cat-a-lot is activated again from bottom bar (the 'cat-a-lot' link text) then it will again capture the click events. It should not show preview in this mode. Existing preview window needs to be closed manually.
Most likely not as if with three tester, it is broken with one (you) it is likely broken with a lot of more users too. I could try to replicate the problem if you tell what browser you are using? --Zache (talk) 14:49, 18 October 2024 (UTC)[reply]
Maybe we can get more testers in the forum. My outdated browser shouldn't be an obstacle.
This tool is also used in different Wikipedias, mine is Romanian Wikipedia. Is it possible to add a tag for Recent changes to also filter them there like it is in Commons? Thank you. Gdaniel111 (talk) 11:53, 29 October 2024 (UTC)[reply]
Done -- Docu at 06:03, 17 February 2013 (UTC)
.jpg){kind=link}
Oppose 1. This would be a separate tool and not cat-a-lot so I think this discussion should be closed here and such a tool be requested elsewhere 2. I think one should only be able to add a file or gallery or category to a category from the respective page or the search results because there one sees some info on the page and otherwise people would often add unfitting pages, e.g. because they confused them or because the only have the filetitle info etc. Prototyperspective (talk) 09:04, 8 October 2024 (UTC)
Agree! Sinigh (talk) 19:01, 20 August 2024 (UTC)