Agree with just about everything said and surprised there isn't a task for it already.

Some of this has been discussed before but we're lacking in developers with the experience to do it.

This is was talked about on Discord. Thank you for creating the task! I will work on this when I return to Miraheze full time.

Now that I have CreateWiki and ManageWiki working on my local MediaWiki install, I will attempt to start working on some of these changes when I get the chance.

Split the long extension list into multiple categories, so that similar functionality is grouped together (kind of akin to what Special:SpecialPages does). While it might be possible to get this from extension.json, this might end up with too many groups. We may want to choose a smaller group to be manually determined, like "User rights and moderation" "Wikicode functions" (parser functions), "Appearance", "Editing", Special Pages", "Other". The categories might be grouped into tabs or with ordinary headers; I'm fairly agnostic on this point.

Already supported, just needs mw-config change for that. You just need to add the 'section' => 'section' key => value to ManageWikiExtensions.php.

Next to each extension, load descriptionmsg from extension.json (or the translation files). The intent here is likely to be able to read what is not applicable before reading every page on Wikimedia.

$extensions = ExtensionRegistry::getInstance()->getAllThings();
$descriptionmsg = $extensions['ExtensionName']['descriptionmsg'];
$description = wfMessage( $descriptionmsg )->parse();

Should work for this (provided that the extension or skin is loaded with ExtensionRegistry (extension/skin.json))

I have a couple additional plans for this though.

In T7125#141452, @Universal_Omega wrote:

Split the long extension list into multiple categories, so that similar functionality is grouped together (kind of akin to what Special:SpecialPages does). While it might be possible to get this from extension.json, this might end up with too many groups. We may want to choose a smaller group to be manually determined, like "User rights and moderation" "Wikicode functions" (parser functions), "Appearance", "Editing", Special Pages", "Other". The categories might be grouped into tabs or with ordinary headers; I'm fairly agnostic on this point.

Already supported, just needs mw-config change for that. You just need to add the 'section' => 'section' key => value to ManageWikiExtensions.php.

Added in this pull request. Currently this just uses the type value from extension.json, but we may want to consider changing these categories to be more useful and balanced in the future.

https://github.com/miraheze/mw-config/pull/3830/ reorders the sections created by @Joritochip (thanks for that by the way)

In T7125#141481, @Universal_Omega wrote:

https://github.com/miraheze/mw-config/pull/3830/ reorders the sections created by @Joritochip (thanks for that by the way)

Note that some extensions define custom types (see Wikibase, for example). I suggest adding those sections. There should be a way to automatically detect this (not very important but would be good).

I'd like to suggest the addition of a search tab to it and an 'All' tab that is just like the previous versions.

https://github.com/miraheze/ManageWiki/pull/278 will support pulling descriptionmsg, namemsg, description, and name to use as the description and name within ManageWikiExtensions. It requires that the name set in ManageWikiExtensions.php is the same as the name in extension.json or $wgExtensionCredits so it also introduces new optional parameters for ManageWikiExtensions:

• displayname: allows for a plain text or localised message key display name for use in ManageWikiExtensions.
• description: allows for a plain text or localised message key description for use in ManageWikiExtensions.

https://github.com/miraheze/mw-config/pull/3990 updates ManageWikiExtensions.php for this usage.

The "improvement" in #1 has actually made my life harder and I am pretty sure many others feel the same way. The types defined in extension registry are not useful at all to the end user; they make navigating ManageWiki harder. I suggest adding custom sections.

In T7125#153783, @R4356th wrote:

The "improvement" in #1 has actually made my life harder and I am pretty sure many others feel the same way. The types defined in extension registry are not useful at all to the end user; they make navigating ManageWiki harder. I suggest adding custom sections.

I actually agree. I'm going to redefine #1 and make it a preference likely or completely revert the change. Or do something else as it makes it much harder I think.

I think instead of having tabs on the form, we should have a filter that simply updates the visibility of the different items (I think we do something similar with the yearly Survey, where checking a checkbox makes more questions visible). This way we could default the page to showing all items, but also easily filter it down to categories. Additionally, depending on how it's implemented, it could display multiple categories at once, and the same item could be in multiple categories.

Descriptions are now displayed.

The third part of this should be done with https://github.com/miraheze/ManageWiki/pull/281.

In T7125#153926, @Void wrote:

I think instead of having tabs on the form, we should have a filter that simply updates the visibility of the different items (I think we do something similar with the yearly Survey, where checking a checkbox makes more questions visible). This way we could default the page to showing all items, but also easily filter it down to categories. Additionally, depending on how it's implemented, it could display multiple categories at once, and the same item could be in multiple categories.

should be nice, and actually may work better with a search instead of tabs. However the list will have to be vertical because of the many categories (assuming an extension can fall in at least 2 different categories).

The third of this is currently blocked on community input. See https://meta.miraheze.org/wiki/Community_noticeboard#ManageWiki_UX_Change_(SRE_Request_for_Community_Input)

The PR to change the way the submit is done, does many other improvements as well. I explained that on https://github.com/miraheze/ManageWiki/pull/281#issue-692147089.

Part 3 now deployed.

Thanks! Great work.