Now if the development made for MediaWiki.org becomes a supported extension that can/should be reusable for other wiki, it's up to Mediawiki.org developers to open-source that development into a deployable module/extension with its own repository (posibly with some more adaptations to work with other wikis, notably by avoiding to use hardcoded references to other contents specific to Mediawiki.org that cannot be tweaked for use on other wikis, such as includion of service URIs, local templates, local user names...).
At that time, you can request an import right for that project, and start importing an XML file (maybe outside the main "MediaWiki" namespace, just like what was done for Miraheze for example in its own namespace for that/those extension(s), or coordinated with other extensions maintained for Mediawiki itself if you really want to keep the generic "MediaWiki" namespace, but probably with prefixes for each message name).
Of course you should then prepare the translations in English (because for now it's impossible to use any other base language for translations; but may be you should allow correcting that English base by allowing translations e.g. in "en-US": when exporting from TWN, you'll detect those suggeted changes/corrections, will review these en-US transltions to fix the "en" base in your project, then reimport them, once curated, into the "en" base; this is a posible solution to avoid havnig many admin requests posted in TWN support pages, or in your project.
Anyway I really suggest that for local development specific to MediaWiki.org, you rename all your needed messages with a common prefix and not just the "MediaWiki:" namespace, which continues to be filled in by supported core messages or extensions/skins messages. So for now they should probably be renamed from "MediaWiki:Tag-*" to "MediaWiki:Wikimedia-Tag-*" (possibly as well with other prefixes or for unprefixed messages) because they are specific to the Wikimedia local instance of the MediaWiki documentation wiki, cleaning up that namespace to avoid collisions with future developments in supported extensions maintained by other teams (including those for use outside Wikimedia: look at what was done for Miraheze or BlueSpice extensions that also use their own prefixes).
Note that even for supported generic extensions for MediaWiki, they all have (or should have already) their own prefix for each translation group. This is needed to help manage the content of that namespace and fix orphaned translations (notably those that are left from old versions that have been replaced over time), without having to make extensive searches and manage new bug requests after their deployments to other wikis.
And anyway, any translation imported from TWN for new messages (or messages whose base English source was updated, except if these updates are fixing minor typos in English and not altering the functionality, excluding for example changes that affect embedded translation variables like "$1", or rename/reorder them for plural/gender support) should first be imported in a test wiki for local curation, and not directly on the production sites. Then Wikimedia Phabricator tasks can be used to validate those curated messages for later deployment on other Wikimedia wikis or to be included in supported projects deployable to other non-WM wikis.
