account_activated email language depends on website language - not user preferred language

I can confirm that issue.
I'm not a developer but maybe this could be a start:

...
if ($admin_setting = variable_get('user_mail_' . $key, FALSE)) {
    // An admin setting overrides the default string.
   
   // edit: If i18n_variable is active, use its function to get translation  
   if(module_exists('i18n_variable')){
        if($admin_setting = i18n_variable_get('user_mail_' .$key,$langcode,False)){
             $text = $admin_setting;
        }
    }
      
    $text = $admin_setting;
  }
  else {
...

Sorry that breaks the config form.
This could work:

if ($admin_setting = variable_get('user_mail_' . $key, FALSE)) {
    // An admin setting overrides the default string.
         
    // edit: If i18n_variable is active, use its function to get translation
    if(module_exists('i18n_variable')){
        if($admin_setting_i18n = i18n_variable_get('user_mail_' .$key,$langcode,False)){
             $admin_setting = $admin_setting_i18n;
        }
    }
      
    $text = $admin_setting;

it works! thanks!

Don't hack the core.
Use: mail_edit instead.
Just found that module a few days ago. Sorry for the core hacking.

mail_edit does work it the link inside email still not aware of language. We need to have multilink module http://drupal.org/project/multilink to have these links arrive in the right languages.

THanks

subscribe

better clarifications

Here's a patch based on #2 that fixes the problem for Drupal 7.39 using i18n_variable.

Why not translating the result from variable_get with t(), just as it does when no overrides were made on the default Drupal configuration?

  // An admin setting overrides the default string.
  $text = t($admin_setting, array(), array('langcode' => $langcode));

The point of using i18n_variable is being able to override these strings per-language. So there's no need to return the translated text value via t() (which should never be used to translate user-entered strings, see https://groups.drupal.org/node/1827 for an explanation).
Simply check the variables you'd like to translate in /admin/config/regional/i18n/variable and the form for these settings should have language tabs to configure the value per-language.

That really making sense. I am reverting back the patch

Thanks for the clarification, PascalAnimateur!
It is clear that t() has its limitations, and that i18n has proved to be a better alternative; it wouldn't be in D8 core otherwise. But using a contrib module inside D7 core? That sounds a little bit strange to me.

It only uses i18n_variable if it's enabled (see the module_exists call in the if statement). Don't want to sound pessimistic, but the patch probably won't be committed to 7.x core..

Thanks for reporting this.

I think this is a duplicate of #1197400: Use user's preferred language in system emails and as you can see there, it is replicable also without the i18n module. Lets keep the older issue open.