Selectable Email Language in EmailEventHandler

[Draykee]

Is your feature request related to a problem? Please describe. Right now the language of an email is determined by the language of the RequestContext. In some cases emails will be triggered by events, cronjobs or services that may use a newly created RequestContext that doesn't apply the language of the customer.

When configuring an EmailEventListener there should be an option that makes the language selectable.

Describe the solution you'd like

const confirmationHandler = new EmailEventListener('order-confirmation')
  .on(OrderStateTransitionEvent)
  .filter(event => event.toState === 'PaymentSettled')
  .setRecipient(event => event.order.customer.emailAddress)
  .setLanguage(context => context.event.order.customer.customFields.preferredLanguage) // new option
  .setSubject(`Order confirmation for #{{ order.code }}`)
  .setTemplateVars(event => ({ order: event.order }));

type LoadLanguageFn<Event extends EventWithContext, R> = (context: {
    event: Event; // to access data from the event (like the customer)
    injector: Injector; // in case that the event doesn't supply a language code - we can load data
}) => Promise<R>;

// This function is simiular to the loadData function
setLanguage<R>(fn: LoadLanguageFn<Event, R>): EmailEventHandlerWithAsyncData<R, T, Event, EventWithAsyncData<Event, R>>;

Describe alternatives you've considered There is none, except duplicating all handlers and sending/filtering for different events.

[michaelbromley]

From v1.8 there is the setLanguageCode method. Does this cover your needs?

[Draykee]

Actually no - for some of my usecases the injector: Injector; is missing and required.

Maybe a second function setLanguageCodeAsync that also loads data with the injector?

[michaelbromley]

How about using the loadData method first, which gives you the injector and is async, and then in the setLanguageCode method you'll have access to the data returned by the loadData method.

[michaelbromley]

Can this issue be closed, or is there still some functionality you can't achieve with existing APIs?

[NadimD]

Hi, do you confirm that there is no languageCode associated to the order ? In this case, the languageCode of the context will always be different from the one used in the store-front.

This means we are obligated to store the preferred language in a custom field.

I don't find this solution intuitive, can I have your suggestions if there is an alternative to a custom field, before closing this issue ?

[dlhck]

This issue is being closed because further data was needed but was not provided. If you want to continue the thread, comment below with the required information and the issue can be re-opened.