RFC 3282

Content Language Headers 🎀

• RFC: 3282 🦋
• Title: Content Language Headers
• Author: Harald Tveit Alvestrand, Cisco Systems
• Category: Standards Track
• Date: May 2002
• Obsoletes: 1766
• Network Working Group (the group that published it)

okay so this doc is the one that finally gives us proper Content-Language and Accept-Language headers. it's the glow-up that RFC 1766 needed 💅

Status of this Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸

Copyright Notice 💜

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🦋

this doc defines a Content-language: header 🌷 for when you want to say what language something is in, if that something has RFC 822-like headers (think MIME body parts or Web documents). it also defines an Accept-Language: header for when you want to say which languages you prefer. two headers, one vibe 💖

1. Introduction 🎀

there are a bunch of languages that people use right now, and some that people used to use 🌍

a LOT of those people would way rather get information in a language they actually understand 🫶

sometimes you can have the same info in more than one language, or you can give people tools like dictionaries so they can work through a language that's new to them 📚

other times it's useful for a computer program to turn info from one format (like plain text) into another, like computer-synthesized speech, Braille, or high-quality printed stuff 🖨️✨

the big prerequisite for all of that is labelling the content with an identifier for the language it's in. the identifiers come from [TAGS]. this doc gives you a protocol element for protocols that use RFC 822-like headers to carry those language tags as defined in [TAGS]. it's giving well-organized 🍓

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 👑

2. The Content-language header 🌈

the Content-Language header is for when you want to say what language(s) something is in, where that something has RFC 822-like headers, like MIME body parts or Web documents. it's the main character of this doc 💅

here's the RFC 822 EBNF of the Content-Language header:

   Content-Language = "Content-Language" ":" 1#Language-tag

and here's the stricter RFC 2234 ABNF:

   Content-Language = "Content-Language" ":" [CFWS] Language-List
   Language-List = Language-Tag [CFWS]
                      *("," [CFWS] Language-Tag [CFWS])

the Content-Language header can list several languages, separated by commas 🫧

CFWS is meant to work like the whitespace convention in RFC 822. that means you can put parenthesized comments anywhere in the language sequence, or use continuation lines 🧚 the formal definition is in RFC 2822 [RFC2822].

iykyk: RFC 2822 is super into being liberal with old syntax, so there's also a more lenient "obsolete" grammar:

   obs-content-language = "Content-Language" *WSP ":"
                           [CFWS] Language-List

so here's the rule, bestie 🫶. like RFC 2822, this spec says conforming implementations MUST accept the obs-content-language syntax, but MUST NOT generate it. all generated headers MUST conform to the Content-Language syntax. 🔥 accept the old stuff, never make it yourself

2.1 Examples of Content-language values 🍓

voice recording from downtown Liverpool 🎙️

   Content-type: audio/basic
   Content-Language: en-scouse

a document in Mingo, an American Indian language that doesn't have an ISO 639 code 🪶

   Content-type: text/plain
   Content-Language: i-mingo

an English-French dictionary 📖

   Content-type: application/dictionary
   Content-Language: en, fr (This is a dictionary)

an official European Commission document (in a few of its official languages) 🇪🇺

   Content-type: multipart/alternative
   Content-Language: da, de, el, en, fr, it

an excerpt from Star Trek 🖖

   Content-type: video/mpeg
   Content-Language: i-klingon

3. The Accept-Language header 🦋

the Accept-Language header is for when a user or a process wants to say which language(s) they prefer, again when RFC 822-like headers (like MIME body parts or Web documents) are being used 💖

RFC 822 EBNF of the Accept-Language header:

   Accept-Language = "Accept-Language" ":"
                          1#( language-range [ ";" "q" "=" qvalue ] )

a slightly stricter RFC 2234 ABNF definition:

   Accept-Language = "Accept-Language:" [CFWS] language-q
                     *( "," [CFWS] language-q )
   language-q = language-range [";" [CFWS] "q=" qvalue ] [CFWS]
   qvalue         = ( "0" [ "." 0*3DIGIT ] )
                  / ( "1" [ "." 0*3("0") ] )

and a more liberal RFC 2234 ABNF definition:

   Obs-accept-language = "Accept-Language" *WSP ":" [CFWS]
        obs-language-q *( "," [CFWS] obs-language-q ) [CFWS]
   obs-language-q = language-range
         [ [CFWS] ";" [CFWS] "q" [CFWS] "=" qvalue ]

same deal as before, like RFC 2822 this spec says conforming implementations MUST accept the obs-accept-language syntax, but MUST NOT generate it. all generated messages MUST conform to the Accept-Language syntax. ✨ receive the messy stuff, send the clean stuff

the syntax and semantics of language-range are defined in [TAGS]. the Accept-Language header can list several language-ranges separated by commas, and each one can include a quality value Q 🎀. if there are no Q values, the language-ranges are in priority order, and the leftmost one is the most preferred. this is an extension to the HTTP/1.1 rules, but it matches current practice 🌸

if Q values are given, look at HTTP/1.1 [RFC 2616] for the details on how to evaluate them 🧠

Full Copyright Statement 💖

Okay bestie, the legal bit! 📜 Copyright (C) The Internet Society (2002). All Rights Reserved. ✨

This document and translations of it can be copied and handed out to others. You can also make derivative works that comment on or explain it, or help people implement it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice and this paragraph stay on every copy and derivative work. 🫶

BUT the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: you can change it as needed to develop Internet standards, but then the copyright procedures in the Internet Standards process must be followed, or you can change it to translate it into languages other than English. 🌍

The limited permissions above are perpetual, and the Internet Society and its successors or assigns won't ever revoke them. 🦋

Now the disclaimer, which is very serious and very all caps 😭: this document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

---

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 👑 Thank you, Internet Society, for keeping the RFC Editor running so all of us can read these documents! 🎀