Topic on Manual talk:Extension registration

still necessary as long as extension-list references PHP entry point rather than JSON file; once JSON file is used, PHP entry point can be removed completely

The Migration for extension developers section has some boilerplate with a mostly empty PHP entry point, but keep[ing] i18n globals so mergeMessageFileList.php doesn't break. Plenty of extensions follow this approach, but as far as I can tell, by this point that’s just cargo culting: Legoktm added support for extension/skin.json files to that maintenance script four years ago. Can someone confirm that this understanding is correct, and I don’t need to bother keeping i18n globals when porting extensions to extension registration nowadays?

You still need to add them. mergeMessageFileList works on a hardcoded extension list (example), and until that is updated to point to extension.json instead of the PHP entry point, the i18n globals need to be kept since the point of the shim is to be a drop-in replacement with no config changes needed.

Okay, but if I understand correctly it doesn’t need to be kept indefinitely? It looks like the workflow could be: convert to extension.json but keep shim in PHP entry point, update extension-list to point to extension.json, remove shim from PHP entry point (or even completely remove PHP entry point).

Correct.

We currently load eight repos via their PHP file (CirrusSearch, Collection, FlaggedRevs, LdapAuthentication, OpenStackManager, Translate, and Wikibase & WikibaseClient).

Most of the extensions in production don't have the backwards-compatibility shim any more (e.g. CodeEditor), or never did (e.g. 3D).