Posted by AdamGerthel on October 21, 2009 at 1:02pm
14 followers
| Project: | MailChimp |
| Version: | 7.x-2.7 |
| Component: | General |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
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
#1
Those field labels are actually coming directly from MailChimp and are not translatable, at least as far as I know.
#2
Ok, thanks for the reply. I'll se what I can do using jQuery instead
#3
Has a .pot file been extracted from Mailchimp?
@insats, did you find a work-around for the non-module strings?
#4
Learnt how to extract pot file here: http://drupal.org/project/potx with thanks to Kenn_VM on IRC
Please find attached.
#5
@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.
#6
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.
#7
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
<?phpfunction _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 :)
#8
I have exactly the same problem with 7.x-2.4.
Proposed patch.
#9
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.#10
Switching this to bug report.
#11
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.
#12
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
#13
#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 :)
#14
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.#15
Patch re-roll for 7.x-2.6
#16
Patch reroll for 7.x-2.7
#17
#16 worked in 7.x-2.x-dev.
#18
and how about to solve this bug in 6 version?
#19
According to the Drupal 7 documentation for t(), you're never supposed to directly translate a variable as suggested in the latest patch.
#20
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: