Mail Languages/Translations
I am a big advocate of keeping all translations in the front-end part. This becomes tricky when we have to deal with sending e-mails. The front-end is not able to send e-mails and thus the back-end can no longer be language agnostic. How do we deal with this?
Luckily, this isn't a big problem as you don't actually need any translation logic in your code. E-mails should be based on some templates, which can be part of your back-end code as some resources, but by no means should you in your code assemble the actual e-mail content or subject. If you do this, you will end up with file containing the e-mail subject and content per language and your application is now only concerned with selecting the right file.
In order for the back-end to select the right template, it needs to know in which language to send the mail. For this there are 2 approaches:
Select the language of the account/user to whom to send the mail
Let the front-end provide the mail
The first option seems to be the easiest one. Your front-end doesn't have to provide any extra information and your back-end handles everything nicely. This does however mean that you need to have a language on the user account. While it is likely that you have something like this, it is not guaranteed. You could for instance have an application where the front-end handles the language based on a language selector and stores it in some cookie/local storage.
There can be some caveats with this system, especially for sending mails that are not linked to a specific user, of that are sent when the user has not created an account yet, like the register/sign-up e-mail. These cases are however rare, especially since you already know to which e-mail to send the mail. Even your register flow can be designed in such a way that you already assign a language to the user before sending the e-mail.
The second approach is to let the front-end provide the language of the e-mail. This is useful when your back-end has no way to figure out the language of the user. The downside of this approach is that every action that causes an e-mail to be sent now relies on the front-end to provide a language. Not only does this leak this information to the front-end, it also means that if you change your back-end to start sending an e-mail for something it didn't do in the past, your front-end now has to provide a language, meaning you have an API change.
Clearly the first approach is the best one, but may be a bit problematic for micro-services. In that case it may be an option to include the language in your JWT, even though this means that when a user changes language, you have to provide a new token.