- Issue created by @Aerzas
- Status changed to Needs review
6 months ago 5:40am 8 January 2024 - Status changed to Needs work
6 months ago 5:23pm 11 January 2024 - ๐ฌ๐งUnited Kingdom AdamPS
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.
- First commit to issue fork.
- Status changed to Needs review
5 months ago 7:10am 15 January 2024 - ๐ฎ๐ณIndia viren18febS
This project now uses merge requests not patches please.
Please review.
- Status changed to Needs work
5 months ago 9:56am 17 January 2024 - ๐ฌ๐งUnited Kingdom AdamPS
Thanks, I mean pass langcode as second parameter to parseAddress()
- Status changed to Needs review
5 months ago 11:33am 17 January 2024 - ๐ฎ๐ณIndia viren18febS
I have updated langcode as second parameter to parseAddress(), please review.
- ๐ฌ๐งUnited Kingdom AdamPS
That looks good to me. @Aerzas please can you test?
- Status changed to Needs work
5 months ago 10:25am 23 January 2024 - ๐จ๐ญSwitzerland Aerzas
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 theMailer::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 inLegacyEmailBuilder::createParams
, but then the account will also be updated/processed inMailer::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. - ๐ฌ๐งUnited Kingdom AdamPS
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__