multiple language websites: user and user_status module issues with confirmation email messages

On multilanguage websites, it looks that when drupal sends basic email messages, such as registration confirmation, it ignores the user native language.

This post is to report how I managed to make it work, but it's been indeed tricky and my solution is open to further and better implementations.

following discussion at http://drupal.org/node/156593...

...that's a good news (drupal 6 solving this) and I'm not requesting any patch to that. However, I've run into other issues that people using Drupal 5.x platform might take into consideration:

0) A brief explanation of the problem: multiple language website, my client asks the following:

- when users register, they receive proper email confirmation in their native language (it looks reasonable); they're initially blocked;
- when site admin activates the users, they receive a proper confirmation email in their native language;
- english is the default language;
- to accomplish that, I installed the user_status module (in Core on Drupal 6)

1) User status incorporate the $user object;
2) the system switches the global $locale depending on $user->language;
3) However, after running A LOT OF TESTS it looked like some ways, modifying the global $locale value wasn't working properly... I had to clone t and locale functions (!) and implement a $locale parameter in them (if someone can help and work out why global $locale cannot do the trick...);
4)I'm quite conscious that manipulating modules ISN'T the way to do things, however, as long as they're user-contributed and not too messy, I feel confident in what I do.
5) Point 4 to justify the real problem: when the user registers from web, the "language" field in the user table remains empty. So, if my user is French and registers on an Italian / English /French website, the site administrator could only guess the language of the user before activating it. This is because locale.module only alters the user form at edit time. Anyway, what my client expected was that the user native language was the one he's currently selected.
6) so, I had to modify the user.module and add a hidden field on line 1197

$form['language'] = Array('#type' => 'hidden','#value' => $GLOBALS['locale']);

7) this actually makes Drupal get and store the current $locale as the native language.

8) last, but not least: user.module hardcodes email texts in the _user_mail_text function. It looks like not the greatest thing on earth, since strings are stored in a user_mail_something variable inside variables table but are also present as strings. So, if you translate them, you will only update the user_mail_something variable according to the last language you update. For this, I simply modified the first if clause (that seeks for proper values in variable table) to always invalidate it and so always get the t() translated text of the hardcoded email strings.