Ora esiste un tipo multipart MIME appositamente per questo scopo: multipart/multilingual , definito in RFC 8255 . Non so quanto sia ben supportato questo tipo dai client di posta, anche se ne ho trovato almeno uno che lo supporta: NeoMutt . Tuttavia, a causa del fallback per tipi multipart in sconosciuto a multipart/mixed , è dovrebbe essere possibile comporre già tali messaggi e averli supportati correttamente o visualizzati in modo equivalente a quanto descritto nel risposte di Matt e Bart , se i client di posta seguono gli standard ...
Per avere un'idea di ciò, consideriamo un esempio tratto da RFC (in qualche modo semplificato da 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--
Questo risultato per alcuni clienti che ho testato segue di seguito; non sono terribilmente incoraggianti. Ma prima vorrei sottolineare che per tutti questi client, quando viene aperto un allegato 'messaggio', fanno più o meno la cosa giusta. (Un problema con questo esempio è che mancano le intestazioni Date , From e To nei messaggi incapsulati, che possono essere risolti dal mittente.)
