RFC 4645

Initial Language Subtag Registry

📅 published September 2006, from ietf

Initial Language Subtag Registry 🎀

okay bestie, this is RFC 4645 💅 It was written by D. Ewell, Ed., who is a Consultant, and it came out in September 2006. It's an Informational doc from the Network Working Group, so it's giving "here's some info" and not "here's a new rule." Its header doesn't list anything it obsoletes or updates, so it's just vibing on its own ✨

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2006).

Abstract 🧚

okay so this memo defined the starting contents of the IANA Language Subtag Registry, the list you use to build tags that identify languages 🌈 But since it was only meant as a kickoff for the registry, the actual contents were pulled before publication so nobody gets confused 🙈

Table of Contents 💜

1. Introduction ....................................................2
2. Initialization of the Registry ..................................2
3. Initial Registry Contents .......................................5
4. Omitted Code Elements ...........................................5
5. Security Considerations .........................................5
6. IANA Considerations .............................................5
7. References ......................................................6
   7.1. Normative References .......................................6
   7.2. Informative References .....................................6

1. Introduction 💖

okay so [RFC4646] is the one that sets up the Language Subtag Registry and explains how it's formatted 🫶 This memo is where the initial contents get defined, and it uses the criteria in Section 2 to do it. literally the main character move 👑

The registry is written in a modified record-jar text format, as described in [record-jar]. The specific format, plus what each field is for, is explained in [RFC4646] too, so you don't have to guess 🦋

The registry is going to change over time 🌸 new subtags get registered, and existing ones get modified or deprecated. The update process lives in Section 3 of [RFC4646]. This memo is NOT defining the permanent contents, and it's not supposed to be presented as if it is 🙈

Lots of the subtags here are based on code elements from [ISO639-1], [ISO639-2], [ISO15924], [ISO3166-1], and [UN_M.49]. But this registry is not a mirror of those code lists, and it's not meant to be used as one 💅

2. Initialization of the Registry 🎀

Section 3.7 of [RFC4646] says the LTRU working group has to make a first version of the Language Subtag Registry and fill it with the starting set of subtags 🌷 That means converting the entries from the existing IANA language tag registry defined by [RFC3066] into the new format, and also defining valid subtags from various source standards. This section walks through the process they used to make the first registry entries ✨

The starting set of records was based on [ISO639-1], [ISO639-2], [ISO15924], and [ISO3166-1]. These criteria were used to pick and format the subtags in the initial Language Subtag Registry (called "ILSR" from here on) 🦋

  1. For each source standard, the date of the standard referenced in [RFC1766] was picked as the starting date. Code elements that were valid on that date in the chosen standard were added to the ILSR. Code elements that had been assigned before but were vacated or withdrawn before that date were NOT added to the ILSR 💀
  2. For each later change to the standard, any extra assignments up to the date [RFC4646] was adopted were added to the ILSR. Withdrawn values got marked as deprecated, but they weren't removed 🫶 The meaning or assignment of a subtag was allowed to change during this process. For example, the [ISO3166-1] code element 'CS' was first assigned to Czechoslovakia, and now it's assigned to Serbia and Montenegro 🌈

Code elements from [UN_M.49] were also added to the ILSR using the criteria above, plus these extra rules 🎀

  1. UN numeric code elements assigned to "macro-geographical (continental)" regions as of the date [RFC4646] was adopted were added to the ILSR, which made them valid for use in language tags 👑
  2. The UN numeric code elements for "economic groupings" or "other groupings," and the alphanumeric code elements in Appendix X of the UN document, were NOT added to the ILSR 🙈
  3. UN numeric code elements for countries or areas that don't have an assigned [ISO3166-1] alpha-2 code element were NOT added to the ILSR. These values are listed in Section 4, and individuals can ask to register them using the process defined in [RFC4646] and the rules in there. Being listed in this section doesn't guarantee they'll get registered later 💅
  4. Code elements that were withdrawn, vacated, or deprecated from [UN_M.49] as of the date [RFC4646] was adopted were NOT added to the ILSR 💀

Next, the tags in the [RFC3066] registry got checked like this 🔍

  1. Tags in the [RFC3066] registry that weren't deprecated, were made up entirely of subtags already in this document, and had the correct form and format for tags defined by [RFC4646] got converted into records of type "redundant" in the ILSR ✨ For example, "zh-Hant" is now defined by [RFC4646] because zh is an [ISO639-1] code element and Hant is an [ISO15924] code element, and both are defined as subtags in the ILSR 🧚
  2. Tags in the [RFC3066] registry that had one or more subtags that either didn't match the valid registration pattern or weren't otherwise defined by [RFC4646] got converted into records of type "grandfathered" in the ILSR 🌸 These records can't become type "redundant" unless [RFC4646] gets revised. They might get a "Deprecated" and "Preferred-Value" field added if a later subtag assignment (or a mix of assignments) makes the tag obsolete 🫶
  3. Tags in the [RFC3066] registry that were marked as deprecated got converted into records of type "grandfathered" in the ILSR 🦋 The grandfathered record has a "Deprecated" field with the most appropriate date that can be figured out for when the [RFC3066] record got deprecated. The "Comments" field may optionally hold a reason for the deprecation. The "Preferred-Value" field holds the tag that replaces it. For example, the [RFC3066] tag art-lojban is deprecated, so it shows up as a grandfathered tag in the ILSR 💜 Its "Deprecated" field holds the deprecation date (in this case 2003-09-02), and its "Preferred-Value" field holds jbo 🎀
  4. The remaining tags in the [RFC3066] registry aren't deprecated and have a format that matches language tags as defined by [RFC4646], but they contain subtags that aren't defined in the ILSR 🌈 These subtags are eligible for registration as variants. The ILSR has proper variant records for the list of subtags below, and the registered [RFC3066] tags that contain these subtags were entered into the ILSR as type "redundant" 💖
1901 (use with Prefix: de)

1996 (use with Prefix: de)

nedis (use with Prefix: sl)

rozaj (use with Prefix: sl)
  1. All remaining [RFC3066] registered tags were converted into records of type "grandfathered" in the ILSR 🫶 Interested folks can use the registration process in [RFC4646] to try registering the variant subtags that aren't already in the Language Subtag Registry. If every subtag in the original tag becomes fully defined by those registrations, then the original tag is superseded, and its record changes from type "grandfathered" to type "redundant" in the registry 🦋 Just know that a tag being approved under [RFC3066] doesn't guarantee a variant subtag gets approved under [RFC4646] 💀 The existing [RFC3066] tag keeps its validity, but the original reason it got registered might be obsolete now 🙈
🎀 that's part 1 of 2! Section 3 and everything after it are coming up next 🦋✨

7.2. Informative References 📚✨

okay so these are the bonus reads, bestie. they're not required to get the vibe, but they're the receipts 💅 Here's the whole list, every detail intact:

  • [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:1988. Codes for the representation of names of countries, 3rd edition", August 1988. 🌍
  • [ISO639-1] International Organization for Standardization, "ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", 2002. 🗣️
  • [ISO639-2] International Organization for Standardization, "ISO 639-2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code, first edition", 1998. 🗣️
  • [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. 🌸
  • [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. 🌸
  • [UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", UN Standard Country or Area Codes for Statistical Use, Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999. 🇺🇳
  • [record-jar] Raymond, E., "The Art of Unix Programming", 2003. 🐧

Author's Address 🎀

Doug Ewell (Editor) 💜 Consultant 💼

EMail: dewell@adelphia.net 💌 URI: http://users.adelphia.net/~dewell 🔗

Copyright (C) The Internet Society (2006). 🦋

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🔐

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

Intellectual Property 🧚

okay so the IETF is not picking a side here 🫶 It takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, or on whether any license under those rights might be available. It also doesn't claim it has done any independent digging to find such rights. If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79. 📖

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🗂️

The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💌

Acknowledgement 🌈

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 👑✨

📦 where this page comes from