The subject and the body of an email template are translatable. So i expect that the language of the party is used when i create an email on a purchase, sale or invoice like it is done for the reports.
But it doesn’t seem to work out of the box and i also miss some methods to make it work. I also didn’t find any language handling based on the transaction language context on the email templates.
I this a missing feature?
No it is indeed a feature 
We enforced that the email content is written in the language of the user who is sending the email. This is the only language that we know he speak of.
I’m wondering if it makes sense to allow to configure the language at template level or at least let the user choose it before sending.
For example, I have all the user interface in Catalan but I’m also able to write in English and Spanish. If Tryton knows that I speak Catalan but the recipient prefers English I may be able to decide that I write it in English (because I also know this language).
Why not but it is going to be very complicated because the client may not have the required information to determine in which language the template should be rendered. I would not want to introduced the same broken design as for the previous email mechanism which relies on field being displayed on the form (which never work from right-click).
It could be done in EmailTemplate.get by collecting the languages of all the recipients and compare to the language spoke by the user. But which one to choose? And what if there are no recipients?
Also there will be no guarantee that the report language used will be the same as the email content.
Probably if you relies so much on the language content it is not this feature that must be used but the email notification.
That’s what I tought about defining on the template the language to be used. I was thinking on a selection field with the following options:
So we delegate to the person defining the template which language to use. This makes sense because is the one that will write the text and translations.
We can not do so much when there are not recipients so I suspect the only option is to fallback to the user language.
It would be good to have the possiblity to fallback to a language that is computed like it is done for the reports now.
Yes, that may be an option. But as there are already multiple languages on the email template i think we should provide flexibility on the language selection.
I do not see why. We have translation in other places of the software and just always use in the user language.
For now as we only know 1 language for the user, we can only choose this language.
I do not see why there should be a selection option.
Once we know which languages the user can speak, we could use randomly one common languages between all recipients and the user, and fallback to the user language.
So it will just requires to know the languages spoken by the user.
Just to avoid random language. We need to decide which language takes presedences to the other: If we prefer the recipient language or the sender language.
I think in most cases you will use a recipient which is connected to a party. So using the language on the party will solve most of the cases.
There are of course multilingual companies where one prefers Dutch, others prefer English. In this case you want to have an extra selection box when you want to email someone where you can select the language. Tryton client will then update the contents with the right language.
You can also add an extra language field on the contact_mechanism so the language can be set.
In all cases you walk into trouble when you have multiple recipients which prefer different languages.
So IMO when the language can be taken from the party is a very welcome enhancement.
I do not say to take a random language but the random one of all the common languages.
I see no point to order the languages in this cases. The randomness of the python set will be good enough.
This can only be managed with the notification_email module, which generates the content in multiple languages so each recipient get it’s prefered.
So probably using the recipient language is enought. And when there is no recipient just use the current one.
But it may be some emails that are sent to internal communication, so in this case the language of the party is not relevant.