Dynamic language negotiation by multiple top level domains I am porting www.example.com, the German version is at de.example.com, the French is at fr.example.com and so forth. I could enter these domains in admin/config/regional/language/detection/url but I would like them to be subdomains: if one visits www.example.test then (www,de,fr).example.test should work, and if one visits www.example.local then (www,de,fr).example.local should be the translated domains and so forth. It seems I need to make the results of $config = $this-&gt;config-&gt;get('language.negotiation')-&gt;get('url'); dynamic. I am at a complete loss at how to implement this:


I could write an entirely new plugin based on LanguageNegotiationUrl. If I started with a copy of it, I could drop processInbound and half of getLangcode but the rest would need to stay -- and given how little change needs to happen, that's a lot of code to keep in sync with core.
I could patch LanguageNegotiationUrl factoring out the four $config['domains'] interactions into a method and then extend accordingly. Much less maintenance pain than the previous one but at the same time, it's a core patch. Of course, composer-patch applies them after updates but still, a core patch for this?
I could write a config override which overrides language.negotiation but it seems the overrider doesn't get the data loaded. So I'd need to get the domain map from somewhere else, for example by re-reading it from the config storage. That's really, really wasteful.
I could write a "super saiyan config override" by decorating the config factory service so when the language.negotiation is get() then do something with it, like put the dynamic overrides in setModuleOverride. OK, that's not a lot of code, great, the proxy script will write most of it, even better, but now all config calls are a hair more complex and a hair slower.


Any clean ideas I missed...?
This sounds to me like the perfect use case for environment specific configuration. No runtime changes required. Just like you would swap the email addresses in your environments that are used to send emails and would swap the API keys in dev/test environments, you would swap this configuration there as well. You could use something like https://www.drupal.org/project/config_split for example.