The intent of this module is exactly what I was searching for, but at a closer look, it doesn't do what I needed... but perhaps you didn't stumble over the following use case:
A user, that is not logged in, wants to retrieve his lost password. He had set his preferred language in his user profile before. Now he is logged off and triggers the password e-mail from a browser, that is not set to his preferred language, but to the sites default language or a very different one.
What happens now is, the e-mail send to the user is not in their preferred language, but in the sites default language (or, what is set in the browser).
But to get the triggered e-mail in the user preferred language is what my users want ;)
The problem and the solution:
In your hook_mail_alter() implementation you use the language that is passed in the $mail['language'] argument, but that is not the users language! according to the manual, the use's language is passed within the account object inside the params array: namely $mail['params']['account']->language (this depends on the $params array, that is passed to drupal_mail(), but generally, it contains the account object, see http://api.drupal.org/api/function/drupal_mail/6)
So I suggest, you check if $mail['params']['account']->language is set, if yes: take it, if not: fall back to $mail['language']->language.
I would provide a patch, if necessary. Thanks in advance!
Comments
Comment #1
salvisThis is a long-standing core issue: #86287: Password reset process ignores the user's language preference.
Have you checked whether $mail['params']['account']->language really has the right language?
Do you think that $mail['params']['account']->language will always be the better choice than $mail['language']->language? Why?
Comment #2
Bilmar commentedsubscribing
Comment #3
klonosI believe we should postpone this on #86287: Password reset process ignores the user's language preference
Comment #3.0
klonos...fix minor typos here and there and extraneous line ends.