Submitting ISO 639-3 Change Requests

• Kinds of changes
• Submitting a Change Request proposal
• Overview of the proposal review process

Types of changes

Language code maintenance activities of the LCA include:

1. Modify the reference information for an existing code element or identifier
2. Deprecate (retire) a code element from use
3. Create a new code element for a previously unidentified language

Submitting a Change Request proposal

To propose a Change Request for ISO639-3, submit a statement document to the Registrar of the Language Coding Agency for ISO639-3 outlining the purpose of the change, elaborating how the proposal meets the criteria listed for the type of change, and listing sources of documentation in support of the change. When preparing the proposal, notify the Registrar using thisGoogle form, which will initiate tracking of the request. The Registrar will contact the email address supplied in the form to offer assistance in the process such as additional tips or information to include, feedback on a draft proposal, or progress updates. Note: for requests that include a Create (Create or Split) make a separate document supplying as much of the relevant information as possible, including citations, listedhere.

Types of Changes defined in the 639:2023 ISO standard

1. Modify reference information for an existing code element  Note: the 3-letter identifier of the language code element shall never be modified!

   1. Modify a Language Reference Name (for exceptionally compelling reasons)

   2. Modify Additional Name (add, change or delete names in English or French)

   3. Change non-normative information such as language Type

2. Deprecate (Retire) - an existing language code element from use, including possible merging of its scope of denotation into that of another code element, for one of the following reasons:

   1. Non-existent - no evidence of language

   2. Duplicate - code denotation same as [zxx]

   3. Merge into [zxx] code element, expanding its denotation, and deprecate [und] as dialect
   4. Split [zxx] into two or more languages (may combine Deprecate & Create--request a new code element for each Create)

3. Create a new Language Code Element - requested language must meet the full language and individual language criteria

   1. Full Language requirement for language coding

      1. Used in a broad range of domains

      2. Supports communication across all social segments of the language community including all genders and age groups

      3. Stable enough to have at least one variety that is widely understood across its whole geographic area over the time span of more than one generation

      4. The language is changing gradually as each new generation of speakers makes it their own

   2. Eligibility for coding as an individual language - the distinction between a language and a language variety/dialect follows these guidelines:

      1. Two related language varieties are considered to belong to the same individual language if speakers of each variety have inherent understanding of the other variety at a functional level (i.e. they can understand each other based on knowledge of their own language variety without needing to  learn the other language variety). Where such mutual intelligibility does not exist, the two varieties are generally seen to belong to different individual languages.

      2. Where spoken intelligibility between language varieties is marginal, the existence of a common literature or of a common ethnolinguistic identity with a central language variety that both speaker communities understand is a strong indicator that they should nevertheless be considered language varieties of the same language.

      3. Where there is enough intelligibility between language varieties to enable communication, they can nevertheless be treated as different individual languages when they have long-standing, distinctly named ethnolinguistic identities coupled with established linguistic normalization and literatures that are distinct.

   3. Types of languages

      1. Living, including sign languages

      2. Extinct or Historical 6.2.2

         1. Need attested literature or

         2. Well documented use by a language community

      3. Constructed languages - must qualify as a full language (3a); also

         1. Grammar covers all areas of language structure

         2. Lexicon complete (several thousand items)

         3. Substantial and growing text corpus

         4. Owned by a vigorous user community

         5. Confirmed in reliable, neutral sources

Overview of the proposal review process

A request to change the code set goes through a multi-step process:

1. A user of ISO 639-3 proposes a change and submits the CR Form to the ISO 639-3 Language Coding Agency (ISO 639-3/LCA).
2. The ISO 639-3 Registrar receives the Change Request proposal (and New Code Proposals, if needed), verifies that the request is compatible with the criteria set forth in the standard, and ensures that the submitter has supplied all necessary information. This may involve rounds of interaction with the submitter.
3. When the Change Request is complete in its documentation, the Change Request is publicly registered by the LCA as "Pending". The MA publishes the CR in its quarterly newsletter, collects comments during a 90-day period, conducts a vote by its members, and publishes it. Results of CR decisions are implemented by the LCA for the language identifier set(s) affected.
4. Three months prior to the end of the annual cycle of review and updating, a new notice is posted on the official web site of the ISO 639-3/RA, and an announcement listing the Candidate Status Change Requests is posted to the LINGUIST discussion list and any other lists as requested by their owners. All Change Requests are then open to further review and comment by any interested party for a period of three months. A Change Request received after the start of the Candidate phase reviews must wait until the next annual cycle for consideration. The purpose of this phase is to ensure that a minimum of three months is allotted for the review of every proposal.
5. At the end of the formal review period, a given Change Request may be:
   1. adopted as a whole,
   2. adopted in part (specific changes implicit in the whole Change Request may be adopted separately),
   3. amended and resubmitted for the next review cycle, or
   4. withdrawn from consideration.