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: Nik@example.com
To: Nathaniel@example.com
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.)