Set langcode with LegacyEmailBuilder

Here is a patch proposition.

Thanks for the issue and patch. Strange, I thought I had written code for this already😃.

The issue is only about LegacyEmailBuilder so the fix should also be in the legacy code. I believe we can fix it in LegacyMailerHelper::emailFromArray(). On line 141 there is a call to $email->setAddress(). We can pass a second parameter of $message['langcode']. This should be only for the to address.

This project now uses merge requests not patches please.

This project now uses merge requests not patches please.

Please review.

Thanks, I mean pass langcode as second parameter to parseAddress()

I have updated langcode as second parameter to parseAddress(), please review.

That looks good to me. @Aerzas please can you test?

Thank you for the updated code @viren18febS .

Unfortunately, it doesn't seem to fix my issue. The langcode is correctly set on the address but it is still the current langcode that it is used by Mailer::doSend. In the context of a legacy email, the __disable_customize__ parameter is set and the langcode processing in the Mailer::doSend method is ended early intentionally, no address is parsed. The address langcode is correct but not the email langcode.

We could prevent the setting of the __disable_customize__ parameter in LegacyEmailBuilder::createParams, but then the account will also be updated/processed in Mailer::doSend which may have unwanted side effects.

We could otherwise split the disabling parameter into two: __disable_customize_langcode__ and __disable_customize_account__. This would offer a fine-grained way of handling overrides but will require additional conditions in the process loop.

Or we could consider that __disable_customize__ only excludes account customization and still gather the langcode from the to addresses.

Good point, thanks @Aerzas. How about this?

- LegacyEmailBuilder creates the To address with the current langcode and also current account. Add an extra param to parseAddress.
- Remove all code for __disable_customize__

Has there been any progress on this issue?
Seems quite the priority since this affects all Core user mails.
Or is there another workaround to be able to send the mails in the correct language?

@yorder.be The patch I proposed fixes the issue in the meanwhile.

@AdamPS Thank you for your feedback, I'll work on a new MR as soon as I can.

__disable_customize__ has now been removed from 2.x. It should now be a 1 line fix to LegacyMailer::send() to pass $message['langcode'] as the 2nd parameter.

@adamps Made the changes. Previous MR was forked form 1.4.0 and LegacyMailer class was not present in that specific version. So, pull the latest 2.x-dev and raised new MR-139 and made the changes in that MR. Kindly review it.

Thank please see the comment in the MR

Added 2nd parameter to parseAddress().

Great, now it needs someone to test. A manual test would be OK. Set up a multi-language site, configure a user with a non-default language, send an email with template text that depends on language. Test without the fix the language is wrong, with the fix it is right.

I was testing this issue as mentioned by @adamps.

• Set up a multilingual site with a user configured with a non-default language.
• Used hook_mail() and mail() method to send mail during user creation (for using LegacyEMailBuilder).
• However the correct language template is being sent to the receiver even without the fix based on the user's langcode.

Am I doing it correctly? If not, then mention where and how the error occurs and how to reproduce it. Any help is appreciated. Thanks in advance :)

Thanks @debrup

I have one idea - make sure that receiver langcode is not the default.

@adamps I have created a new user set to a non-default language. When their account gets created the mail is sent with the corresponding template in the langcode set for that user.

adamps → changed the visibility of the branch 3413081-set-langcode-with to hidden.

Also please make sure that the current account that you are logged in with has a different langcode from the one on the new user.

Sorry I realise anyway that the fix is incomplete, my mistake. We need to

1. Remove reference to __disable_customize__ in Mailer::doSend() and LegacyMailer::send()
2. Add a 3rd parameter to ImportHelper::parseAddress() which is ?AccountInterface $account = NULL and pass the value to new Address() in 2 places.
3. In LegacyMailer, after the code that we already added, pass a 3rd parameter which is the current account. Add an extra constructor parameter protected readonly AccountInterface $account to fetch this.