By issuing Email Address as a default mergevar with fixed name, translation is difficult [#2747027]

Issue #https://www.drupal.org/node/610506 fixes translation. BUT Email Address now always has the name Email Address. So if the default language of a site is not english, translation for that mergefield to the default language is (as far as I can see) impossible.

Comment	File	Size	Author
#12	mailchimp-email-label-2747027.patch	560 bytes	Peter Majmesku
#12	8.x-1.x: PHP 5.5 & MySQL 5.5, D8.4 Skipped, branch did not pass for 4 weeks PHP 5.5 & PostgreSQL 9.1, D8.4 Skipped, branch did not pass for 4 weeks PHP 5.5 & SQLite 3.8, D8.4 Skipped, branch did not pass for 4 weeks PHP 5.6 & MySQL 5.5, D8.4 Skipped, branch did not pass for 4 weeks PHP 7 & MySQL 5.5, D8.4 Skipped, branch did not pass for 4 weeks

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

11 June 2016 at 15:55

daften created an issue. See original summary.

Comment #2

B-Prod CreditAttribution: B-Prod commented 1 July 2016 at 10:46

Any news about this?

Comment #3

B-Prod CreditAttribution: B-Prod commented 1 July 2016 at 11:38

I tried to get the EMAIL merge field data from the Mailchimp API, but I didn't get any result. It seems that the Mailchimp API never send this field.

So the way used to translate the fields (@see issue Translation) will never work with the email address field, that is not considered by Mailchimp as a normal MERGE tag.

So we need an other way to translate this field...

Maybe the "Email address" string could be translated when defining the MERGE var?

Comment #4

daften CreditAttribution: daften at Picabit commented 1 July 2016 at 12:10

The problem now is that Email address is hardcoded, so if the default language is Dutch, that string just can't be translated to dutch. I have honestly no idea how to fix this properly. I worked around it by creating a patch for my project that changes this hardcoded string to Emailadres (the dutch variant), but that's a dirty hack.

Comment #5

B-Prod CreditAttribution: B-Prod commented 2 July 2016 at 22:58

Actually translating the name when defining the MERGE var works, but has some other issue.

The workflow is the following :

When creating the MERGE var, the "Email Adress" string is translated to the expected translation (if it exists and if the target language is forced to the site default language)
When displaying the EMAIL var, the already translated string is translated again, this time from the default language to the current language.

This works, but... :

Changing the default language (note that this is a really bad thing and should never be done, regardless of Mailchimp) leads to issues
If there are some signup forms already existing, the MERGE var will remain the original ones, because they are stored in the signup entity and are not changed, even on submission.
This is really not a clean way to process (translation of translation)

What would be better:
add some options in the signup form to override the value of each MERGE var label, so we could use i18n strings as it is expected to be used. I am not really convinced by the current method of translating the MERGE fields inside Mailchimp backoffice.

Comment #6

fotograafinge CreditAttribution: fotograafinge commented 22 September 2016 at 11:16

What would be better:
add some options in the signup form to override the value of each MERGE var label, so we could use i18n strings as it is expected to be used. I am not really convinced by the current method of translating the MERGE fields inside Mailchimp backoffice.

I agree. Also have he same problem (for 7.4 and 8.x)

@daften: how did you patch it ? I could not manage to solve it.

Comment #7

Greg Boggs

he/him

English

Portland Oregon

CreditAttribution: Greg Boggs at ThinkShout commented 11 October 2016 at 17:59

Version:

7.x-4.4

» 7.x-4.x-dev

Comment #8

idebr CreditAttribution: idebr at One Shoe commented 3 November 2016 at 12:04

Hello everyone,

You should now be able to translate Mailchimp merge fields using the new mailchimp_i18n submodule added in #2724711: Implement i18n_object_info so i18n_strings can be imported automatically. Please let me know if you need any more help with your translations.

Comment #9

esolitos

he/him

Italian

Trondheim

CreditAttribution: esolitos at Ramsalt Lab commented 15 November 2016 at 08:01

Version:

7.x-4.x-dev

» 8.x-1.x-dev

What about D8? The module mailchimp_i18n is not available and it seems that this is still an issue on D8?

Comment #10

Anybody

German

Porta Westfalica

CreditAttribution: Anybody as a volunteer and commented 21 December 2016 at 13:50

Please see https://www.drupal.org/node/2822227#comment-11836593 for further discussion also.

Comment #11

daften CreditAttribution: daften at Picabit commented 15 April 2017 at 23:08

@idebr. It's been a while since I worked this project and my changes have been overwritten by somebody doing an unchecked drush up. But if I remember correctly, I patched it to add a t function. Not correct, but it did fix it for me.

Comment #12

Peter Majmesku

🇩🇪Düsseldorf

CreditAttribution: Peter Majmesku commented 23 April 2017 at 12:35

Status:

Active

» Reviewed & tested by the community

File	Size
mailchimp-email-label-2747027.patch	560 bytes
8.x-1.x: PHP 5.5 & MySQL 5.5, D8.4 Skipped, branch did not pass for 4 weeks PHP 5.5 & PostgreSQL 9.1, D8.4 Skipped, branch did not pass for 4 weeks PHP 5.5 & SQLite 3.8, D8.4 Skipped, branch did not pass for 4 weeks PHP 5.6 & MySQL 5.5, D8.4 Skipped, branch did not pass for 4 weeks PHP 7 & MySQL 5.5, D8.4 Skipped, branch did not pass for 4 weeks

Here is the patch, which solves this issue for me. Edit for 1 line of code.

Comment #13

daften CreditAttribution: daften at Picabit commented 23 April 2017 at 16:33

Status:

Reviewed & tested by the community

» Needs review

Marking as needs review, since you can't mark your own patch as reviewed :D

Comment #14

devad CreditAttribution: devad as a volunteer commented 7 November 2017 at 03:26

Status:

Needs review

» Needs work

The patch #12 doesn't apply cleanly any more to latest 8.x-1.3 and 8.x-1.x-dev. It needs rewrite.

But, after I have edited one line manually (as patch is supposed to do) - it works.

However, it needs some instruction how it works.

1. Create first Mailchimp Signup Form.
2. Visit /admin/config/regional/translate, search for "Email Address" string and translate it.
3. Edit already created Mailchimp Signup Form (and create other signup forms if you need more than one).

An attempt to search for "Email Address" string before step one will fail because step 1 is necessary for translation string creation.

Form translation to multiple languages works nicely as well.

Marking this to "needs work" just because the patch needs to be updated.

Comment #15

snsblvd CreditAttribution: snsblvd as a volunteer commented 28 November 2017 at 20:55

I just saw that this issue https://www.drupal.org/project/mailchimp/issues/2903123 (Mergefields can not be translated: Email Address, First Name, Last Name) made it to the latest release (https://www.drupal.org/project/mailchimp/releases/8.x-1.4). So I guess this issue is solved too, right?