TYPO3 Core

My hack right now (and that's absolutely nasty!!!):

diff --git a/Classes/EventDispatcher/ListenerProvider.php b/Classes/EventDispatcher/ListenerProvider.php
index 99a48475f..143256f28 100644
--- a/Classes/EventDispatcher/ListenerProvider.php
+++ b/Classes/EventDispatcher/ListenerProvider.php
@@ -41,6 +41,28 @@ class ListenerProvider implements ListenerProviderInterface
     public function __construct(ContainerInterface $container)
     {
         $this->container = $container;
+
+        // --------------------------------------------------
+        // HACK
+        // See: https://forge.typo3.org/issues/50467
+        if ($container instanceof \TYPO3\CMS\Core\DependencyInjection\FailsafeContainer) {
+            $languagePackRemoateBaseUrlModifier = \VENDOR\YourExt\EventListener\InstallServiceEventListener::class;
+            $this->addListener(
+                \TYPO3\CMS\Install\Service\Event\ModifyLanguagePackRemoteBaseUrlEvent::class,
+                $languagePackRemoateBaseUrlModifier,
+                'modifyLanguagePackRemoteBaseUrl'
+            );
+
+            // and, that's absolutely nasty, but to make it work:
+            $reflectionOfContainer = new \ReflectionObject($container);
+            $privateEntries = $reflectionOfContainer->getProperty('entries');
+            $privateEntries->setAccessible(true);
+            $entries = $privateEntries->getValue($container);
+            $entries[$languagePackRemoateBaseUrlModifier] =
+                new $languagePackRemoateBaseUrlModifier();
+            $privateEntries->setValue($container, $entries);
+        }
+        // --------------------------------------------------
     }

     /**

That's not primarly a container thing, but rather a consequence of the context change in https://review.typo3.org/c/Packages/TYPO3.CMS/+/55998/

Are you sure that worked in 9.5?
I guess it was broken in there as well, also v9 style extbase signal handlers wouldn't fire as ext_localconf isn't loaded, right?

Regarding a possible solution:
With the help of (Late)BootService we could load all extensions in install context and therefore get a ListenerProvider from the symfony container.
But that of course means that all extensions will be loaded and the full container bootstraped. So there is little use in working in install tool context at all.
I don't know about the reasons for moving this tool into the installtool in the first place, therefore I'd like to know what Christian Kuhn thinks (as author of the patch linked above).

That worked in v9 since in v9 we had a signal/slot mechanism. I use it actively in v9 without any problem. Just facing this problem in v11 with a new project. The other one in v9 is not yet ready for v10 so did not spot earlier.

We really need to find a solution, at least for this very use case of changing the download URL of the language packs, this is extremely useful in an enterprise context. For other use cases, I know that Christian Kuhn is really unlikely to be fine loading extensions in the Install Tool context but we must address the XLIFF stuff anyway.

@bnf: I remember we killed the slot in v9 when the dusty language pack handling has been moved to install tool where it belongs. IIRC, we re-integrated the same slot or a similar one. So, this broke again with the psr-14 or DI changes.

Benjamin, there are some more places in install tool that bootstrap "full system", right? For instance the upgrade wizards need to do this, and some others, too. We could use the same mechanism to re-enable the listener?

friendly ping :)

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/68754