Removed MediaWiki-extensions-Gadgets from this task as this is unrelated to the code of the MW extension called "Gadgets".

Not sure how this request could/should be implemented though. :(

Implement via MediaWiki core (or skin) and add a new configuration variable?

Could someone maybe explain how bad enabling the JS gadget by default would really be? I've been using it for years and it works flawlessly. Are there any real disadvantages or is it just a matter of bad style? Is it really worth waiting (possibly years) for this to be implemented in MediaWiki, when the problem could be solved by simply flicking a switch?

In T102776#1391918, @El_Grafo wrote:

Could someone maybe explain how bad enabling the JS gadget by default would really be? I've been using it for years and it works flawlessly. Are there any real disadvantages or is it just a matter of bad style? Is it really worth waiting (possibly years) for this to be implemented in MediaWiki, when the problem could be solved by simply flicking a switch?

Jumping content, especially if your browser isn't fast. If you have disabled JS, then it does not work. It also means moor load on resource loader. And it is a ugly hack, locks very unprofessional.

If you like to have this fixed soon you should probably find a volunteer which can provide the code.

So is there any reason not to do this with all files, in all skins? For all wikis?

In T102776#5666096, @Isarra wrote:

So is there any reason not to do this with all files, in all skins? For all wikis?

I don't think there is a reason. It could be made optional so that users would be able to disable it.

This would need to be a skin specific preference as skins decide layout.

Untagging as this is a generic request that should presumably work across skins, not just one skin.

In T102776#7165809, @Jdlrobson wrote:

This would need to be a skin specific preference as skins decide layout.

In T102776#8595699, @Jdlrobson wrote:

Untagging as this is a generic request that should presumably work across skins, not just one skin.

So what is it now, skin-specific or not? There are finally some people working on moving things around a bit in the Mediawiki user interface. Whole menus are being restructured and moved to the right side of the screen. Why not Categories? This is frustrating: we have community consensus for what should be a fairly simple tweak and where ever I go with it all it's just being declared Somebody else's problem.

Presumably any change here needs to move categories on file pages for all skins (mobile, monobook, vector etc..). Is that correct? It so this is a generic skin request. The scope of the desktop improvements tag is only the vector-2022 skin and I presume that wouldn't be sufficient to call this done? It should also only apply to Wikimedia Commons and presumably this must be supported in a responsible way i.e. it shouldn't ever break as skins change (which as you currently point out are changing).

I think to meet the criteria "This needs a integration in MediaWiki to avoid Jumping Content." and to have special behaviour for file pages it becomes trickier. Ideally this requires someone building a new extension, not a "fairly simple tweak" that takes over control of category rendering. I reckon that would take at least a month, maybe 2 months to build and deplooy (building out an extension that rendered categories as part of the subtitle, and then going through the various deployment checks of security review, performance review). This is presumably why this task has been open since 2015: Who is going to build it? Who is going to maintain it? What is the priority of this work relating to items on the community wishlist?

One thing I would personally consider is take MediaWiki software out of the equation and leave this to your local community - make the script a global default as originally planned. To workaround "jumping content" you could allocate some fixed space via CSS using MediaWiki:Common.css and/or MediaWiki:Sitenotice at the top of the page with vertical scroll to accommodate the category box (for example the fixed height might assume 3 lines). That's going to move a lot quicker and hopefully that would provide the impetus to invest the 1 month of work to get this done more formally. It would also assert the validity of the 2015 RFC - I see at least one oppose there, so perhaps as more people experience that change, you may get more discussion and improvements to the solution.

Hope this is helpful.