Current user missing from language negotiator outside of request context

Appears to have a phpstan failure

Line core/tests/Drupal/Tests/Core/PathProcessor/PathProcessorTest.php
------ --------------------------------------------------------------------
140 Class Drupal\language\HttpKernel\PathProcessorLanguage constructor
invoked with 5 parameters, 4 required.
🪪 arguments.count

Not sure a good rule of thumb but do we think these interfaces could be pretty widely uses in translation contrib modules? Only mention if maybe we should wait till 13 to remove.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I left feedback in MR comments. Mostly, your change record URLs resulted in 404 pages. So I'm setting the issue to Needs Work for that. There's also a note about future-proofing the new test.

I rebased the MR because there were some weird test failures. Rebasing fixed them and everything is passing now.

I re-read all of the changes and change records. I don't have any additional feedback. So I'm going to set this to RTBC.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Post-bot-rebellion rebase

I dug through git history to find the source of this. #1862202: Objectify the language system added this code, where initially both the current request and the the current user were injected by LanguageRequestSubscriber. This was picked up in review, but the answer was "If we want to support lazy language negotiation, I cannot see an alternative to storing those into the negotiator" - but still not sure why it wasn't injected directly. Request was later removed with no issues when the request object was removed from the container - the request stack was available but it wasn't required.

However, while we are here, shouldn't we also remove LanguageNegotiatorInterface::setCurrentUser() and deprecate any implementations?

Probably for a followup but I also wonder why we do this:

  public function getNegotiationMethodInstance($method_id) {
    if (!isset($this->methods[$method_id])) {
      $instance = $this->negotiatorManager->createInstance($method_id, []);
      $instance->setLanguageManager($this->languageManager);
      $instance->setConfig($this->configFactory);
      $instance->setCurrentUser($this->currentUser);
      $this->methods[$method_id] = $instance;
    }
    return $this->methods[$method_id];
  }

Feels like these services should be injectable into the plugins in the normal way too, via create() or autowiring? Most of the plugins don't use all three services.