Currently, the API does not provide a way to automatically detect language and add a proper translation to the subscription. It means additional API calls after receiving the webhook.
For initial i18n implementation in the EAM, it would be recommended approach. As a potential improvement in the future, we could make configuration variants depending on the language:
user creates a base configuration, it will be used as a fallback if there's no variant related to the email language
user creates a dedicated variant for the language. A variant would provide an interface to choose a different sender, message subject and template.
When a webhook arrives, the App checks for any configuration variant of the event language. If none is found, the base configuration is used.
The proposed solution increases the app's complexity (both for implementation and for the user).
Impact
modify webhook subscriptions to add customer/event language code
Problem I would like to solve
Send fully translated emails to customers.
Intro
API
Saleor API provides translation models that the App could use. To choose a language, we can:
Currently, the API does not provide a way to automatically detect language and add a proper translation to the subscription. It means additional API calls after receiving the webhook.
Templates
Sendgrid and SMTP providers lack dedicated i18n support and require conditional rendering with Handlebars to localize text. Sendgrid documentation with examples for reference.
For initial i18n implementation in the EAM, it would be recommended approach. As a potential improvement in the future, we could make configuration variants depending on the language:
base
configuration, it will be used as a fallback if there's no variant related to the email languageWhen a webhook arrives, the App checks for any configuration variant of the event language. If none is found, the base configuration is used.
The proposed solution increases the app's complexity (both for implementation and for the user).
Impact