Multiple Language Content Type
Extracted elements (24)
'message/rfc822' is the preferred Content-Type for individual language parts (over a flat content type) specifically to provide good rendering support in non-conforming clients that will display all parts; 'message/global' is permitted as an alternative as its support grows.
'multipart/multilingual' has similar semantics to 'multipart/alternative' but differs fundamentally in selection logic: instead of choosing by part ordering and Content-Type, the client chooses by matching the Content-Language field against the user's language preferences. This makes language-based dispatch explicit and machine-readable.
The multilingual preface exists solely for backward compatibility: non-conforming clients are expected (per RFC 2046 Sections 5.1.3 and 5.1.7) to treat an unknown multipart subtype as 'multipart/mixed' and display all parts sequentially or as attachments, so the preface helps recipients of such clients understand the message structure.
Email clients that do not understand 'multipart/multilingual' will treat it as 'multipart/mixed' per RFC 2046 Sections 5.1.3 and 5.1.7, rendering all parts sequentially or as attachments. Systems that do not follow this fallback requirement are also non-compliant with MIME.
A conforming email client SHOULD ignore the multilingual preface and select the best-matching language part for the user's preferred language. The matching schemes of RFC 4647 are RECOMMENDED as a starting point. If no language match exists, the client SHOULD select the language-independent part if present, otherwise the first language part after the preface.
A Subject field SHOULD be provided in each language message part, containing a translation of the email subject appropriate for that language. The subject presented to the recipient SHOULD be taken from the selected language part; if absent, the top-level Subject header value is used.
All language message parts MUST have both a Content-Language field and a Content-Type field; they MAY additionally carry a Content-Translation-Type field. Language parts SHOULD be ordered so the first part after the preface is the language most likely recognizable by the recipient, serving as the fallback.
If a From field is present inside a language message part, its value MUST include the same email address as the top-level From header, though the display name MAY be a localized version. On address mismatch, the top-level From value SHOULD be shown to the recipient.
If a language-independent part is present it MUST be the last part and MUST carry a Content-Language field with value 'zxx' (BCP 47 tag for 'no linguistic content'). It SHOULD use Content-Type 'message/rfc822' or 'message/global' to match the language parts.
Interactive implementations MAY offer the user a choice among available language parts or the option to display them all, going beyond automatic selection based on preference settings.
The Content-Language field MUST comply with RFC 3282 (Content Language Headers) and BCP 47 / RFC 5646 (Tags for Identifying Languages). Valid examples include 'en-GB', 'de', 'es-MX, fr', and 'sr-Cyrl'.
The Content-Translation-Type field value MAY be used for further part selection when the user prefers (for example) a human-verified original over a machine translation into their first language. If no translation-type preference is available, the field values MAY be ignored.
The Content-Type for each language message part SHOULD be 'message/rfc822' to maximize support in non-conforming clients. An implementation MAY use 'message/global' as that format becomes more commonplace.
The message SHOULD contain a multilingual preface as the first part; this preface MUST NOT be marked with a Content-Language field, SHOULD have Content-Type 'text/plain', and SHOULD briefly explain in all provided languages that multiple translations follow.
The multilingual preface SHOULD use a UTF-8 charset because it is likely to contain scripts requiring non-US-ASCII characters. Conforming email clients SHOULD only show the single language part matching the user's preference and thus will normally suppress the preface.
The Content-Translation-Type header field identifies the translation provenance of a language message part. It takes one of three initial values: 'original' (source language), 'human' (human-translated or human-corrected), or 'automated' (machine-translated without correction). Additional values may be registered via the 'Specification Required' procedure.
The 'multipart/multilingual' MIME subtype enables a single email message to carry multiple language versions of the same content. Each language version is an alternative body part, and the receiving client selects the appropriate part based on Content-Language and optionally Content-Translation-Type rather than on part ordering or Content-Type values.
IANA created a new 'Content-Translation-Type Header Field Values' registry using the 'Specification Required' procedure. Initial values are 'original', 'human', and 'automated'. Each registration must include a value, a short description, and a specification reference.
The 'Content-Translation-Type' header field has been added to the IANA 'Permanent Message Header Field Names' registry with applicable protocol 'MIME' and status 'standard'.
The 'multipart/multilingual' media type has been registered with IANA under the 'multipart' type. Required parameter: boundary (from RFC 2046). Intended usage: COMMON. Applications include MTAs, MUAs, spam/virus filters, and message authentication modules.
A recipient who cannot read a translation may inadvertently forward undesirable content embedded in that translation to a third party who can read it. Interactive implementations are encouraged to let recipients view all available translations before forwarding.
Because language parts use Content-Type 'message/rfc822' or 'message/global', they may contain From fields that differ from the top-level From address. A non-conforming email client that exposes these inner From values could mislead a recipient about the true sender's identity.
Language parts are claimed to be direct translations of the original but may contain undesirable or malicious content. A spam or content filter that does not scan all parts could miss harmful material in alternate language parts. The risk is mitigated because RFC 2046 requires unknown multipart subtypes to be treated as 'multipart/mixed', causing each part to be scanned individually.
The ABNF for Content-Translation-Type is: Content-Translation-Type = [FWS] translationtype; translationtype = "original" / "human" / "automated" / translTypeExt; translTypeExt = 1*atext. FWS and atext are imported from RFC 5322.