Recipient Type Email Field does not work for translated content, always uses original language value.

Thanks, looks great
Can we add to the kernel test here

Thanks, we still need a test here - can you add to the kernel test?

here's a test only patch demonstrating the language issues

Question is, should langcode come from content or recipient's user account?

I think for emails it should come from user profile and for token replacement it should come from content.

Bumping to major as per the duplicate issue.

I have fixed the issues below which was closed because of duplicates, based on #7 patch.

#3017022: Event subscriber should pass the entity lang code into the queue
#3025113: Send emails in the language of the recipient and not in the current UI language

In my patch the mail language is set from current UI language, and the token language is set from updated content.

#12 works nicely for us.
Here's a re-roll for 2.x.

#13 is not applies for 3.x.
I reroll a patch for 3.x.

There was a test in #10 but it looks like we lost that?

There's also a BC break here, so we either need to work out a way to do it in a BC compatible fashion, or we need to make this a V4 only change. Comments below are a possible BC layer approach.

1. +++ b/src/Plugin/QueueWorker/WorkbenchEmailProcessor.php
   @@ -53,13 +53,6 @@ class WorkbenchEmailProcessor extends QueueWorkerBase implements ContainerFactor
   -   * Entity repository service.
   -   *
   -   * @var \Drupal\Core\Entity\EntityRepositoryInterface
   -   */
   -  protected $entityRepository;
   
   @@ -78,8 +71,6 @@ class WorkbenchEmailProcessor extends QueueWorkerBase implements ContainerFactor
   -   * @param \Drupal\Core\Entity\EntityRepositoryInterface $entity_repository
   -   *   Entity repository service.
   
   @@ -87,11 +78,10 @@ class WorkbenchEmailProcessor extends QueueWorkerBase implements ContainerFactor
   -  public function __construct(array $configuration, $plugin_id, $plugin_definition, MailManagerInterface $mail_manager, EntityRepositoryInterface $entity_repository, Token $token, RendererInterface $renderer, EntityTypeManagerInterface $entity_type_manager) {
   +  public function __construct(array $configuration, $plugin_id, $plugin_definition, MailManagerInterface $mail_manager, Token $token, RendererInterface $renderer, EntityTypeManagerInterface $entity_type_manager) {
   ...
   -    $this->entityRepository = $entity_repository;
   
   @@ -106,7 +96,6 @@ class WorkbenchEmailProcessor extends QueueWorkerBase implements ContainerFactor
   -      $container->get('entity.repository'),
   

   I think we can keep the argument but move to named arguments in the factory create method, and then if the argument is set for the entity repository emit a deprecation error.

   Would require bumping min php to 8.0 but I think we're there already for 3.x branch.

2. +++ b/src/Plugin/QueueWorker/WorkbenchEmailProcessor.php
   @@ -120,15 +109,18 @@ class WorkbenchEmailProcessor extends QueueWorkerBase implements ContainerFactor
   +      $revision_id = $data->getRevisionId();
   

   if we add some error checking here for if revision ID is not set and just load up the default revision based off the UUID instead, and emit a deprecation error, we're keeping BC

3. +++ b/src/Plugin/QueueWorker/WorkbenchEmailProcessor.php
   @@ -120,15 +109,18 @@ class WorkbenchEmailProcessor extends QueueWorkerBase implements ContainerFactor
   +      $langcode = $data->getLangcode();
   ...
   +        if ($entity->hasTranslation($langcode)) {
   +          $entity = $entity->getTranslation($langcode);
   

   And same here, if there's no language, we can emit a deprecation error

4. +++ b/src/QueuedEmail.php
   @@ -35,12 +49,16 @@ class QueuedEmail {
   +  public function __construct(TemplateInterface $template, $uuid, $revisionId, $langcode, $to) {
   

   Let's keep the arguments in the same order, and make langcode and revision optional, emitting a deprecation error if they're omitted.

Re-roll. Leaving in NW as per #15.