Send email in correct language

Noticed the same thing, diff with fixed that worked for me.

Hi @iamcarrico :)

I'm not sure this will work properly if locale is disabled, and it expects to get LANGUAGE_NONE.
Can you please confirm it's working fine also without locale module?

The problem still exists and is still major. We're sending the mails via rules. Is there a way to set the language to the user language via rules? Or is it determined automatically from the user object assigned to the entity?

This is really major. Let's get this fixed ASAP. :)

I am in front of the same problem. My site spits out the localized version based on subdomains with a fallback on the browser language. So when an admin makes an action which triggers message notify the admins current language will be used to generate language. To use the users language i would have to save the last language selection the user made, load this information in rules and then pass the setting to the message notiy rules action.

A general solution could be to let the admin define in rules where to pull the language. Possible options are:

• manual static selection
• grap a field / variable from rules
• current users language who is running the action

I made a custom cron task in which I'm creating and sending messages to certain users, which all have different default languages.

Setting $message->language to the value of the user is working using the above patch. But as amitaibu mentioned it should be tested on a site where locale is disabled.

I'll try to test it and post back. Otherwise a small check would be needed before the buildContent().

Hi boshtian,

Do you set the $message->language through Rules?
When I try that, I'm getting the error "The selected data property doesn't support writing."

OK,

I have also found this issue about the same problem:
https://www.drupal.org/node/2278831

I have added the same php-code to my Rule where I use message notify as fugazi wrote and it works for me, without the patch from #1

$account = user_load($commerce_order->uid);
$languages = language_list();
global $language;
if ($language->language != $account->language) {
  $language = $languages[$account->language];
}

@maxplus: Thanks a lot for your feedback in #7.
Anyway it should work without that quickfix of course. So a correction / patch is still required and the issue is still major. I think your comment will help to fix the deeper reason also.

Inspired by the core rule "Send mail" action this patch adds a language setting to the "Send Message with Message notify" action. With this one can select a language directly from a dropdown or use a selector widget to determine the language dynamically (e.g. site:current-page:language).

If locale is disabled it falls back to LANGUAGE_NONE.

If the message type does not have the subject and body translated to the selected language, the message will be sent in a random language. I think that's ok, the rule should take care of this by selecting the correct language.

@czigor, thank you very much. It think the patch is good. Lets have some more reviewers.

You're writing "random language". I think the right behaviour would be to use the site default language instead?

Under "random language" I meant that it chooses one of the translations and I don't know which one. (I think it's the last language that we have translation for but I'm not sure.)

The translation in the site default language is not guaranteed to exist either, but it might be a better fallback, yes.

Great,

for me patch #9 works .

Why Do you not update the module "Message notify" ? The project is stopped at 2013-Apr-22 .

Patch #9 works for me except any tokenized urls will still be in the current language instead of the selected language for the message. I'm thinking that maybe it will be necessary to temporarily change the global language while building the message.

Here's a patch that improves #9 to also provide the correct language for any links in the message.

+++ b/plugins/notifier/abstract.inc
@@ -71,12 +71,30 @@ abstract class MessageNotifierBase implements MessageNotifierInterface {
+    $language_original = $language;

Isn't changing the global $language a bit of a dangerous something.
Knowing that the $message object is an object of type Entity. Isn't it possible to set the $language for that object instead?

a slightly different patch works for me with an additional change to the notify module. no side-effect yet..

Same approach as #18, but restores $language_original after calling $this->deliver(). This allows template wrappers calling to t() function to render mails in correct language (for example when you use mimemail with mimemail-message.tpl.php)

Additionally passed the language to $message->buildContent() and re-initialized the variables since they might have different values in the different language.