From the list in the description I wouldn't consider the Special pages element would be fine in the more menu. I don't know which should be the best location for that link if the idea is to remove the current box completely, but it shouldn't be by default in the list of article tools. It's not even related to the current article...

How targeted menu links are built

Looking into how the proposed link definitions are created, there are a number of ways these menu items are inserted into the sidebar in Vector:

• Toolbox links
  • Most of the toolbox links (What links here, Related changes, Special pages, Permanent link, Page information) are built in the Skin class by Skin::buildSidebar().
  • Within this method the toolbox links are created (specifically by Skin::buildNavUrls():

$sidebar['TOOLBOX'] = $this->makeToolbox(
	$this->buildNavUrls(),
	$this->buildFeedUrls()
);

• Hooks
  • Additional links can be inserted by 3rd party extensions using hooks which is how Cite this page and Wikidata item links are appended to the Toolbox list by the CiteThisPage and Wikibase extensions respectively.
  • Cite this page uses the onSidebarBeforeOutput() hook.
  • Wikidata item also uses the onSidebarBeforeOutput() hook.
  • Possible ways to customize menu items appear to be (there could be more I haven't identified):
    • onSidebarBeforeOutput()
    • onSkinBuildSidebar()
    • onSkinAfterPortlet()
    • mw.util.addPortletLink()
• The Edit interlanguage links item is added to the Toolbox list via custom javascript (T287206), specifically by Vector's languageButton.js.
• Download as PDF is added via the onSidebarBeforeOutput() hook by the ElectronPdfService extension.
• Printable version is also created by the Skin class in Skin::buildNavUrls().

Identify which of the above definitions of article tools carries the least risk

I understand "least risk" to mean the easiest, simplest ones to move which are the links generated by code we maintain - i.e. those that are built by Skin::makeToolbox(). These are available to whatever template we specify so What links here, Related changes, Special pages, Permanent link, Page information and Printable version, as well as Edit interlanguage links should be relatively straightforward to output to a different template.

Identify what approach must be taken for moving the article tools to the more menu

In terms of approach, for the links that are built within the Skin classes, it looks like SkinTemplate::getPortletsTemplateData() is where we invoke Skin::buildSidebar() and create the data-portlets-sidebar key of the $data array. For other skins that utilize this sidebar area, presumably we need to keep all this current functionality. For modern Vector, if we simply want to move those menu items to a new location, we could intercept the sidebar data array in SkinVector22::getTemplateData(), manipulate it (do we move everything over? maybe only specified/known menu items should move over?), and re-package the relevant data to a new template partial for the "more" menu.

By the time SkinVector22::getTemplateData() is called, presumably all the backend hooks (a note about the frontend hook in the blockers section below) that can intercede have been run so whatever 3rd parties have injected into the sidebar or the toolbox should be available to SkinVector22.

For Edit interlanguage links in particular, there is a note in the code that the js is a temporary solution until the new ULS is built in Vue. Until then, we can just append the link to the new menu id.

Identify what approach must be taken to make the article tools menu configurable by communities

I'm making the assumption that this means something like https://www.mediawiki.org/wiki/MediaWiki:Sidebar wherein admins can utilize a wiki page to change the article tools menu. I don't know what it takes to build one of these interfaces but presumably it can be done for this use case.

From what I've been able to deduce (h/t to @nray), the sidebar contents are comprised by an i18n message and can be overridden. I do not know if this is the only way to create an editable interface for any given menu. More details TK.

Identify any blockers and dependencies with the above steps

Because the relevant Skin methods and hooks for the targeted links explicitly name "sidebar", it could be confusing/misleading to continue to use these hooks to populate the new "more" menu dropdown. They will continue to be used by legacy Vector and other skins which will want to keep these menu items in their sidebar regions in which case the nomenclature isn't an issue.

For the "more" menu specifically, we may want to create a new hook for this dropdown or group of menu items for 3rd parties to inject links. If we were to do this however, it would be on the 3rd parties to have to keep track of which hooks they use and which menus they want to change. And we would have to decide whether to include the menu items injected by sidebar hooks or limit them to a new hook for this specific menu.

If however this group of menu items are functionally similar enough to live together wherever they are placed, then moving all of them over wholesale (including all 3rd party injected items) seems like an easier lift than having to write logic to separate/sift out what should move over and what should stay in the pin-able sidebar menu.

To address the specific frontend hook mw.util.addPortletLink() -- there are a number of instances in MediaWiki codesearch where extensions are using this hook to inject an item into the toolbox (p-tb) specifically. To move any of these over to the new "more" menu likely requires custom javascript to identify and intercept them. Not necessarily a blocker per se but we would have to address this use case separately from the backend hooks.

There also appears to be a number of menu extensions - https://www.mediawiki.org/wiki/Category:Menu_extensions. I'm not sure how many of them affect the sidebar menu but for those that do, there's a question of how this proposed change will affect the features they purport to enable.

One thing to keep in mind as a backdrop to all this is that we have noted in our Q1/Q2 OKRs to improve the menu architecture. In theory this work will make it much easier and less obtuse to extend menus by 3rd parties and communities. If we were to take on this effort of moving the article tools menu before this menu re-architecture work is complete, it's likely that we will need to refactor whatever short-term solution we put in place shortly thereafter.

Moving to backlog for now, since our focuses are elsewhere. @cjming I'll pick up reviewing this later when it's a priority again.

Just in case, I'll leave it here :) It seems to me that you can use a standard sidebar with additional special words that will transfer blocks from one side to the other.

--LEFT--
* navigation
** mainpage|mainpage-description
** content-url|content
** featured-url|featured
** randompage-url|randompage
** currentevents-url|currentevents
** sitesupport-url|sitesupport

* SEARCH

* participation
** bug_in_article-url|bug_in_article
** introduction-url|introduction
** portal-url|portal
** forum-url|forum
** recentchanges-url|recentchanges
** newpages-url|newpages
** helppage|help

--RIGHT--
* TOOLBOX
* coll-print_export
* Projects

I've split out T318434 on the recommendation that toolbox might be the least risky. Thanks for that assessment! After we've done that we can worry about other menus.

Regarding gadgets:

to address the specific frontend hook mw.util.addPortletLink() -- there are a number of instances in MediaWiki codesearch where extensions are using this hook to inject an item into the toolbox (p-tb) specifically. To move any of these over to the new "more" menu likely requires custom javascript to identify and intercept them. Not necessarily a blocker per se but we would have to address this use case separately from the backend hooks.

This should just work, provided we retain the p-tb element ID in the new sidebar.

Regarding MediaWiki:Sidebar I'm not seeing any blockers here to actually building out this menu. I've made a note to investigate that later: https://phabricator.wikimedia.org/T318435

Thanks for the detailed analysis @cjming I'll let someone else in the team sign this off in case they have any follow up questions.