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.