I need to send automated emails to customers whose language I am not sure about.
90 % are french and would probably not be able to read mails in english.
The other 10 % would probably be able to read in english and clearly not in french.
I don’t know what their language is.
I investigated the multipart/alternative that looked promising, give the mailer several variants and he selects the best one.
( see: http://www.ietf.org/rfc/rfc1766.txt )
Unfortunately no mailer seems to care about that, they always show the last part…
did someone manage to make multi-lingual mail with automatic selection of the best version for the users?
Is there some kind of trick to know?
Do you have another solution?
2
We send bilingual emails in the format
<h1 lang="fr">*** La version française [follows] ***</h1>
<div lang="en">English text here</div>
<h1 lang="en">*** English version precedes ***</h1>
<div lang="fr">Texte français ici</div>
Use of the lang attribute will allow a screen reader to correctly toggle between pronunciations; use of headings will allow a screen reader to jump to the relevant version of the email (both assume support in mail client).
http://www.w3.org/TR/html-markup/global-attributes.html#common.attrs.lang
1
The common solution that I am aware of for such bi-lingual emails is to write them like this:
For the English version, see below
<The text of the message in the local language>
==============
<The text of the message in English>
This way, you don’t depend on the capabilities of the mail software of the recipient.
The reason for putting the local language first is because that is what the majority of the recipients will understand best (why bother writing a local language version if everybody understands the English version well enough).
UPDATE: If you are sending emails in HTML, also consider the use of language attributes, as explained in the answer by Matt.
There is now a MIME multipart type especially for this purpose: multipart/multilingual, defined in RFC 8255. I do not know how well supported this type is by mail clients, although I have found at least one that supports it: NeoMutt. However, because of the fallback for unknown multipart types to multipart/mixed, it should be possible to already compose such mails and either have them supported correctly, or displayed in a way equivalent to what is described in the answers by Matt and Bart, if mail clients follow the standards…
To get a feel for this, let us consider an example from the RFC (somewhat simplified by me):
From: [email protected]
To: [email protected]
Subject: Example of a message in Spanish and English
Date: Thu, 7 Apr 2017 20:55:00 +0100
MIME-Version: 1.0
Content-Type: multipart/multilingual; boundary="01189998819991197253"
--01189998819991197253
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
This is a message in multiple languages. It says the same thing in each =
language. If you can read it in one language, you can ignore the other =
translations. The other translations may be presented as attachments or =
grouped together.
Este es un mensaje en varios idiomas. Dice lo mismo en cada idioma. Si puede =
leerlo en un idioma, puede ignorar las otras traducciones. Las otras =
traducciones pueden presentarse como archivos adjuntos o agrupados.
--01189998819991197253
Content-Type: message/rfc822
Content-Language: en
Content-Translation-Type: original
Content-Disposition: inline
Subject: Example of a message in Spanish and English
Content-Type: multipart/alternative;
boundary="72530118999911999881"; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
--72530118999911999881
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hello, this message content is provided in your language.
--72530118999911999881
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<html><body>Hello, this message content is <b>provided</b> in
<i>your</i> language.</body></html>
--72530118999911999881--
--01189998819991197253
Content-Type: message/rfc822
Content-Language: es
Content-Translation-Type: human
Content-Disposition: inline
Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?=
=?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?=
Content-Type: multipart/alternative;
boundary="53011899989991197281"; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
--53011899989991197281
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hola, el contenido de este mensaje esta disponible en su idioma.
--53011899989991197281
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<html><body>Hola, el contenido de este <b>mensaje</b> <i>esta</i>
disponible en su idioma.</body></html>
--53011899989991197281--
--01189998819991197253--
This results for some clients I tested follows below; they are not terribly encouraging. But first I’d like to note that for all these clients, when a ‘message’ attachment is opened, they do more-or-less the right thing. (One problem being with this example that the Date, From, and To headers are missing in the encapsulated messages. That can be fixed by the sender.)
-
Trojitá (decent):
-
KMail (cannot deal with more than one
multipart/alternative?): -
Outlook Web Access (ignores the
inlinedirective…):