Send mail in correct language not working

Hello, same for me... the message module doesn't send message into the prefered language of the user...
patches are no more insync with the dev... and I am not sure they will work.

I have made another patch not based on the OP.
It is involving a patch in the message module and a patch in the message_subscribe module.

More than getting the message translated into the preferred language of the user, the patch is doing 2 other things:

1-I have changed the way a message is handled when there is no translation available for this message.

Before: empty message is sent ????
Now: message in default language is sent

2-I have added an option shared by all the notifiers: $option['language override']
If set, the message will be sent in the default language regardless of the user.
Note that this option was existing but with this shape: $option[$notifier_name]['language override']
As explained in the code (see patch) I don't think its a good idea... I didn't change anything about this, but maybe, we could copy the main setting $option['language override'] into each notifier...

VERY IMPORTANT

You could have some troubles if you translate a message using the built-in UI : /admin/structure/message/manage/TEMPLATE_ID/translate/LANGCODE/edit

This is because this UI doesn't store the text_format in the config like the module would like to get it....
More specifically, the 'format' column will not exists after a save from the built-in UI

I don't have a problem with that because, in my use case, I translate the messages in a custom form and I am saving correctly the 'format' information.

As a quick fix, you can hook something like this:

function txs8_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  if ($form_id == 'config_translation_edit_form') {
    $msg_template_id = FALSE;
    foreach (array_keys($form['config_names']) as $key) {
      if (0 === stripos($key, 'message.template')) {
        $msg_template_id = $key;
        break;
      }
    }
    if ($msg_template_id) {
      // 1- you may want to transform the textarea into text_format with the needed filter
      // 2- you can add a submit which will fix the missing 'format' column (eg: re-saving config)
    }
  }
}

patch #3 was missing few bits of code...
here is the corrected version.

Don't forget to use also the 2nd patch for the message module (see #3)

#4 was good, but it include also #3101137: Using hook_message_subscribe_get_subscribers() or hook__message_subscribe_get_subscribers_alter() creates endless loop which is not a good idea.
Here is a version specific for this issue.

Patch #5 for message_subscribe and patch #3 for message did appear to largely work in my case. However I noticed that the subject text is completely removed if there isn't a translation for it. And it seems we can't provide a translation currently as the subject is not exported as part of the translated config. So I have added an additional check to #3 that puts any untranslated fields back into the final text array.

A couple things re: this thread:

Yes, using language seems to be broken for message notify.

I am not sure what the patches related to message subscribe are as that module is not part of sending email. There may be issues in what Message Subscribe does but those should be posted against that module (and that code would need ot be cleaned up before it would ever be committed to that module).

I am using message notify to programmatically send email (nothing to do with Message Subscribe). I see that there is already a method on the message object called setLanguauge(). I also see that one of the patches supplied by the OP:

$build = $view_builder->view($this->message, $view_mode, $this->message->language()->getId());

if i hard code in a language id there it does do the right thing. So these 2 combined seemed like they should do the right thing; but sadly, setting the message language is not retrievable with $this->message->language().

The other part of the OP's patch looks to be related to how the language is determined. Not sure I want that as i need to set the language in the code where i set up my message object. Ass my mail is all sent to user's on the site - i would use their preferred language as the language to send the email in. This is all easy in my code and using the $message->setLanguage() method - it just doesn't get used in the
MessageNotifierBase class. Looking into it.

I've added a new getLanguage() method to the $message object which simply returns the language code set with setLanguage(). I was originally going with $language being a language object as the OP's patch had language()->getId() but that didnt match with the $language property already defined in the Message object as being a string.

Also, when i was passing around the full language object, even though i was now getting the correct translation of the template; the node link that i had as a token in my tpl was still coming out in EN. Once i changed everything to pass around just the language code - everything worked.

I'll post a patch tomorrow.

Patch for Message and Message Notify as per #8.

is this still broken in 9?! Seems like

$mailManager = \Drupal::service('plugin.manager.mail');
$result = $mailManager->mail($module, $key, $to, $langcode, $params, NULL, $mode);

ignores $langcode...

I tested proper_language-2965975-9.patch and it worked for me. However, the related patch to the message module, allow_using_message_language-2965975-9.patch, did not apply. There is a feature request on the message module (https://www.drupal.org/i/3157375) that provides the getLanguage() method and updates MessageInterface. If this patch is also applied then the issue is resolved. In order for this issue to move forward the feature request on the message module will need to be integrated and this module will need to update the minimum version required of message module.

I re-rested the patch (taking care to have a different interface language then that of the intended language of the message), and the patch did not resolve the issue. I will create a separate issue (and likely with an MR) in the message module as I have isolated the problem there.

The fix referenced in comment #7 in issue #3307555 (https://www.drupal.org/i/3307555) of the message module, resolved this issue for our project.