Somewhat related: T103285

The script is old, and uses some outdated techniques (esp on api/promise/async level). The UI is powerful, but occasionally confusing to new comers, some refinement can take place.

There don't appear to be many open bugs, questions, or feature requests, although there are some.

Recent questions from Commons and enwiki:

• https://commons.wikimedia.org/wiki/Commons:Help_desk/Archive/2015/06#Tool_for_making_intersection-cat
• https://commons.wikimedia.org/wiki/Commons:Help_desk/Archive/2015/02#HotCat_question
• https://en.wikipedia.org/wiki/Wikipedia_talk:HotCat

Bugs from Phabricator:

• Deprecation of features used by HotCat makes core/extension JavaScript fail: T86142. Related discussion: https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-HotCat.js/Archive03#Errors_in_webconsole_-_deprecated. Apparently fixed on enwiki/commons, but potentially broken on a number of other projects.
• Questions about compatibility with Flow categories: T92874
• HotCat doesn't load after saving a page in VisualEditor: T103285. Needs new hook (T53583). Associated patch to add hook needs review: https://gerrit.wikimedia.org/r/#/c/219629/

Turning HotCat into an extension:

• Clean up and Graduate HotCat via Beta Features: T104394. Notes on what might need doing.
• 2-y-o thread on wikitech: http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=374666;page=1;mh=-1;list=wiki;sb=post_latest_reply;so=ASC. No particular consensus.
• Left a comment on the Commons gadget talk page asking for responses: https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-HotCat.js#Interest_in_conversion_to_an_extension.3F

Similar feature request:

• Implement visual interface for changing the categories a page is in: T29312.

Conclusions:

• HotCat could be updated to use jQuery and there are a couple of bugs that could be fixed.
• There is currently no push for it to be converted to an extension, but there has been at least a little thought given to it.
• HotCat on other projects may be broken and might be worth looking at.

The UI should be decoupled from the internal representation of category links. Parsoid could be used as source for both a revamped version of HotCat (T52239#1490877) and VisualEditor, while old wikis could still leverage HotCat's built-in parser.

The T86142 bug sounds pretty serious. Checking 386 wikis by hand won't be feasible. It should be pretty easy to write a bot to check MediaWiki:Gadget-HotCat.js at all those wikis and tell us which ones have pages longer than 10 lines (in which case it probably isn't importing the Gadget from Commons).

The impact of the Flow bug is tiny at this point, so I wouldn't worry about it yet.

The VisualEditor bug (T103285) sounds like it might be worth fixing.

The proposal for promoting this to an extension (T104394) is interesting. It already has a design pass, but it sounds like it would involve redoing the interface pretty much from scratch (and significantly simplifying it). I think we would want to get more community input before tackling something like that, but it might be worth considering.

Agree on all counts. We should keep converting it to an extension in mind when we have the capacity to plan for larger projects.

If you want to think "larger", there are two other scripts I wrote that somewhat overlap hotcat, but are specifically for Commons:

Cat-a-lot does simple mass-move operations for files on categories:
https://commons.wikimedia.org/wiki/Help:Gadget-Cat-a-lot
(Someone even made a how-to-use video! Amazing!)

Commons Commander is a much more powerful version of Cat-a-lot, with drag'n'drop mass "copy"/"move" operations between categories, user uploads, new files stream, search results, etc.
https://commons.wikimedia.org/wiki/MediaWiki:Commander.js
My 2011 blog post explaining this: http://magnusmanske.de/wordpress/?p=11

Potential tasks for HotCat:

• T86142 - Deprecation of features used by HotCat makes core/extension JavaScript fail
• T103285 - HotCat doesn't load after saving a page in VE
• Refactor and update to use jQuery (if converting to extension, this would be part of that)
• Prepare for extension conversion: request and summarize community feedback for UI changes and any other integrated abilities (as from Cat-a-lot or Commons Commander)
• Convert HotCat to an extension

HotCat, when it comes to the features, is basically perfect and needs no improvements. When it comes to the UI, it can be sometimes confusing, but is also quite powerful; I'm not sure if much can be improved here.

The problem with HotCat is that the code is extremely unmaintainable, written a long time ago using techniques which were good then but have better alternatives now, and tries to be compatible with ancient versions of MediaWiki – which has negative effects on modern versions of MediaWiki, especially because it keeps breaking when implementation details of core scripts or ResourceLoader are changed for this reason.

Please, do not convert HotCat in its current form to an extension. It would not improve its maintenance (I can guarantee that no one will step up to maintain it, because we value our sanity), and it will make it more difficult for gadget writers to maintain it.

@matmarex: Do you think it would be useful to create a simplified version of HotCat (from scratch) as an extension (using an interface similar to the one proposed at T104394)?

No idea. Probably depends on what you mean by "simplified" :) You should probably discuss with the actual users which advanced features they really use, I rarely use HotCat myself.

Also, I think that when you try to strip out all of the code which handles IE 6 and MW 1.15 and such, HotCat's code will become a lot less scary. @Lupo, are you still committed to keeping compatibility with them?

By simplified, I mostly mean getting rid of the tree traversal stuff (browsing parent and child categories). I personally never use those features and I think they make the UI more confusing than it could be otherwise. Also having the batch vs. instant change capabilities seems like confusing and unnecessary UI to me. The interface would be a lot cleaner and easier to understand without those features (and would still be totally usable). I didn't use HotCat myself for years solely because I found the UI confusing when I first tried it.

In T108630#1576734, @kaldari wrote:

getting rid of the tree traversal stuff (browsing parent and child categories)

= killing HotCat

have you recently changed hotcat?
i noticed different repsonses:
it is not changing lowercase to upper case, but requires a click on the drop down suggestion
it is not filling in suggestion consistently, but the drop down is blank, requiring typing in the whole category

In T108630#1613648, @Slowking4 wrote:

have you recently changed hotcat?
i noticed different repsonses:
it is not changing lowercase to upper case, but requires a click on the drop down suggestion
it is not filling in suggestion consistently, but the drop down is blank, requiring typing in the whole category

Hi there. No, we have not made any changes to HotCat so far.

the look & feel appears different in commons:
when type in the text box, the auto fill does not appear in the drop down box,
until i click away from the text box
when i save when an auto fill is in drop down box
it does not save the first auto fill suggestion, but the text in the text box

@Slowking4: That issue has been filed separately as T111614 and does not appear to be caused by anything related to this task. (In fact, it appears to be a Chrome bug. Please always say what browser you're using and on what site you're seeing the problem.)

thanks, sorry if off topic.
got here from
https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-HotCat.js
will post that other thread there

is it possible to bypass old java,
and start over using wikidata?