Are you intentionally dropping the extension config loading? If so, the extension parameter on this method no longer serves a purpose. If not, we need to figure out how to approach it. I'm guessing it's probably still needed, but wondering if perhaps Ed's recent refactoring changed something.

I couldn't find any extension that didn't have a single configuration file. If an extension requires localisation in the future, it can figure that out itself!

I thought the way this worked was that it loaded the extension-specific config file, and then replaced the localization placeholders in that file with strings retrieved from the locale file. If we remove the loading of the extension-specific config file, I don't see how we have the framework on which to inject all the translations... but maybe I'm missing some initialization of this.defaultConfig somewhere...

Ah, so as I understand it, each extension has the import for the config.

// extensions/[name]/Extension.ts

import defaultConfig from './config/config.json';

class XyzExtension {
  defaultConfig = defaultConfig;
  // ...
}

The injections happen on line 480 using this.defaultConfig which is cloned and patched from line 489 (I didn't change that part)

Ahh, I see, excellent. No objections from me, then... It's a little confusing that this method now takes an argument that it doesn't use, but maybe it's worth keeping that as a hook for the future. Beyond that, if this solves the problem at hand, I don't object!

(And sorry for my uninformed questions -- the perils of trying to figure out code by looking at GitHub alone is that you don't always get the best insights... :-) ).