In order for the submodule to work correctly the following patch must be applied.
I propose that once we have chosen the language in Mailer.php then we should reload the policy with the correct language. The code that loaded them originally was in EmailFactory:
Might also be an idea to only instantiate adjuster plugins when they are applied during a certain phase and have the plugins use different phases - address adjusters should probably run earlier than e.g. subject or body adjusters since they could be responsible for determining the language of the email. SearchApiProcessor plugins use "stages" in their plugin annotations, maybe EmailAdjuster plugins should define "phases" in their annotations. 🤔
The $basePluginId property should be removed form modules/wingsuit_ui_patterns/src/Plugin/Deriver/LibraryDeriver.php - it's already declared in Drupal\ui_patterns\Plugin\Deriver\AbstractPatternsDeriver which is extended by this class but the base definition was apparently updated in ui_patterns 8.x-1.8 release so this will now cause a fatal error.
/**
* The base plugin ID.
*
* @var string
*/
protected $basePluginId;
Added the following as a workaround to my email builder plugin. Not overly pretty, but it seems to work. 🤷🏻♂️
/**
* {@inheritdoc}
*/
public function preRender(EmailInterface $email) {
$adjusters = ['email_body', 'email_subject'];
$suggestions = $email->getSuggestions('', '.');
$adjuster_manager = \Drupal::service('plugin.manager.email_adjuster');
$policy_config = MailerPolicy::loadInheritedConfig(end($suggestions));
foreach ($policy_config as $plugin_id => $config) {
if (in_array($plugin_id, $adjusters) && $adjuster_manager->hasDefinition($plugin_id)) {
$adjuster_manager->createInstance($plugin_id, $config)->build($email);
}
}
}
While the proposed patch is certainly not the way to go the problem with mails being sent in the wrong language when using adjusters like SubjectEmailAdjuster or BodyEmailAdjuster still persists. The adjuster plugins are already instantiated during initEmail() in the EmailFactory class which is happening quite some time before the eventual language switch might happen in Mailer::doSend(), so there's no way to get mails sent in the correct language using these adjusters even when using config translation properly. Not seeing a simple solution for this though. :-/
Patrick R. → created an issue.
Patrick R. → created an issue.