Multilingual support : Simplenews does not send the right translation (it only send the original language newsletter)

What are you using the create the translations? The core translation module or entity translation?

Are you sure that your subscribers have the language assigned?

This should be working and we actually have tests that cover this...

I was using Simplenews on a Drupal 6 system which was recently updated to Drupal 7. Since I hacked the 6.x version of Simplenews to allow anonymous users to subscribe for any language (disregarding the language the current page was shown in), I was happy to have the language choice within Simplenews itself now.

But I am facing the same problem as described above. The website has two languages enabled (English [default], German). Newsletter is set up and translated into both languages (node/1 for English, node/2 for German). Upon sending the newsletter, each subscriber receives the English version, only, despite their choice.

I tried to debug the module and found that in line 396 of simplenews.source.inc translation_node_get_translations($tnid) returns an empty array. Further digging revealed that line 467 in translation.module was responsible. There, an access check is added to the query that retrieves the translations of the translation set.

However, the newsletter is still unpublished thus anonymous user is not allowed to view it. While testing a newsletter, I want the newsletter to be and stay unpublished until I am satisfied with the result. Therefore, Simplenews should use another method to retrieve the nodes of a translation set.

I also facing the same problem with the latest Drupal core 7.19 & the latest simplenews version.

I have the same problem. I tested and this only occurs when I send simplenews with cron.
If we send it manually (push button and send all newsletters at once) it works ok.
But in my case this is not an option because I'm limited by the host on the number of emails to send in an hour.

Here is the patch that should fix it, please review.
It works just fine for me, I am using Entity Translation to translate nodes.

+++ b/includes/simplenews.admin.incundefined
@@ -1950,7 +1950,8 @@ function simplenews_node_tab_send_form_validate($form, &$form_state) {
-  $mails = array($default_address);
+  // There could be a couple of mails.
+  $mails = explode(',', $default_address);

This is unrelated. Please add a separate issue AND add test coverage!

Rest of the code seems fine. Also we need test coverage here.

@miro_dietiker Exploding $default_address is related to this issue, because otherwise it prevents sending translated mails to test emails. Reproducing is simple: create 2 subscribers with different language preferences and add both to the test list.
Test-coverage is definitely must-have, I agree. Changing to 'needs work' - until I (or somebody else) create tests for it.

Strange, it doesn't work for me completely. Subject gets translated, as well as additional texts like the test message at the bottom of the mail but not the body itself. Entity, properly translated otherwise. The $language variable in the template always shows the original language.

I'll report back with the solution, hopefully soon.

Here it is. A slight change In build(), too (around line 655):

global $language;
$build = node_view($this->node, 'email_' . $format, $language->language);

Could you add this to the patch and re-test again?

Not to steal anyone's thunder, but since I used the excellent work of Staratel and djg_tram, I thought I would attach the patch I have which contains both of their contributions.

Resubmitting patch for testing

oops. missed one long path. Should be fine now.

Ok this one takes care of the exceptions throwing in the last test. Sorry for the spam.

I fail to see how this would fix the bug, language should already default to global $language, why do we have to provide it explicitly?

We need test coverage for this somehow...

It seems to me that it defaults to the language of the request (practically, the site), not the user we actually send the mail to.

I tried this and it seems to work well. I was having issues also related to it not sending properly based on current language.

#21 works for me to.

In my case the title was send in the right language, but the body field wasn't translated. It doesn't make sense to me because both of those (in my case fields) are translated with entity translation. (Title field transformed to a field with title module)

Yes for me it was defaulting to the site rather then the specific user.

I found one issue with this patch though. Any t() wrapped variables are not translated properly in the tpl files. I'm noticing that when sending test messages but sending the test messages to specific users that exist with different languages.

Is anyone else experiencing that?

Could you try the patch with both the Echo module and caching disabled? Echo doesn't support a language parameter yet (you can help out by reviewing #1377632: Add language parameter), so the parts surrounding the content aren't translated.

The patch still applies to 7.x-1.1

However wouldn't it be prettier to set a language property instead of repeatedly calling the global?
Also in the setContext() method the global is called in a different format $language = $GLOBALS['language']; instead of global $language;
I think we should at least use one format within the code of this module.

Finally, I'd like to point out that there is no use case that I can think of right now, which includes mixed languages in a localised newsletter. Hence, the different language properties could be combined. There is the node language, the subscriber language and the global language. Perhaps the getLanguage() method could be used to set the language once within the object. Would be a nice and clean solution for generic language definition within the newsletter.

Typo

patch #21 works for me with 1.1 and Entity Translation

My issue was identical to #25

Using entity_translation only

• Title field was sent in the correct language translation
• Body field was sent in the default language only

Applying patch #21 resolve the issue

Thank you very much

Re-rolling patch #21, moving global into start of function.

This really needs to go in.

Proper remake of #21, with both files. Please ignore the previous file.

#37 works OK, but the title doesn't get translated above the newsletter's body when using title + entity_translation (it's always using the current language when the newsletter was sent).

This new patch works for me with these modules.. perhaps we should add a check to see if title module is enabled or not.

Is there a more standard way of getting the translated title from the node stdObject?

Any patch work for my EN/FR content issue.
I apply this patch for correction

Based on #43, this new patch supports for user's language preferences

Same issue as #25 on Version 7.x-1.1
The patch does not fix this for me.
Any update on this?

This issue keeps coming up for my clients. As described in #5 almost five years ago, this is due to access restrictions to unpublished content. Thus, as long as the newsletter node and its translations are unpublished (which they should be until they are tested and final), the anonymous user (who is used for retrieving/sending the newsletter) does not have access to the unpublished translation.

I created a new newsletter (English), translated it into German and kept both unpublished. I made sure, two subscribers exist, one for English and one for German. When sending a test newsletter two both of them, the following error message is thrown:

Notice: Undefined index: de in SimplenewsSourceNode->setNode() (line 409 of /sites/all/modules/simplenews/includes/simplenews.source.inc).

Despite that, both subscribers receive the English version.

Problem is still the same. Simplenews uses translation_node_get_translations() from translation module, which in turn applies the node_access tag to its database query. Thus, since the anonymous user is used for sending the newsletter, the function does not return the available translations. For the test newsletter, the switch to the anonymous user happens in simplenews.mail.inc in line 103:

$GLOBALS['user'] = drupal_anonymous_user();

As a quick hack, I just commented that line and everything works as expected. I am aware, that this can't be the fix to this issue, as it might have implications on other stuff. But for my clients it's sure enough a simple way to test multilingual newsletters. Also, this hack does not affect the switch to the anonymous user when sending the real newsletter as there is a separate function for that (simplenews_impersonate_user()).

I am also having with the latest version of Simplenews on Drupal 8.3.1. The newsletter is not published and I test to send it out to two different subscribers with two different preferred languages. But it only sends the English one. Any solutions for this issue? Thanks.

Paul Broon: It looks like the issue you describe is a node_access related issue, not a translation one. Since the anonymous user cannot access your content, you cannot send it as anonymous. One solution can be publish all newsletter nodes and use another way to block access to them. For example rabithole module, or another node access related module.

Hey akalam, you are right, the anonymous is not allowed to see unpublished content. That's the main cause of the problem. But even if the original language is still unpublished, it is sent out. The fault is in switching to the anonymous user _before_ retrieving the translations (see my dirty hack solution in #46 which demonstrates that it is technically possible to get it done). Since the user who is triggering the newsletter test is not anonymous, there must be a way to get the still unpublished translations (again, see the dirty workaround).

Thanks @jcnventura, patch in #37 worked for me to get the interface translated (blocks that were in Panelizer).

For content, with Entity Translation 7.x-1.0-beta7, I used https://www.drupal.org/project/simplenews/issues/2567145#comment-10320075. Using Drupal core 7.56, Mail System 7.x-2.34+5-dev, Mime Mail 7.x-1.0 and Simplenews 7.x-1.x-dev

I render nodes with Panelizer 7.x-3.4

@Paul Broon I tested what you say for unpublished newsletter nodes and anonymous users when you send a test newsletter and I didn't have a problem. Maybe because I use Panelizer ...