Hi Drupal !

I'm running Drupal 6.9 with Update Status enabled and all components "current", to build a mockup site for a small NGO active in Africa. Most of our members are strict francophones, and we plan to migrate an existing hand-made site to Drupal to improve our collaboration and communication efficiency.

To ease the approach to the new site, I was hoping that the email inviting the participants to log in would be issued in the person's own language, but this is not the case.

A bit of searching brought up a hint to i18n_variables, further grepping revealed a list of user_mail_*_subject and user_mail_*_body variables to include in settings.php, with the result that the User Settings forms now showed the fields as translatable. But the mails would still be issued in the site's default language.

So I resorted to print and print again, and came to the place where things were meant to happen : _user_maiil_text() in user.module. And cooked a small patch to allow my site's mail to go out translated to the user's preferred language - see attachment.

I don't know if you'll give this patch any consideration, but you should give the issue some. Many people have left messages in various places wondering and complaining that mails couldn't reach their users in the proper language.

Thanks for an otherwise very system.

-ungeek-

The relevant variables at the end of settings.php
--------------------------------------------
$conf['i18n_variables'] = array(
.....
// Different front page for each language
'site_frontpage',
// Primary and secondary links
'menu_primary_links_source',
'menu_secondary_links_source',
// Contact form information
'contact_form_information',
// User settings notifications
'user_mail_register_admin_created_subject',
'user_mail_register_admin_created_body',
'user_mail_register_no_approval_required_subject',
'user_mail_register_no_approval_required_body',
'user_mail_register_pending_approval_subject',
'user_mail_register_pending_approval_body',
'user_mail_status_activated_subject',
'user_mail_status_activated_body',
'user_mail_status_blocked_subject',
'user_mail_status_blocked_body',
'user_mail_status_deleted_subject',
'user_mail_status_deleted_body',
'user_mail_password_reset_subject',
'user_mail_password_reset_body',
// For theme variables, read more below
'theme_settings',
......
--------------------------------------------

CommentFileSizeAuthor
user.module.patch1.05 KBdimmie

Comments

dimmie’s picture

Version: 6.9 » 6.10

Hello Drupal !

I'm kind of disappointed by the lack of reaction to my original post. Is anything wrong with it ? More information needed ?

Pls. give me a hint.

-ungeek-

dimmie’s picture

Priority: Normal » Critical

Trying to draw attention to this post ...

gábor hojtsy’s picture

Category: bug » support
Priority: Critical » Normal
Status: Active » Closed (works as designed)

Ha, this is not critical, sorry. You need i18n module to make use of the i18n variables. It modifies the variables directly, so you should not need to use t(). If you still consider this is a bug, please follow up and move it to the i18n module queue.

dimmie’s picture

Version: 6.10 » 6.12
Status: Closed (works as designed) » Active

Hi Gábor !

I am re-opening this, because I don't know how to have notifications translated properly.

My current configuration (all components unpatched)
* drupal 6.12
* i18 6.x-1.0
* phpmailer 6.x-2.0

Problem description:
Admin blocking a (french) user account results in an email being sent to the user - in english, which I claim is an error, given the actual set-up.
All relevant variables are declared as multi-language variables. All relevant french translations have been provided and are available.

Other considerations:
When I first stumbled upon the problem, I tried - as best I could - to trace the flow of preparing emails through the different components, and was only able to fix the problem by patching the user module applying the patch included above.

An indication that this patch is not completely off the mark, and that the system is (nearly) properly configured, is that when the path is applied, the emails are actually issued in the expected and appropriate language.

So please,
tell me what I've been missing or what more information I should provide to you. As for the overrated priority - just keep in mind that the issue was opened on feb. 22, and that it took nearly three months and some priority ringing to get any acknowledgment.

Thanks for following up on this post. Also, if you can, please assign the issue to the proper module or project - you have the knowledge and the relevant specs, not the uneducated user in the field, and your assesment will give more credibility to this issue.

Thanks and kind regards.

-ungeek-

dimmie’s picture

Project: Drupal core » Internationalization
Version: 6.12 » 6.x-1.0
Component: user system » Code
Category: support » bug

Please look at #3 and #4 above for Gabòr's statements and my re-opening the issue.

Thanks.

Franz Kafka, on its way to (yet?) another desk ....

amalaer’s picture

Hi ungeek

I use D6.13 and also ran into the problem you describe. In http://drupal.org/node/163165#comment-1983616, I propose a solution.

For your interest:
There is a patch http://drupal.org/node/163165#comment-901473 (in #163165: Multilanguage support for user emails) whose first lines are very similar to your patch. And http://drupal.org/node/163165#comment-1100834 Point 1 explains why you shouldn't use t().

hass’s picture

amalaer’s picture

#163165: Multilanguage support for user emails is about different issues now (see http://drupal.org/node/163165#comment-1983974). Therefore, I opened a new issue.

Thus, I'd say

Duplicate of #563048: Multilanguage support for user emails using i18n

hass’s picture

Status: Active » Closed (duplicate)

So we mark this case here as a duplicate of #563048: Multilanguage support for user emails using i18n? Re-open if not...