Currently choosing localization template requires writing user's locale to the user table and then querying it before sending the email. This is done in the localeCallback. However, this requires 1 read operation each time the email is dispatched. In addition, this doesn't allow for automatic locale detection. And if user changes browser language, they will still be getting their emails in their old language.
Feature / Enhancement Description
Would it be possible to provide access to request object inside the localeCallback? The request object of cloud functions usually contains the Allow-Language header, or cf-ipcountry header for the sites behind cloudflare.
These can be conveniently used for dynamic localization without any need to write or read anything from db.
Example Use Case
localeCallback: async (req) => {
const locale = req?.headers["accept-language"]?.split(",")?.[0]?.split("-")?.[0]; // en or tr or es
return locale;
},
New Feature / Enhancement Checklist
Current Limitation
Currently choosing localization template requires writing user's locale to the user table and then querying it before sending the email. This is done in the localeCallback. However, this requires 1 read operation each time the email is dispatched. In addition, this doesn't allow for automatic locale detection. And if user changes browser language, they will still be getting their emails in their old language.
Feature / Enhancement Description
Would it be possible to provide access to request object inside the localeCallback? The request object of cloud functions usually contains the Allow-Language header, or cf-ipcountry header for the sites behind cloudflare.
These can be conveniently used for dynamic localization without any need to write or read anything from db.
Example Use Case
Alternatives / Workarounds
3rd Party References