Set langcode with LegacyEmailBuilder

Created on 8 January 2024, 6 months ago
Updated 3 February 2024, 5 months ago

Problem/Motivation

When using LegacyEmailBuilder, the email langcode is always set to the current langcode. Since a langcode is provided to the mail method on the MailManager, we should use that langcode.

Proposed resolution

Use the legacy message langcode during the processing in Mailer.

โœจ Feature request
Status

Needs work

Version

1.4

Component

Code

Created by

๐Ÿ‡จ๐Ÿ‡ญSwitzerland Aerzas

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @Aerzas
  • Status changed to Needs review 6 months ago
  • ๐Ÿ‡จ๐Ÿ‡ญSwitzerland Aerzas

    Here is a patch proposition.

  • Status changed to Needs work 6 months ago
  • ๐Ÿ‡ฌ๐Ÿ‡ง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
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia viren18febS

    This project now uses merge requests not patches please.

    Please review.

  • Status changed to Needs work 5 months ago
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom AdamPS

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

  • Status changed to Needs review 5 months ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณ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
  • ๐Ÿ‡จ๐Ÿ‡ญ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 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.

  • ๐Ÿ‡ฌ๐Ÿ‡ง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__

Production build 0.69.0 2024