I can't seem to find a way to translate the text in the block that says "Email address:", "First name" etc. I guess I can find it in the module code, but I don't want to edit the source of the module.

I found the string that says "Subscribe to the @newsletter newsletter", but it's the form below I want to translate.

#35 mailchimp-signup-i18n-string-610506-35.patch4.91 KBpyry_p
#27 mailchimp-translation-610506-27.patch2.18 KBvillette
#25 mailchimp_signup-translation-610506-24.patch1.73 KBraychaser
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mailchimp_signup-translation-610506-24.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#21 mailchimp-translation-610506-21.patch7.78 KBczigor
#16 610506-16.patch703 bytesstella
#15 610506-15.patch703 bytesstella
#8 mailchimp_lists.module.patch572 bytespverrier
#4 mailchimp.pot7.32 KBQuartz


levelos’s picture

Status:Active» Closed (works as designed)

Those field labels are actually coming directly from MailChimp and are not translatable, at least as far as I know.

AdamGerthel’s picture

Ok, thanks for the reply. I'll se what I can do using jQuery instead

Quartz’s picture

Has a .pot file been extracted from Mailchimp?

@insats, did you find a work-around for the non-module strings?

Quartz’s picture

new7.32 KB

Learnt how to extract pot file here: http://drupal.org/project/potx with thanks to Kenn_VM on IRC

Please find attached.

Quartz’s picture


All this can be done at Mailchimp. Click on any field that you want to change and type in the new translation string. Don't forget to save.

netsensei’s picture

This is an issue by design.

Quartz tip is okay if you want to change the default language of your installation to something other then English. But if your project supports multiple languages, then you'll run into trouble since Mailchimp doesn't do translation of fields either.

Yet, I think the problem could be solved within Drupal.

For one, I was wondering why the form page hits the API to retrieve the MC fields. Wouldn't it be easier to cache the fieldstructure Drupalside? This strategy would give you 2 benefits:

1. Less traffic with MC (retrieve fields only once)
2. The possibility to add an extra tab to Drupal which maps fixed label strings to fields. Those labels can be wrapped with t() which solves the translation issue.

Now, if an admin would change the fields in MC (not likely to happen every day!) he just needs to go to the MC settings page, click an 'update' button and MC would update the field structure in Drupal.

Just my 2 cents.

compujohnny’s picture

OK, I was successful in solving this issue

All u need to do is change the following line to add the t() function to the label texts returned from Mailchimp

function _mailchimp_insert_drupal_form_tag($mergevar) {
// Insert common FormAPI properties
$input = array(
'#title' => t($mergevar['name']),   //This is the changed line, it was '#title' => $mergevar['name'] but after I added the t() I was able to translate it via the Translate Interface page
'#weight' => $mergevar['order'],
'#required' => $mergevar['req'],
'#default_value' => $mergevar['default']

Hope that helps :)

pverrier’s picture

Version:6.x-2.0-beta8» 7.x-2.4
Component:Code» General
new572 bytes

I have exactly the same problem with 7.x-2.4.
Proposed patch.

alexverb’s picture

Category:bug» feature
Status:Active» Closed (works as designed)

The module is using the correct way of translating user input. The patch you're proposing is not a good solution. But I'm having the same problem when using the placeholder @mergevar it doesn't become translatable.

alexverb’s picture

Category:feature» bug
Status:Closed (works as designed)» Active

Switching this to bug report.

alexverb’s picture

After re-thinking on this I have to join the opinion of patch #8. I don't see any other way we could translate the labels. And I'm thinking we should do the same for the interest groups and interest group label. That would allow for full form translation.

mohamadaliakbari’s picture

Category:feature» bug
Status:Closed (works as designed)» Active

How patch #8 will make Merge-vars translatable? I think #7 is the solution: t($mergevar['name'])

t('@mergevar'... will not make difference between First-name, Last-name and E-mail...! you have just @mergevar variable in translate interface...

so we should use #7 ways instead #8

pverrier’s picture

#8 is just the patch form of #7, as you can see:

- '#title' => t('@mergevar', array('@mergevar' => $mergevar['name'])),
+ '#title' => t($mergevar['name']),

Line '-' is replaced by '+'. So we all agree :)

tkrugg’s picture

I had problem with the patch. It's failing at some point and I can't say why.
Hunk #1 FAILED at 696.

I prefered the jquery solution. That's all I need for the moment. I hope it will help

<script type="text/javascript">
/* mailchimp subscription block translation */
        <?php if($language->language == 'fr'): ?>
$('#block-mailchimp-lists-institutions-list #edit-mailchimp-lists-mailchimp-institutions-list-title').html("S'abonner à notre newsletter");
$('#block-mailchimp-lists-institutions-list .form-item-mailchimp-lists-mailchimp-institutions-list-mergevars-EMAIL > label').html("Adresse e-mail");
$('#block-mailchimp-lists-institutions-list .form-item-mailchimp-lists-mailchimp-institutions-list-mergevars-FNAME > label').html("Prénom");
$('#block-mailchimp-lists-institutions-list .form-item-mailchimp-lists-mailchimp-institutions-list-mergevars-LNAME > label').html("Nom");
        <?php endif; ?>

Just past this before the </head> markup of your html.tpl.php file.

stella’s picture

Status:Active» Needs review
new703 bytes

Patch re-roll for 7.x-2.6

stella’s picture

Version:7.x-2.4» 7.x-2.7
new703 bytes

Patch reroll for 7.x-2.7

brunorios1’s picture

Status:Needs review» Reviewed & tested by the community

#16 worked in 7.x-2.x-dev.

eL’s picture

and how about to solve this bug in 6 version?

levelos’s picture

Status:Reviewed & tested by the community» Needs work

According to the Drupal 7 documentation for t(), you're never supposed to directly translate a variable as suggested in the latest patch.

stella’s picture

No, you probably shouldn't as then they can't be extracted to po files.

I don't have the time to work on this, but you just need to implement hook_variable_info() in mailchimp (a hook provided by the 'variable' module).

If you implement that hook, then the process for translating the variable for end-users is:

  1. Install the variable and i18n modules
  2. Go to Admin ->Configuration -> Regional and language -> Mulitlingual settings (admin/config/regional/i18n) and click on the 'Variables' tab
  3. There you can select the variables you wish to translate. Enable all the ones you wish to modify and save
  4. Navigate back to the mailchimp configuration page
  5. There you can set the values for the declared variables in the site's default language.
  6. At the top there will be a language selector, switch to another language by clicking on the appropriate link.
  7. Then configure the strings for that language and save
czigor’s picture

new7.78 KB

As the strings in question are not coming from drupal variables I think the proper way to translate them is using i18n_string without the variable module.

The attached patch creates a mailchimp_i18n module in mailchimp/modules. Installing it creates a Mailchimp checkbox on the /admin/config/regional/translate/i18n_string page. Check it and press 'Refresh strings'. Now you can filter for the 'Mailchimp' textgroup strings at /admin/config/regional/translate/translate.

Currently the following strings can be translated:
- all enabled mergevar names like 'Email address' and 'First name'. 'enabled' means the ones that appear on the subscribe form for an anonymous user.
- List label and description

czigor’s picture

Status:Needs work» Needs review

The method was taken from the Countries and Metatag modules.

anibal’s picture

Hi all,

Just go to this link and use the translation features that are located in the mailchimp site.


There's no need for all this patch's and messing with the module.

This will translate the block that is used in the drupal side for the user subscription.

kopeboy’s picture

Issue summary:View changes

#23 Are you sure? I can't see a form to translate my list name and description.

When will patch at #21 be added to the module?
I don't know how to patch (I usually make simple edits by hand but this patch is big..).


raychaser’s picture

new1.73 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mailchimp_signup-translation-610506-24.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I think this relates but if not let me know and I'll open a separate issue.

We had a need for the mailchimp signup form to have its block title, block description and all field labels translated so this is what we came up with. It's a little crude but it does allow for all fields to be string translated.

Status:Needs review» Needs work

The last submitted patch, 25: mailchimp_signup-translation-610506-24.patch, failed testing.

villette’s picture

new2.18 KB

I just updated the patch #25 to make the confirmation message translatable as well.

mathieudg’s picture

I came across the same issue in 7.x-3.1.
The solution in #23 works only if you follow these steps:
- translate the signup forms (or other, depending on what you use on your site) on the Mailchimp site
- on your drupal site: enable the Mailchimp List in Modules and go to Mailchimp configuration
- load up the List and click "Refresh lists from Mailchimp"

Then and only then the translation takes effect.

czigor’s picture

@#25 and #27: You should not (almost) ever pass a variable to the first argument of a t() function. See https://api.drupal.org/api/drupal/includes!bootstrap.inc/function/t/7.

I'm pretty sure that using i18n_string is the way to go but the code has changed so much in the past one year that #21 does not apply any more.

zvaranka’s picture

I followed the intructions described in #28. I translated into Hungarian all strings of the signup forms and other in the MailChimp website after I selected the Hungarian language. I enabled the MailChimp list in Modules and finally in the Drupal Mailchimp configurationI refreshed the lists from MailChimp. But the in the signup form on my Drupal based website the field labels remained English. Of course in the MailChimp website I see my signup form already translated correctly. But in my Drupal site the labels remained English.

mathieudg’s picture

#30: Have you tried manually translating these field labels? Search for these labels in the translation settings (admin/config/regional/translate).

kopeboy’s picture

Version:7.x-2.7» 7.x-3.2

Using the instructions at #28 you can CHANGE the language of your Mailchimp fields, not translate them.

At least this is what I am able to do in Mailchimp app. It seems you have to create another list, with another default language, and there change the field labels (or re-create the fields in the new language).

Anybody? This seems stupid, why wouldn't Mailchimp support basic translation of this type, I mean, a sign-up form is their core!

If I understand correctly, with version 3 in Drupal, you would have to add two lists (Fields of type Mailchimp subscription) on the same user...

The last submitted patch, 25: mailchimp_signup-translation-610506-24.patch, failed testing.

pyry_p’s picture

Quick version with i18n_string as suggested in #29
This applies only to signup forms.
Looking back the title callback doesnt make sense because they get the string translation anyway. Mayby adds tiny consistency with context, but adds confusion since the title gets translatable twice.

pyry_p’s picture

After reading the patch in #21 I feel its closer to best implementation. Clear submodule for translation. The existing modules should only be touched to add alteration hooks where needed.

axe312’s picture

I can confirm that patch from #35 is working. But like pyry_p, I'd prefer to have a separate module for that: The way he describes it in the above comment.