I have a site in two languages, Macedonian (as default) and English, but the confirmation emails are always sent in Macedonian.

Steps: a user comes to the English version of the site (http://mydomain.mk/en), submits his address in the simplenews box (which is also on English) and receives the following email:

[...]
За да потврдите дека сакате да бидете додадени на оваа листа, едноставно кликнете на линкот за потврда на крајот од овој е-мејл. http://mydomain.mk/en/newsletter/confirm/add/85b37d443719t1

After clicking the link, the pages are also on English. The same thing happens for both subscribe and unsubscribe.

(the bug was also present in the beta1 version)

CommentFileSizeAuthor
#29 simplenews_292634_tt_3.patch8.15 KBsutharsan
#27 simplenews_292634_tt_2.patch8.06 KBsutharsan
#26 simplenews_292634_tt_1.patch12.96 KBsutharsan
#20 simplenews_292634_tt.patch4.45 KBmiro_dietiker
#11 simplenews.292634b.patch698 bytessutharsan
#10 simplenews.292634a.patch461 bytesmiopa
#4 simplenews.292634.patch1.78 KBsutharsan

Comments

miopa’s picture

miopa commented

I just want to add that I tried applying the simplenews.anon_lang.patch (http://drupal.org/node/285719) and it made no difference. 'en' is added in the language column in the simplenews_subscriptions table for the submitted address, but the confirmation email is still on the default language.

sutharsan’s picture

sutharsan commented
Assigned: Unassigned » sutharsan

A lot of bug depend on users to report them. Especially multilingual issues since most of the sites are single language.

sutharsan’s picture

sutharsan commented

Please use the latest 6.x-1.x-dev version. Important changes have been made on the multilingual support.

sutharsan’s picture

sutharsan commented
Assigned: sutharsan » Unassigned
Status: Active » Fixed
StatusFileSize
new simplenews.292634.patch1.78 KB

Thanks for reporting. The issue is now fixed.
Use the attached patch or wait for the next nightly build of the 6.x-1.x-dev version.

miopa’s picture

miopa commented

I've applied the patch, but now the confirmation emails are always sent on English.

[...]
To confirm this subscription please use the link below.
http://mydomain.mk/mk/newsletter/confirm/add/85b37d443722t1

(in the simplenews_subscriptions table the correct 'mk' value is stored)

Anyway, I'll try the nightly build before changing the status to active.

sutharsan’s picture

sutharsan commented

The patch should be applied to the 6.x-1.x-dev.
The fact that the has the right language in the simplenews_subscriptions table was very useful info! The (un)subscription message should match this language.

How it should work:
Users with an account are subscribed with their preferred language as set in their account page.
Anonymous users are subscribed with the language of the subscription page.
The confirmation messages are in the subscription language.

miopa’s picture

miopa commented
Version: 6.x-1.0-beta3 » 6.x-1.x-dev
Status: Fixed » Active

I have tried the nightly from 08/08/2008, it's NOT ok (see #5).

In addition, it's displaying

Fatal error: Call to undefined function _trigger_get_hook_aids() in /home/[...]/sites/all/modules/simplenews/simplenews.module on line 1721

after clicking (un)subscribe on the confirmation page.

sutharsan’s picture

sutharsan commented
Status: Active » Postponed (maintainer needs more info)

The error is probably due to the trigger module not being enabled. Please check the status of this module.
If you have not enabled trigger module, this is caused by a missing dependency in a the BETA3. See #273218: Second block submits to first block
Please enable the trigger module and the error is gone.

Please give me all details of your multilingual setup (in addition to what you initially described). I need this to reproduce the error.

miopa’s picture

miopa commented

What a mess. I've spend few hours sorting it out, I'm finding it difficult even to describe it :)

The bottom line is this: variables!

There are 5 variables specific to subscription emails:

'simplenews_confirm_unsubscribe_unsubscribed'
'simplenews_confirm_subscribe_subject'
'simplenews_confirm_subscribe_unsubscribed'
'simplenews_confirm_subscribe_subscribed'
'simplenews_confirm_unsubscribe_subscribed'

in which the text displayed in the emails is stored. When the variables don't exist in the variable table, the emails are sent with the default translation of the string.

So, your patch didn't cause all emails to be sent on English, it was just a coincidence with me saving the settings in the Newsletter subscription configuration page (/en/admin/settings/simplenews/subscription) and thus creating the variables in the table - with their value on English.

If I had saved the configuration from /mk/admin/settings/simplenews/subscription, the variables would have been created on Macedonian (I've tried this latter).

I should note that I didn't fill in the forms in that configuration page at any moment, i did the translation through the translate interface and was a bit surprised when i saw translated strings in the forms (when I eventually discovered that they exist, buried in two hidden divs at the bottom - nice that this is reorganized in the dev version).

==========
My current setup: I have Drupal 6.3, Macedonian as default, English as second language. I have also installed i18n (6.x-1.0-beta3) but I think it plays no role here.

Multilingual settings:
Content selection mode: Only current language and no language
Language negotiation: Path prefix with language fallback.

miopa’s picture

miopa commented
StatusFileSize
new simplenews.292634a.patch461 bytes

This solution works for me, now when i have the variables stored in the table.

sutharsan’s picture

sutharsan commented
Status: Postponed (maintainer needs more info) » Fixed
StatusFileSize
new simplenews.292634b.patch698 bytes

miopa, good work!
I've added a touch of paint so the function can also be used when the current page does not match the preferred language.
The attached patch is committed. Thanks.

miopa’s picture

miopa commented

Yep, this works fine.

But please note that the variables must be created in English in order for this to work properly, and they can easily be created with the other translation (see #9).

sutharsan’s picture

sutharsan commented

I will concider to add a note to admin the form.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

vendeka’s picture

vendeka commented
Priority: Normal » Minor
Status: Closed (fixed) » Needs work

I believe you should add a note to admin form in order to support multilingual subscription emails (as mentioned in #9 post)

heine’s picture

heine commented

When an admin visits the confirmation settings page in a non-english language, the translations would be shown in the textareas and, if saved, overwrite the correct english strings.

sutharsan’s picture

sutharsan commented

Heine, you are right (of course ;) ). But I see no easy solution for this. On a Macedonian, single language site it is intuitive to enter the messages in Macedonian. On a multilingual, Macedonian and English, site the admin can only enter the text in one language. currently _simplenews_subscription_confirmation_text() and the admin page do not support this. For a start I revert #11 but we need other solutions in place.

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented

Sutharsan
We ran into this issue on our multilanguage site.
Indeed the current solution in 6.x-2.x is also insufficient.
As soon as admins override the text even translation with t() gets inactive.

If you like to have best multilanguage support you need to add tt() from i18n string translation.

To show you a simple fix that introduced translation for other module xxxx see:
You can still allow variable overrides when using tt(). But it's indeed wrong to pass some editable text to t().

More about tt()
http://groups.drupal.org/node/15177

#299416: translations support
With patches like:
#27
http://drupal.org/files/issues/299416.patch

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented
Version: 6.x-1.x-dev » 6.x-2.x-dev
Priority: Minor » Critical

Moving to 6.x-2.x-dev since this will be a new working feature once added.

Priority critical since current situation is not sufficient for multilanguage mail communication. At least normal is adequate. We should fix this ASAP from my side in 2.x-dev.

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented
Status: Needs work » Needs review
StatusFileSize
new simplenews_292634_tt.patch4.45 KB

Did some work on this to allow simplenews to translate these mails.

Attached patch will allow overrides in admin and also translation using translate interface.
Editing the defaults will only apply in default language / fallback. No translations will happen on the settings page.

t() completely removed from mail variables, which might be done for other configurable and translateable fields too? It will gracefully degrade without i18nstrings.

We're going to run this in production live and hope this will fix it sustainable.

hs@henrikstrindberg.se’s picture

hs@henrikstrindberg.se commented

Great that you are working in this! Been struggling with this problem on a new Swedish/English site:

Even if the text strings are correctly translated from English to Swedish, the links in the confirmation emails take the subscriber to an English page.

Thanks

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented

Well if the link is wrong this might be some additional problem (and there are further issues about this). let's face it step by step.

sutharsan’s picture

sutharsan commented
Priority: Critical » Normal
Status: Needs review » Needs work

Thanks for the patch. I think the approach in using the tt() function is Ok. But I have no experience in using hook_locale().
Is it required to implement 'refresh' in simplenews_locale()?

From a users perspective Multi lingual sites should use the I18n String translation module, single language sites (English and Non-English) can edit the confirmation emails in the local language. A comment of help text should be added to the admin page to instruct in case of a multilingual site.

Don't use $return as variable name here, us a more descriptive one. $text will do.

Use pwolanin's first suggestion on: http://drupal.org/node/609364

Use comments in the code to explain what happens and why. Expecially if functions are spread out over different parts of the module. Don't use it to convince me as module maintainer or to excuse your self (there is no reason to do so).

Documentation (README.txt) must state that I18n String translation module is required to be able translate the confirmation emails.

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented

Note: We especially need to be sure no translation occurs on the settings form. (which seems to happen accidentally in my code)

tajabosc’s picture

tajabosc commented
Version: 6.x-2.x-dev » 6.x-1.x-dev

Hello, i'm also reporting an issue in confirmation email.

I'm using 6.x-1.x-dev, i have a site in two languages (english and italian). Confirmation email are sent only in english, while footer links and variables like !newsletter_name are correct.

The patches above are already comitted in the latest 6.x-1.x-dev version?
How can i modify italian translation, uploading an updated it.po file or directly trough translate interface link with i18n string translation?

Thanks for support

Daniele

sutharsan’s picture

sutharsan commented
Version: 6.x-1.x-dev » 6.x-2.x-dev
Status: Needs work » Needs review
StatusFileSize
new simplenews_292634_tt_1.patch12.96 KB

The patch in #22 does not work with the latest version of i18n. I needed the code for a new module but ended up rewriting it. The attached patch requires i18n version 6.x-1.3.

sutharsan’s picture

sutharsan commented
StatusFileSize
new simplenews_292634_tt_2.patch8.06 KB

Reverted an unnecessary function name change.

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented

Looks fine, sutharsan.
However i'd recommend to modify

_simplenews_subscription_confirmation_text

Rename the third parameter $refresh=FALSE to a more general purpose/inverse $translate=TRUE

I actually don't know if it's by intention:
i18n clearly specifies default site language as direct output if current language matches. This means - whatever is entered in the admin interface will be output directly in case of user-language=default-language.
With this concept it is a nightmare to switch default language later.
In my opinion this is wrong behaviour and i clearly vote for a switch to enable translation for default language also. As you do - we could then enter everything in a development language (english) in admin interfaces and still have a different default language and correctly translated content.

However you should realize that you're completely against usual rules with this setup. Normally users enter their current default language in the admin fields... (till' it changes ;-) ...)

Sutharsan, it would be a very nice move if we can bring in this concept to i18n. If you look at the issue overthere it is very hard for those i18n guys to understand the need for it.
http://drupal.org/node/676002

sutharsan’s picture

sutharsan commented
StatusFileSize
new simplenews_292634_tt_3.patch8.15 KB

thanks for the information. I did read the comment in the code but I did not find the concept of using the default site language for entering text. The attached patch changes to the i18n intended behavior.

I understand you point and the problem of switching the default language, but I also see the value of the current design.

askibinski’s picture

askibinski commented

Thanks Sutharsan,

I think this patch is commited to version 1.1?
Anyway, just wanted to let you know version 1.1 seems to work with multilanguage sites so far.

sutharsan’s picture

sutharsan commented

No this patch is not committed at all, it still needs review. Please do if you are in the position to do so.

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented

Looks fine to me. However just reviewed code - i didn't test resulting system behaviour till now.

tajabosc’s picture

tajabosc commented

Hi Sutharsan,

I tried your patch at #29 on the 6.x-2.x-dev and latest i18n (6.x-1.4), everything seems to work fine except the tokens like [simplenews-subscribe-url] and so on.

To me these links are always in the default language, while the message strings are instead now translated fine with the "translate interface".

Do you face this issue too?

Regards

Daniele

sutharsan’s picture

sutharsan commented

Tajabosc, please create a different issue for the tokens. The issue is unknown to me.

tajabosc’s picture

tajabosc commented

Ok,

i created a new issue in the main page.

Thanks for support,

Daniele

sutharsan’s picture

sutharsan commented
Status: Needs review » Fixed

Patch committed. Will be available in the next 6.x-2.x-dev release.

sutharsan’s picture

sutharsan commented

@tajabosc: I create #775172: No language prefix in [simplenews-subscribe-url] token for your issue. A patch is included for test.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.