When saving a new configuration for User Settings under admin/user/settings, emails translations are lost and only the default languade is shown.
This happens in a multi-language site where also the user emails are translated - see User email settings. By defaults only few emails are enabled. If I try to enable other emails - like Account deleted email - and save this new profile, the User Setting page will show User emails with default language only for all languages.
This happens even of no change is done to the user setting profile, but simply the Save Configuration button i pressed.
Pressing -Reset-to-Default- will restore the original email translations.
So in the end there is no way to have multiple email languages with a User Setting profile different from the default.
This is a bug, which can be easily reproduced with D6.9 + i18n (not essentlial I believe) and Locale, Internationalization enalbled.
Thanks for any feedback on this issue.
bye.
Comments
Comment #1
kars-t commentedHi univac
I know you had some problems with mail edit but here again my solution as no one else is giving an answer:
As work around to this issue you can use the mail edit module.
As far as I tested this module it runs fine even the beta for D6. If the mail has a proper language set the module will change the mailstring to the one set through the module. Please make sure you set all mails in all languages you use.
If you have problems with the users language please take a look at my module Registration Language
Comment #2
kustolovic commentedThis bug still exist in the d7 version, and nothing has changed.
The reason is that the default values of the textfields and textareas and the bodies of the e-mails are provided by the same function _user_mail_text (http://api.drupal.org/api/drupal/modules--user--user.module/function/_us...) who provides default translated strings or the content of the variable if it exists.
Or you just need to press one time the Save Configuration button to set these variables with the current variables.
as work around to this issue we can use the i18n_variable module, but doesn't need the core work better?
Comment #3
kars-t commentedHi kustolovic
I am setting this to "works as designed" as it is as it is. For D7 we can't change anything about it.
For D8 please join this group and their discussions so we get a solution for D8:
http://groups.drupal.org/internationalization
Maybe set the issue to D8 but I think a common solution for D8 will make it obsolete anyway.