Posted by wimh on November 3, 2009 at 8:30pm
| Project: | Ubercart |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
uc_order_mail() looks at its $message argument to determine the language for the mail, which is calculated by uc_store_mail_recipient_language($recipient) in uc_order_mail_invoice_form_submit(). This language is correctly used to translate the e-mail subject.
The body of the e-mail, the invoice itself, is not translated correctly though, but is sent in the current language (i.e. the language the site was in at the time the mail is sent).
To fix this, uc_order_load_invoice(), when called from uc_order_mail(), should also get the $langcode and translate the invoice template accordingly.
Comments
#1
I've been trying to correct this on my site, I think things have changed a little though because of the new invoice templating system introduced in 6.x-2.4. However, the bug still exists and the core issue is the same. $settings['message'] is set prior to determining the user's language preference, so the message body gets sent in the same language as the site language at the time of generation.
The attached patch should fix the issue by first generating the message bodies from the template in the required languages and then sending the appropriately translated message body to the corresponding user based on language preference.
Some notes about how the patch works or what the patch changes:
<?php
t('Welcome !username', array('!username' => ));
# becomes
t('Welcome !username', array('!username' => ), $langcode);
# and
t('Some string');
# becomes
t('Some string', array(), $langcode);
# array() is used to indicate that there are no text replacements.
?>
The attached patch makes this change for the invoice templates included with Ubercart.
#2
I wonder if we can temporarily switch the global site language before rendering the email template, to avoid having to add $langcode to every single t() call in there.
#3
Also, is it worth adding that extra code to avoid re-rendering the template multiple times, as most sites will only be sending one or two mails here?
#4
The last submitted patch, invoice_recipient_language-622388-1.patch, failed testing.
#5
#1: invoice_recipient_language-622388-1.patch queued for re-testing.
#6
[Re-queued the patch for testing because I have no clue why it did not apply successfully, I ran the same command it lists in the log and it applies cleanly]
I believe it would be possible to switch the global language, but that seemed a bit too hacky to me so I went the alternate route. If this is preferred though, I will redo the patch using this method. As for the extra code to avoid re-generatation, it is only a simple associative array that does all the work and it's well commented so I don't think it adds too much complexity and it has the possibility of improving performance.
#7
The last submitted patch, invoice_recipient_language-622388-1.patch, failed testing.
#8
@firewing1: It's failing because of a bug with the testbot - hopefully that will be fixed soon. Until then, it would help if you install the simplest module on your own site and make sure the tests run clean with your patch.
#9
subscribing... unless this has been solved elsewhere in the past 2 years?
#10
@micheleannj: A fix was proposed only last month. If you would like to see this resolved, you can test the fix and report whether it works for you. Issues don't magically resolve themselves - they need community participation. That means you are one of the people responsible for solving, or not solving, this problem.
#11
I was thinking the same as @longwave in comment #2, so I created a quite different / smaller patch.
Ideally: drupal_mail() would let other modules, such as reglang, define which language to use for a mail, by invoking a hook before calling hook_mail() ... I guess
#12
#13
The last submitted patch, ubercart-order_mail_respects_user_preferred_language-622388-11.patch, failed testing.