Thank you for tagging this task with good first task for Wikimedia newcomers!

Newcomers often may not be aware of things that may seem obvious to seasoned contributors, so please take a moment to reflect on how this task might look to somebody who has never contributed to Wikimedia projects.

A good first task is a self-contained, non-controversial task with a clear approach. It should be well-described with pointers to help a completely new contributor, for example it should clearly point to the codebase URL and provide clear steps to help a contributor get set up for success. We've included some guidelines at https://phabricator.wikimedia.org/tag/good_first_task/ !

Thank you for helping us drive new contributions to our projects <3

Change #1290487 had a related patch set uploaded (by VadymTS1; author: VadymTS1):

[mediawiki/core@master] Consolidate user‑upload aliases in MessagesEn.php

https://gerrit.wikimedia.org/r/1290487

Change #1290487 abandoned by VadymTS1:

[mediawiki/core@master] Consolidate user‑upload aliases in MessagesEn.php

Reason:

Does not skip the change with the deletion of one of the special pages

https://gerrit.wikimedia.org/r/1290487

SpecialAllMyUploads and SpecialMyuploads are functionally distinct in a way the task description doesn't capture: SpecialAllMyUploads.getRedirect() sets $this->mAddedRedirectParams['ilshowall'] = 1, forcing old/superseded file revisions into the redirect to Special:Listfiles/{user}. SpecialMyuploads does not set this, though it lists ilshowall in mAllowedRedirectParams, meaning it can be passed through explicitly. This difference appears load-bearing rather than incidental; see T32607, whose patch introduced the ilshowall-forcing behaviour so old/superseded revisions remain visible in a user's file list.

Based on reading the source, the proposed MessagesEn.php-only patch appears to have two problems:

1. Moving AllMyUploads as a language alias of Myuploads looks like a no-op. AllMyUploads is registered in CORE_LIST in SpecialPageFactory, so getAliasList() registers allmyuploads → AllMyUploads as a protected canonical self-alias in its first pass. The second pass processes MessagesEn.php aliases under an !isset($keepAlias[...]) guard, which silently drops any attempt to repoint an already-canonical alias string. Special:AllMyUploads would continue routing to SpecialAllMyUploads unchanged. MyFiles and Myuploads are already correctly registered and unaffected.

2. Moving AllMyFiles to Myuploads looks like a regression. AllMyFiles is not in CORE_LIST and has no canonical self-alias protection. It currently resolves to SpecialAllMyUploads (and thus forces ilshowall=1) because it is the second element of 'AllMyUploads' => [ 'AllMyUploads', 'AllMyFiles' ] in MessagesEn.php. As a Myuploads alias it would resolve to SpecialMyuploads instead, losing the forced ilshowall=1 default. Special:AllMyFiles would silently stop showing old/superseded file revisions.

If this is right, true consolidation would require deregistering SpecialAllMyUploads from CORE_LIST, folding the ilshowall=1 behaviour into SpecialMyuploads, and updating the alias arrays, a multi-step change touching routing behaviour, not just message aliases. Should this be rescoped to that larger change, or is preserving the "force all revisions by default" distinction the intended outcome? Happy to be corrected; I read the source but haven't tested on a live install.

(Researched with AI assistance.)