You can translate invite email subject properly, since the code for getting subject looks like this:
function invite_get_subject($args = array()) {
$subject = variable_get('invite_subject', t('[invite:inviter-raw] has sent you an invite!'));
return token_replace($subject, invite_token_data($args));
}
So, if you submit invite settings, the default value of string wrapped by t() will never be called.
And the "invite_subject" variable will hold one value for all languages.
The correct way to fix it is to use variable module API to expose invite variables for translation.
Comments
Comment #1
miqmago commentedIt happens the same with _invite_get_email_template()
For me this patch resolves the issue. The main point is to change the t() position to variable_get:
Comment #2
basillic commentedThe integration with the Variable module seems to have been modified since the issue submission date.
Variables must be declared in a separated file (invite.variable.inc). Here the code I've written to use Variable with Invite :
Please give me a feedback for this hack.
Comment #3
passengerabcd commentedI patched invite 7.x-2.1-beta2 with comment #1 and #2, and it's working great. Thanks for your sharing, miqmago & basilic. Hope it can be merged into future release.
Comment #4
benjifisherUsing Invite 7.x-4.0-beta2, I do not run into this issue with the default configuration, but when I check off "Invite By Mail" as the Sending method at admin/structure/invite-types/manage/invite_by_email, suddenly my subject and body are not translated. :-( It seems that the problem has gone away in the main Invite module, but still exists in the invite_by_email submodule.
My solution is similar to the one @miqmago suggested in #1 above: put
variable_get()insidet(). This has a disadvantage that the strings will not be extracted when you generate PO files. (This is why you are supposed to uset()with literal strings.) For the site I am working on, we manage the PO files and keep them in a git repository, so this is not too bad.Integrating with the Variable and i18n_variable modules, as in @basillic's comment #2 above, is another approach. It will work better for some sites, but I do not know how to manage translations using PO files and this approach.
I have attached a little patch.
Comment #5
basillic commented@benjifisher, to clarify my method : I don't use PO files to translate realm variables (i18n_variables). I translate realm variables with the admin interface (on my dev site) and use the module features_translations to deploy all the translated variables to the testing and production sites.
Comment #6
ipwa commentedAdding patch for 7.x-2.x-dev based on #3.
Comment #7
ipwa commentedAdding new correct patch that also adds file from #2
Comment #8
alfthecat commentedPatch from #7 fails
Comment #9
ckngFor 7.x-4.x (patch #4), would prefer Variable integration via i18n.
7.x-2.x is currently not supported and no maintainer.
Comment #10
MorinLuc0 commented@basillic has it right you should not be translating a variable.
Rolling his code in a patch after fixing a few items. (7.x-4.0-beta2) release.
Comment #11
SpartyDan commented