RFC 5646

Tags for Identifying Languages

📅 published September 2009, from ietf

RFC 5646: Tags for Identifying Languages ✨

Part 1 of 19 🎀

Okay bestie, let's start with the basics 💅 This one is RFC 5646, called Tags for Identifying Languages, and it came out in September 2009. It's a Best Current Practice, which is why it's also BCP 47 🧚. The co-authors are A. Phillips, Ed. from Lab126 and M. Davis, Ed. from Google, and they're both listed as editors 🫶 It's from the Network Working Group (the IETF crew) and it obsoletes RFC 4646, so that older version is officially out and this one is the new main character 👑

The big idea: it defines language tags, which are little labels that say what language a piece of content is in, plus a way to register new values and make your own private ones 💖

Tags for Identifying Languages

Abstract 🌸

Okay so the abstract says this document covers the structure, content, construction, and semantics of language tags. Those are the tags you use when you want to say what language an information object is in 📚 It also explains how to register values you can use in language tags, and how to create user-defined extensions for private swapping between people who agree on them 🦋

Status of This Memo 💌

This doc is a Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for making it better ✨ Anyone can share it, since distribution is unlimited 🌈

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which were in effect on the date it was published. The rules are at http://trustee.ietf.org/license-info, so please read them carefully because they spell out your rights and restrictions for this document 🙈

This document might include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭 Unless you get a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌸

Table of Contents 📖

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  The Language Tag . . . . . . . . . . . . . . . . . . . . . . .  4
    2.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  4
      2.1.1.  Formatting of Language Tags  . . . . . . . . . . . . .  6
    2.2.  Language Subtag Sources and Interpretation . . . . . . . .  8
      2.2.1.  Primary Language Subtag . . . . . . . . . . . . . . . . 9
      2.2.2.  Extended Language Subtags  . . . . . . . . . . . . . . 11
      2.2.3.  Script Subtag  . . . . . . . . . . . . . . . . . . . . 12
      2.2.4.  Region Subtag  . . . . . . . . . . . . . . . . . . . . 13
      2.2.5.  Variant Subtags  . . . . . . . . . . . . . . . . . . . 15
      2.2.6.  Extension Subtags  . . . . . . . . . . . . . . . . . . 16
      2.2.7.  Private Use Subtags  . . . . . . . . . . . . . . . . . 18
      2.2.8.  Grandfathered and Redundant Registrations  . . . . . . 18
      2.2.9.  Classes of Conformance . . . . . . . . . . . . . . . . 19
  3.  Registry Format and Maintenance  . . . . . . . . . . . . . . . 21
    3.1.  Format of the IANA Language Subtag Registry  . . . . . . . 21
      3.1.1.  File Format  . . . . . . . . . . . . . . . . . . . . . 21
      3.1.2.  Record and Field Definitions . . . . . . . . . . . . . 23
      3.1.3.  Type Field . . . . . . . . . . . . . . . . . . . . . . 26
      3.1.4.  Subtag and Tag Fields  . . . . . . . . . . . . . . . . 26
      3.1.5.  Description Field  . . . . . . . . . . . . . . . . . . 26
      3.1.6.  Deprecated Field . . . . . . . . . . . . . . . . . . . 28
      3.1.7.  Preferred-Value Field  . . . . . . . . . . . . . . . . 28
      3.1.8.  Prefix Field . . . . . . . . . . . . . . . . . . . . . 31
      3.1.9.  Suppress-Script Field  . . . . . . . . . . . . . . . . 32
      3.1.10. Macrolanguage Field  . . . . . . . . . . . . . . . . . 32
      3.1.11. Scope Field  . . . . . . . . . . . . . . . . . . . . . 33
      3.1.12. Comments Field . . . . . . . . . . . . . . . . . . . . 34
    3.2.  Language Subtag Reviewer . . . . . . . . . . . . . . . . . 35
    3.3.  Maintenance of the Registry  . . . . . . . . . . . . . . . 35
    3.4.  Stability of IANA Registry Entries . . . . . . . . . . . . 36
    3.5.  Registration Procedure for Subtags . . . . . . . . . . . . 41
    3.6.  Possibilities for Registration . . . . . . . . . . . . . . 46
    3.7.  Extensions and the Extensions Registry . . . . . . . . . . 49
    3.8.  Update of the Language Subtag Registry . . . . . . . . . . 52
    3.9.  Applicability of the Subtag Registry . . . . . . . . . . . 52
  4.  Formation and Processing of Language Tags  . . . . . . . . . . 53
    4.1.  Choice of Language Tag . . . . . . . . . . . . . . . . . . 53
      4.1.1.  Tagging Encompassed Languages  . . . . . . . . . . . . 58
      4.1.2.  Using Extended Language Subtags  . . . . . . . . . . . 59
    4.2.  Meaning of the Language Tag  . . . . . . . . . . . . . . . 61
    4.3.  Lists of Languages . . . . . . . . . . . . . . . . . . . . 63
    4.4.  Length Considerations  . . . . . . . . . . . . . . . . . . 63
      4.4.1.  Working with Limited Buffer Sizes  . . . . . . . . . . 64
      4.4.2.  Truncation of Language Tags  . . . . . . . . . . . . . 65
    4.5.  Canonicalization of Language Tags  . . . . . . . . . . . . 66
    4.6.  Considerations for Private Use Subtags . . . . . . . . . . 68
  5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 69
    5.1.  Language Subtag Registry . . . . . . . . . . . . . . . . . 69
    5.2.  Extensions Registry  . . . . . . . . . . . . . . . . . . . 71
  6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 71
  7.  Character Set Considerations . . . . . . . . . . . . . . . . . 72
  8.  Changes from RFC 4646  . . . . . . . . . . . . . . . . . . . . 73
  9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 76
    9.1.  Normative References . . . . . . . . . . . . . . . . . . . 76
    9.2.  Informative References . . . . . . . . . . . . . . . . . . 78
  Appendix A.  Examples of Language Tags (Informative) . . . . . . . 80
  Appendix B.  Examples of Registration Forms  . . . . . . . . . . . 82
  Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 83

1. Introduction ✨

Humans on this planet have used lots of languages, both now and throughout history 🌍 There are plenty of reasons you'd want to identify which language is being used when information is presented or requested 💖

The language of an information item, or a user's language preferences, often has to be identified so the right processing can happen 🎀 For example, a user's language preferences in a Web browser can be used to pick the right Web pages 🦋 Language info can also help you choose tools like dictionaries that help with processing or understanding content in different languages 📚 Knowing the specific language of some content might be useful, or even required, for certain kinds of processing. Think spell-checking, computer-synthesized speech, Braille transcription, or high-quality print renderings 🖨️✨

One way to say which language is used is to label the content with an identifier, or "tag" 🏷️ These tags can also be used to specify a user's preferences when picking content, or to label other attributes of content and its related resources 🌸

Sometimes language tags show extra language attributes of content too 🌈 For example, saying which dialect, writing system, or orthography a document or resource uses can help a user get info in a form they actually understand. It can also matter for processing or rendering the content into the right form or style 💅

This document specifies a particular identifier mechanism, which is the language tag, plus a registration function for the values used to form tags 🧚 It also defines a mechanism for private use values and future extensions 🔮

This document replaces [RFC4646] (which obsoleted [RFC3066] which, in turn, replaced [RFC1766]). Together with [RFC4647], this document makes up BCP 47. For a list of changes in this document, see Section 8 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶 Those are the official BCP 14 key words, so read them carefully bestie!! ⭐

2. The Language Tag 🎀

Language tags help identify languages for communication, whether they're spoken, written, signed, or signaled some other way 🗣️✍️ That includes constructed and artificial languages, but it leaves out languages that aren't meant mainly for humans to communicate in, like programming languages 💻 Sorry coding languages, you're not invited to this one 💀

2.1. Syntax ✨

okay bestie, so a language tag is basically a chain of "subtags" stuck together with hyphens 🔗 Each subtag narrows down the language a little more, like zooming into a map 🗺️ A subtag is just a bunch of letters and digits, and the hyphen (-, [Unicode] U+002D) is what keeps them separate.

Here's the lowkey genius part 💅 Every subtag type can be figured out just from its length, where it sits in the tag, and what it contains. So even if you've never seen that exact subtag before, you can still tell what kind it is 🦋 That means a tag processor doesn't need a list of every valid tag (aka a copy of some version of the IANA Language Subtag Registry) just to do basic searching and matching 🧚 The only exceptions are the grandfathered tags in the regular and irregular productions below. They were registered under [RFC3066], they're a fixed list, and they can never change 🌸

Here's the ABNF [RFC5234] for the tag:

 Language-Tag  = langtag             ; normal language tags
               / privateuse          ; private use tag
               / grandfathered       ; grandfathered tags

 langtag       = language
                 ["-" script]
                 ["-" region]
                 *("-" variant)
                 *("-" extension)
                 ["-" privateuse]

 language      = 2*3ALPHA            ; shortest ISO 639 code
                 ["-" extlang]       ; sometimes followed by
                                     ; extended language subtags
               / 4ALPHA              ; or reserved for future use
               / 5*8ALPHA            ; or registered language subtag

 extlang       = 3ALPHA              ; selected ISO 639 codes
                 *2("-" 3ALPHA)      ; permanently reserved

 script        = 4ALPHA              ; ISO 15924 code

 region        = 2ALPHA              ; ISO 3166-1 code
               / 3DIGIT              ; UN M.49 code

 variant       = 5*8alphanum         ; registered variants
               / (DIGIT 3alphanum)

 extension     = singleton 1*("-" (2*8alphanum))

                                     ; Single alphanumerics
                                     ; "x" reserved for private use
 singleton     = DIGIT               ; 0 - 9
               / %x41-57             ; A - W
               / %x59-5A             ; Y - Z
               / %x61-77             ; a - w
               / %x79-7A             ; y - z

 privateuse    = "x" 1*("-" (1*8alphanum))

 grandfathered = irregular           ; non-redundant tags registered
               / regular             ; during the RFC 3066 era

 irregular     = "en-GB-oed"         ; irregular tags do not match
               / "i-ami"             ; the 'langtag' production and
               / "i-bnn"             ; would not otherwise be
               / "i-default"         ; considered 'well-formed'
               / "i-enochian"        ; These tags are all valid,
               / "i-hak"             ; but most are deprecated
               / "i-klingon"         ; in favor of more modern
               / "i-lux"             ; subtags or subtag
               / "i-mingo"           ; combination
               / "i-navajo"
               / "i-pwn"
               / "i-tao"
               / "i-tay"
               / "i-tsu"
               / "sgn-BE-FR"
               / "sgn-BE-NL"
               / "sgn-CH-DE"

 regular       = "art-lojban"        ; these tags match the 'langtag'
               / "cel-gaulish"       ; production, but their subtags
               / "no-bok"            ; are not extended language
               / "no-nyn"            ; or variant subtags: their meaning
               / "zh-guoyu"          ; is defined by their registration
               / "zh-hakka"          ; and all of these are deprecated
               / "zh-min"            ; in favor of a more modern
               / "zh-min-nan"        ; subtag or sequence of subtags
               / "zh-xiang"

 alphanum      = (ALPHA / DIGIT)     ; letters and numbers

Figure 1: Language Tag ABNF 🎀

For examples of language tags, check out Appendix A 📖

Every subtag is at most eight characters long, and whitespace is a big no-no in a language tag 🙅‍♀️ There's one little subtlety in the variant production: a variant that starts with a digit has a minimum length of four characters, but one that starts with a letter needs a minimum of five 🤓

Technically [RFC5234] talks about octets, but language tags are really sequences of characters from the US-ASCII [ISO646] repertoire 💕 They MAY show up in documents and apps that use other encodings too, as long as those encodings cover the relevant part of US-ASCII. For example, an XML document using the UTF-16LE [RFC2781] encoding of [Unicode] is totally fine ✨

2.1.1. Formatting of Language Tags

Okay, capitalization drama incoming 🙈 Language tags and their subtags, including private use and extensions, are always treated as case insensitive. There are conventions for capitalizing some subtags, but those MUST NOT be taken to carry any meaning 😭

So "mn-Cyrl-MN" is the same as "MN-cYRL-mn" or "mN-cYrL-Mn" (or literally any other mix). Every single one of those means the same thing: Mongolian written in the Cyrillic script as used in Mongolia 🇲🇳💜

The ABNF doesn't care about upper versus lower case either. Uppercase US-ASCII letters from 'A' through 'Z' are always treated as equivalent to their lowercase versions from 'a' through 'z' 🫶 So "I-AMI" is equal to the irregular value "i-ami" 🌈

Even though case doesn't change meaning, keeping things consistently formatted helps people read tags more easily ✨ The format of subtags in the registry is RECOMMENDED as the form to use in language tags 📋 It mostly lines up with the usual conventions from the ISO standards these subtags come from:

  • [ISO639-1] recommends that language codes be written in lowercase ('mn' Mongolian).
  • [ISO15924] recommends that script codes use lowercase with the initial letter capitalized ('Cyrl' Cyrillic).
  • [ISO3166-1] recommends that country codes be capitalized ('MN' Mongolia).

You can reproduce this formatting without touching the registry 🧁 All subtags, including extension and private use subtags, use lowercase letters, with two exceptions. Two-letter subtags and four-letter subtags that don't appear at the start of the tag and don't come right after a singleton get special treatment. Two-letter ones are all uppercase (like "en-CA-x-ca" or "sgn-BE-FR"), and four-letter ones are titlecase (like "az-Latn-x-latn") 💅

Note: Case folding of ASCII letters in certain locales, unless carefully handled, sometimes produces non-ASCII character values. 🚨 The Unicode Character Database file "SpecialCasing.txt" [SpecialCasing] lists the specific cases that are known to cause problems with this. The big one is the letter 'i' (U+0069) in Turkish and Azerbaijani, which gets uppercased to U+0130 (LATIN CAPITAL LETTER I WITH DOT ABOVE). Implementers SHOULD specify a locale-neutral casing operation so that case folding of subtags doesn't produce this value, because it's illegal in language tags 💀 For example, if you uppercase the region subtag 'in' using Turkish locale rules, you get the sequence U+0130 U+004E instead of the expected 'IN'. Yikes 😭

2.2. Language Subtag Sources and Interpretation 📚

The namespace of language tags and their subtags is run by the Internet Assigned Numbers Authority (IANA) under the rules in Section 5 of this document 👑 The Language Subtag Registry that IANA maintains is the official source for valid subtags. The other standards referenced in this section are where the source material for that registry comes from 🧠

Here are some terms we'll be using 🎀

  • "Tag" means a complete language tag, like "sr-Latn-RS" or "az-Arab-IR". Examples of tags in this document are wrapped in double-quotes ("en-US").
  • "Subtag" means one specific chunk of a tag, separated by a hyphen. For example, the subtags 'zh', 'Hant', and 'CN' in the tag "zh-Hant-CN". Examples of subtags in this document are wrapped in single quotes ('Hant').
  • "Code" means values defined in external standards that get used as subtags in this document. For example, 'Hant' is an [ISO15924] script code that was used to define the 'Hant' script subtag for use in a language tag. Examples of codes in this document are wrapped in single quotes ('en', 'Hant') 🌸

Language tags are designed so that each subtag type has its own unique length and content restrictions 🦋 That makes it possible to tell what type a subtag is, even if you don't recognize its actual content. So tags can be parsed and processed without needing the latest version of the underlying standards or the IANA registry, and the exception handling when parsing gets way simpler 🙌

Some subtags in the IANA registry don't come from an underlying standard. Those can only show up in specific spots in a tag: they can only be primary language subtags or variant subtags 🍓

Private use and extension subtag sequences MUST occur at the end of the sequence of subtags, and they MUST NOT be mixed in with subtags defined elsewhere in this document 🚫 These sequences start with single-character subtags, and those single characters are reserved like this:

  • The single-letter subtag 'x' introduces a sequence of private use subtags. What a private use subtag means is decided only by private agreement. It isn't defined by the rules in this section or by any standard or registry in this document 🤫
  • The single-letter subtag 'i' is used by some grandfathered tags, like "i-default", where it always shows up in the first position and can't be mistaken for an extension 🧚
  • All other single-letter and single-digit subtags are reserved to introduce standardized extension subtag sequences, as described in Section 3.7 🔮

2.2.1. Primary Language Subtag ✨

okay bestie, the primary language subtag is the first subtag in a language tag and it literally can't be left out 😭 but there are two plot twists 👀

  • The single-character subtag x as the primary subtag means the whole tag is made up only of subtags whose meaning comes from a private agreement 🔐. So in the tag x-fr-CH, the fr and CH are NOT French or Switzerland (or anything else in the IANA registry) unless there's a private agreement saying so 💅. See Section 4.6.
  • The single-character subtag i shows up in some grandfathered tags (see Section 2.2.8), like i-klingon and i-bnn 🧚. (Other grandfathered tags have a primary language subtag in their first position.)

here's the rulebook for the primary language subtag 📜

  1. Two-character primary language subtags were defined in the IANA registry based on the assignments in the standard "ISO 639-1:2002, Codes for the representation of names of languages -- Part 1: Alpha-2 code" [ISO639-1], or on assignments made later by the ISO 639-1 registration authority (RA) or the governing standardization bodies 🌸
  2. Three-character primary language subtags in the IANA registry were defined according to one of these extra ISO 639 parts, or to assignments made later by the relevant ISO 639 registration authorities or governing standardization bodies 🎀
    • A. "ISO 639-2:1998 - Codes for the representation of names of languages -- Part 2: Alpha-3 code - edition 1" [ISO639-2]
    • B. "ISO 639-3:2007 - Codes for the representation of names of languages -- Part 3: Alpha-3 code for comprehensive coverage of languages" [ISO639-3]
    • C. "ISO 639-5:2008 - Codes for the representation of names of languages -- Part 5: Alpha-3 code for language families and groups" [ISO639-5]
  3. The subtags in the range qaa through qtz are reserved for private use in language tags 🦋. These subtags match codes that ISO 639-2 reserved for private use. These codes MAY be used for non-registered primary language subtags (instead of using private use subtags after x-). Please refer to Section 4.6 for more info on private use subtags.
  4. Four-character language subtags are reserved for possible future standardization 🔮.
  5. Any language subtags that are five to eight characters long in the IANA registry were defined through the registration process in Section 3.5, and they MAY be used to form the primary language subtag 🍓. An example of what that kind of registration might look like is the grandfathered IANA registration i-enochian. The subtag enochian could be registered in the IANA registry as a primary language subtag (assuming ISO 639 doesn't register this language first), which would make tags like enochian-AQ and enochian-Latn valid 🌈.

When this document was created, there were no examples of this kind of subtag. Future registrations of this type are discouraged: any attempt to register a new proposed primary language MUST be made to the ISO 639 registration authority 🙅‍♀️. Proposals that the ISO 639 registration authority rejects are unlikely to meet the criteria for primary language subtags, so they're unlikely to get registered either 💀.

  1. Other values MUST NOT be assigned to the primary subtag, except through a revision or update of this document 🚫.

when a language has both an ISO 639-1 two-character code AND a three-character code (assigned by ISO 639-2, ISO 639-3, or ISO 639-5), only the ISO 639-1 two-character code is defined in the IANA registry 🫶.

when a language has no ISO 639-1 two-character code, and the ISO 639-2/T (Terminology) code and the ISO 639-2/B (Bibliographic) code for that language are different, only the Terminology code is defined in the IANA registry 📚. When this document was created, every language that had both kinds of three-character codes also had a two-character code, and future assignments like this are expected not to happen 🙏.

to keep the canonical form of tags stable, if a two-character code gets added to ISO 639-1 for a language that already had a three-character code in ISO 639-2 or ISO 639-3, the two-character code MUST NOT be registered 🛑. See Section 3.4.

for example, if some content was tagged with haw (Hawaiian), which currently has no two-character code, the tag wouldn't need to change if ISO 639-1 assigned a two-character code to Hawaiian later on 🌺.

to dodge these versioning and subtag-choice problems (like the ones people ran into during the switch from RFC 1766 to RFC 3066) 😩, and to keep the subtags defined by this document canonical, the ISO 639 Registration Authority Joint Advisory Committee (ISO 639/RA-JAC) put this statement in [iso639.prin]:

"A language code already in ISO 639-2 at the point of freezing ISO 639-1 shall not later be added to ISO 639-1. This is to ensure consistency in usage over time, since users are directed in Internet applications to employ the alpha-3 code when an alpha-2 code for that language is not available."

2.2.2. Extended Language Subtags 🦋

extended language subtags are used to identify certain specially picked languages that, for historical and compatibility reasons, are closely tied to or tagged using an existing primary language subtag 💜. They're always used together with their enclosing primary language subtag (shown in a Prefix field in the registry) when forming the language tag. Every language with an extended language subtag in the registry also has an identical primary language subtag record in the registry 👯. That primary language subtag is RECOMMENDED for forming the language tag ⭐. Here are the rules for extended language subtags:

  1. Extended language subtags consist ONLY of three-letter subtags 🔤. All the extended language subtag records in the registry were defined according to the assignments in [ISO639-3]. Language collections and groupings, like the ones defined in [ISO639-5], are specifically excluded from being extended language subtags 🙅‍♀️.
  2. Extended language subtag records MUST include exactly one Prefix field, naming an appropriate subtag or sequence of subtags for that extended language subtag 🧩.
  3. Extended language subtag records MUST include a Preferred-Value. The Preferred-Value and Subtag fields MUST be identical 🪞.
  4. Even though the ABNF production extlang allows up to three extended language tags in the language tag, extended language subtags MUST NOT include another extended language subtag in their Prefix. That means the second and third extended language subtag positions in a language tag are permanently reserved, and tags that use those subtags in those positions are, and always will be, invalid 🚫💀.

for example, the macrolanguage Chinese (zh) covers a bunch of languages 🥢. For compatibility reasons, each of these languages has both a primary and an extended language subtag in the registry. A few picked examples are Gan Chinese (gan), Cantonese Chinese (yue), and Mandarin Chinese (cmn). Each one is encompassed by the macrolanguage zh (Chinese), so each has the prefix zh in its registry record ✨. That means Gan Chinese shows up in tags starting with zh-gan or gan, Cantonese with either yue or zh-yue, and Mandarin Chinese with zh-cmn or cmn 🌸. The language subtag zh can still be used without an extended language subtag to label a resource as some unspecified variety of Chinese 🫶. The primary language subtag (gan, yue, cmn) is preferred over the extended language form (zh-gan, zh-yue, zh-cmn) 👑.

2.2.3. Script Subtag 🖋️

script subtags show which script or writing system variation distinguishes the written forms of a language or its dialects 📝. Here are the rules for script subtags:

  1. Script subtags MUST follow any primary and extended language subtags, and MUST precede any other type of subtag 🧁.
  2. Script subtags consist of four letters and were defined according to the assignments in [ISO15924] ("Information and documentation -- Codes for the representation of names of scripts"), or assigned later by the ISO 15924 registration authority or governing standardization bodies 🔠. Only codes assigned by ISO 15924 will be considered for registration.
  3. The script subtags Qaaa through Qabx are reserved for private use in language tags 🕵️‍♀️. These subtags match codes that ISO 15924 reserved for private use. These codes MAY be used for non-registered script values. Please refer to Section 4.6 for more info on private use subtags.
  4. There MUST be at most one script subtag in a language tag 1️⃣. The script subtag SHOULD be omitted when it adds no distinguishing value to the tag, or when the primary or extended language subtag's record in the subtag registry includes a Suppress-Script field listing the applicable script subtag 🙈.

for example: sr-Latn represents Serbian written in the Latin script 🌷.

2.2.4. Region Subtag 🌍

Region subtags are the little hints that say which country, territory, or region a language is for 💖. Usually they show off regional dialects, local vibes, or region-specific spelling. They can also mean the content works across a whole region, like Spanish that's tailored to be useful all over Latin America 🌎.

The following rules apply to the region subtags:

  1. Region subtags MUST follow any primary language, extended language, or script subtags and MUST precede any other type of subtag. 📍
  2. Two-letter region subtags were defined according to the assignments found in [ISO3166-1] ("Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes"), using the list of alpha-2 country codes or using assignments subsequently made by the ISO 3166-1 maintenance agency or governing standardization bodies. In addition, the codes that are "exceptionally reserved" (as opposed to "assigned") in ISO 3166-1 were also defined in the registry, with the exception of 'UK', which is an exact synonym for the assigned code 'GB'. 🇬🇧
  3. The region subtags 'AA', 'QM'-'QZ', 'XA'-'XZ', and 'ZZ' are reserved for private use in language tags. These subtags correspond to codes reserved by ISO 3166 for private use. These codes MAY be used for private use region subtags (instead of using a private use subtag sequence). Please refer to Section 4.6 for more information on private use subtags. 🔒
  4. Three-character region subtags consist solely of digit (number) characters and were defined according to the assignments found in the UN Standard Country or Area Codes for Statistical Use [UN_M.49] or assignments subsequently made by the governing standards body. Not all of the UN M.49 codes are defined in the IANA registry. The following rules define which codes are entered into the registry as valid subtags: 🔢
    • A. UN numeric codes assigned to 'macro-geographical (continental)' or sub-regions MUST be registered in the registry. These codes are not associated with an assigned ISO 3166-1 alpha-2 code and represent supra-national areas, usually covering more than one nation, state, province, or territory. 🗺️
    • B. UN numeric codes for 'economic groupings' or 'other groupings' MUST NOT be registered in the IANA registry and MUST NOT be used to form language tags. 🚫
    • C. When ISO 3166-1 reassigns a code formerly used for one country or area to another country or area and that code already is present in the registry, the UN numeric code for that country or area MUST be registered in the registry as described in Section 3.4 and MUST be used to form language tags that represent the country or region for which it is defined (rather than the recycled ISO 3166-1 code). ♻️
    • D. UN numeric codes for countries or areas for which there is an associated ISO 3166-1 alpha-2 code in the registry MUST NOT be entered into the registry and MUST NOT be used to form language tags. Note that the ISO 3166-based subtag in the registry MUST actually be associated with the UN M.49 code in question. 🔗
    • E. For historical reasons, the UN numeric code 830 (Channel Islands), which was not registered at the time this document was adopted and had, at that time, no corresponding ISO 3166-1 code, MAY be entered into the IANA registry via the process described in Section 3.5, provided no ISO 3166-1 code with that exact meaning has been previously registered. 🏝️
    • F. All other UN numeric codes for countries or areas that do not have an associated ISO 3166-1 alpha-2 code MUST NOT be entered into the registry and MUST NOT be used to form language tags. For more information about these codes, see Section 3.4. 🙅‍♀️
  5. The alphanumeric codes in Appendix X of the UN document MUST NOT be entered into the registry and MUST NOT be used to form language tags. (At the time this document was created, these values matched the ISO 3166-1 alpha-2 codes.) 📝
  6. There MUST be at most one region subtag in a language tag and the region subtag MAY be omitted, as when it adds no distinguishing value to the tag. ✌️

For example:

  • "de-AT" represents German ('de') as used in Austria ('AT'). 🇦🇹
  • "sr-Latn-RS" represents Serbian ('sr') written using Latin script ('Latn') as used in Serbia ('RS'). 🇷🇸
  • "es-419" represents Spanish ('es') appropriate to the UN-defined Latin America and Caribbean region ('419'). 💃

2.2.5. Variant Subtags 🦋

Variant subtags point out extra, well-known twists that define a language or its dialects and aren't covered by any other subtag ✨. The following rules apply to the variant subtags:

  1. Variant subtags MUST follow any primary language, extended language, script, or region subtags and MUST precede any extension or private use subtag sequences. 🧩
  2. Variant subtags, as a collection, are not associated with any particular external standard. The meaning of variant subtags in the registry is defined in the course of the registration process defined in Section 3.5. Note that any particular variant subtag might be associated with some external standard. However, association with a standard is not required for registration. 📚
  3. More than one variant MAY be used to form the language tag. 🎀
  4. Variant subtags MUST be registered with IANA according to the rules in Section 3.5 of this document before being used to form language tags. In order to distinguish variants from other types of subtags, registrations MUST meet the following length and content restrictions: 📏
    1. Variant subtags that begin with a letter (a-z, A-Z) MUST be at least five characters long.
    2. Variant subtags that begin with a digit (0-9) MUST be at least four characters long.
  5. The same variant subtag MUST NOT be used more than once within a language tag. 🚫
    • For example, the tag "de-DE-1901-1901" is not valid. 🙅‍♀️

Variant subtag records in the Language Subtag Registry MAY include one or more 'Prefix' (Section 3.1.8) fields. Each 'Prefix' indicates a suitable sequence of subtags for forming (with other subtags, as appropriate) a language tag when using the variant. 🗝️

Most variants that share a prefix are mutually exclusive. For example, the German orthographic variations '1996' and '1901' SHOULD NOT be used in the same tag, as they represent the dates of different spelling reforms. A variant that can meaningfully be used in combination with another variant SHOULD include a 'Prefix' field in its registry record that lists that other variant. For example, if another German variant 'example' were created that made sense to use with '1996', then 'example' should include two 'Prefix' fields: "de" and "de-1996". 🙅‍♀️💫

For example:

  • "sl-nedis" represents the Natisone or Nadiza dialect of Slovenian. 🇸🇮
  • "de-CH-1996" represents German as used in Switzerland and as written using the spelling reform beginning in the year 1996 C.E. 🇨🇭
Heads up, bestie: the lowercase "should" in that last bit isn't the BCP 14 kind, so don't go treating it as a hard rule 🫶

2.2.6. Extension Subtags 🧚

Extensions are the way to stretch language tags for all sorts of apps 🌈. They're meant to carry info that's often used alongside languages or language tags but isn't actually part of identifying the language itself. See Section 3.7. The following rules apply to extensions:

  1. An extension MUST follow at least a primary language subtag. That is, a language tag cannot begin with an extension. Extensions extend language tags, they do not override or replace them. For example, "a-value" is not a well-formed language tag, while "de-a-value" is. Note that extensions cannot be used in tags that are entirely private use (that is, tags starting with "x-"). 🙅‍♀️
  2. Extension subtags are separated from the other subtags defined in this document by a single-character subtag (called a "singleton"). The singleton MUST be one allocated to a registration authority via the mechanism described in Section 3.7 and MUST NOT be the letter 'x', which is reserved for private use subtag sequences. 🔑
  3. Each singleton subtag MUST appear at most one time in each tag (other than as a private use subtag). That is, singleton subtags MUST NOT be repeated. For example, the tag "en-a-bbb-a-ccc" is invalid because the subtag 'a' appears twice. Note that the tag "en-a-bbb-x-a-ccc" is valid because the second appearance of the singleton 'a' is in a private use sequence. 🔁
  4. Extension subtags MUST meet whatever requirements are set by the document that defines their singleton prefix and whatever requirements are provided by the maintaining authority. Note that there might not be a registry of these subtags and validating processors are not required to validate extensions. 📜
  5. Each extension subtag MUST be from two to eight characters long and consist solely of letters or digits, with each subtag separated by a single '-'. Case distinctions are ignored in extensions (as with any language subtag) and normalized subtags of this type are expected to be in lowercase. 🔤
  6. Each singleton MUST be followed by at least one extension subtag. For example, the tag "tlh-a-b-foo" is invalid because the first singleton 'a' is followed immediately by another singleton 'b'. 🙈
  7. Extension subtags MUST follow all primary language, extended language, script, region, and variant subtags in a tag and MUST precede any private use subtag sequences. 🧱
  8. All subtags following the singleton and before another singleton are part of the extension. Example: In the tag "fr-a-Latn", the subtag 'Latn' does not represent the script subtag 'Latn' defined in the IANA Language Subtag Registry. Its meaning is defined by the extension 'a'. 🕵️‍♀️
  9. In the event that more than one extension appears in a single tag, the tag SHOULD be canonicalized as described in Section 4.5, by ordering the various extension sequences into case-insensitive ASCII order. 💅

For example, if an extension were defined for the singleton 'r' and it defined the subtags shown, then the following tag would be a valid example: "en-Latn-GB-boont-r-extended-sequence-x-private" 🎉

2.2.7. Private Use Subtags

Okay so private use subtags are basically your secret handshake 🫶 They let you flag language distinctions that matter in a specific context, as long as everyone involved privately agreed on them ✨ Here are the ground rules:

  1. Private use subtags are separated from the other subtags defined in this document by the reserved single-character subtag x 💅
  2. Private use subtags MUST conform to the format and content constraints defined in the ABNF for all subtags. That means they MUST consist solely of letters and digits and not exceed eight characters in length 🔢
  3. Private use subtags MUST follow all primary language, extended language, script, region, variant, and extension subtags in the tag. Another way to say this is that every subtag after the singleton x MUST be considered private use. For example, the subtag US in the tag en-x-US is a private use subtag 🇺🇸
  4. A tag MAY consist entirely of private use subtags 🌈
  5. No source is defined for private use subtags. Use of private use subtags is by private agreement only 🤫
  6. Private use subtags are NOT RECOMMENDED where alternatives exist or for general interchange. See Section 4.6 for more information on choosing private use subtags 🙈

Picture this: a group of scholars is studying some medieval Greek texts 📜 They could agree on a set of private use subtags to tell apart the different writing styles in the texts. For example, they might use el-x-koine for documents in the "common" style and el-x-attic for other documents that imitate the Attic style. Outside processes and systems wouldn't recognize these subtags, but they'd be super useful for sorting texts within the group 🧚

There's one more thing to watch for. The registry also has subtags derived from codes that ISO 639, ISO 15924, or ISO 3166 reserved for private use. Don't mix these up with private use subtag sequences that follow the subtag x. See Section 4.6 💜

2.2.8. Grandfathered and Redundant Registrations

Before RFC 4646 came along, whole language tags were registered under the rules in [RFC1766] and/or [RFC3066]. Here's the good news: every one of those registered tags is still valid as a language tag 🎀

A lot of them became redundant once either [RFC4646] or this document arrived 🍓 A redundant tag is a grandfathered registration whose individual subtags show up in the registry with the same semantic meaning. For instance, the tag "zh-Hant" (Traditional Chinese) can now be built from the subtags zh (Chinese) and Hant (Han script traditional variant) ✨ These redundant tags stay in the registry as records of type redundant, mostly as a bit of historical curiosity 📚

The rest of the previously registered tags are called "grandfathered" 👑 They fall into two groups, "regular" and "irregular".

Grandfathered tags that (appear to) match the langtag production in Figure 1 are considered "regular" grandfathered tags. These tags contain one or more subtags that either don't show up in the registry on their own or show up with a different semantic meaning. Each tag, as a whole, represents a language or a collection of languages 🌸

Grandfathered tags that don't match the langtag production in the ABNF and would otherwise be invalid are considered "irregular" grandfathered tags. The one exception is "en-GB-oed", which is a variant of "en-GB". Every other irregular tag, as a whole, represents a language 💀

A lot of the grandfathered tags have since been superseded by newer subtags. Each superseded record includes a Preferred-Value field, and that's the value you should use when forming language tags for that meaning. For example, the tag "art-lojban" is superseded by the primary language subtag jbo 🦋

2.2.9. Classes of Conformance

Implementations sometimes need to describe what they can do with the rules and practices in this document 💅 You can check or verify tags in a bunch of different ways, but this document formally defines two specific classes of tag conformance.

A tag is considered "well-formed" if it conforms to the ABNF (Section 2.1). A tag can be well-formed in terms of syntax and still not be valid in terms of content. That said, lots of operations involving language tags work perfectly fine without knowing anything about the meaning or validity of the subtags 🫶

A tag is considered "valid" if it satisfies these conditions:

  • The tag is well-formed.
  • Either the tag is in the list of grandfathered tags, or all of its primary language, extended language, script, region, and variant subtags appear in the IANA Language Subtag Registry as of the particular registry date.
  • There are no duplicate variant subtags.
  • There are no duplicate singleton (extension) subtags.

Heads up: a tag's validity depends on the date of the registry you validate it against 📅 A newer copy of the registry might include a subtag that an older version doesn't have.

A tag is considered valid for a given extension (Section 3.7), as of a particular version, revision, and date, if it meets the criteria for "valid" above and also satisfies this condition:

Each subtag used in the extension part of the tag is valid according to the extension.

Older specifications and language tag implementations sometimes reference [RFC3066]. That document considered a wider array of tags to be well-formed. Any tag that was valid under RFC 3066 is both well-formed and valid under this document's syntax. Only the invalid or illegal tags that were well-formed under the earlier definition are no longer well-formed 🙈 The language tag syntax under RFC 3066 was:

obs-language-tag = primary-subtag *( "-" subtag )
primary-subtag   = 1*8ALPHA
subtag           = 1*8(ALPHA / DIGIT)

Figure 2: RFC 3066 Language Tag Syntax

Subtags designated for private use, along with private use sequences introduced by the x subtag, are there for cases where no assigned subtags exist and registration isn't a good option 🧚 For example, you could use a tag like "no-QQ", where QQ is one of a range of private use ISO 3166-1 codes, to indicate an otherwise undefined region. Users MUST NOT assign language tags that use subtags that don't appear in the registry, except inside private use sequences (like the subtag personal in the tag "en-x-personal"). Besides being invalid, that also risks colliding with a future assignment or registration ⚠️

Note well: the Language-Tag production in this document is functionally equivalent to the one in [RFC4646], but it has been changed to prevent certain well-formedness errors that came from the old grandfathered production 🌈

3. Registry Format and Maintenance

The IANA Language Subtag Registry ("the registry") is a comprehensive list of all the subtags that are valid in language tags 📋 That gives implementers a straightforward, reliable way to validate language tags. The registry will be maintained so that, except for extension subtags, you can validate every subtag that appears in a language tag under the provisions of this document or its revisions or successors. The meaning of the various subtags will also stay unambiguous and stable over time 💖 (Private use subtags are the exception here, of course. Their meaning isn't defined by the registry 🙈)

This section defines the registry, its maintenance and update procedures, and a registry for extensions to language tags (Section 3.7) 🦋

3.1. Format of the IANA Language Subtag Registry

The IANA Language Subtag Registry is a machine-readable file in the format described in this section. It also includes copies of the registration forms approved under the process described in Section 3.5 ✨

The existing registration forms for the grandfathered and redundant tags taken from RFC 3066 have been kept as part of the obsolete RFC 3066 registry 🗂️ The subtags added to the registry by either [RFC4645] or [RFC5645] don't have separate registration forms, so no forms are archived for those additions.

3.1.1. File Format

Here's the vibe: the registry is a [Unicode] text file made up of a series of records, in a format based on "record-jar" (described in [record-jar]) 📄 Each record is made of fields that describe the various subtags and tags. The actual registry file is encoded using the UTF-8 [RFC3629] character encoding 💜

Each field can be thought of as one logical line of characters. Every field has a "field-name" and a "field-body", separated by a "field-separator". The field-separator is a COLON character (U+003A) plus any surrounding whitespace. Each field ends with the newline sequence CRLF. The text in each field MUST be in Unicode Normalization Form C (NFC) ✨

A collection of fields forms a "record". Records are separated by lines that contain nothing but the sequence "%%" (U+0025 U+0025) 🎀

Fields are logically one line of text, but each line in the file format is capped at 72 bytes. To fit that, the field-body can be split across multiple lines, which is called "folding". Folding follows the usual line-wrapping conventions, typically breaking on whitespace. It can also happen between other characters when the value has no spaces, like when a language doesn't use whitespace between words. Either way, there MUST NOT be breaks inside a multibyte UTF-8 sequence or in the middle of a combining character sequence. For more information, see [UAX14] 🔥

The file uses the Unicode character set and the UTF-8 encoding, but fields are restricted to printable characters from the US-ASCII [ISO646] repertoire, unless the description of a specific field says otherwise (Section 3.1.2) 🌸

The registry's format is described by the following ABNF [RFC5234]. Character numbers (code points) come from Unicode, and the terminals in the ABNF productions are characters rather than bytes 🧠

registry   = record *("%%" CRLF record)
record     = 1*field
field      = ( field-name field-sep field-body CRLF )
field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
field-sep  = *SP ":" *SP
field-body = *([[*SP CRLF] 1*SP] 1*CHARS)
CHARS      = (%x21-10FFFF)      ; Unicode code points

Figure 3: Registry Format ABNF

The sequence '..' (U+002E U+002E) in a field-body denotes a range of values. A range stands for all subtags of the same length that are in alphabetic or numeric order within that range, including the values explicitly mentioned. For example, 'a..c' means the values 'a', 'b', and 'c', and '11..13' means the values '11', '12', and '13' 🔢

All fields whose field-body contains a date value use the "full-date" format specified in [RFC3339]. For example, "2004-06-28" represents June 28, 2004, in the Gregorian calendar 📅

3.1.2. Record and Field Definitions ✨

okay so the registry has exactly three kinds of records: "File-Date", "Subtag", and "Tag" 🎀

The very first record is always the "File-Date" record 📅. It only shows up once in the file, and it has one field called File-Date. Its field-body is a date (see Section 5.1), so you can tell different versions of the registry apart at a glance. Here's what it looks like (Figure 4):

File-Date: 2004-06-28
%%

Figure 4: Example of the File-Date Record

Everything after that is a "Subtag" or a "Tag" record 🧚. They're built the same way, with one difference: "Subtag" records have a Subtag field, and "Tag" records have a Tag field (unsurprisingly 💀). Field-names MUST NOT occur more than once per record, except for Description, Comments, and Prefix. Those three are the exceptions 🙈

Every record MUST contain at least one of each of these fields:

  • Type
    • Its field-body MUST consist of one of these strings: "language", "extlang", "script", "region", "variant", "grandfathered", and "redundant". It tells you what kind of tag or subtag the record is 💖
  • Either Subtag or Tag
    • Subtag's field-body holds the subtag being defined. This field MUST appear in every record whose Type is "language", "extlang", "script", "region", or "variant" ✨
    • Tag's field-body holds a complete language tag. This field MUST appear in every record whose Type is "grandfathered" or "redundant". If the Type is "grandfathered", then the Tag field-body will be one of the tags listed in either the regular or irregular production found in Section 2.1 🌈
  • Description
    • Its field-body is a non-normative description of the subtag or tag. (Translation: it's not the rulebook, it's just a label 🫶)
  • Added
    • Its field-body is the date the record was registered. For grandfathered or redundant tags, it's the date the matching tag was registered under the rules of [RFC1766] or [RFC3066] instead 🍓

Each record MAY also contain these fields:

  • Deprecated
    • Its field-body is the date the record was deprecated. Sometimes this date is earlier than the Added date in the same record, which just means the deprecation happened before the record was added to the registry. Wild, right? 💀
  • Preferred-Value
    • Its field-body is a canonical mapping from this record's value to a modern equivalent that's preferred in its place. What it looks like depends on the Type:
      • For 'language' fields, Preferred-Value contains the primary language subtag that's preferred when forming the language tag.
      • For 'script', 'region', or 'variant' fields, Preferred-Value contains the subtag of the same type that's preferred for forming the language tag.
      • For 'extlang', 'grandfathered', or 'redundant' fields, Preferred-Value contains an "extended language range" [RFC4647] that's preferred for forming the language tag. So the preferred tag will contain, in order, each subtag that shows up in the Preferred-Value. Extra fields can be included in a language tag too, as described elsewhere in this document. For example, the replacement for the grandfathered tag zh-min-nan (Min Nan Chinese) is nan, which can be the basis for tags like nan-Hant or nan-TW. (Also, the extended language subtag form like zh-nan-Hant or zh-nan-TW works too 🌸)
  • Prefix
    • Its field-body is a valid language tag that's RECOMMENDED as one possible prefix to this record's subtag. This field MAY appear in records whose Type field-body is 'extlang' or 'variant'. It MUST NOT appear in any other record type 🚫
  • Suppress-Script
    • Its field-body is a script subtag that SHOULD NOT be used to form language tags with the associated primary or extended language subtag. This field MUST appear only in records whose Type field-body is 'language' or 'extlang'. See Section 4.1 🙈
  • Macrolanguage
    • Its field-body is a primary language subtag that ISO 639 defines as the "macrolanguage" encompassing this language subtag. This field MUST appear only in records whose Type field-body is 'language' or 'extlang' 👑
  • Scope
    • Its field-body is info about a primary or extended language subtag, saying what kind of language code it is according to ISO 639. The allowed values are "macrolanguage", "collection", "special", and "private-use". This field only shows up in records whose Type field-body is 'language' or 'extlang'. If it's left out, the language is an individual language 🦋
  • Comments
    • Its field-body is extra info about the subtag, as needed for understanding the registry and actually implementing language tags with the subtag or tag 💅

Future versions of this document might add more fields to the registry, so implementations SHOULD ignore any fields found in the registry that aren't defined here. Not gonna lie, that's a very mature move 🫶

3.1.3. Type Field 🦋

The Type field is the string that says which record type it's in, and it's super important 💖 Its values are: "language" (Section 2.2.1); "extlang" (Section 2.2.2); "script" (Section 2.2.3); "region" (Section 2.2.4); "variant" (Section 2.2.5); "grandfathered" or "redundant" (Section 2.2.8).

3.1.4. Subtag and Tag Fields 🧚

The Subtag field holds the subtag defined in the record. The Tag field shows up in records whose Type is either "grandfathered" or "redundant", and it holds a tag registered under [RFC3066] 🌈

Now, casing. The Subtag field-body MUST follow the casing conventions in Section 2.1.1. Basically everything is lowercase in the field-body, with two exceptions 🍓

  • Subtags whose Type field is "script" (aka subtags defined by ISO 15924) MUST use titlecase.
  • Subtags whose Type field is "region" (aka the non-numeric region subtags defined by ISO 3166-1) MUST use all uppercase.

And the Tag field-body MUST be formatted according to the rules in Section 2.1.1. Casing is a whole vibe, and the spec is strict about it ✨

3.1.5. Description Field 💅

The Description field describes the tag or subtag in the record. It MAY appear more than once per record, and it MAY include the full range of Unicode characters 🌈 At least one of the Description fields MUST be written or transcribed into the Latin script. Any additional Description fields MAY be in any script or language 🌸

Here's the main job of Description: it's for identification purposes 🎀 Descriptions SHOULD contain all and only the info needed to tell one subtag apart from others it might get mixed up with. They are NOT meant to give general background or list every possible alternate name or designation. Description fields don't have to be the item's actual native name, and none of them are guaranteed to be in any particular language, like English or French. Honestly, the vibe is "just help me tell these apart" 💀

Descriptions in the registry that match ISO 639, ISO 15924, ISO 3166-1, or UN M.49 codes are only meant to show what that identifier means in the source standard, as it was when it was added or as later changed. Changes happen within the bounds of the stability rules (Section 3.4), through later registration. The Description doesn't replace the source standard itself. Also, Description fields aren't meant to be the localized English names for the subtags, and localizing or translating tag and subtag descriptions is out of scope for this document. Not its job, bestie 🙅‍♀️

For subtags taken from a source standard (like ISO 639 or ISO 15924), the Description fields start out taken from that standard too. If the standard has several descriptions, each one gets split into its own Description field. The source descriptions MAY be edited or modified, either before insertion or through the registration process, and extra or leftover descriptions can be left out or removed 🔥 Each Description field MUST be unique within the record it's in, and formatting variations of the same description SHOULD NOT occur in that record. For example, the ISO 639-1 code fy has both "Western Frisian" and "Frisian, Western" in that standard, but only one of those shows up in the registry 🦋

Now, the big rule so users don't get confused about which subtag to use 👑 Description fields for any one record type (language, extlang, script, and so on) MUST be unique within that type, with one exception: if a particular Description shows up in several records of the same type, then at most one of those records can leave out the Deprecated field. All deprecated records sharing a Description MUST have the same Preferred-Value, and all non-deprecated records MUST be that Preferred-Value. So two same-type records with a shared Description are also semantically equivalent, and no more than one record with a given Description is preferred for that meaning. Okay, that's some serious consistency energy ✨

Example time! Look at the language subtags zza (Zaza) and diq (Dimli). zza is a macrolanguage that encloses diq, so its ISO 639-3 description is also "Dimli". That got edited to read "Dimli (macrolanguage)" in the registry record for zza to avoid a collision 💅

On the flip side, the subtags he and iw share a Description value of "Hebrew", and that's allowed because iw is deprecated and its Preferred-Value is he 🌈

For fields of type 'language', the first Description field in the registry matches the Reference Name assigned by ISO 639-3 whenever possible. This makes cross-referencing between ISO 639 and the registry way easier 🧚

Last bit: when creating or updating a record because one of the source standards changed, the Language Subtag Reviewer MAY edit descriptions to fix formatting irregularities (like misspellings, weird apostrophes or other punctuation, or extra or missing spaces) before submitting the proposed record to the ietf-languages@iana.org list for consideration 🫶

3.1.6. Deprecated Field 🗑️

okay bestie, the Deprecated field is where we log the date a record got deprecated 📅 It MAY be added, changed, or removed from any record through the maintenance process in Section 3.3 or the registration process in Section 3.5. Usually it shows up because a standards body, like ISO 3166, withdrew a code 💅

Even though they're still valid in language tags, subtags and tags with a Deprecated field are deprecated, so validating processors SHOULD NOT generate these subtags 🙅‍♀️

⚠️ a record with a Deprecated field but no matching Preferred-Value field has no replacement mapping. so it's basically on its own, no backup plan 😭

sometimes we just can't figure out the exact deprecation date anymore 🥺 for those cases, the registry shows an approximate date. some subtags and some grandfathered or redundant tags got deprecated before the registry even existed 🕰️ the exact rules for that are in Section 2 of [RFC4645]. and yes, these records have a Deprecated date that's earlier than their Added date. it's giving time travel 🌀

3.1.7. Preferred-Value Field 💖

the Preferred-Value field maps a record to another tag or subtag (which one depends on the record's Type) 🧩 this mapping is used for canonicalization (see Section 4.5). when a subtag or tag also has a Deprecated field, the Preferred-Value is RECOMMENDED as the best pick when you're choosing a language tag ✨

records with a Preferred-Value fall into one of these four groups:

  1. ISO 639 language codes that got withdrawn in favor of other codes. honestly these are mostly a historical curiosity 📜 the he/iw pairing above is an example of this.
  2. Subtags (with types other than language or extlang) that came from codes or values later withdrawn in favor of a new code. this mostly hits region subtags from ISO 3166-1, because sometimes a country changes its name or government so much that it needs a new region code 🌍 sometimes countries switch back to an older name, which might already be encoded. for example, the subtag ZR (Zaire) got replaced by CD (Democratic Republic of the Congo) when that country's name changed.
  3. Tags or subtags that became obsolete because the values they stood for were later encoded. a lot of the grandfathered or redundant tags got encoded by ISO 639 later, so they land here. for example, "i-klingon" got deprecated when the subtag tlh was added, so its record has a Preferred-Value of tlh 👽
  4. Extended language subtags always map to their identical primary language subtag 🔁 for example, the extended language subtag yue (Cantonese) can be used to form the tag zh-yue. its Preferred-Value maps to the primary language subtag yue, so a tag like zh-yue-Hant-HK can be canonicalized to yue-Hant-HK.

records that aren't type extlang but DO have a Preferred-Value MUST also have a Deprecated field 📌 that field holds the date the tag or subtag got deprecated in favor of the preferred value.

for records of type extlang, the Preferred-Value shows up with no matching Deprecated field 🫶 an implementation MAY ignore these preferred value mappings, but if it ignores them, it SHOULD do that consistently. it SHOULD also treat the Preferred-Value as equivalent to the mapped item. so zh-yue-Hant-HK and yue-Hant-HK are semantically equivalent and ought to be treated as the same tag, periodt ✨

sometimes the deprecated code is actually the preferred one in certain contexts 🤓 for example, both "iw" and "he" work in the Java programming language, but "he" gets converted to "iw" on input, so "iw" is the canonical form in Java.

🌏 Preferred-Value mappings in records of type region don't always mean exactly the same thing as the original value. countries change codes for lots of reasons, and how that affects language tags depends on what kind of change it was. for example, the region subtag YD (Democratic Yemen) got deprecated in favor of YE (Yemen) when those two countries unified in 1990.

a Preferred-Value MAY be added to, changed, or removed from records following the rules in Section 3.3 💅 adding, changing, or removing a Preferred-Value field doesn't mean content using the affected subtag has to be retagged. no retagging drama here 🙌

the Preferred-Value fields in records of type "grandfathered" and "redundant" each hold an "extended language range" [RFC4647] that is strongly RECOMMENDED for use in place of the record's value 🎀 a lot of these mappings came from deprecating tags during the time before [RFC4646] was adopted. for example, the tag "no-nyn" got deprecated in favor of the ISO 639-1-defined language code nn.

the Preferred-Value field in subtag records of type "extlang" also holds an "extended language range" 🧚 that lets the subtag get deprecated in favor of either a single primary language subtag or a new language-extlang sequence.

usually, adding, removing, or changing a Preferred-Value field for a subtag happens because one of the source standards changed 🔄 for example, if an ISO 3166-1 region code gets deprecated in favor of another code, that SHOULD result in adding a Preferred-Value field.

changes to one subtag can ripple out to other subtags too 🌊 when proposing registry changes, the Language Subtag Reviewer MUST review the registry for these effects and propose the necessary changes using the process in Section 3.5, though anyone MAY request such changes. here are two examples:

Suppose that subtag 'XX' has a 'Preferred-Value' of 'YY'.  If 'YY'
later changes to have a 'Preferred-Value' of 'ZZ', then the
'Preferred-Value' for 'XX' MUST also change to be 'ZZ'.

Suppose that a registered language subtag 'dialect' represents a
language not yet available in any part of ISO 639.  The later
addition of a corresponding language code in ISO 639 SHOULD result
in the addition of a 'Preferred-Value' for 'dialect'.

3.1.8. Prefix Field 🌷

the Prefix field holds a valid language tag that is RECOMMENDED as one possible prefix for this record's subtag, maybe with other subtags tagging along 🪄 so when you add an extended language or variant subtag that has at least one Prefix to a language tag, the result SHOULD match at least one of the subtag's Prefix fields using the "Extended Filtering" algorithm (see [RFC4647]). and each subtag in that Prefix SHOULD appear before the subtag itself 🫧

the Prefix field MUST appear exactly once in a record of type extlang 📍 in records of type variant, the Prefix field MAY appear multiple times, or not at all. extra fields of this type MAY be added to a variant record through the registration process, as long as that variant record already has at least one Prefix field 💜

each Prefix field points to a specific sequence of subtags that make a meaningful tag with this subtag. for example, the extended language subtag cmn (Mandarin Chinese) only makes sense with its prefix zh (Chinese) 🇨🇳 similarly, rozaj (Resian, a dialect of Slovenian) fits with its prefix sl (Slovenian), while tags like "is-1994" aren't appropriate (and probably not meaningful either). even though the Prefix for rozaj is "sl", other subtags can sit in between them. for example, the tag "sl-IT-rozaj" (Slovenian, Italy, Resian) matches the Prefix "sl" 🇮🇹

the Prefix also tells you when variant subtags make sense together (lots of variants that share a Prefix are mutually exclusive 🙅‍♀️) and what order the variants are supposed to go in 🔢 for example, the variant 1994 (Standardized Resian orthography) has several Prefix fields in the registry: "sl-rozaj", "sl-rozaj-biske", "sl-rozaj-njiva", "sl-rozaj-osojs", and "sl-rozaj-solba". that means 1994 works with all five Resian variant subtags (rozaj, biske, njiva, osojs, and solba), and it SHOULD appear after any of these variants in a tag. so the language tag ought to look like "sl-rozaj-biske-1994", not "sl-1994-rozaj-biske" or "sl-rozaj-1994-biske" 💅

if a record has no Prefix field, a Prefix field MUST NOT be added to it later on 🚫 otherwise, changes to the set of Prefix fields (additions, deletions, or modifications) MAY be registered, as long as they strictly widen the range of language tags that are recommended. for example, a Prefix of "be-Latn" (Belarusian, Latin script) could be swapped for "be" (Belarusian), but not for "ru-Latn" (Russian, Latin script) or "be-Latn-BY" (Belarusian, Latin script, Belarus), since those either change or narrow the range of suggested tags 🧐

🙅‍♀️ the field-body of the Prefix field MUST NOT conflict with any Prefix already registered for a given record. a conflict happens when no valid tag could be built that contains the prefix, like when two subtags each have a Prefix containing the other subtag. for example, say the subtag avariant has the prefix "es-bvariant". then the subtag bvariant can't be given the prefix avariant, because that would need a tag like "es-avariant-bvariant-avariant", which isn't valid 💀

3.1.9. Suppress-Script Field 🫧

the Suppress-Script field holds a script subtag (one that has its own record in the registry) 🔤 the Suppress-Script field MUST appear only in records whose Type field-body is either language or extlang. and it MUST NOT appear more than one time in a record.

this field points to a script that's used to write the overwhelming majority of documents in that language 📖 that script subtag adds no distinguishing info to a language tag, so it SHOULD NOT be used for most documents in that language. leaving out the script subtag named by this field helps keep language tags made under this document compatible with language tags and tag processors or consumers based on RFC 3066 🤝 for example, basically all Icelandic documents are written in the Latin script, which makes the subtag Latn redundant in the tag is-Latn 🇮🇸

a lot of language subtag records don't have a Suppress-Script field 🤷‍♀️ that can mean the language is customarily written in more than one script, or that it isn't customarily written at all. it could also mean there wasn't enough info when the record got created, so it's still a candidate for future registration ✨

3.1.10. Macrolanguage Field 🌸

okay so the Macrolanguage field 🧚 points at a primary language subtag (the one with its own record in the registry). It tells you which bigger language that subtag belongs to, based on what ISO 639-3 says. 💖

ISO 639-3 has some languages marked as "macrolanguages" 👑. It describes them as "clusters of closely-related language varieties that [...] can be considered distinct individual languages, yet in certain usage contexts a single language identity for all is needed". 🫶 These are codes that ISO 639-2 had as single languages, but that turned out to cover more than one language in ISO 639-3.

A language inside a macrolanguage is called an "encompassed language" 🦋. Its record gets a Macrolanguage field in the registry, but the macrolanguages themselves aren't marked in any special way. Also, some encompassed languages have ISO 639-1 or ISO 639-2 codes, so don't be surprised if you spot one. 👀

The Macrolanguage field can only show up in records of type language or extlang 💅. Only values assigned by ISO 639-3 will be considered for inclusion. The Macrolanguage field MAY be added or removed through the normal registration process whenever ISO 639-3 defines new values or withdraws old ones 🔥. Macrolanguages are purely informational, so they MAY be removed or changed if ISO 639-3 changes the values 🌈. If you want more on how to use this field and how to pick between a macrolanguage and an encompassed language subtag, check out Section 4.1.1 ✨.

For example, the language subtags nb (Norwegian Bokmal) and nn (Norwegian Nynorsk) each have a Macrolanguage field with a value of no (Norwegian) 🍓. For more info, see Section 4.1 🎀.

3.1.11. Scope Field 🦋

okay the Scope field 💜 holds classification info about a primary or extended language subtag, pulled from ISO 639. Most languages have a scope of individual, which just means it's not a macrolanguage, collection, special code, or private use. It's what you'd normally call "a language" 🙈. Any primary or extended language subtag with no Scope field counts as an individual language ✨.

Scope info can be super helpful when you're picking language tags, because it shows the purpose, or "scope", of the code assignment within ISO 639 🔥. The available values are:

  • macrolanguage - Indicates a macrolanguage as defined by ISO 639-3 (see Section 3.1.10). A macrolanguage is a cluster of closely related languages that are sometimes considered to be a single language. 👑
  • collection - Indicates a subtag that represents a collection of languages, typically related by some type of historical, geographical, or linguistic association. Unlike a macrolanguage, a collection can contain languages that are only loosely related, and a collection cannot be used interchangeably with languages that belong to it. 🌸
  • special - Indicates a special language code. These are subtags used for identifying linguistic attributes not particularly associated with a concrete language. These include codes for when the language is undetermined or for non-linguistic content. 🧚
  • private-use - Indicates a code reserved for private use in the underlying standard. Subtags with this scope can be used to indicate a primary language for which no ISO 639 or registered assignment exists. 💅

The Scope field MAY appear in records of type language or extlang 🫶. Heads up that a lot of the prefixes for extended language subtags will have a Scope of macrolanguage (though some won't), and plenty of languages with a Scope of macrolanguage will have extended language subtags attached to them 🌈.

The Scope field MAY be added, modified, or removed through the registration process, as long as the change mirrors what ISO 639 changed about the assignment's classification 💖. Those changes are expected to be rare 🙈.

For example, the primary language subtag zh (Chinese) has a Scope of macrolanguage, while its enclosed language nan (Min Nan Chinese) has a Scope of individual. The special value und (Undetermined) has a Scope of special. The ISO 639-5 collection gem (Germanic languages) has a Scope of collection ⭐.

3.1.12. Comments Field 🎀

the Comments field holds extra info about the record, and it MAY show up more than once per record 💬. The field-body MAY include the full range of Unicode characters, and it isn't limited to any particular script 🌍. This field MAY be inserted or changed through the registration process, and no guarantee of stability is given 🫶.

The content here isn't restricted, except by the need to register the info, how suitable the request is, and reasonable practical size limits 🧾. The main reason the Comments field exists is subtag identification 🔍: it helps tell a subtag apart from others it might get mixed up with, so it's easier to use correctly. Big walls of text about a subtag's use, history, or background are frowned upon 🙅‍♀️, since that stuff really belongs in a registration request, not in the registry 💅.

3.2. Language Subtag Reviewer 👑

the Language Subtag Reviewer moderates the ietf-languages@iana.org mailing list 📬, responds to registration requests, and handles the other registry maintenance duties described in Section 3.3 💅. Only the Language Subtag Reviewer is allowed to ask IANA to change, update, or add records in the Language Subtag Registry 🔒. The Language Subtag Reviewer MAY delegate list moderation and other clerical duties as needed 🫶.

The IESG appoints the Language Subtag Reviewer for an indefinite term 🗓️, and they can be removed or replaced whenever the IESG decides 🔄. The IESG will ask for nominees for the role (when this document is adopted or when the seat is vacant) and then ask for feedback on the nominees' qualifications 📣. Qualified candidates should be familiar with BCP 47 and its requirements 📚. They should also be willing to run the registration process fairly, responsively, and judiciously ⚖️, and be informed enough about language identification issues to assess claims and draw on the input of language experts and subtag requesters 🧠.

Decisions or performance from the Language Subtag Reviewer MAY be appealed to the IESG under the same rules as other IETF decisions (see [RFC2026]) 🙌. The IESG can reverse or overturn the Language Subtag Reviewer's decisions, give guidance, or take other appropriate actions 👑.

3.3. Maintenance of the Registry 🌈

keeping the registry up to date means that, whenever ISO 639, ISO 15924, ISO 3166, or UN M.49 assign or withdraw codes, the Language Subtag Reviewer MUST evaluate each change and decide what to do under the rules in this document 🧐. These updates follow the registration process described in Section 3.5 📝. Usually, the Language Subtag Reviewer starts the process for the new or updated record by filling in the registration form and submitting it 💌. If one of these standards changes and the Language Subtag Reviewer doesn't do this in a timely manner, then any interested party MAY submit the form ⏰. After that, the registration process carries on as normal 🔁.

Be aware that some registrations affect other subtags, sometimes more than one, like when a region subtag is deprecated in favor of a new value 🌏. The Language Subtag Reviewer is responsible for making sure any such changes get registered properly, and each change needs its own registration form 🗂️.

The Language Subtag Reviewer MUST make sure new subtags meet the requirements elsewhere in this document (especially Section 3.4) 🔍, or else submit an appropriate registration form for an alternate subtag as described in that section 🔀. Each individual subtag affected by a change MUST be sent to the ietf-languages@iana.org list with its own registration form and in a separate message 📨. Keep each one separate, bestie 💅.

3.4. Stability of IANA Registry Entries 💖

the stability of entries and what they mean in the registry is critical for the long-term stability of language tags 🏰. The rules in this section guarantee that a specific language tag's meaning stays stable over time and never changes 🔒.

These rules specifically cover how changes to codes (including withdrawals and deprecations) maintained by ISO 639, ISO 15924, ISO 3166, and UN M.49 get reflected in the IANA Language Subtag Registry 🪞. Assignments to the IANA Language Subtag Registry MUST follow these stability rules 🫡:

  1. Values in the fields Type, Subtag, Tag, and Added MUST NOT be changed, and they are guaranteed to be stable over time 💎.
  2. Values in the fields Preferred-Value and Deprecated MAY be added, altered, or removed via the registration process 🔄. These changes SHOULD be limited to changes necessary to mirror changes in one of the underlying standards (ISO 639, ISO 15924, ISO 3166-1, or UN M.49), and typically alteration or removal of a Preferred-Value is limited specifically to region codes 🌍.
  3. Values in the Description field MUST NOT be changed in a way that would invalidate any existing tags 🚫. The description MAY be broadened somewhat in scope, changed to add information, or adapted to the most common modern usage 📖. For example, countries occasionally change their names; a historical example of this is "Upper Volta" changing to "Burkina Faso" 🌍.
  4. Values in the field Prefix MAY be added to existing records of type variant via the registration process, provided the variant already has at least one Prefix 🧩. A Prefix field SHALL NOT be registered for any variant that has no existing Prefix field 🙅‍♀️. If a prefix is added to a variant record, Comment fields MAY be used to explain different usages with the various prefixes 💬.
  5. Values in the field Prefix in records of type variant MAY also be modified, as long as the modifications broaden the set of prefixes 📈. That is, a prefix MAY be replaced by one of its own prefixes 🪄. For example, the prefix "en-US" could be replaced by "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont". If one of those prefix values were needed, it would have to be separately registered 📝.
  6. Values in the field Prefix in records of type extlang MUST NOT be added, modified, or removed 🔐.
  7. The field Prefix MUST NOT be removed from any record in which it appears 🚫. This field SHOULD be included in the initial registration of any records of type variant, and MUST be included in any records of type extlang 🫶.
  8. The field Comments MAY be added, changed, modified, or removed via the registration process or any of the processes or considerations described in this section ✏️.
  9. The field Suppress-Script MAY be added or removed via the registration process 🌟.
  10. The field Macrolanguage MAY be added or removed via the registration process, but only in response to changes made by ISO 639 🔁. The Macrolanguage field appears whenever a language has a corresponding macrolanguage in ISO 639 🪞. That is, the Macrolanguage fields in the registry exactly match those of ISO 639 📏. No other macrolanguage mappings will be considered for registration 🙅‍♀️.
  11. okay bestie, the field 'Scope' MAY be added or removed from a primary or extended language subtag after initial registration 🌸, and it MAY be modified to match any changes ISO 639 makes. Changes to the 'Scope' field MUST mirror what ISO 639 changed 🔥. Also, primary or extended language subtags without a 'Scope' field (aka most of them 💀) are individual languages, as described in Section 3.1.11 ✨.
  12. Primary and extended language subtags (other than independently registered values created through the registration process) get made based on the different parts of ISO 639, and it goes like this 💅:
    • A. Codes assigned by ISO 639-1 that don't conflict with existing two-letter primary language subtags, and that don't already have a matching three-letter primary in the registry, get entered into the IANA registry as new 'language' records 🎀. Also, languages with an ISO 639-1 code can't get extended language subtags, even if a macrolanguage covers them 🙈.
    • B. Codes assigned by ISO 639-3 or ISO 639-5 that don't conflict with existing three-letter primary language subtags, and that don't have ISO 639-1 codes assigned (or expected to be) get entered into the IANA registry as new 'language' records 🧚. These two standards are now a superset of ISO 639-2 codes, which is so iconic 👑. Codes with a defined 'macrolanguage' mapping at the time they get registered MUST contain a 'Macrolanguage' field 💜.
    • C. Codes assigned by ISO 639-3 MAY also be considered for an extended language subtag registration 🦋. Heads up: they MUST be assigned a primary language subtag record of type 'language' even when an 'extlang' record gets proposed 😭. When considering extended language subtag assignment, these criteria apply:
      1. If a language has a macrolanguage mapping, and that macrolanguage has other encompassed languages that are assigned extended language subtags, then the new language SHOULD have an 'extlang' record assigned to it as well. For example, any language with a macrolanguage of 'zh' or 'ar' would be assigned an 'extlang' record 🌈.
      2. 'Extlang' records SHOULD NOT be created for languages if other languages encompassed by the macrolanguage don't also include 'extlang' records. For example, if a new Serbo-Croatian ('sh') language were registered, it would not get an extlang record, because other encompassed languages, like Serbian ('sr'), don't include one in the registry 🙅‍♀️.
      3. Sign languages SHOULD have an 'extlang' record with a 'Prefix' of 'sgn' 🤟.
      4. 'Extlang' records MUST NOT be created for items already in the registry. Extended language subtags only get considered at the time of initial registration ⏰.
      5. Extended language subtag records MUST include the fields 'Prefix' and 'Preferred-Value', with field values assigned as described in Section 2.2.2 ✨.
    • D. Any other codes assigned by ISO 639-2 that don't conflict with existing three-letter primary or extended language subtags, and that don't have ISO 639-1 two-letter codes assigned, get entered into the IANA registry as new 'language' records 🍓. This type of registration is not supposed to happen in the future, so it's a one-time thing 🫶.
  13. Codes assigned by ISO 15924 and ISO 3166-1 that don't conflict with existing subtags of the associated type, and whose meaning isn't the same as an existing subtag of the same type, get entered into the IANA registry as new records 🌸.
  14. Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that get withdrawn by their respective maintenance or registration authority still remain valid in language tags 🦋. A 'Deprecated' field holding the date of withdrawal MUST be added to the record 📅. If a new record of the same type gets added to represent a replacement value, then a 'Preferred-Value' field MAY also be added 🔁. The registration process MAY be used to add comments about the withdrawal of the code by the respective standard 💬.
For example: the region code 'TL' was assigned to the country 'Timor-Leste', replacing the code 'TP' (which was assigned to 'East Timor' when it was under administration by Portugal). The subtag 'TP' remains valid in language tags, but its record contains the 'Preferred-Value' of 'TL', and its field 'Deprecated' contains the date the new code was assigned ('2004-07-06') 🗓️.
  1. Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that conflict with existing subtags of the associated type, including subtags that are deprecated, MUST NOT be entered into the registry 🚫. These extra considerations apply to subtag values that get reassigned 👀:
    • A. For ISO 639 codes, if the newly assigned code's meaning isn't represented by a subtag in the IANA registry, the Language Subtag Reviewer, as described in Section 3.5, SHALL prepare a proposal for entering a registered language subtag into the IANA registry as an alternate value for the new code, as soon as practical ⚡. The form of that registered language subtag is up to the Language Subtag Reviewer and MUST conform to other restrictions on language subtags in this document 📝.
    • B. For all subtags whose meaning is derived from an external standard (that is, by ISO 639, ISO 15924, ISO 3166-1, or UN M.49), if a new meaning gets assigned to an existing code and that new meaning broadens the code's meaning, then the meaning for the associated subtag MAY be changed to match 🌿. The meaning of a subtag MUST NOT be narrowed, though, because that can make an unknown proportion of the existing uses of a subtag invalid 😱. Note: the ISO 639 registration authority (RA) has adopted a similar stability policy 🤝.
    • C. For ISO 15924 codes, if the newly assigned code's meaning isn't represented by a subtag in the IANA registry, the Language Subtag Reviewer, as described in Section 3.5, SHALL prepare a proposal for entering a registered variant subtag into the IANA registry as an alternate value for the new code, as soon as practical 🎨. The form of that registered variant subtag is up to the Language Subtag Reviewer and MUST conform to other restrictions on variant subtags in this document 💅.
    • D. For ISO 3166-1 codes, if the newly assigned code's meaning is associated with the same UN M.49 code as another 'region' subtag, then the existing region subtag stays as the preferred value for that region, and no new entry gets created 🗺️. A comment MAY be added to the existing region subtag to show how it relates to the new ISO 3166-1 code 💬.
    • E. For ISO 3166-1 codes, if the newly assigned code's meaning is associated with a UN M.49 code that isn't represented by an existing region subtag, then the Language Subtag Reviewer, as described in Section 3.5, SHALL prepare a proposal for entering the appropriate UN M.49 country code as an entry in the IANA registry 🌍.
    • F. For ISO 3166-1 codes, if there's no associated UN numeric code, then the Language Subtag Reviewer SHALL petition the UN to create one 🙏. If the UN doesn't respond within 90 days of the request being sent, the Language Subtag Reviewer SHALL prepare a proposal for entering a registered variant subtag into the IANA registry as an alternate value for the new code, as soon as practical 📨. The form of that registered variant subtag is up to the Language Subtag Reviewer and MUST conform to other restrictions on variant subtags in this document 🧾. This situation is very unlikely to ever happen 🙃.
  2. UN M.49 has codes for both "countries and areas" (like '276' for Germany) and "geographical regions and sub-regions" (like '150' for Europe) 🌏. UN M.49 country or area codes that don't have a matching ISO 3166-1 code MUST NOT be registered, except as a surrogate for an ISO 3166-1 code that's blocked from registration by an existing subtag 🛑.

If one of these codes becomes necessary, the maintenance agency for ISO 3166-1 SHALL be petitioned first to assign a code to the region 💌. If that petition gets refused, or isn't acted on in a timely manner, then the registration process described in Section 3.5 can be used to register the matching UN M.49 code 🪄. This way, UN M.49 codes stay available as the value of last resort, for cases where ISO 3166-1 reassigns a deprecated value in the registry 🫶.

  1. The redundant and grandfathered entries together form the complete list of tags registered under [RFC3066] 📜. The redundant tags are the previously registered tags that can now be formed using the subtags defined in the registry 🧩. The grandfathered entries include the ones that can never be legal, because they're 'irregular' (meaning they don't match the 'langtag' production in Figure 1) 🙅‍♀️. Others are limited by rule (subtags like 'nyn' and 'min' look like the extlang production, but they can't be registered as extended language subtags), or their subtags are just inappropriate for registration 🚧. All of the grandfathered tags are listed in either the 'regular' or the 'irregular' productions in the ABNF 📋. Under [RFC4646], it was possible for grandfathered tags to become redundant. However, all of the tags for which that was possible became redundant before this document was produced 🏁. So the set of redundant and grandfathered tags is now permanent and immutable: new entries of either type MUST NOT be added, and existing entries MUST NOT be removed 🔒. The decision-making process about which tags were initially grandfathered and which were made redundant is described in [RFC4645] 🕰️.

Many of the grandfathered tags are deprecated -- indeed, they were deprecated even before [RFC4646] 🥲. For example, the tag "art-lojban" was deprecated in favor of the primary language subtag 'jbo' 🐾. These tags could have been made 'redundant' by registering some of their subtags as 'variants' 🌷. The 'variant-like' subtags in the grandfathered registrations SHALL NOT be registered in the future, even with a similar or identical meaning 🚫✨.

3.5. Registration Procedure for Subtags ✨

Okay so the procedure in this section MUST be used by anyone who wants to use a subtag that isn't in the IANA Language Subtag Registry yet, or who wants to add, modify, update, or remove info in existing records as this document allows. 💅

Only subtags of type 'language' and 'variant' will be considered for independent registration of new subtags. Subtags needed for stability, and subtags needed to keep the registry synced with ISO 639, ISO 15924, ISO 3166, and UN M.49 (within the limits this document sets), also go through this process, as described in Section 3.3 and subject to the stability provisions in Section 3.4. 🌈

Registration requests are accepted for info in the 'Comments', 'Deprecated', 'Description', 'Prefix', 'Preferred-Value', 'Macrolanguage', or 'Suppress-Script' fields in a subtag's record, as described in Section 3.4. Changes to all other fields in the IANA registry are NOT permitted. 🚫

Registering a new subtag or requesting changes to an existing tag or subtag starts with the requester filling out the registration form below. Each response isn't size-limited, so you can really describe your registration in full. ✨ The fields in the "Record Requested" section need to follow the requirements in Section 3.1 before the record gets approved. 🎀

   LANGUAGE SUBTAG REGISTRATION FORM
   1. Name of requester:
   2. E-mail address of requester:
   3. Record Requested:

      Type:
      Subtag:
      Description:
      Prefix:
      Preferred-Value:
      Deprecated:
      Suppress-Script:
      Macrolanguage:
      Comments:

   4. Intended meaning of the subtag:
   5. Reference to published description
      of the language (book or article):
   6. Any other relevant information:

              Figure 5: The Language Subtag Registration Form

Examples of completed registration forms can be found in Appendix B. 🍓 A complete list of approved registration forms is online through http://www.iana.org. Heads up, readers: the Language Tag Registry is now obsolete, so look for the Language Subtag Registry instead. 🦋

The subtag registration form MUST be sent to <ietf-languages@iana.org>. Registration requests get a two-week review period before being approved and submitted to IANA for inclusion in the registry. ⏳ If modifications are made to the request during the registration process (like corrections to meet the requirements in Section 3.1, or to make the 'Description' fields unique for the given record type), the modified form MUST also be sent to <ietf-languages@iana.org> at least one week prior to submission to IANA. 📬

The ietf-languages list is an open list, and you can join by sending a request to <ietf-languages-request@iana.org>. The list can be hosted by IANA or by any third party at the request of IESG. 🫶

Before forwarding any registration to IANA, the Language Subtag Reviewer MUST ensure that all requirements in this document are met. This includes making sure that values in the 'Subtag' field match case according to the description in Section 3.1.4, and that 'Description' fields are unique for the given record type as described in Section 3.1.5. The Reviewer MUST also ensure that an appropriate File-Date record is included in the request, to help IANA when updating the registry (see Section 5.1). 🔍

Some fields in both the registration form and the registry record itself permit the use of non-ASCII characters. Registration requests SHOULD use the UTF-8 encoding for consistency and clarity. However, since some mail clients don't support this encoding, other encodings MAY be used for the registration request. The Language Subtag Reviewer is responsible for making sure the proper Unicode characters show up in both the archived request form and the registry record. If IANA makes a transcription or encoding error, the Language Subtag Reviewer will request that the registry be repaired, providing any necessary info to help IANA fix it. 🛠️

Extended language subtags (type 'extlang') are, by definition, always encompassed by another language. So all records of type 'extlang' MUST contain a 'Prefix' field at the time of registration. 🔗 This 'Prefix' field can never be altered or removed, and requests to do so MUST be rejected. Not happening, bestie. 🙅‍♀️

Variant subtags are usually registered for use with a particular range of language tags, and variant subtags based on the terminology of the language they apply to are encouraged. 🧚 For example, the subtag 'rozaj' (Resian) is intended for use with language tags that start with the primary language subtag "sl" (Slovenian), since Resian is a dialect of Slovenian. So 'rozaj' would be appropriate in tags like "sl-Latn-rozaj" or "sl-IT-rozaj". This info is stored in the 'Prefix' field in the registry. Variant registration requests SHOULD include at least one 'Prefix' field in the registration form. 💜

Requests to assign an additional record of a given type with an existing subtag value MUST be rejected. Like, the variant subtag 'rozaj' already exists in the registry, so adding a second record of type 'variant' with the subtag 'rozaj' is prohibited. 🙈

The 'Prefix' field for a given registered variant subtag exists in the IANA registry as a guide to usage. Additional 'Prefix' fields MAY be added by filing an additional registration form. In that form, the "Any other relevant information:" field MUST indicate that it is the addition of a prefix. 🌸

Requests to add a 'Prefix' field to a variant subtag that imply a different semantic meaning SHOULD be rejected. For example, a request to add the prefix "de" to the subtag '1994' so that the tag "de-1994" represented some German dialect or orthographic form would be rejected. The '1994' subtag represents a particular Slovenian orthography, and the extra registration would change or blur the semantic meaning assigned to the subtag. A separate subtag SHOULD be proposed instead. 🧐

Requests to add a 'Prefix' to a variant subtag that has no current 'Prefix' field MUST be rejected. Variants are registered with no prefix because they're potentially useful with many or even all languages. Adding one or more 'Prefix' fields would be potentially harmful to the use of the variant, since it dramatically reduces the scope of the subtag (which is not allowed under the stability rules (Section 3.4)), as opposed to broadening the scope of the subtag, which is what adding a 'Prefix' normally does. An example of such a "no-prefix" variant is the subtag 'fonipa', which represents the International Phonetic Alphabet, a scheme that can be used to transcribe many languages. 🔤

The 'Description' fields provided in the request MUST contain at least one description written or transcribed into the Latin script. The request MAY also include additional 'Description' fields in any script or language. The 'Description' field is used for identification purposes and doesn't necessarily represent the actual native name of the language or variation. It also doesn't have to be in any particular language, but it SHOULD be both suitable and sufficient to identify the item in the record. The Language Subtag Reviewer will check and edit any proposed 'Description' fields so as to ensure uniqueness and prevent collisions with 'Description' fields in other records of the same type. If this happens in an independent registration request, the Language Subtag Reviewer MUST resubmit the record to <ietf-languages@iana.org>, treating it as a modification of a request due to discussion, as described in Section 3.5, unless the request's sole purpose is to introduce a duplicate 'Description' field. In that case, the request SHALL be rejected. 🚫

The 'Description' field is not guaranteed to be stable. Corrections or clarifications of intent are examples of possible changes. Attempts to provide translations or transcriptions of entries in the registry (which, by definition, provide no new information) are unlikely to be approved. 🙄

Soon after the two-week review period has passed, the Language Subtag Reviewer MUST take one of the following actions:

  • Explicitly accept the request and forward the form containing the record to be inserted or modified to <iana@iana.org>, according to the procedure described in Section 3.3. ✅
  • Explicitly reject the request because of significant objections raised on the list, or due to problems with constraints in this document (which MUST be explicitly cited). ❌
  • Extend the review period by granting an additional two-week increment to permit further discussion. After each two-week increment, the Language Subtag Reviewer MUST indicate on the list whether the registration has been accepted, rejected, or extended. ⏩

Note that the Language Subtag Reviewer MAY raise objections on the list if he or she so desires. The important thing is that the objection MUST be made publicly. 📣

Sometimes the request needs to be modified because of discussion during the review period, or due to requirements in this document. The applicant, the Language Subtag Reviewer, or others MAY submit a modified version of the completed registration form, which will be considered in lieu of the original request with the explicit approval of the applicant. Such changes do not restart the two-week discussion period. Still, an application containing the final record submitted to IANA MUST appear on the list at least one week prior to the Language Subtag Reviewer forwarding the record to IANA. ⏰ The applicant MAY modify a rejected application with more appropriate or additional information and submit it again. This starts a new two-week comment period. 🔁

Registrations initiated due to the provisions of Section 3.3 or Section 3.4 SHALL NOT be rejected altogether (since they have to ultimately appear in the registry), and they SHOULD be completed as quickly as possible. ⚡ The review process lets list members comment on the specific info in the form and the record it contains, and thus helps ensure it's correct and consistent. The Language Subtag Reviewer MAY reject a specific version of the form, but MUST propose a suitable replacement, extending the review period as described above, until the form is in a format worthy of the reviewer's approval and meets with rough consensus of the list. 👑

Decisions made by the Language Subtag Reviewer MAY be appealed to the IESG [RFC2028] under the same rules as other IETF decisions [RFC2026]. This includes a decision to extend the review period, or the failure to announce a decision in a clear and timely manner. 🧾

The approved records appear in the Language Subtag Registry. The approved registration forms are available online from http://www.iana.org. 🌟

Updates or changes to existing records follow the same procedure as new registrations. The Language Subtag Reviewer decides whether there is consensus to update the registration following the two-week review period. Normally, objections by the original registrant carry extra weight in forming such a consensus. 🫧

Registrations are permanent and stable. Once registered, subtags will not be removed from the registry and will remain a valid way in which to specify a specific language or variant. 💖

Okay bestie, so the Note is basically the reason the reference field exists 🧐📚 It helps people check whether a language is registered, or which language a subtag actually points at. A grammar or dictionary of that language is usually the gold standard 👑 If there isn't one, other well-known works describing that language, or written in it, MAY be appropriate ✨ The Language Subtag Reviewer decides what counts as "good enough" 💅 And this is the part I'm obsessed with: small languages and dialects are NOT shut out just because they have fewer speakers or no standardized spelling 🫶 Minority languages get judged on their own merits, period 🌈

3.6. Possibilities for Registration 🦋

Okay, here's what you can actually register, or add info to, in the IANA registry 🗂️

  • Primary language subtags for languages that aren't in ISO 639 and aren't variants of any listed or registered language MAY be registered 🌸 Fun fact, there were no examples of this kind when the document was written 🙈 And before you even try registering one, you MUST attempt to register the language with ISO 639 first, bestie 📝 Subtags MUST NOT be registered for languages that already have codes in ISO 639-1, ISO 639-2, or ISO 639-3 💀 The same goes for languages ISO 639 is currently considering, or languages nobody has ever tried to register with those authorities 🚫 Now here's the tea ☕ If ISO 639 has already said no to a language, it's reasonable to assume you need some really, really compelling evidence before the IANA registry will accept it as a primary language subtag 🥲 Like, to the point where it's super unlikely any subtags of this type ever get registered 😭
  • Dialects and other variations within a language MAY be registered as variant subtags 💜 That covers orthography, writing system, regional or historical usage, transliteration or other transformation, or any other distinguishing variation 🧚 The example they give is the rozaj subtag, which is the Resian dialect of Slovenian 🇸🇮🎀
  • Fields in tag or subtag records, like the ones in Section 3.1, can be added or maintained, usually for informational stuff 📋 Those changes are subject to the stability provisions in Section 3.4 🔒 This includes Description, Comments, Deprecated, and Preferred-Value fields for obsolete or withdrawn codes 🍓 It also covers adding a Suppress-Script or Macrolanguage field to a primary language subtag ✨ And you can add a suitable Prefix field to a variant subtag, plus other changes this document allows 💖
  • Records and field value changes needed to reflect assignments made by ISO 639, ISO 15924, ISO 3166-1, and UN M.49 are allowed, as described in Section 3.4 🌍 Go you, keeping the registry in sync 🙌
Heads up, this one's serious 🚨 A subtag proposal that would make all or part of a grandfathered tag redundant MUST be rejected IF its meaning conflicts with or changes the meaning of that grandfathered tag 🛑 No exceptions, no vibes-based overrides 💅

This document leaves it up to the registration process in Section 3.5 to decide which subtags or subtag changes are appropriate, or not 🧾 So that's where the real judgment calls happen 👑

Note: Four-character primary language subtags are reserved 🌟 That's so there's room for possible alpha4 codes in a future addition to the ISO 639 family of standards 🔮

ISO 639 has a registration authority for adding to and changing the list of languages in ISO 639 ☎️ Here's who to call:

International Information Centre for Terminology (Infoterm)
Aichholzgasse 6/12, AT-1120
Wien, Austria
Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72

ISO 639-2 has its own registration authority for changes to its list of languages 📚 That agency is:

Library of Congress
Network Development and MARC Standards Office
Washington, DC 20540, USA
Phone: +1 202 707 6237 Fax: +1 202 707 0115
URL: http://www.loc.gov/standards/iso639-2

ISO 639-3 has a registration authority too, for additions and changes to its list 🌏 That's:

SIL International
ISO 639-3 Registrar
7500 W. Camp Wisdom Rd.
Dallas, TX 75236, USA
Phone: +1 972 708 7400, ext. 2293
Fax: +1 972 708 7546
Email: iso639-3@sil.org
URL: http://www.sil.org/iso639-3

ISO 639-5 has a registration authority for changes to its list of languages too 🌺 It's the same agency as ISO 639-2 ✨ So:

Library of Congress
Network Development and MARC Standards Office
Washington, DC 20540, USA
Phone: +1 202 707 6237
Fax: +1 202 707 0115
URL: http://www.loc.gov/standards/iso639-5

The maintenance agency for ISO 3166-1, the country codes, is:

ISO 3166 Maintenance Agency
c/o International Organization for Standardization
Case postale 56
CH-1211 Geneva 20, Switzerland
Phone: +41 22 749 72 33 Fax: +41 22 749 73 49
URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html

The registration authority for ISO 15924, the script codes, is:

Unicode Consortium
Box 391476
Mountain View, CA 94039-1476, USA
URL: http://www.unicode.org/iso15924

The Statistics Division of the United Nations Secretariat maintains the Standard Country or Area Codes for Statistical Use 🗺️ You can reach them here:

Statistical Services Branch
Statistics Division
United Nations, Room DC2-1620
New York, NY 10017, USA
Fax: +1-212-963-0623
Email: statistics@un.org
URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm

That's the whole vibe, bestie 🌈✨

3.7. Extensions and the Extensions Registry ✨

Okay bestie, so extension subtags are the ones that show up after a single-character subtag (a "singleton") other than 'x'. 🦋 They're reserved for making identifiers that have a language component and still play nicely with apps that understand language tags. 💖

The structure and form of extensions are defined by this document so that implementations can be created that are forward compatible with applications that might be created using singletons in the future. ✨ Defining a mechanism for maintaining singletons also lends stability to this document, since it cuts down on the likely need for future revisions or updates. 🧚

Single-character subtags are assigned by IANA using the "IETF Review" policy defined by [RFC5226]. 💅 This policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the subtags. The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC. The RFC MUST specify or include each of the following:

  • The specification MUST reference the specific version or revision of this document that governs its creation and MUST reference this section of this document.
  • The specification and all subtags defined by the specification MUST follow the ABNF and other rules for the formation of tags and subtags as defined in this document. In particular, it MUST specify that case is not significant and that subtags MUST NOT exceed eight characters in length.
  • The specification MUST specify a canonical representation.
  • The specification of valid subtags MUST be available over the Internet and at no cost.
  • The specification MUST be in the public domain or available via a royalty-free license acceptable to the IETF and specified in the RFC.
  • The specification MUST be versioned, and each version of the specification MUST be numbered, dated, and stable.
  • The specification MUST be stable. That is, extension subtags, once defined by a specification, MUST NOT be retracted or change in meaning in any substantial way.
  • The specification MUST include, in a separate section, the registration form reproduced in this section (below) to be used in registering the extension upon publication as an RFC.
  • IANA MUST be informed of changes to the contact information and URL for the specification.

IANA will maintain a registry of allocated single-character (singleton) subtags. 📝 This registry MUST use the record-jar format described by the ABNF in Section 3.1.1. Upon publication of an extension as an RFC, the maintaining authority defined in the RFC MUST forward this registration form to <iesg@ietf.org>, who MUST forward the request to <iana@iana.org>. The maintaining authority of the extension MUST maintain the accuracy of the record by sending an updated full copy of the record to <iana@iana.org> with the subject line "LANGUAGE TAG EXTENSION UPDATE" whenever content changes. Only the 'Comments', 'Contact_Email', 'Mailing_List', and 'URL' fields MAY be modified in these updates. 🌸

Failure to maintain this record, maintain the corresponding registry, or meet other conditions imposed by this section of this document MAY be appealed to the IESG [RFC2028] under the same rules as other IETF decisions (see [RFC2026]) and MAY result in the authority to maintain the extension being withdrawn or reassigned by the IESG. 🚨 Not the vibe we want, so please don't let this happen. 😭

Here's the registration form template:

%%
Identifier:
Description:
Comments:
Added:
RFC:
Authority:
Contact_Email:
Mailing_List:
URL:
%%

Figure 6: Format of Records in the Language Tag Extensions Registry

'Identifier' contains the single-character subtag (singleton) assigned to the extension. The Internet-Draft submitted to define the extension SHOULD specify which letter or digit to use, although the IESG MAY change the assignment when approving the RFC. 🍓

'Description' contains the name and description of the extension. 🎀

'Comments' is an OPTIONAL field and MAY contain a broader description of the extension. 💜

'Added' contains the date the extension's RFC was published in the "full-date" format specified in [RFC3339]. For example: 2004-06-28 represents June 28, 2004, in the Gregorian calendar. 🗓️

'RFC' contains the RFC number assigned to the extension.

'Authority' contains the name of the maintaining authority for the extension.

'Contact_Email' contains the email address used to contact the maintaining authority.

'Mailing_List' contains the URL or subscription email address of the mailing list used by the maintaining authority.

'URL' contains the URL of the registry for this extension.

The determination of whether an Internet-Draft meets the above conditions and the decision to grant or withhold such authority rests solely with the IESG and is subject to the normal review and appeals process associated with the RFC process. ⚖️

Extension authors are strongly cautioned that many (including most well-formed) processors will be unaware of any special relationships or meaning inherent in the order of extension subtags. 👀

Extension authors SHOULD avoid subtag relationships or canonicalization mechanisms that interfere with matching or with length restrictions that sometimes exist in common protocols where the extension is used. In particular, applications MAY truncate the subtags in doing matching or in fitting into limited lengths, so it is RECOMMENDED that the most significant information be in the most significant (left-most) subtags and that the specification gracefully handle truncated subtags. 🫶

When a language tag is to be used in a specific, known protocol, it is RECOMMENDED that the language tag not contain extensions not supported by that protocol. In addition, note that some protocols MAY impose upper limits on the length of the strings used to store or transport the language tag. 🔥

3.8. Update of the Language Subtag Registry 🌈

After the adoption of this document, the IANA Language Subtag Registry needed an update so that it would contain the complete set of subtags valid in a language tag. [RFC5645] describes the process used to create this update. ✨

Registrations that are in process under the rules defined in [RFC4646] when this document is adopted MUST be completed under the rules contained in this document. 📋

3.9. Applicability of the Subtag Registry 🦋

The Language Subtag Registry is the source of data elements used to construct language tags, following the rules described in this document. Language tags are designed for indicating linguistic attributes of various content, including not only text but also most media formats, such as video or audio. They also form the basis for language and locale negotiation in various protocols and APIs. 🎧

The registry is therefore applicable to many applications that need some form of language identification, with these limitations:

  • It is not designed to be the sole data source in the creation of a language-selection user interface. For example, the registry does not contain translations for subtag descriptions or for tags composed from the subtags. Sources for localized data based on the registry are generally available, notably [CLDR]. Nor does the registry indicate which subtag combinations are particularly useful or relevant.
  • It does not provide information indicating relationships between different languages, such as might be used in a user interface to select language tags hierarchically, regionally, or on some other organizational model.
  • It does not supply information about potential overlap between different language tags, as the notion of what constitutes a language is not precise: several different language tags might be reasonable choices for the same given piece of content.
  • It does not contain information about appropriate fallback choices when performing language negotiation. A good fallback language might be linguistically unrelated to the specified language. The fact that one language is often used as a fallback language for another is usually a result of outside factors, such as geography, history, or culture -- factors that might not apply in all cases. For example, most people who use Breton (a Celtic language used in the Northwest of France) would probably prefer to be served French (a Romance language) if Breton isn't available. 🥖

4. Formation and Processing of Language Tags 💅

This section addresses how to use the information in the registry with the tag syntax to choose, form, and process language tags. 🧩

4.1. Choice of Language Tag 🌸

The guiding principle in forming language tags is to "tag content wisely." ✨ Sometimes there is a choice between several possible tags for the same content. The choice of which tag to use depends on the content and application in question, and some amount of judgment might be necessary when selecting a tag. 🤔

Interoperability is best served when the same language tag is used consistently to represent the same language. If an application has requirements that make the rules here inapplicable, then that application risks damaging interoperability. It is strongly RECOMMENDED that users not define their own rules for language tag choice. 🙅‍♀️

Standards, protocols, and applications that reference this document normatively but apply different rules to the ones given in this section MUST specify how language tag selection varies from the guidelines given here. 📜

To ensure consistent backward compatibility, this document contains several provisions to account for potential instability in the standards used to define the subtags that make up language tags. 🧠

These provisions mean that no valid language tag can become invalid, nor will a language tag have a narrower scope in the future (it may have a broader scope). The most appropriate language tag for a given application or content item might evolve over time, but once applied, the tag itself cannot become invalid or have its meaning wholly change. 💖

A subtag SHOULD only be used when it adds useful distinguishing information to the tag. Extraneous subtags interfere with the meaning, understanding, and processing of language tags. In particular, users and implementations SHOULD follow the 'Prefix' and 'Suppress-Script' fields in the registry (defined in Section 3.1): these fields provide guidance on when specific additional subtags SHOULD be used or avoided in a language tag. 🎯

The choice of subtags used to form a language tag SHOULD follow these guidelines:

  1. Use as precise a tag as possible, but no more specific than is justified. Avoid using subtags that are not important for distinguishing content in an application.
    • For example, 'de' might suffice for tagging an email written in German, while "de-CH-1996" is probably unnecessarily precise for such a task. 🇩🇪
  2. 🎀 The script subtag SHOULD NOT be used to form language tags unless the script adds some distinguishing information to the tag. Script subtags were first formally defined in [RFC4646]. Their use can affect matching and subtag identification for implementations of [RFC1766] or [RFC3066] (which are obsoleted by this document), because these subtags sit between the primary language and region subtags. Some applications can benefit from script subtags, as long as you use them consistently within a given context. Script subtags are never appropriate for unwritten content, like audio recordings. The Suppress-Script field in the primary or extended language record of the registry lists script subtags that don't add distinguishing information for most applications. That field defines when users SHOULD NOT include a script subtag with a particular primary language subtag. 🧚

For example, if an implementation picks content using Basic Filtering [RFC4647] (originally described in Section 14.4 of [RFC2616]) and the user asks for the language range en-US, content labeled en-Latn-US won't match the request and won't get selected. 😭 So it's super important to know when script subtags are customarily used and when they really shouldn't be.

  • For example, the subtag 'Latn' should not be used with the primary language 'en', because nearly all English documents are written in the Latin script and it adds no distinguishing information. However, if a document were written in English mixing Latin script with another script like Braille ('Brai'), it might be appropriate to indicate both scripts to help with content selection, such as applying a style sheet. ✨
  • When labeling content that is unwritten (like a recording of human speech), the script subtag should not be used, even if the language is customarily written in several scripts. So the subtitles for a movie might use the tag "uz-Arab" (Uzbek, Arabic script), but the audio track for the same language would just be tagged "uz". (The tag "uz-Zxxx" could also be used where content is not written, since the subtag 'Zxxx' represents the "Code for unwritten documents".) 🌈
  1. 🦋 If a tag or subtag has a Preferred-Value field in its registry entry, then the value of that field SHOULD be used to form the language tag, in preference to the tag or subtag where the preferred value appears.
    • For example, use 'jbo' for Lojban in preference to the grandfathered tag "art-lojban". 💜
  2. 👑 Use subtags or sequences of subtags for individual languages in preference to subtags for language collections. A "language collection" is a group of languages that descend from a common ancestor, are spoken in the same geographical area, or are otherwise related. Certain language collections are assigned codes by [ISO639-5] (and some of these [ISO639-5] codes are also defined as collections in [ISO639-2]). These codes are included as primary language subtags in the registry. Subtags for a language collection in the registry have a Scope field with a value of collection. A subtag for a language collection is always preferred to less specific alternatives like 'mul' and 'und' (see below), and a subtag representing a language collection MAY be used when more specific language information isn't available. However, most users and implementations don't know there's a relationship between the collection and its individual languages. Plus, the relationship between the individual languages in the collection isn't well defined. In particular, the languages are usually not mutually intelligible. Since the subtags are different, a request for the collection will typically only produce items tagged with the collection's subtag, not items tagged with subtags for the individual languages inside it. 🙈
    • For example, collections are interpreted inclusively, so the subtag 'gem' (Germanic languages) could, but SHOULD NOT, be used with content that would be better tagged "en" (English), "de" (German), or "gsw" (Swiss German, Alemannic). While 'gem' collects all of these (and other) languages, most implementations won't match 'gem' to the individual languages, so using it won't give you the result you want. 💀
  3. 🌸 [ISO639-2] has defined several codes in the subtag registry that need extra care when you choose language tags. In most of these cases, where leaving out the language tag is allowed, leaving it out is better than using these codes. Language tags SHOULD NOT incorporate these subtags as a prefix, unless the extra information actually adds value for the application.
    • The 'mul' (Multiple) primary language subtag identifies content in multiple languages. This subtag SHOULD NOT be used when a list of languages or individual tags for each content element can be used instead. For example, the Content-Language header [RFC3282] allows a list of languages, not just a single language tag. 🍓
    • The 'und' (Undetermined) primary language subtag identifies linguistic content whose language isn't determined. This subtag SHOULD NOT be used unless a language tag is required and language information is unavailable or can't be determined. Leaving out the language tag (where permitted) is preferred. The 'und' subtag might be useful for protocols that require a language tag to be provided, or where a primary language subtag is required (such as in "und-Latn"). The 'und' subtag MAY also be useful when matching language tags in certain situations. 🔥
    • The 'zxx' (Non-Linguistic, Not Applicable) primary language subtag identifies content for which a language classification is inappropriate or doesn't apply. Some examples include instrumental or electronic music; sound recordings made of nonverbal sounds; audiovisual materials with no narration, dialog, printed titles, or subtitles; machine-readable data files made of machine languages or character codes; or programming source code. 🧚‍♀️
    • The 'mis' (Uncoded) primary language subtag identifies content whose language is known but doesn't currently have a corresponding subtag. This subtag SHOULD NOT be used. Because adding other codes in the future can make its use invalid, it's inherently unstable and therefore incompatible with the stability goals of BCP 47. It's always better to use other subtags: either 'und' or (with prior agreement) private use subtags. 🚫
  4. 💖 Use variant subtags sparingly and in the correct order. Most variant subtags have one or more Prefix fields in the registry that list the subtags they're appropriate with. Variants SHOULD only be used with subtags that appear in one of these Prefix fields. If a variant lists a second variant in one of its Prefix fields, the first variant SHOULD appear directly after the second variant in any language tag where both occur. General purpose variants (those with no Prefix fields at all) SHOULD appear after any other variant subtags. Order any remaining variants by putting the most significant subtag first. If none of the subtags is more significant, or no relationship can be determined, alphabetize the subtags. Because variants are very specialized, using lots of them together usually makes the tag so narrow that it overrides the extra precision you gained. Putting the subtags in another order interferes with interoperability, as well as with the overall interpretation of the tag. 🎀
    • For example, the tag "en-scotland-fonipa" (English, Scottish dialect, IPA phonetic transcription) is correctly ordered, because 'scotland' has a Prefix of "en", while 'fonipa' has no Prefix field.
    • The tag "sl-IT-rozaj-biske-1994" is correctly ordered: 'rozaj' lists "sl" as its sole Prefix, and 'biske' lists "sl-rozaj" as its sole Prefix. The subtag '1994' has several prefixes, including "sl-rozaj". However, it follows both 'rozaj' and 'biske', because one of its Prefix fields is "sl-rozaj-biske". ⭐
  5. 🍑 The grandfathered tag "i-default" (Default Language) was originally registered according to [RFC1766] to meet the needs of [RFC2277]. It isn't used to indicate a specific language. Instead, it identifies the condition or content used where the language preferences of the user can't be established. It SHOULD NOT be used except as a means of labeling the default content for applications or protocols that require default language content to be labeled with that specific tag. It MAY also be used by an application or protocol to identify when the default language content is being returned. 🫶

4.1.1. Tagging Encompassed Languages ✨

Okay so some primary language records in the registry have a Macrolanguage field (Section 3.1.10) that maps each "encompassed language" to its macrolanguage 🌸. But the Macrolanguage mapping doesn't spill what the relationship between the encompassed language and its macrolanguage actually is, and it doesn't say how languages under the same macrolanguage relate to each other either. Two different languages encompassed by the same macrolanguage can be way more different from each other than, say, French and Spanish are 🙈.

A few special macrolanguages, like Chinese ('zh') and Arabic ('ar'), are handled differently, so go check out Section 4.1.2 🧚.

The more specific encompassed language subtag SHOULD be used to form the language tag 💖, although either the macrolanguage's primary language subtag or the encompassed language's subtag MAY be used. So for example, you'd tag Plains Cree with 'crk' rather than 'cr' (Cree), and so on and so forth 💅.

Each macrolanguage subtag's scope, by definition, includes all of its encompassed languages 👑. Because the relationship between encompassed languages varies, users cannot assume that the macrolanguage subtag means any particular encompassed language, and they can't assume that any given pair of encompassed languages are mutually intelligible or otherwise interchangeable 🙅.

Applications MAY use macrolanguage information to improve matching or language negotiation 🔥. Like, the fact that 'sr' (Serbian) and 'hr' (Croatian) share a macrolanguage tells you those two are more closely related than 'sr' (Serbian) and 'ma' (Macedonian) are. BUT, and this is important, that relationship is not guaranteed, and it's not exclusive 😭. Romanian ('ro') and Moldavian ('mo') don't share a macrolanguage, yet they're way more closely related to each other than Cantonese ('yue') and Wu ('wuu'), which do share a macrolanguage. Wild, right? 🤯

4.1.2. Using Extended Language Subtags 🎀

Okay, so to accommodate language tag forms used before this document came along, language tags have a special compatibility mechanism: the extended language subtag 🦋. Some languages have been given both primary and extended language subtags. These include macrolanguages, like Malay ('ms') and Uzbek ('uz'), that have a specific dominant variety that is generally synonymous with the macrolanguage. Other languages, like the Chinese ('zh') and Arabic ('ar') macrolanguages and the various sign languages ('sgn'), have traditionally used their primary language subtag, maybe paired with region subtags or as part of a registered grandfathered tag, to indicate the language 🌈.

With this document, specific ISO 639-3 subtags became available to identify the languages inside these diverse language families or groupings. That gives you a choice of language tags where there used to be none 🍓:

  • Each encompassed language's subtag SHOULD be used as the primary language subtag. For example, a document in Mandarin Chinese would be tagged "cmn" (the subtag for Mandarin Chinese) in preference to "zh" (Chinese).
  • If compatibility is desired or needed, the encompassed subtag MAY be used as an extended language subtag. For example, a document in Mandarin Chinese could be tagged "zh-cmn" instead of either "cmn" or "zh".
  • The macrolanguage or prefixing subtag MAY still be used to form the tag instead of the more specific encompassed language subtag. That is, tags such as "zh-HK" or "sgn-RU" are still valid 💜.

Chinese ('zh') is the perfect example here 👑. In the past, lots of content used tags starting with the 'zh' subtag, with application-specific meanings attached to region codes, private use sequences, or grandfathered registered values. That happened because, historically, only the macrolanguage subtag 'zh' was available for forming language tags. The thing is, the languages encompassed by the Chinese subtag 'zh' are, for the most part, not mutually intelligible when spoken, and their written forms show wide variation in form and usage 😭.

To keep things compatible, Chinese languages encompassed by the 'zh' subtag are in the registry as both primary language subtags and extended language subtags 🫶. For example, the ISO 639-3 code for Cantonese is 'yue'. Content in Cantonese might historically have used a tag like "zh-HK" (since Cantonese is commonly spoken in Hong Kong), even though that tag actually means any type of Chinese used in Hong Kong. Now that ISO 639-3 codes are in the registry, Cantonese content can be tagged directly with the 'yue' subtag. It can use that as a primary language subtag, like "yue-HK" (Cantonese, Hong Kong). Or it can use an extended language subtag with 'zh', like "zh-yue-Hant" (Chinese, Cantonese, Traditional script) ✨.

As noted above, applications can choose to use the macrolanguage subtag to form the tag instead of the more specific encompassed language subtag 🧚. Say an app already has tons of data tagged with the 'zh' (Chinese) subtag. It might keep using that more general subtag even for new data, even though the content could be tagged more precisely with 'cmn' (Mandarin), 'yue' (Cantonese), 'wuu' (Wu), and so on. Same deal for an app already using tags that start with the 'ar' (Arabic) subtag: it might keep using that general subtag for new data, which could be tagged more precisely with 'arb' (Standard Arabic) 🌸.

Some encompassed languages had tags registered for them during the RFC 3066 era 🕰️. Those grandfathered tags that weren't already deprecated or made redundant were deprecated in the registry when this document was adopted. As grandfathered values, they're still valid for use, and some content or applications might still use them. Just like with other grandfathered tags: implementations might not be able to link those grandfathered tags to the encompassed language subtag equivalents this document recommends, so implementations are encouraged to canonicalize tags for comparison purposes 🤓. Some examples include the tags "zh-hakka" (Hakka) and "zh-guoyu" (Mandarin or Standard Chinese).

Sign languages share a mode of communication, not a linguistic heritage 🙌. There are lots of sign languages that developed independently, and the subtag 'sgn' only tells you that a sign language is present. A number of sign languages also had grandfathered tags registered for them during the RFC 3066 era. For example, the grandfathered tag "sgn-US" was registered to represent 'American Sign Language' specifically, without any reference to the United States. It's still valid, but deprecated: a document in American Sign Language can be labeled either "ase" or "sgn-ase" (the 'ase' subtag is for the language called 'American Sign Language') 💅.

4.2. Meaning of the Language Tag 💖

Okay so the meaning of a language tag is tied to the meaning of the subtags inside it ✨ Each subtag gives you a certain range of expectations about the related content, but it's not a guarantee 🦋 For example, a script subtag like 'Arab' (Arabic script) doesn't mean the content only has Arabic characters. It does mean the language is mostly written in the Arabic script 🌸 So a language tag and its subtags can cover a super wide range of variation and still be appropriate in each specific case 💅

Validity isn't the only thing that decides whether a tag is useful 🎀 Every valid tag has a meaning, but it might not match any real-world language usage at all 💀 This is unavoidable when subtags can be mixed together freely. For example, ar-Cyrl-CO (Arabic, Cyrillic script, as used in Colombia) and tlh-Kore-AQ-fonipa (Klingon, Korean script, as used in Antarctica, IPA phonetic transcription) are both valid, but they're unlikely to be a useful combo of language attributes 😭

A tag's meaning doesn't change based on where it shows up 🧚 The relationship between that meaning and the information objects the tag gets applied to, though, can totally vary 👑

  • For a single information object, the language tags might be read as the set of languages you need to fully understand the whole object. Example: Plain text documents.
  • For an aggregation of information objects, the language tags could be taken as the set of languages used inside the parts of that aggregation. Examples: Document stores and libraries.
  • For information objects whose purpose is to provide alternatives, the language tags could be treated as a hint that the content comes in several languages, and you have to check each alternative to find its language or languages. In this case, having multiple tags doesn't mean you need to be multilingual to fully understand the document. Example: MIME multipart/alternative [RFC2046].
  • For markup languages, such as HTML and XML, language info can be added to each part of the document marked up by the structure (including the whole document itself) 🌈 For example, you could write <span lang="fr">C'est la vie.</span> inside a German document. A German-speaking reader could then use a French-German dictionary to find out what the marked bit meant. If the user were listening to that document through a speech synthesis interface, this markup could tell the synthesizer to use French text-to-speech pronunciation rules for that span, instead of the inappropriate German rules 🔥
  • For markup languages and document formats that let you identify the audience, a language tag could indicate the audience or audiences that suit that document 🫶 For example, the same HTML document from the bullet above might have an HTTP header Content-Language: de to show that the intended audience is German, even though three words in it appear and are identified as French 😂
  • For systems and APIs, language tags are the foundation for most implementations of locale identifiers. For example, see Unicode's CLDR (Common Locale Data Repository) (see UTS #35 [UTS35]) project. 🍓

Language tags are related when they share a similar sequence of subtags 🦋 For example, if a language tag B has language tag A as a prefix, then B is typically "narrower" or "more specific" than A. So zh-Hant-TW is more specific than zh-Hant ✨

This relationship isn't guaranteed in every case 🙈 Specifically, languages that start with the same sequence of subtags are NOT guaranteed to be mutually intelligible, although they might be. For example, the tag az shares a prefix with both az-Latn (Azerbaijani written using the Latin script) and az-Cyrl (Azerbaijani written using the Cyrillic script). A person who's fluent in one script might not be able to read the other, even if the linguistic content (like what you'd hear if both texts were read aloud) is totally identical 😭 Content tagged as az is most likely written in just one script, so it might not be intelligible to a reader who only knows the other script 💜

Also, not every subtag points to an actual difference in language 💅 For example, the tags en-US and en-CA roughly mean English with features generally thought of as characteristic of the United States and Canada, respectively. They don't imply that there's a significant dialect boundary between any randomly picked point in the United States and any randomly picked point in Canada 🌸 And a region subtag doesn't mean there are no linguistic differences inside that region either 🎀

4.3. Lists of Languages 🌈

Sometimes in some apps, one content item is best linked to more than one language tag ✨ Examples of this kind of usage include:

  • Content items that have multiple, distinct varieties 🦋 This is often used to show the right audience for a content item when more than one choice might fit. Examples of this could include:
    • Metadata about the right audience for a movie title. For example, a DVD might label its individual audio tracks 'de' (German), 'fr' (French), and 'es' (Spanish), but the overall title would list "de, fr, es" as its overall audience 🎬
    • A French/English, English/French dictionary tagged as both "en" and "fr" to say it applies equally to French and English 📚
    • A side-by-side or interlinear translation of a document, which is commonly done with classical works in Latin or Greek 🏛️
  • Content items that contain a single language but need multiple levels of specificity 💖 For example, a library might want to classify a particular work as both Norwegian ('no') and as Nynorsk ('nn'), for audiences who can appreciate the difference or who need to pick content more narrowly 👑

4.4. Length Considerations 📏

There's no defined upper limit on how big language tags can be 🧚 Historically, most language tags have been language and region subtags with a combined total length of up to six characters, but larger tags have always been possible and have actually shown up in real use 💅

Neither the language tag syntax nor the other requirements in this document put a fixed upper limit on the number of subtags in a language tag (and so no upper bound on tag size either) 🫶 The syntax suggests that, depending on the specific language, more subtags (and a longer tag) are sometimes needed to fully identify the language for certain applications. So it's possible to imagine long or complex subtag sequences 🌸

4.4.1. Working with Limited Buffer Sizes 🍓

Some applications and protocols are forced to allocate fixed buffer sizes or otherwise limit the length of a language tag 😭 A conformant implementation or specification MAY refuse to support storing language tags that go over a specified length. Any such limitation SHOULD be clearly documented, and that documentation SHOULD include what happens to longer tags (for example, whether an error value is generated or the language tag gets truncated). A protocol that lets tags get truncated at an arbitrary limit, without any indication of what that limit is, can cause harm by changing the meaning of tags in major ways 🚨

In practice, most language tags don't need more than a few subtags and won't come anywhere near reasonably sized buffer limits 🦋 See Section 4.1.

Some specifications or protocols have limits on tag length but no fixed length limitation 🌈 For example, [RFC2231] has no explicit length limitation: the length available for the language tag is constrained by the length of other header components (such as the charset's name) combined with the 76-character limit in [RFC2047]. So the "limit" might be 50 or more characters, but it could potentially be quite small 🤏

The considerations for assigning a buffer limit are:

  • Implementations SHOULD NOT truncate language tags unless the meaning of the tag is purposefully being changed, or unless the tag doesn't fit into a limited buffer size specified by a protocol for storage or transmission.
  • Implementations SHOULD warn the user when a tag is truncated, since truncation changes the semantic meaning of the tag ⚠️
  • Implementations of protocols or specifications that are space constrained but have no fixed limit SHOULD use the longest possible tag in preference to truncation.
  • Protocols or specifications that specify limited buffer sizes for language tags MUST allow for language tags of at least 35 characters. Note that [RFC4646] recommended a minimum field size of 42 characters because it included all three elements of the 'extlang' production. Two of these are now permanently reserved, so a registered primary language subtag of the maximum length of 8 characters is now longer than the longest language-extlang combination. Protocols or specifications that commonly use extensions or private use subtags might wish to reserve or recommend a longer "minimum buffer" size 💜

The following illustration shows how the 35-character recommendation was derived 🧮

   language      =  8 ; longest allowed registered value
                      ;   longer than primary+extlang
                      ;   which requires 7 characters
   script        =  5 ; if not suppressed: see Section 4.1
   region        =  4 ; UN M.49 numeric region code
                      ;   ISO 3166-1 codes require 3
   variant1      =  9 ; needs 'language' as a prefix
   variant2      =  9 ; very rare, as it needs
                      ;   'language-variant1' as a prefix

   total         = 35 characters

              Figure 7: Derivation of the Limit on Tag Length

4.4.2. Truncation of Language Tags ✂️

Truncating a language tag changes the meaning of the tag, so it SHOULD be avoided 💅 That said, truncation is sometimes necessary because of limited buffer sizes. Such truncation MUST NOT chop a subtag off in the middle or create invalid tags (for example, one ending with the "-" character) 😱

This means that applications or protocols that truncate tags MUST do so by progressively removing subtags, along with their preceding "-", from the right side of the language tag until the tag is short enough for the given buffer. If the resulting tag ends with a single-character subtag, that subtag and its preceding "-" MUST also be removed. For example 🎀

   Tag to truncate: zh-Latn-CN-variant1-a-extend1-x-wadegile-private1
   1. zh-Latn-CN-variant1-a-extend1-x-wadegile
   2. zh-Latn-CN-variant1-a-extend1
   3. zh-Latn-CN-variant1
   4. zh-Latn-CN
   5. zh-Latn
   6. zh

                    Figure 8: Example of Tag Truncation

4.5. Canonicalization of Language Tags 💅

okay so, one language tag can get passed around to a whole bunch of different processes, so bestie, language tags SHOULD always be created or generated in canonical form 🫶

so what even is "canonical form"? 🤔 a tag is in canonical form when it's well-formed (per Sections 2.1 and 2.2) AND it's been canonicalized by running through each of these steps in order, using data from the IANA registry (see Section 3.1):

  1. Extension sequences get sorted into case-insensitive ASCII order by their singleton subtag. 🗂️
    • like, -a-babble comes before -b-warble 💜
  2. Redundant or grandfathered tags get swapped for their 'Preferred-Value', if they have one ✨
    • the field-body of the 'Preferred-Value' for grandfathered and redundant tags is an "extended language range" [RFC4647] and might have more than one subtag 🌈
    • 'Preferred-Value' fields in the registry map deprecated tags to modern ones. lots of these were made before this doc even existed (like no-nyn to nn, or i-klingon to tlh 💀), and others come from later registrations or additions the registry allows or requires under this document (ex: zh-hakka got deprecated in favor of the ISO 639-3 code hak when this doc was adopted) 🍓
  3. Subtags get replaced by their 'Preferred-Value', if there is one. for extlangs, the original primary language subtag gets replaced too if the 'Preferred-Value' has a primary language subtag 🎀
    • the field-body for extlangs is an "extended language range" and usually maps to a primary language subtag. for example, zh-hak (Chinese, Hakka) gets replaced with the subtag hak (Hakka) 🧚
    • most non-extlang subtags are either Region subtags where the country name or designation changed, or clerical fixes to ISO 639-1 🌸

the canonical form has no 'extlang' subtags. there's also an alternate 'extlang form' that keeps or brings back extlang subtags. that's useful where having the 'Prefix' subtag helps with matching or selection (see Section 4.1.2) 🦋

a tag is in 'extlang form' when it's well-formed (per Sections 2.1 and 2.2) and it's been processed by these two steps in order, using data from the IANA registry:

  1. the tag gets transformed into canonical form first, as described above.
  2. if the tag starts with a primary language subtag that's also an extlang subtag, then the tag gets prepended with the extlang's 'Prefix'.
    • for example, hak-CN (Hakka, China) has the primary language subtag hak, which has an 'extlang' record with a 'Prefix' of zh (Chinese). the extlang form is zh-hak-CN (Chinese, Hakka, China) 🧧
    • note that Step 2 (prepending a prefix) can restore a subtag that got removed by Step 1 (canonicalizing) 🔁

Example: en-a-aaa-b-ccc-bbb-x-xyz is in canonical form, while en-b-ccc-bbb-a-aaa-X-xyz is well-formed and potentially valid (extensions 'a' and 'b' aren't defined as of the publication of this document) but NOT in canonical form, because the extensions aren't in alphabetical order 🙈

Example: en-BU (English as used in Burma) keeps its validity, but it's not in canonical form because the 'BU' subtag has a canonical mapping to 'MM' (Myanmar) 🇲🇲

canonicalization doesn't imply anything about the use of upper- or lowercase letters when processing or comparing subtags (see Section 2.1). all comparisons MUST be performed in a case-insensitive manner. it's giving consistency, no cap 😤

when canonicalizing, processors MAY regularize the case of the subtags (that is, this process is OPTIONAL), following the case used in the registry (see Section 2.1.1) 🧁

if more than one variant shows up in a tag, processors MAY reorder the variants to get better matching behavior or more consistent presentation. reordering the variants SHOULD follow the recommendations for variant ordering in Section 4.1 💫

if the field 'Deprecated' appears in a registry record without an accompanying 'Preferred-Value' field, then that tag or subtag is deprecated with no replacement. these values are canonical when they show up in a language tag. HOWEVER, tags that include these values SHOULD NOT be selected by users or generated by implementations. not it 🚫

an extension MUST define any relationships that exist between its various subtags, and so it MAY define an alternate canonicalization scheme for the extension's subtags. extensions MAY define how the order of their subtags is interpreted. for example, an extension could say its subtags are in canonical order when they're placed in ASCII order, like en-a-aaa-bbb-ccc instead of en-a-ccc-bbb-aaa. another extension might say the order of the subtags changes their semantic meaning, so en-b-ccc-bbb-aaa has a different value from en-b-aaa-bbb-ccc 🤯. still, extension specifications SHOULD be designed so they're tolerant of the typical processes described in Section 3.7 🥹

4.6. Considerations for Private Use Subtags 🔒

okay private use subtags, like every other subtag, MUST conform to the format and content constraints in the ABNF. they have no meaning outside the private agreement between the parties who plan to use or swap language tags with them 🤫. the same subtags MAY be used with a different meaning under a separate private agreement. they SHOULD NOT be used where alternatives exist, and they SHOULD NOT be used in content or protocols meant for general use 🙅‍♀️

private use subtags are literally useless for info exchange without prior arrangement 💀. the value and semantic meaning of private use tags, and of the subtags used inside them, aren't defined by this document.

private use sequences introduced by the 'x' singleton are completely opaque to anyone outside the private use agreement. so, besides private use subtag sequences introduced by the singleton subtag 'x', the Language Subtag Registry also gives you private use language, script, and region subtags derived from the private use codes assigned by the underlying standards 🧩. these subtags are valid for forming language tags, and they are RECOMMENDED over the 'x' singleton private use subtag sequences because they convey more information through their linkage to the language tag's inherent structure ✨

for example, the region subtags 'AA', 'ZZ', and the ones in the ranges 'QM'-'QZ' and 'XA'-'XZ' (derived from the ISO 3166-1 private use codes) can be used to form a language tag 🌍. a tag like zh-Hans-XQ conveys a whole lot of public, interchangeable info about the language material (it's Chinese, in the simplified Chinese script, and suitable for some geographic region 'XQ') 📚. the precise region isn't known outside the private agreement, but the tag still says way more than an opaque tag like x-somelang or even zh-Hans-x-xq (where the 'xq' subtag's meaning is totally opaque) 🫠

HOWEVER, in some cases content tagged with private use subtags can interact with other systems in a different and possibly unsuitable way compared to tags that use opaque, privately defined subtags. so the best approach sometimes depends on the particular domain in question 🧠

5. IANA Considerations 🎀

this section covers the processes and requirements IANA needs in order to maintain the subtag and extension registries, as defined by this document and in line with the requirements of [RFC5226] 📋.

the impact on the IANA maintainers of the two registries defined by this document will be a small increase in how often new entries or updates happen 📈. IANA also is required to create a new mailing list (described below in Section 5.1) to announce registry changes and updates 📣

5.1. Language Subtag Registry ✨

okay so IANA already updated the registry using the instructions and content from a companion doc, [RFC5645] 🧚. The criteria and process for picking the updated set of records are described in that doc. bestie, the updated set has no impact on IANA at all, since all the work to make it happens externally 💅.

Future work on the Language Subtag Registry includes these activities:

  • Inserting or replacing whole records. These records are preformatted for IANA by the Language Subtag Reviewer, as described in Section 3.3.
  • Archiving and making publicly available the registration forms.
  • Announcing each updated version of the registry on the ietf-languages-announcements@iana.org mailing list.

Each registration form sent to IANA contains a single record for the registry. The Language Subtag Reviewer sends the form to <iana@iana.org>. The subject line says whether the form is an insertion of a new record (the word INSERT in the subject line) or a replacement of an existing record (the word MODIFY in the subject line). At no time can a record be deleted from the registry 🙅‍♀️

IANA pulls the record out of the form and puts the inserted or modified record into the right section of the Language Subtag Registry, grouping the records by their Type field 🗂️ Inserted records can go anywhere within that section. There's no guarantee about any particular order, except that the records will always be grouped by Type. Modified records overwrite the record they replace.

Whenever an entry is created or modified, the File-Date record at the start of the registry gets updated to show the most recent modification date. The date format SHALL be the "full-date" format of [RFC3339]. The date SHALL be the date on which that version of the registry was first published by IANA. There SHALL be at most one version of the registry published in a day 📅 A File-Date record is also included in each request to IANA to insert or modify records, showing the acceptance date of the records in that request.

The updated registry file MUST use the UTF-8 character encoding, and IANA MUST check the registry file for proper encoding. Non-ASCII characters can be sent to IANA by attaching the registration form to the email message, or by using various encodings in the mail message body (UTF-8 is recommended). IANA will verify any unclear or corrupted characters with the Language Subtag Reviewer before posting the updated registry 🔍

IANA will also archive and make publicly available each registration form from http://www.iana.org. Note that multiple registrations can pertain to the same record in the registry 🧾

Developers who depend on the Language Subtag Registry sometimes want to hear about changes so they can update their implementations, and that's so valid 🫶 When any change is made to the Language Subtag Registry, IANA will send an announcement message to <ietf-languages-announcements@iana.org>. That's a self-subscribing list that only IANA can post to 📣

5.2. Extensions Registry 🧩

The Language Tag Extensions Registry can contain at most 35 records, so changes to this registry are expected to be very infrequent. It's giving small and curated 💜

Future work by IANA on the Language Tag Extensions Registry is limited to two cases. First, the IESG MAY request that new records be inserted into this registry from time to time. These requests MUST include the record to insert, in the exact format described in Section 3.7. In addition, there MAY be occasional requests from the maintaining authority for a specific extension to update the contact information or URLs in the record. These requests MUST include the complete, updated record. IANA is not responsible for validating the information provided, only that it is properly formatted. IANA SHOULD take reasonable steps to ascertain that the request comes from the maintaining authority named in the record already present in the registry 🕵️‍♀️

6. Security Considerations 🔐

Language tags used in content negotiation, like any other information exchanged on the Internet, might be a source of concern, because they might be used to infer the nationality of the sender and thus identify potential targets for surveillance 👀 This is serious, bestie, so please read it carefully.

This is a special case of the general problem that anything sent is visible to the receiving party and possibly to third parties as well. It's useful to be aware that these concerns can exist in some cases 🦋

The evaluation of the exact magnitude of the threat, and any possible countermeasures, is left to each application protocol. (See BCP 72 [RFC3552] for best current practice guidance on security threats and defenses.) 🛡️

The language tag associated with a particular information item is of no consequence whatsoever in determining whether that content might contain possible homographs. The fact that a text is tagged as being in one language, or using a particular script subtag, provides no assurance whatsoever that it does not contain characters from scripts other than the one(s) associated with or specified by that language tag. So a tag is not a guarantee about the characters inside the text 🙈

Since there is no limit to the number of variant, private use, and extension subtags, and consequently no limit on the possible length of a tag, implementations need to guard against buffer overflow attacks. See Section 4.4 for details on language tag truncation, which can occur as a consequence of defenses against buffer overflow 💥

To prevent denial-of-service attacks, applications SHOULD NOT depend on either the Language Subtag Registry or the Language Tag Extensions Registry being always accessible. Additionally, although the specification of valid subtags for an extension (see Section 3.7) MUST be available over the Internet, implementations SHOULD NOT mechanically depend on those sources being always accessible 🚦

The registries specified in this document are not suitable for frequent or real-time access to, or retrieval of, the full registry contents. Most applications don't need registry data at all. For others, being able to validate or canonicalize language tags as of a particular registry date will be sufficient, since the registry contents change only occasionally 🗓️ Changes are announced to <ietf-languages-announcements@iana.org>. That mailing list is intended for interested organizations and individuals, not for bulk subscription to trigger automatic software updates. The size of the registry makes it unsuitable for automatic software updates. Implementers who are considering integrating the Language Subtag Registry into an automatic updating scheme are strongly advised to distribute only suitably encoded differences, and only via their own infrastructure, not directly from IANA 🏗️

Changes, or the absence of them, can also easily be detected by looking at the File-Date record at the start of the registry, or by using features of the protocol used for downloading, without having to download the full registry. At the time of publication of this document, IANA is making the Language Tag Registry available over HTTP 1.1. The proper way to update a local copy of the Language Subtag Registry using HTTP 1.1 is to use a conditional GET [RFC2616] 📥✨

7. Character Set Considerations 🔤

The syntax in this document requires that language tags use only the characters A-Z, a-z, 0-9, and HYPHEN-MINUS (-). These are present in most character sets, so the composition of language tags shouldn't have any character set issues 🌸

The rendering of text based on the language tag is not addressed here. Historically, some processes have relied on character set and encoding information (or other external information) to infer how a specific string of characters should be rendered. Notably, this applies to language- and culture-specific variations of Han ideographs as used in Japanese, Chinese, and Korean. For example, using a Japanese character encoding such as EUC-JP implies that the text itself is in Japanese 🇯🇵🇨🇳🇰🇷 When language tags are applied to spans of text, rendering engines might be able to use that information to better select fonts or make other rendering choices, particularly where languages with distinct writing traditions use the same characters 🎀

8. Changes from RFC 4646 ✨

okay bestie, this section is basically the glow-up log 💅 The big goal of this revision was to bring two new parts of ISO 639 (ISO 639-3 and ISO 639-5) and all their language codes into the IANA Language Subtag Registry 🌍 That means way more languages and language collections can be identified than before 🦋

Here's everything that changed in this document to make that happen 👇

  • Defined how ISO 639-3 and ISO 639-5 codes can be used as primary and extended language subtags 🎀 It also permanently reserves and disallows any additional 'extlang' subtags 🙅‍♀️ The changes needed for this were:
    • Modified the ABNF comments.
    • Updated various registration and stability requirements sections to reference ISO 639-3 and ISO 639-5 in addition to ISO 639-1 and ISO 639-2.
    • Edited the text to eliminate references to extended language subtags where they are no longer used.
    • Explained the change in the section on extended language subtags.
  • Changed the ABNF related to grandfathered tags 🌸 The irregular tags are now listed. Well-formed grandfathered tags are now described by the 'langtag' production, so the 'grandfathered' production was removed as a result. Also added a description of both types of grandfathered tags to Section 2.2.8 ✨
  • Added the paragraph on "collections" to Section 4.1 💜
  • Changed the capitalization rules for 'Tag' fields in Section 3.1 🧚
  • Split Section 3.1 up into subsections 🍓
  • Modified Section 3.5 to allow 'Suppress-Script' fields to be added, modified, or removed via the registration process. This was an erratum from RFC 4646 😭
  • Modified examples that used region code 'CS' (formerly Serbia and Montenegro) to use 'RS' (Serbia) instead 🇷🇸
  • Modified the rules for creating and maintaining record 'Description' fields to prevent duplicates, including inverted duplicates 🙈
  • Removed the lengthy description of why RFC 4646 was created from this section, which also caused the removal of the reference to XML Schema 🫶
  • Modified the text in Section 2.1 to place more emphasis on the fact that language tags are not case sensitive 🔥
  • Replaced the example "fr-Latn-CA" in Section 2.1 with "sr-Latn-RS" and "az-Arab-IR" because "fr-Latn-CA" doesn't respect the 'Suppress-Script' on 'Latn' with 'fr' 💀
  • Changed the requirements for well-formedness to make singleton repetition checking optional (it is required for validity checking) in Section 2.2.9 👑
  • Changed the text in Section 2.2.9 referring to grandfathered checking to note that the list is now included in the ABNF ⭐
  • Modified and added text to Section 3.2. The job description was placed first. A note was added making clear that the Language Subtag Reviewer may delegate various non-critical duties, including list moderation. Finally, additional text was added to make the appointment process clear and to clarify that decisions and performance of the reviewer are appealable ⚖️
  • Added text to Section 3.5 clarifying that the ietf-languages@iana.org list is operated by whomever the IESG appoints 🦋
  • Added text to Section 3.1.5 clarifying that the first Description in a 'language' record matches the corresponding Reference Name for the language in ISO 639-3 🌈
  • Modified Section 2.2.9 to define classes of conformance related to specific tags (formerly 'well-formed' and 'valid' referred to implementations). Notes were added about the removal of 'extlang' from the ABNF provided in RFC 4646, allowing for well-formedness using this older definition. Reference to RFC 3066 well-formedness was also added 🎀
  • Added text to the end of Section 3.1.2 noting that future versions of this document might add new field types to the registry format and recommending that implementations ignore any unrecognized fields 🌸
  • Added text about what the lack of a 'Suppress-Script' field means in a record to Section 3.1.9 ✨
  • Added text allowing the correction of misspellings and typographic errors to Section 3.1.5 💅
  • Added text to Section 3.1.8 disallowing 'Prefix' field conflicts (such as circular prefix references) 🔁
  • Modified text in Section 3.5 to require the subtag reviewer to announce his/her decision (or extension) following the two-week period. Also clarified that any decision or failure to decide can be appealed 📣
  • Modified text in Section 4.1 to include the (heretofore anecdotal) guiding principle of tag choice, and clarifying the non-use of script subtags in non-written applications 🧠
  • Prohibited multiple use of the same variant in a tag (i.e., de-1901-1901). Previously, this was only a recommendation ("SHOULD") 🚫
  • Removed inappropriate [RFC2119] language from the illustration in Section 4.4.1 🧹
  • Replaced the example of deprecating "zh-guoyu" with "zh-hakka"->"hak" in Section 4.5, noting that it was this document that caused the change 🔄
  • Replaced the section in Section 4.1 dealing with "mul"/"und" to include the subtags 'zxx' and 'mis', as well as the tag "i-default". A normative reference to RFC 2277 was added 🌟
  • Added text to Section 3.5 clarifying that any modifications of a registration request must be sent to the <ietf-languages@iana.org> list before submission to IANA 📬
  • Changed the ABNF for the record-jar format from using the LWSP production to use a folding whitespace production similar to obs-FWS in [RFC5234]. This effectively prevents unintentional blank lines inside a field 🙌
  • Clarified and revised text in Sections 3.3, 3.5, and 5.1 to clarify that the Language Subtag Reviewer sends the complete registration forms to IANA, that IANA extracts the record from the form, and that the forms must also be archived separately from the registry 🗂️
  • Added text to Section 5 requiring IANA to send an announcement to an ietf-languages-announcements list whenever the registry is updated 📢
  • Modification of the registry to use UTF-8 as its character encoding. This also entails additional instructions to IANA and the Language Subtag Reviewer in the registration process 🔤
  • Modified the rules in Section 2.2.4 so that "exceptionally reserved" ISO 3166-1 codes other than 'UK' were included into the registry. In particular, this allows the code 'EU' (European Union) to be used to form language tags or (more commonly) for applications that use the registry for region codes to reference this subtag 🇪🇺
  • Modified the IANA considerations section (Section 5) to remove unnecessary normative [RFC2119] language 🥰

9. References 📚

9.1. Normative References

  • [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004.
  • [ISO3166-1] International Organization for Standardization, "ISO 3166-1:2006. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", November 2006.
  • [ISO639-1] International Organization for Standardization, "ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", July 2002.
  • [ISO639-2] International Organization for Standardization, "ISO 639-2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code", October 1998.
  • [ISO639-3] International Organization for Standardization, "ISO 639-3:2007. Codes for the representation of names of languages - Part 3: Alpha-3 code for comprehensive coverage of languages", February 2007.
  • [ISO639-5] International Organization for Standardization, "ISO 639-5:2008. Codes for the representation of names of languages -- Part 5: Alpha-3 code for language families and groups", May 2008.
  • [ISO646] International Organization for Standardization, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991.
  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
  • [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
  • [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [SpecialCasing] The Unicode Consoritum, "Unicode Character Database, Special Casing Properties", March 2008, <http://unicode.org/Public/UNIDATA/SpecialCasing.txt>.
  • [UAX14] Freitag, A., "Unicode Standard Annex #14: Line Breaking Properties", August 2006, <http://www.unicode.org/reports/tr14/>.
  • [UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999.
  • [Unicode] Unicode Consortium, "The Unicode Consortium. The Unicode Standard, Version 5.0, (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-49081-0)", January 2007.

That's the end of the changes and references, slay 🌈✨

9.2. Informative References ✨

Okay bestie, here are the informative refs, the extra reading that's not required but makes you look super smart 💅🎀

[CLDR]           "The Common Locale Data Repository Project",
                 <http://cldr.unicode.org>.

[RFC1766]        Alvestrand, H., "Tags for the Identification of
                 Languages", RFC 1766, March 1995.

[RFC2028]        Hovey, R. and S. Bradner, "The Organizations
                 Involved in the IETF Standards Process", BCP 11,
                 RFC 2028, October 1996.

[RFC2046]        Freed, N. and N. Borenstein, "Multipurpose Internet
                 Mail Extensions (MIME) Part Two: Media Types",
                 RFC 2046, November 1996.

[RFC2047]        Moore, K., "MIME (Multipurpose Internet Mail
                 Extensions) Part Three: Message Header Extensions
                 for Non-ASCII Text", RFC 2047, November 1996.

[RFC2231]        Freed, N. and K. Moore, "MIME Parameter Value and
                 Encoded Word Extensions:
                 Character Sets, Languages, and Continuations",
                 RFC 2231, November 1997.

[RFC2616]        Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P., and T. Berners-Lee,
                 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
                 June 1999.

[RFC2781]        Hoffman, P. and F. Yergeau, "UTF-16, an encoding of
                 ISO 10646", RFC 2781, February 2000.

[RFC3066]        Alvestrand, H., "Tags for the Identification of
                 Languages", RFC 3066, January 2001.

[RFC3282]        Alvestrand, H., "Content Language Headers",
                 RFC 3282, May 2002.

[RFC3552]        Rescorla, E. and B. Korver, "Guidelines for Writing
                 RFC Text on Security Considerations", BCP 72,
                 RFC 3552, July 2003.

[RFC3629]        Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", STD 63, RFC 3629, November 2003.

[RFC4645]        Ewell, D., "Initial Language Subtag Registry",
                 RFC 4645, September 2006.

[RFC4646]        Phillips, A. and M. Davis, "Tags for Identifying
                 Languages", BCP 47, RFC 4646, September 2006.

[RFC5645]        Ewell, D., Ed., "Update to the Language Subtag
                 Registry", September 2009.

[UTS35]          Davis, M., "Unicode Technical Standard #35: Locale
                 Data Markup Language (LDML)", December 2007,
                 <http://www.unicode.org/reports/tr35/>.

[iso639.prin]    ISO 639 Joint Advisory Committee, "ISO 639 Joint
                 Advisory Committee:  Working principles for ISO 639
                 maintenance", March 2000, <http://www.loc.gov/
                 standards/iso639-2/iso639jac_n3r.html>.

[record-jar]     Raymond, E., "The Art of Unix Programming", 2003,
                 <urn:isbn:0-13-142901-9>.

Appendix A. Examples of Language Tags (Informative) 🦋

Here's the tag buffet! 🍓 Every example is copied exactly from the original, so you can use them as the cutest little cheat sheet 🧚

Simple language subtag:

   de (German)

   fr (French)

   ja (Japanese)

   i-enochian (example of a grandfathered tag)

Language subtag plus Script subtag:

   zh-Hant (Chinese written using the Traditional Chinese script)

   zh-Hans (Chinese written using the Simplified Chinese script)

   sr-Cyrl (Serbian written using the Cyrillic script)

   sr-Latn (Serbian written using the Latin script)

Extended language subtags and their primary language subtag
counterparts:

   zh-cmn-Hans-CN (Chinese, Mandarin, Simplified script, as used in
   China)

   cmn-Hans-CN (Mandarin Chinese, Simplified script, as used in
   China)

   zh-yue-HK (Chinese, Cantonese, as used in Hong Kong SAR)

   yue-HK (Cantonese Chinese, as used in Hong Kong SAR)

Language-Script-Region:

   zh-Hans-CN (Chinese written using the Simplified script as used in
   mainland China)

   sr-Latn-RS (Serbian written using the Latin script as used in
   Serbia)

Language-Variant:

   sl-rozaj (Resian dialect of Slovenian)

   sl-rozaj-biske (San Giorgio dialect of Resian dialect of
   Slovenian)

   sl-nedis (Nadiza dialect of Slovenian)

Language-Region-Variant:

   de-CH-1901 (German as used in Switzerland using the 1901 variant
   [orthography])

   sl-IT-nedis (Slovenian as used in Italy, Nadiza dialect)

Language-Script-Region-Variant:

   hy-Latn-IT-arevela (Eastern Armenian written in Latin script, as
   used in Italy)

Language-Region:

   de-DE (German for Germany)

   en-US (English as used in the United States)

   es-419 (Spanish appropriate for the Latin America and Caribbean
   region using the UN region code)

Private use subtags:

   de-CH-x-phonebk

   az-Arab-x-AZE-derbend

Private use registry values:

   x-whatever (private use using the singleton 'x')

   qaa-Qaaa-QM-x-southern (all private tags)

   de-Qaaa (German, with a private script)

   sr-Latn-QM (Serbian, Latin script, private region)

   sr-Qaaa-RS (Serbian, private script, for Serbia)

Tags that use extensions (examples ONLY -- extensions MUST be defined
by revision or update to this document, or by RFC):

   en-US-u-islamcal

   zh-CN-a-myext-x-private

   en-a-myext-b-another

Some Invalid Tags:

   de-419-DE (two region tags)

   a-DE (use of a single-character subtag in primary position; note
   that there are a few grandfathered tags that start with "i-" that
   are valid)

   ar-a-aaa-b-bbb-a-ccc (two extensions with same single-letter
   prefix)

Appendix B. Examples of Registration Forms 🌈

Now for the paperwork that makes the registry go brrr 📋✨ These are the sample forms exactly as written:

LANGUAGE SUBTAG REGISTRATION FORM

1. Name of requester: Han Steenwijk
2. E-mail address of requester: han.steenwijk @ unipd.it
3. Record Requested:

Type:        variant
Subtag:      biske
Description: The San Giorgio dialect of Resian
Description: The Bila dialect of Resian
Prefix:      sl-rozaj
Comments:    The dialect of San Giorgio/Bila is one of the
   four major local dialects of Resian

4. Intended meaning of the subtag:

The local variety of Resian as spoken in San Giorgio/Bila

5. Reference to published description of the language (book or
article):

 -- Jan I.N. Baudouin de Courtenay - Opyt fonetiki rez'janskich
govorov, Varsava - Peterburg: Vende - Kozancikov, 1875.

LANGUAGE SUBTAG REGISTRATION FORM

1. Name of requester: Jaska Zedlik
2. E-mail address of requester: jz53 @ zedlik.com
3. Record Requested:

Type:   variant
Subtag: tarask
Description: Belarusian in Taraskievica orthography
Prefix: be
Comments: The subtag represents Branislau Taraskievic's Belarusian
  orthography as published in "Bielaruski klasycny pravapis" by
  Juras Buslakou, Vincuk Viacorka, Zmicier Sanko, and Zmicier Sauka
  (Vilnia-Miensk 2005).

4. Intended meaning of the subtag:

The subtag is intended to represent the Belarusian orthography as
published in "Bielaruski klasycny pravapis" by Juras Buslakou, Vincuk
Viacorka, Zmicier Sanko, and Zmicier Sauka (Vilnia-Miensk 2005).

5. Reference to published description of the language (book or
article):

Taraskievic, Branislau. Bielaruskaja gramatyka dla skol. Vilnia: Vyd.
"Bielaruskaha kamitetu", 1929, 5th edition.

Buslakou, Juras; Viacorka, Vincuk; Sanko, Zmicier; Sauka, Zmicier.
Bielaruski klasycny pravapis. Vilnia-Miensk, 2005.

6. Any other relevant information:

Belarusian in Taraskievica orthography became widely used, especially
in Belarusian-speaking Internet segment, but besides this some books
and newspapers are also printed using this orthography of Belarusian.

Appendix C. Acknowledgements 🫶

Any list of contributors is bound to be incomplete, so think of this as a highlight reel of the people who made this doc what it is today 💖

The folks behind RFC 4646, RFC 4647, RFC 3066, and RFC 1766 are the OGs. Their huge contributions, direct or indirect, made this document possible and are generally why language tags work at all 😭🙌

Here are the people who contributed to this document: Stephane Bortzmeyer, Karen Broome, Peter Constable, John Cowan, Martin Duerst, Frank Ellerman, Doug Ewell, Deborah Garside, Marion Gunn, Alfred Hoenes, Kent Karlsson, Chris Newman, Randy Presuhn, Stephen Silver, Shawn Steele, and many, many others 🌸

Very special thanks must go to Harald Tveit Alvestrand, who originated RFCs 1766 and 3066, and without whom this document would not have been possible 👑

Special thanks go to Michael Everson, who served as the Language Tag Reviewer for almost the entire RFC 1766/RFC 3066 period, as well as the Language Subtag Reviewer since the adoption of RFC 4646 🔥

Special thanks also go to Doug Ewell, for his production of the first complete subtag registry, his work to support and maintain new registrations, and his careful editorship of both RFC 4645 and [RFC5645] 💜

Authors' Addresses ✨

Here's who to reach out to 💌

Addison Phillips (editor)
Lab126

EMail: addison@inter-locale.com
URI:   http://www.inter-locale.com


Mark Davis (editor)
Google

EMail: markdavis@google.com
📦 where this page comes from