From sprint kick-off meeting:
Support: Medium/High
Feasibility: Good/Medium (not sure how many instances are broken)
Impact: High
Risk: Low

Priority: High

When switching to "hotlink" HotCat rather than using a local copy, be sure to check if there is a localization page for HotCat on that wiki. If there is, you'll want to set

window.hotcat_translations_from_commons = false;

before the mw.loader.load statement, so that it loads the local localization rather than trying to load the localization from Commons.

An example:
https://bg.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B4%D0%B8%D1%8F%D0%A3%D0%B8%D0%BA%D0%B8:Gadget-HotCat.js
https://bg.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B4%D0%B8%D1%8F%D0%A3%D0%B8%D0%BA%D0%B8:Gadget-HotCat.js/bg

So it looks like there are 32 wikis where HotCat is currently available as a gadget but broken: P2167. Would it make more sense to fix them by hand, or write a script to fix them?

It looks like we'll probably need to do these manually, as you need to create a 'local defaults' file on each wiki that you hotlink from and this will often involve copying code from the MediaWiki:Gadget-HotCat.js page.

I fixed the half-broken HotCat on az.wikipedia.org. It turns out it was broken because the HotCat.category_regexp value was wrong (which hotlinking to the Commons version didn't help since that value is still set locally).

I manually fixed HotCat on the 30 wikis listed in P2167 (2 were duplicates). In the process, I also fixed some other JS errors from default gadgets that were preventing other gadgets from loading (typically due to scope issues introduced by ResourceLoader).

There are probably still wikis where HotCat is broken simply due to ResourceLoader not being used in the gadget definition, but those will be much easier to fix. I'll create a new task for identifying those.