TYPO3 Core

Example:
A form with two E-Mail finishers is configured, the first of which has options.translation.language set to Standard, like this:

finishers:
  -
    options:
      subject: 'New request'
      recipients:
        'some.receiver@company.com': Company
      senderAddress: noreply@company.com
      senderName: Company
      addHtmlPart: true
      attachUploads: false
      useFluidEmail: true
      translation:
        language: Standard
    identifier: EmailToReceiver
  -
    options:
      subject: 'Your request'
      recipients:
        '{email}': '{firstName} {lastName}'
      senderAddress: noreply@company.com
      senderName: Company
      addHtmlPart: true
      attachUploads: false
      useFluidEmail: true
    identifier: EmailToSender

Furthermore the following german label is configured, which should override the subject of the second finisher when the form was submitted on a german page:

<trans-unit id="finisher.EmailToSender.subject">
    <source>Your request</source>
    <target>Ihre Anfrage</target>
</trans-unit>

When submitting the form on a german page however, the subject remains in the default language. If the first finisher is removed (or if options.translation.language is removed from its configuration) it is properly translated into german.

The issue:
In \TYPO3\CMS\Form\Domain\Finishers\EmailFinisher the service \TYPO3\CMS\Form\Service\TranslationService is used, which is a SingletonInterface (and this might also affect other finishers using the TranslationService). The EmailFinisher memorizes the initial language like this:

$translationService = GeneralUtility::makeInstance(TranslationService::class);
if (is_string($this->options['translation']['language'] ?? null) && $this->options['translation']['language'] !== '') {
    $languageBackup = $translationService->getLanguage();
    $translationService->setLanguage($this->options['translation']['language']);
}

and later restores it like this:

if (!empty($languageBackup)) {
    $translationService->setLanguage($languageBackup);
}

However the memorization happens after many calls of $this->parseOption(), which internally eventually calls TranslationService::translate() passing along the language configured in options.translation.language. In TranslationService::translate() the services languageKey is updated to this language:

if ($language) {
    $this->languageKey = $language;
}

Therefore, when memorizing the initial language of the TranslationService, it's already set to another language, which also means that the restoration of the initial language does not work. And since TranslationService is a Singleton, the now incorrect language remains throughout following finishers.

Possible solutions:
1. move the initial language memorization in front of the parseOption()-calls
2. Don't update $this->languageKey in TranslationService::translate(). Use $language for this specific call of translate() and fall back to $this->languageKey if $language is null. Calling translate() with a different language than the one currently set as default in the TranslationService does not imply to me, that the services default language will be changed in the process.

Additional information:
This might also be the case in TYPO3 12.
This applies across all valid php versions.