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.

Comments

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.

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

Has a .pot file been extracted from Mailchimp?

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

StatusFileSize
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.

@insats

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.

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.

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

<?php
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 :)

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

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

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.

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

Switching this to bug report.

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.

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

#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 :)

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">
$(document).ready(function(){
/* 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; ?>
}
</script>

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

Status:Active» Needs review
StatusFileSize
new703 bytes

Patch re-roll for 7.x-2.6

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

Patch reroll for 7.x-2.7

Status:Needs review» Reviewed & tested by the community

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

and how about to solve this bug in 6 version?

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.

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

StatusFileSize
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

Status:Needs work» Needs review

The method was taken from the Countries and Metatag modules.

Hi all,

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

http://kb.mailchimp.com/article/can-you-translate-my-signup-forms-respon...

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.

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..).

Thanks