8

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?

siukurnin
  • 191
  • 1
  • 5
  • 2
    I thought multipart/alternative was about offering the same message in different *formats* (typically plain text vs HTML), rather than differing content. – AakashM Mar 14 '13 at 12:23
  • 2
    @AakashM : the RFC reads : When using the Multipart/Alternative body part of MIME, it is possible to have the body parts giving the same information content in different languages. In this case, one should put a Content- Language header on each of the body parts, and a summary Content- Language header onto the Multipart/Alternative itself. – siukurnin Nov 04 '13 at 15:56

3 Answers3

8

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.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
5

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

Matt
  • 515
  • 3
  • 5
2

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.)

  • Trojitá (decent):

    enter image description here

  • KMail (cannot deal with more than one multipart/alternative?):

    enter image description here

  • Outlook Web Access (ignores the inline directive…):

    enter image description here

equaeghe
  • 121
  • 2