RFC 5646 | Теги для идентификации языков

Аннотация

Этот документ описывает структуру, содержание, конструкцию и семантику языковых тегов для использования в тех случаях, когда желательно указать язык, используемый в информационном объекте. Также описывается, как зарегистрировать значения для использования в языковых тегах и создания пользовательских расширений для частного обмена.

 

Оглавление

1. Введение
2. Языковой тег
2.1. Синтаксис
2.1.1. Форматирование языковых тегов
2.2. Язык подтегов — Источники и Интерпретация
2.2.1. Основной язык подтегов
2.2.2. Расширенные языковые подтэги
2.2.3. Сценарий подтега
2.2.4. Регион подтега
2.2.5. Варианты подтегов
2.2.6. Расширение подтегов
2.2.7. Подтеги частного использования
2.2.8. Выжитые и избыточные регистрации
2.2.9. Классы соответствия
3. Формат реестра и обслуживание
3.1. Формат реестра языковых вложенных тегов IANA
3.1.1. Формат файла
3.1.2. Запись и определения полей
3.1.3. Поле Type
3.1.4. Поля Subtag и Tag
3.1.5. Поле Description
3.1.6. Поле Deprecated
3.1.7. Поле Preferred-Value
3.1.8. Поле Prefix
3.1.9. Поле Suppress-Script
3.1.10. Поле Macrolanguage
3.1.11. Поле Scope
3.1.12. Поле Comments
3.2. Обозреватель языка подтегов
3.3. Ведение реестра
3.4. Стабильность записей реестра IANA
3.5. Процедура регистрации подтегов
3.6. Возможности для регистрации
3.7. Расширения и реестр расширений
3.8. Обновление реестра подтегов языка
3.9. Применимость реестра подтегов
4. Формирование и обработка языковых тегов
4.1. Выбор языкового тега
4.1.1. Пометка включенных языков
4.1.2. Использование расширенных языковых подтегов
4.2. Значение языкового тега
4.3. Списки языков
4.4. Соображения длины
4.4.1. Работа с ограниченными размерами буфера
4.4.2. Усечение языковых тегов
4.5. Канонизация языковых тегов
4.6. Соображения для частного использования подтегов
5. Соображения IANA
5.1. Реестр языковых подтегов
5.2. Реестр расширений
6. Вопросы безопасности
7. Особенности набора символов
8. Отличия от RFC 4646
9. Ссылки
9.1. Нормативные ссылки
9.2. Информационные ссылки
Приложение А. Примеры языковых тегов (информативный)
Приложение B. Примеры регистрационных форм
Приложение C. Благодарности
Адрес автора

 

Статус этой заметки

В этом документе описываются передовые практики Интернета для интернет-сообщества и запрашиваются обсуждения и предложения по улучшению. Распространение этой заметки не ограничено.

 

Уведомление об авторских правах

Copyright (c) 2009 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

Настоящий документ регулируется BCP 78 и правовыми положениями IETF Trust, касающимися документов IETF, действующих на дату публикации этого документа (http://trustee.ietf.org/license-info). Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа.

Этот документ может содержать материалы из Документов IETF или Вкладов IETF, опубликованных или обнародованных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из этих материалов, возможно, не предоставили Трасту IETF право разрешать модификации таких материалов. вне процесса стандартизации IETF. Без получения адекватной лицензии от лица (лиц), контролирующих авторские права на такие материалы, этот документ не может быть изменен вне процесса стандартизации IETF, и его производные работы не могут быть созданы вне процесса стандартизации IETF, за исключением того, что он отформатирован для публикация в качестве RFC или перевод на другие языки, кроме английского.

 

1. Введение

Люди на нашей планете в прошлом и настоящем использовали несколько языков. Есть много причин, по которым хотелось бы определить язык, используемый при представлении или запросе информации.

Язык информационного элемента или языковые предпочтения пользователя часто необходимо идентифицировать, чтобы можно было применить соответствующую обработку. Например, языковые предпочтения пользователя в веб-браузере можно использовать для правильного выбора веб-страниц. Информация о языке также может использоваться для выбора среди инструментов (таких как словари), чтобы помочь в обработке или понимании контента на разных языках. Знание конкретного языка, используемого для некоторой части информационного контента, может быть полезным или даже необходимым для некоторых типов обработки, например, для проверки орфографии, речи с компьютерным синтезом, транскрипции Брайля или высококачественной печати.

Одним из способов указания используемого языка является маркировка информационного содержимого идентификатором или «тегом». Эти теги также можно использовать для указания пользовательских предпочтений при выборе информационного контента или для маркировки дополнительных атрибутов контента и связанных ресурсов.

Иногда языковые теги используются для обозначения дополнительных языковых атрибутов контента. Например, указание конкретной информации о диалекте, системе письма или орфографии, используемых в документе или ресурсе, может позволить пользователю получить информацию в понятной им форме, или это может быть важно при обработке или преобразовании данного контента в соответствующая форма или стиль.

Этот документ определяет конкретный механизм идентификатора (языковой тег) и функцию регистрации для значений, которые будут использоваться для формирования тегов. Он также определяет механизм для значений частного использования и будущих расширений.

Этот документ заменяет [RFC4646] (который устарел [RFC3066], который, в свою очередь, заменил [RFC1766]). Этот документ, в сочетании с [RFC4647], включает в себя BCP 47. Список изменений в этом документе см. В разделе 8.

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

 

2. Языковой тег

Языковые теги используются для определения языков, на которых говорят, пишут, подписывают или иным образом сигнализируют, для целей общения. Это включает в себя искусственные и искусственные языки, но исключает языки, не предназначенные в первую очередь для человеческого общения, такие как языки программирования.

 

2.1. Синтаксис

Языковой тег состоит из последовательности из одного или нескольких «вложенных тегов», каждый из которых уточняет или сужает диапазон языка, идентифицируемый общим тегом. Вложенные теги, в свою очередь, представляют собой последовательность буквенно-цифровых символов (букв и цифр), которые выделяются и отделяются от других вложенных тегов в теге дефисом («-«, [Unicode] U + 002D).

Существуют различные типы вложенных тегов, каждый из которых отличается по длине, положению в теге и содержанию: тип каждого вложенного тега может быть распознан только этими функциями. Это позволяет извлекать и назначать некоторую семантическую информацию для вложенных тегов, даже если конкретные значения вложенных тегов не распознаются. Таким образом, процессору языковых тегов не требуется иметь список допустимых тегов или вложенных тегов (то есть копии какой-либо версии реестра языковых вложенных тегов IANA) для выполнения общих операций поиска и сопоставления. Единственными исключениями из этой способности выводить значение из структуры подтэга являются обнаруженные теги, перечисленные в «регулярных» и «нерегулярных» производствах ниже. Эти теги были зарегистрированы в [RFC3066] и представляют собой фиксированный список, который никогда не может измениться.

Синтаксис языкового тега в ABNF [RFC5234]:

Language-Tag = langtag ; обычные языковые теги
/ privateuse ; теги частного использования
/ grandfathered ; теги дедушки

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

language = 2*3ALPHA ; кратчайший код ISO 639
[«-» extlang] ; иногда следуют расширенные языковые подтэги
/ 4ALPHA ; или зарезервировано для будущего использования
/ 5*8ALPHA ; или зарегистрированный языковой подтег

extlang = 3ALPHA ; выбранные коды ISO 639
*2(«-» 3ALPHA) ; навсегда защищены

script = 4ALPHA ; Код ISO 15924

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

variant = 5*8alphanum ; зарегистрированные варианты
/ (DIGIT 3alphanum)

extension = singleton 1*(«-» (2*8alphanum))

singleton = DIGIT ; 0 — 9
/ %x41-57 ; A — W
/ %x59-5A ; Y — Z
/ %x61-77 ; a — w
/ %x79-7A ; y — z

Отдельные буквенно-цифровые символы «x» зарезервированы для частного использования

privateuse = «x» 1*(«-» (1*8alphanum))

grandfathered = irregular ; зарегистрированные избыточные теги
/ regular ; в эпоху RFC 3066

irregular = «en-GB-oed» ; неправильные метки не совпадают
/ «i-ami» ; «langtag» производства и
/ «i-bnn» ; иначе не было бы
/ «i-default» ; считается «хорошо-сформированным»
/ «i-enochian» ; Эти теги действительны,
/ «i-hak» ; но большинство устарели
/ «i-klingon» ; в пользу более современного
/ «i-lux» ; подтегов или подтега
/ «i-mingo» ; сочетание

/ «i-navajo»
/ «i-pwn»
/ «i-tao»
/ «i-tay»
/ «i-tsu»
/ «sgn-BE-FR»
/ «sgn-BE-NL»
/ «sgn-CH-DE»

regular = «art-lojban» ; эти теги соответствуют продукции langtag, но их вложенные теги не являются расширенными языковыми или вариантными вложенными тегами: их значение определяется их регистрацией, и все они не рекомендуются в пользу более современного вложенного тега или последовательности вложенных тегов
/ «cel-gaulish» ;
/ «no-bok» ;
/ «no-nyn» ;
/ «zh-guoyu» ;
/ «zh-hakka» ;
/ «zh-min» ;
/ «zh-min-nan» ;
/ «zh-xiang»

alphanum = (ALPHA / DIGIT) ; буквы и цифры

Примеры языковых тегов см. В приложении А.

Все вложенные теги имеют максимальную длину восемь символов. Пробелы не допускаются в языковом теге. В производственном варианте ABNF есть тонкость: вариант, начинающийся с цифры, имеет длину не менее четырех символов, а вариант, начинающийся с буквы, имеет длину не менее пяти символов.

Хотя [RFC5234] относится к октетам, языковые теги, описанные в этом документе, представляют собой последовательности символов из репертуара US-ASCII [ISO646]. Языковые теги МОГУТ использоваться в документах и приложениях, использующих другие кодировки, если они охватывают соответствующую часть репертуара US-ASCII. Примером этого может служить XML-документ, который использует кодировку UTF-16LE [RFC2781] для [Unicode].

 

2.1.1. Форматирование языковых тегов

В любом случае языковые теги и их вложенные теги, в том числе частное использование и расширения, должны рассматриваться как нечувствительные к регистру: существуют соглашения об использовании заглавных букв некоторых вложенных тегов, но они НЕ ДОЛЖНЫ восприниматься как несущие значение.

Таким образом, тег «mn-Cyrl-MN» не отличается от «MN-cYRL-mn» или «mNcYrL-Mn» (или любой другой комбинации), и каждая из этих вариаций передает то же значение: монгольский, написанный на кириллице сценарий, используемый в Монголии.

Синтаксис ABNF также не делает различий между прописными и строчными буквами: прописные буквы US-ASCII в диапазоне от «A» до «Z» всегда считаются эквивалентными и отображаются непосредственно в их строчные эквиваленты USASCII в диапазоне от «a» до «z». ». Таким образом, тег «I-AMI» считается эквивалентным этому значению «i-ami» в «нерегулярном» производстве.

Хотя различия в регистре не несут смысла в языковых тегах, пользователям поможет последовательное форматирование и представление языковых тегов. Формат subtags в реестре РЕКОМЕНДУЕТСЯ как форма для использования в языковых тегах. Этот формат обычно соответствует общим соглашениям для различных стандартов ИСО, из которых получены подтэги.

Эти соглашения включают в себя:

• [ISO639-1] рекомендует, чтобы языковые коды были написаны строчными буквами («mn» на монгольском языке).
• [ISO15924] рекомендует использовать в кодах сценариев строчные буквы с заглавной начальной буквой (кириллица Cyrl).
• [ISO3166-1] рекомендует использовать заглавные коды стран («MN», Монголия).

Реализация может воспроизвести этот формат без доступа к реестру следующим образом. Все вложенные теги, включая вложенные теги расширений и частного использования, используют строчные буквы с двумя исключениями: двухбуквенные и четырехбуквенные вложенные теги, которые не появляются ни в начале тега, ни после одиночных символов. Такие двухбуквенные вложенные теги имеют заглавные буквы (как в тегах «en-CA-x-ca» или «sgn-BE-FR»), а вложенные теги из четырех букв являются заглавными буквами (как в теге «az-Latn-x-latn»).

Примечание: сворачивание регистров букв ASCII в определенных локалях, если их не обрабатывать аккуратно, иногда приводит к значениям символов, отличных от ASCII. Файл базы данных символов Unicode «SpecialCasing.txt» [SpecialCasing] определяет конкретные случаи, которые, как известно, вызывают проблемы с этим. В частности, буква ’i’ (U + 0069) на турецком и азербайджанском языках указывается заглавной буквой U + 0130 (ПИСЬМО ЛАТИНСКОГО КАПИТАЛА I С ТОЧКОЙ ВЫШЕ). Реализаторам СЛЕДУЕТ указать операцию с регистром, не зависящую от локали, чтобы гарантировать, что сворачивание в регистр подтегей не приводит к этому значению, что недопустимо в языковых тегах. Например, если в верхнем регистре подтег ‘in’ прописать, используя турецкие правила локали, получится последовательность U + 0130 U + 004E вместо ожидаемого IN ‘.

 

2.2. Язык подтегов — Источники и Интерпретация

Пространство имен языковых тегов и их вложенных тегов администрируется Управлением по присвоению номеров в Интернете (IANA) в соответствии с правилами, приведенными в разделе 5 настоящего документа. Реестр языковых подтэгов, поддерживаемый IANA, является источником действительных подтагов: другие стандарты, упомянутые в этом разделе, предоставляют исходный материал для этого реестра.

Терминология, используемая в этом документе:

• o «Метка» относится к полной языковой метке, такой как «sr-Latn-RS» или «az-Arab-IR». Примеры тегов в этом документе заключены в двойные кавычки («en-US»).
• o «Subtag» относится к определенному разделу тега, разделенному дефисом, таким как subtags ’zh’, ’Hant’ и ’CN’ в теге «zh-Hant-CN». Примеры вложенных тегов в этом документе заключены в одинарные кавычки («Hant»).
• o «Код» относится к значениям, определенным во внешних стандартах (и которые используются в этом документе как подтеги). Например, «Hant» — это код сценария [ISO15924], который использовался для определения вложенного тега «Hant» для использования в теге языка. Примеры кодов в этом документе заключены в одинарные кавычки («en», «Hant»).

Языковые теги разработаны таким образом, чтобы каждый тип подтега имел уникальную длину и ограничения по содержанию. Это позволяет идентифицировать тип подтэга, даже если его содержимое не распознается. Это позволяет анализировать и обрабатывать теги без ссылки на последнюю версию базовых стандартов или реестра IANA и упрощает обработку связанных исключений при синтаксическом анализе тегов.

Некоторые из вложенных тегов в реестре IANA не являются базовым стандартом. Они могут появляться только в определенных позициях в теге: они могут встречаться только как субтаги основного языка или как альтернативные субтаги.

Последовательности вложенных тегов частного использования и расширения ДОЛЖНЫ иметь место в конце последовательности вложенных тегов и НЕ ДОЛЖНЫ перемежаться с вложенными тегами, определенными в другом месте этого документа. Эти последовательности представлены односимвольными подтэгами, которые зарезервированы следующим образом:

• Однострочный вложенный тег ’x’ представляет последовательность вложенных тегов частного использования. Интерпретация любого частного тега использования определяется исключительно частным соглашением и не определяется правилами в этом разделе или в любом стандарте или реестре, определенных в этом документе.
• Однобуквенный подтег «’ »используется некоторыми тегами-дедушками, такими как« i-default », где он всегда отображается в первой позиции и его нельзя спутать с расширением.
• Все другие однозначные и однозначные вложенные теги зарезервированы для введения стандартизированных последовательностей расширенных вложенных тегов, как описано в разделе 3.7.

 

2.2.1. Основной язык подтегов

Основной языковой вложенный тег является первым вложенным тегом в языковом теге и не может быть пропущен, за исключением двух:

• Односимвольный вложенный тег ’x’ в качестве основного вложенного тега указывает, что языковой тег состоит исключительно из вложенных тегов, значение которых определяется частным соглашением. Например, в теге «x-fr-CH» подтэги «fr» и «CH» не представляют французский язык или страну Швейцарии (или любое другое значение в реестре IANA), если нет частного соглашения на месте, чтобы сделать это. Смотрите раздел 4.6.
• Односимвольный subtag ’i’ используется некоторыми метками-дедушками (см. раздел 2.2.8), такими как «i-klingon» и «i-bnn». (У других унаследованных тегов есть основной языковой тег в своей первой позиции.)

Следующие правила применяются к основной языковой подтэг:

1. Двухсимвольные субтеги основного языка были определены в реестре IANA в соответствии с присвоениями, указанными в стандарте «ISO 639-1: 2002, Коды для представления названий языков. Часть 1. Код альфа-2» [ISO639 -1] или с использованием присвоений, впоследствии сделанных органом регистрации ISO (39) или руководящими органами по стандартизации.

2. Трехсимвольные субтеги основного языка в реестре IANA были определены в соответствии с присвоениями, найденными в одной из этих дополнительных частей или назначений ISO 639, которые впоследствии были сделаны соответствующими органами по регистрации ISO 639 или руководящими органами по стандартизации:

A. «ISO 639-2: 1998 — Коды для представления названий языков. Часть 2. Код Alpha-3 — издание 1» [ISO639-2]
B. «ISO 639-3: 2007 — Коды для представления названий языков. Часть 3. Код Alpha-3 для всестороннего охвата языков» [ISO639-3]
C. «ISO 639-5: 2008 — Коды для представления названий языков. Часть 5. Код Alpha-3 для языковых семей и групп» [ISO639-5]

3. Вложенные теги в диапазоне от «qaa» до «qtz» зарезервированы для частного использования в языковых тегах. Эти подтэги соответствуют кодам, зарезервированным ISO 639-2 для частного использования. Эти коды МОГУТ использоваться для незарегистрированных вложенных тегов основного языка (вместо использования вложенных тегов частного использования после «x-»). Пожалуйста, обратитесь к Разделу 4.6 для получения дополнительной информации о subtags частного использования.

4. Четырехзначные языковые подтэги зарезервированы для возможной будущей стандартизации.

5. Любые языковые подтэги длиной от пяти до восьми символов в реестре IANA были определены в процессе регистрации в разделе 3.5 и МОГУТ использоваться для формирования основного языкового подтэга.

Примером того, что может включать такая регистрация, является созданная IANA регистрация i-enochian. Подтег «енохианский» может быть зарегистрирован в реестре IANA в качестве основного языкового подтега (при условии, что ISO 639 сначала не регистрирует этот язык), что делает допустимыми такие теги, как «enochian-AQ» и «enochian-Latn».
На момент создания этого документа не было примеров подобного рода тегов. Будущие регистрации этого типа не приветствуются: попытка регистрации любого нового предложенного основного языка ДОЛЖНА быть сделана в орган регистрации ISO 639. Предложения, отклоненные регистрирующим органом ISO 639, вряд ли будут соответствовать критериям для субтегов основного языка и, следовательно, вряд ли будут зарегистрированы.

6. Другие значения НЕ ДОЛЖНЫ присваиваться первичному подтэгу, за исключением случаев пересмотра или обновления этого документа.

 

Если языки имеют как двухсимвольный код ISO 639-1, так и трехсимвольный код (назначенный ISO 639-2, ISO 639-3 или ISO 639-5), только двухсимвольный код ISO 639-1 определяется в реестр IANA.

Если в языке нет двухсимвольного кода ISO 639-1, а код ISO 639-2 / T (терминология) и код ISO 639-2 / B (библиографический) для этого языка различаются, в термине определяется только код терминологии. Реестр IANA. На момент создания этого документа всем языкам, имеющим оба вида трехсимвольных кодов, также был присвоен двухсимвольный код; Ожидается, что в будущем назначения такого рода не произойдет.

Во избежание нестабильности в канонической форме тегов, если в ISO 639-1 добавлен двухсимвольный код для языка, для которого трехсимвольный код уже был включен в ISO 639-2 или ISO 639-3, двухсимвольный код НЕ ДОЛЖЕН быть зарегистрирован. Смотрите Раздел 3.4.

Например, если какой-либо контент был помечен как «haw» (гавайский), который в настоящее время не имеет двухсимвольного кода, тег не нужно будет менять, если ISO 639-1 назначит двухсимвольный код гавайскому языку. впоследствии.

Чтобы избежать этих проблем с версионированием и выбором подтэгов (как это произошло во время перехода между RFC 1766 и RFC 3066), а также для обеспечения канонического характера подтегей, определенных в этом документе, Объединенный консультативный комитет органа регистрации ISO 639 (ISO 639 / RA-JAC) включил следующее заявление в [iso639.prin]:

«Код языка, уже введенный в ISO 639-2 на момент замораживания ISO 639-1, не должен быть впоследствии добавлен в ISO 639-1. Это делается для обеспечения согласованности в использовании во времени, поскольку пользователи в интернет-приложениях должны использовать код альфа-3, когда код альфа-2 для этого языка недоступен. «

 

2.2.2. Расширенные языковые подтэги

Расширенные языковые подтэги используются для идентификации определенных специально выбранных языков, которые по различным историческим причинам и причинам совместимости тесно идентифицируются или помечаются с использованием существующего основного языкового подтэга. Расширенные языковые вложенные теги всегда используются с включенным вложенным основным языковым вложенным тегом (указывается в поле «Префикс» в реестре), когда они используются для формирования языкового тега. Все языки с расширенным языковым подтэгом в реестре также имеют идентичные записи основного языкового подтэга в реестре. Этот основной языковой подтаг РЕКОМЕНДУЕТСЯ для формирования языкового тега. Следующие правила применяются к расширенным языковым подтэгам:

1. Расширенные языковые вложенные теги состоят исключительно из трехбуквенных вложенных тегов. Все записи расширенного языкового подтэга, определенные в реестре, были определены в соответствии с назначениями, найденными в [ISO639-3]. Языковые коллекции и группы, такие как определенные в [ISO639-5], специально исключены из расширенных языковых вложенных тегов.
2. Записи подтэга расширенного языка ДОЛЖНЫ включать ровно одно поле «Префикс», указывающее соответствующий подтэг или последовательность подтэгов для этого подтэга расширенного языка.
3. Записи расширенного языкового подтэга ДОЛЖНЫ включать «Preferred-Value». Поля «Preferred-Value» и «Subtag» ДОЛЖНЫ быть идентичны.
4. Хотя «extlang» производства ABNF допускает использование до трех расширенных языковых тегов в языковом теге, расширенные языковые вложенные теги НЕ ДОЛЖНЫ включать другой расширенный языковой вложенный тег в свой префикс. То есть позиции второго и третьего расширенных языковых вложенных тегов в языковом теге зарезервированы на постоянной основе, а теги, которые включают в себя эти вложенные теги в этой позиции, являются и всегда будут недействительными.

Например, макроязыковой китайский (’zh’) охватывает несколько языков. По причинам совместимости каждый из этих языков имеет как основной, так и расширенный языковой вложенный тег в реестре. Несколько избранных примеров из них включают китайский ган (’gan’), кантонский китайский (’yue’) и мандаринский (’cmn’). Каждый из них включает макроязык ‘zh’ (китайский). Поэтому каждый из них имеет префикс «zh» в своих записях реестра. Таким образом, китайский ган представлен тегами, начинающимися с «zh-gan» или «gan», кантонский с тегами, начинающимися либо с «yue», либо «zh-yue», а китайский с мандаринским языком с «zh-cmn» или «cmn». Языковой вложенный тег ‘zh’ все еще можно использовать без расширенного языкового вложенного тега, чтобы пометить ресурс как какое-то неопределенное разнообразие китайского языка, в то время как основной языковой вложенный тег (‘gan’, ‘yue’, ‘cmn’) предпочтительнее использования расширенного языка. языковая форма («zh-gan», «zh-yue», «zh-cmn»).

 

2.2.3. Сценарий подтега

Подтеги скрипта используются для указания вариантов скрипта или системы письма, которые различают письменные формы языка или его диалектов. Следующие правила применяются к вложенным тегам сценария:

1. Подтеги сценария ДОЛЖНЫ следовать за любыми основными и расширенными языковыми подтегами и ДОЛЖНЫ предшествовать любому другому типу вложенных тегов.

2. Подтеги сценариев состоят из четырех букв и были определены в соответствии с присвоениями, найденными в [ISO15924] («Информация и документация. Коды для представления имен сценариев»), или впоследствии присвоены органом регистрации ISO 15924 или регулирующей стандартизацией. тела. Только коды, присвоенные ISO 15924, будут рассматриваться для регистрации.

3. Подтеги сценариев от «Qaaa» до «Qabx» зарезервированы для частного использования в языковых тегах. Эти подтэги соответствуют кодам, зарезервированным ISO 15924 для частного использования. Эти коды МОГУТ использоваться для незарегистрированных значений сценариев. Пожалуйста, обратитесь к Разделу 4.6 для получения дополнительной информации о subtags частного использования.

4. НЕОБХОДИМО, чтобы в языковом теге было не более одного вложенного тега сценария, и этот вложенный тег сценария СЛЕДУЕТ пропускать, если он не добавляет отличительного значения тегу или когда запись основного или расширенного языкового вложенного тега в реестре вложенного тега включает в себя «Suppress-Script». ‘со списком применимых сценариев.

Например: «sr-Latn» представляет сербский язык, написанный с использованием латинского алфавита.

 

2.2.4. Регион подтега

Подтеги региона используются для обозначения языковых вариаций, связанных или соответствующих конкретной стране, территории или региону. Как правило, региональный подтег используется для обозначения изменений, таких как региональные диалекты или использование, или региональные соглашения по правописанию. Он также может использоваться для указания того, что контент выражен таким образом, который подходит для использования во всем регионе, например, испанский контент, специально предназначенный для использования во всей Латинской Америке.

Следующие правила применяются к подтегам региона:

1. Вложенные теги регионов ДОЛЖНЫ следовать за любым вложенным тегами основного языка, расширенного языка или сценария и ДОЛЖНЫ предшествовать любому другому типу вложенных тегов.

2. Двухбуквенные субтеги регионов были определены в соответствии с присвоениями, найденными в [ISO3166-1] («Коды для представления названий стран и их подразделений — Часть 1: Коды стран»), используя список альфа-2 коды стран или использование присвоений, впоследствии сделанных агентством по техническому обслуживанию ISO 3166-1 или руководящими органами по стандартизации. Кроме того, коды, которые являются «исключительно зарезервированными» (в отличие от «назначенных») в ISO 3166-1, также были определены в реестре, за исключением «UK», который является точным синонимом для назначенного кода «GB».

3. Региональные подтэги «AA», «QM» — «QZ», «XA» — «XZ» и «ZZ» зарезервированы для частного использования в языковых тегах. Эти подтэги соответствуют кодам, зарезервированным ISO 3166 для частного использования. Эти коды МОГУТ использоваться для подтегей области частного использования (вместо использования последовательности подтегей частного использования). Пожалуйста, обратитесь к Разделу 4.6 для получения дополнительной информации о subtags частного использования.

4. Трехэлементные субтеги региона состоят исключительно из цифр (чисел) и были определены в соответствии с присвоениями, указанными в стандартных кодах ООН или кодах стран для статистического использования [UN_M.49], или присвоениями, которые впоследствии были сделаны руководящим органом по стандартизации. Не все коды UN M.49 определены в реестре IANA. Следующие правила определяют, какие коды вводятся в реестр как допустимые подтэги:

A. Цифровые коды ООН, присвоенные «макрогеографическим (континентальным)» или субрегионам, ДОЛЖНЫ быть зарегистрированы в реестре. Эти коды не связаны с присвоенным кодом ISO 3166-1 alpha-2 и представляют наднациональные области, обычно охватывающие более одной нации, штата, провинции или территории.

B. Цифровые коды ООН для «экономических группировок» или «других групп» НЕ ДОЛЖНЫ быть зарегистрированы в реестре IANA и НЕ ДОЛЖНЫ использоваться для формирования языковых тегов.

C. Когда ИСО 3166-1 переназначает код, ранее использовавшийся для одной страны или региона, в другую страну или район, и этот код уже присутствует в реестре, цифровой код ООН для этой страны или района ДОЛЖЕН быть зарегистрирован в реестре, как описано в Раздел 3.4 и ДОЛЖЕН использоваться для формирования языковых тегов, которые представляют страну или регион, для которых он определен (а не переработанный код ISO 3166-1).

D. Цифровые коды ООН для стран или регионов, для которых в реестре имеется соответствующий код альфа-2 ИСО 3166-1, НЕ ДОЛЖНЫ вводиться в реестр и НЕ ДОЛЖНЫ использоваться для формирования языковых тегов. Обратите внимание, что подтег на основе ISO 3166 в реестре ДОЛЖЕН быть связан с соответствующим кодом ООН M.49.

E. По историческим причинам цифровой код ООН 830 (Нормандские острова), который не был зарегистрирован на момент принятия этого документа и в то время не имевший соответствующего кода ISO 3166-1, МОЖЕТ быть внесен в реестр IANA через процесс, описанный в разделе 3.5, при условии отсутствия кода ISO 3166-1 с таким точным значением, был ранее зарегистрирован.

F. Все другие числовые коды ООН для стран или регионов, которые не имеют ассоциированного кода ISO 3166-1 alpha-2, НЕ ДОЛЖНЫ быть введены в реестр и НЕ ДОЛЖНЫ использоваться для формирования языковых тегов. Для получения дополнительной информации об этих кодах см. Раздел 3.4.

5. Буквенно-цифровые коды в Приложении X к документу ООН НЕ ДОЛЖНЫ быть введены в реестр и НЕ ДОЛЖНЫ использоваться для формирования языковых тегов. (На момент создания этого документа эти значения соответствовали кодам ISO 3166-1 alpha-2.)

6. НЕОБХОДИМО, чтобы в языковом теге было не более одного регионального тега, и этот региональный тег МОЖЕТ быть опущен, например, когда он не добавляет отличительного значения к тегу.

Например:

«de-AT» обозначает немецкий («de»), используемый в Австрии («АТ»).
«sr-Latn-RS» представляет сербский язык («sr»), написанный на латинском языке («Latn»), как в Сербии («RS»).
«es-419» обозначает испанский («es»), соответствующий определенному ООН региону Латинской Америки и Карибского бассейна («419»).

 

2.2.5. Вариант подтега

Вариантные вложенные теги используются для указания дополнительных, общепризнанных вариантов, которые определяют язык или его диалекты, которые не охватываются другими доступными вложенными тегами. Следующие правила применяются к вариантным вложенным тегам:

1. Вариантные подтэги ДОЛЖНЫ следовать за любыми субтагами основного языка, расширенного языка, сценария или региона и ДОЛЖНЫ предшествовать любым последовательностям субтага расширения или частного использования.

2. Варианты subtags, как коллекция, не связаны с каким-либо конкретным внешним стандартом. Значение вариантных вложенных тегов в реестре определяется в ходе процесса регистрации, определенного в разделе 3.5. Обратите внимание, что любой конкретный вариант subtag может быть связан с некоторым внешним стандартом. Однако ассоциация со стандартом не требуется для регистрации.

3. Для формирования языкового тега МОЖЕТ использоваться более одного варианта.

4. Варианты вложенных тегов ДОЛЖНЫ быть зарегистрированы в IANA в соответствии с правилами, приведенными в разделе 3.5 настоящего документа, прежде чем они будут использоваться для формирования языковых тегов. Чтобы отличать варианты от других типов вложенных тегов, регистрация ДОЛЖНА соответствовать следующим ограничениям длины и содержания:

• Варианты вложенных тегов, начинающиеся с буквы (a-z, A-Z), ДОЛЖНЫ быть длиной не менее пяти символов.
• Варианты вложенных тегов, начинающиеся с цифры (0-9), ДОЛЖНЫ иметь длину не менее четырех символов.

5. Один и тот же вариант subtag НЕ ДОЛЖЕН использоваться более одного раза внутри языкового тега.

* Например, тег «de-DE-1901-1901» недопустим.

Записи о вариантах вложенных тегов в Реестре языковых вложенных тегов МОГУТ включать одно или несколько полей «Префикс» (раздел 3.1.8). Каждый «Префикс» указывает подходящую последовательность вложенных тегов для формирования (с другими вложенными тегами, в зависимости от случая) языкового тега при использовании варианта.

Большинство вариантов, имеющих общий префикс, являются взаимоисключающими. Например, немецкие орфографические вариации «1996» и «1901» НЕ ДОЛЖНЫ использоваться в одном и том же теге, поскольку они представляют даты различных реформ правописания. Вариант, который может быть разумно использован в сочетании с другим вариантом, ДОЛЖЕН включать поле «Префикс» в своей записи реестра, в котором перечислены другие варианты. Например, если был создан другой немецкий вариант ’example’, который имеет смысл использовать с ’1996’, то ’example’ должен включать два поля «prefix»: «de» и «de-1996».

Например:

«sl-nedis» представляет диалект словенского языка натисон или надиза.

«de-CH-1996» представляет немецкий язык в том виде, в каком он используется в Швейцарии, и в том виде, как он написан с использованием реформы правописания, начавшейся в 1996 году C.E.

 

2.2.6. Расширение подтегов

Расширения предоставляют механизм для расширения языковых тегов для использования в различных приложениях. Они предназначены для идентификации информации, которая обычно используется в связи с языками или языковыми тегами, но не является частью языковой идентификации. Смотрите Раздел 3.7. Следующие правила применяются к расширениям:

1. Расширение ДОЛЖНО следовать по крайней мере за основным языком. То есть языковой тег не может начинаться с расширения. Расширения расширяют языковые теги, они не переопределяют и не заменяют их. Например, «a-value» не является правильно сформированным языковым тегом, в то время как «de-a-value» — это. Обратите внимание, что расширения не могут использоваться в тегах, которые являются полностью частными (т. е. Теги, начинающиеся с «x-»).

2. Расширяемые вложенные теги отделяются от других вложенных тегов, определенных в этом документе, однозначным вложенным тегом (называемым «singleton — синглтоном»). Синглтон ДОЛЖЕН быть тем, который назначен органу регистрации через механизм, описанный в разделе 3.7, и НЕ ДОЛЖЕН быть буквой ‘x’, которая зарезервирована для последовательностей подтегов частного использования.

3. Каждый одноэлементный вложенный тег ДОЛЖЕН появляться не более одного раза в каждом теге (кроме как в качестве вложенного тега личного пользования). То есть одноэлементные подтэги НЕ ДОЛЖНЫ повторяться. Например, тег «en-a-bbb-a-ccc» недопустим, потому что подтег ’a’ появляется дважды. Обратите внимание, что тег «en-a-bbb-x-a-ccc» действителен, поскольку второе появление синглтона ’a’ находится в частной последовательности использования.

4. Расширяемые вложенные теги ДОЛЖНЫ соответствовать любым требованиям, установленным в документе, который определяет их одноэлементный префикс, и любым требованиям, предъявляемым обслуживающим органом. Обратите внимание, что может отсутствовать реестр этих вложенных тегов, и для проверки расширений не требуются проверяющие процессоры.

5. Каждый дополнительный подтэг ДОЛЖЕН иметь длину от двух до восьми символов и состоять исключительно из букв или цифр, при этом каждый вложенный тег отделяется одним ‘-‘. Различия в регистре игнорируются в расширениях (как с любым языковым подтэгом), а нормализованные подтэги этого типа должны быть в нижнем регистре.

6. За каждым синглтоном ДОЛЖЕН следовать хотя бы один дополнительный тег. Например, тег «tlh-a-b-foo» недопустим, потому что за первым синглтоном ’a’ сразу же следует другой синглтон ’b’.

7. Расширяемые вложенные теги ДОЛЖНЫ следовать за всеми вложенными тегами основного языка, расширенного языка, сценария, региона и варианта в теге и ДОЛЖНЫ предшествовать любым частным вложенным последовательностям вложенного тега.

8. Все подтэги, следующие за синглтоном и перед другим синглтоном, являются частью расширения. Пример: в теге «fr-a-Latn» вложенный тег «Latn» не представляет вложенный тег сценария «Latn», определенный в реестре языковых вложенных тегов IANA. Его значение определяется расширением «а».

9. В случае, когда в одном теге появляется более одного расширения, тег СЛЕДУЕТ канонизировать, как описано в разделе 4.5, упорядочив различные последовательности расширений в порядке ASCII без учета регистра.

Например, если расширение было определено для синглтона ‘r’, и оно определило показанные подтэги, то следующий тег был бы допустимым примером: «en-Latn-GB-boont-r-extended-sequence-x-private».

 

2.2.7. Подтеги частного использования

Подтеги частного использования используются для обозначения различий в языке, которые важны в данном контексте по частному соглашению. Следующие правила применяются к частным тегам использования:

1. Вложенные теги частного использования отделяются от других вложенных тегов, определенных в этом документе, зарезервированным однозначным вложенным тегом ’x’.

2. Частичные теги использования ДОЛЖНЫ соответствовать формату и ограничениям содержания, определенным в ABNF для всех вложенных тегов; то есть они ДОЛЖНЫ состоять только из букв и цифр и не превышать восемь символов в длину.

3. Вложенные теги частного использования ДОЛЖНЫ следовать за всеми вложенными тегами основного языка, расширенного языка, сценария, региона, варианта и расширения в теге. Еще один способ сказать, что все вложенные теги, следующие за синглтоном ‘x’, ДОЛЖНЫ рассматриваться как личное использование. Пример: вложенный тег «US» в теге «en-x-US» является вложенным тегом частного использования.

4. Тег МОЖЕТ состоять исключительно из личных тегов.

5. Не определен источник для частных тегов использования. Использование субтагов частного использования только по частному соглашению.

6. Подтеги частного использования НЕ РЕКОМЕНДУЕТСЯ, если существуют альтернативы или для общего обмена. См. Раздел 4.6 для получения дополнительной информации о выборе частного тега.

Например, предположим, что группа ученых изучает некоторые тексты на средневековом греческом. Они могут согласиться использовать некоторую коллекцию вложенных тегов частного использования для определения различных стилей письма в текстах. Например, они могут использовать «el-x-koine» для документов в «обычном» стиле, а «el-x-attic» — для других документов, имитирующих стиль чердака. Эти подтэги не будут распознаваться внешними процессами или системами, но могут быть полезны при классификации различных текстов для изучения участниками группы.

В реестре есть также подтэги, полученные из кодов, зарезервированных ISO 639, ISO 15924 или ISO 3166 для частного использования. Не путайте их с последовательностями вложенных тегов частного использования, следующими за вложенным тегом x. Смотрите раздел 4.6.

 

2.2.8. Выжитые и избыточные регистрации

До RFC 4646 целые языковые теги были зарегистрированы в соответствии с правилами в RFC 1766 и / или RFC 3066. Все эти зарегистрированные теги остаются действительными как языковые теги.

Многие из этих зарегистрированных тегов стали излишними с появлением либо RFC 4646, либо этого документа. Избыточный тег — это устаревшая регистрация, отдельные субтеги которой имеют одинаковое семантическое значение в реестре. Например, тег «zh-Hant» (традиционный китайский) теперь может состоять из подтегей «zh» (китайский) и «Hant» (традиционный вариант сценария хань). Эти избыточные теги хранятся в реестре как записи типа «избыточные», в основном из исторического любопытства.

Оставшаяся часть ранее зарегистрированных тегов является «grandfathered — дедушкой». Эти теги делятся на две группы: «regular — обычные» и «irregular — нерегулярные».

Найденные теги, которые (по-видимому, соответствуют) «лангтагу» на рисунке 1, считаются «обычными» найденными тегами. Эти теги содержат один или несколько вложенных тегов, которые либо отдельно не отображаются в реестре, либо имеют другое семантическое значение: каждый тег в целом представляет язык или набор языков.

Найденные теги, которые не совпадают с продукцией langtag в ABNF и в противном случае были бы недействительными, считаются «неправильными» найденными тегами. За исключением «en-GB-oed», который является вариантом «en-GB», каждый из них в целом представляет язык.

Многие устаревшие теги были заменены последующим добавлением новых вложенных тегов: каждая замененная запись содержит поле «Preferred-Value», которое следует использовать для формирования языковых тегов, представляющих это значение. Например, тег «art-lojban» заменяется основным языком subtag ’jbo’.

 

2.2.9. Классы соответствия

Реализации иногда должны описывать свои возможности в отношении правил и практик, описанных в этом документе. Теги можно проверять или проверять несколькими способами, но формально определены два конкретных класса соответствия тегов.

Метка считается «правильно сформированной», если она соответствует ABNF (раздел 2.1). Языковые теги могут быть правильно сформированы с точки зрения синтаксиса, но не действительны с точки зрения содержания. Тем не менее, многие операции с использованием языковых тегов работают хорошо, ничего не зная о значении или валидности вложенных тегов.

Тег считается «действительным», если он удовлетворяет следующим условиям:

• Тег хорошо сформирован.
• Либо тег находится в списке обнаруженных тегов, либо все его основные языки, расширенный язык, сценарий, регион и вариантные подтеги появляются в Реестре подзаголовков языка IANA на конкретную дату реестра.
• Нет повторяющихся вариантов подтегей.
• Нет дублирующих одноэлементных (расширенных) подтегей.

Обратите внимание, что срок действия тега зависит от даты регистрации, используемой для проверки тега. Более поздняя копия реестра может содержать подтэг, которого нет в старой версии.

Тег считается действительным для данного расширения (раздел 3.7) (по состоянию на конкретную версию, редакцию и дату), если он соответствует критериям для «действительный» выше, а также удовлетворяет этому условию:

Каждый вложенный тег, используемый в расширенной части тега, действителен в соответствии с расширением.

Более старые спецификации или реализации языковых тегов иногда ссылаются на [RFC3066]. В рамках этого документа было сочтено, что более широкий набор тегов хорошо сформирован. Любые теги, которые были допустимы для использования в соответствии с RFC 3066, являются правильно сформированными и действительными в соответствии с синтаксисом этого документа; только недействительные или недопустимые теги были правильно сформированы согласно более раннему определению, но больше не являются таковыми. Синтаксис языкового тега в RFC 3066 был:

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

Вложенные теги, предназначенные для частного использования, а также последовательности частного использования, введенные вложенным тегом «x», доступны для случаев, когда нет доступных назначенных вложенных тегов, и регистрация не является подходящим вариантом. Например, можно использовать тег, такой как «no-QQ», где «QQ» — это один из диапазона кодов ISO 3166-1 для частного использования, чтобы указать иным образом неопределенную область. Пользователи НЕ ДОЛЖНЫ назначать языковые теги, использующие вложенные теги, которые не отображаются в реестре, кроме как в частном порядке использования (например, вложенный тег «personal» в теге «en-xpersonal»). Помимо того, что он недействителен, пользователь также рискует столкнуться с возможным будущим назначением или регистрацией.

Обратите внимание: хотя продукция «Language-Tag», представленная в этом документе, функционально эквивалентна той, что описана в [RFC4646], она была изменена, чтобы предотвратить определенные ошибки в правильном формировании, возникающие в результате старой «унаследованной» продукции.

 

3. Формат реестра и обслуживание

Реестр языковых вложенных тегов IANA («реестр») содержит полный список всех вложенных тегов, допустимых в языковых тегах. Это позволяет разработчикам простой и надежный способ проверки языковых тегов. Реестр будет поддерживаться таким образом, чтобы, кроме расширенных вложенных тегов, можно было проверить все вложенные теги, которые присутствуют в языковом теге в соответствии с положениями этого документа или его редакциями или преемниками. Кроме того, значение различных вложенных тегов будет однозначным и стабильным во времени. (Значение subtags частного использования, конечно, не определяется реестром.)

В этом разделе определяется реестр, а также процедуры обслуживания и обновления, связанные с ним, а также реестр расширений языковых тегов (раздел 3.7).

 

3.1. Формат реестра языковых вложенных тегов IANA

Реестр языковых подтэгов IANA — это машиночитаемый файл в формате, описанном в этом разделе, плюс копии регистрационных форм, утвержденных в соответствии с процедурой, описанной в разделе 3.5.

Существующие регистрационные формы для устаревших и избыточных тегов, взятых из RFC 3066, были сохранены как часть устаревшего реестра RFC 3066. Вложенные теги, добавленные в реестр [RFC4645] или [RFC5645], не имеют отдельных регистрационных форм (поэтому формы для этих дополнений не архивируются).

 

3.1.1. Формат файла

Реестр представляет собой текстовый файл [Unicode] и состоит из серии записей в формате, основанном на «record-jar» (описано в [record-jar]). Каждая запись, в свою очередь, состоит из ряда полей, которые описывают различные вложенные теги и теги. Фактический файл реестра кодируется с использованием кодировки символов UTF-8 [RFC3629].
Каждое поле можно рассматривать как одну логическую строку символов. Каждое поле содержит «имя-поля» и «тело-поля». Они разделены «полем-разделителем».

азделитель полей — это символ COLON (U+003A) плюс любой окружающий пробел. Каждое поле оканчивается последовательностью новой строки CRLF. Текст в каждом поле ДОЛЖЕН быть в форме нормализации Unicode C (NFC).

Коллекция полей образует «запись». Записи разделены строками, содержащими только последовательность «%%» (U+0025 U+0025).

Хотя поля логически представляют собой одну строку текста, каждая строка текста в формате файла имеет длину не более 72 байтов. Чтобы приспособить это, тело поля может быть разделено на многострочное представление; это называется «складывание». Складывание выполняется в соответствии с обычными соглашениями для переноса строк. Обычно это происходит на границах пробелов, но может происходить между другими символами, когда значение не содержит пробелов, например, когда язык не использует пробелы между словами. В любом случае НЕ ДОЛЖНЫ быть разрывы внутри многобайтовой последовательности UTF-8 или в середине последовательности символов объединения. Для получения дополнительной информации см. [UAX14].

Хотя формат файла использует набор символов Unicode, а сам файл кодируется с использованием кодировки UTF-8, поля ограничиваются печатными символами из репертуара US-ASCII [ISO646], если иное не указано в описании конкретного поля (Раздел 3.1.2).

Формат реестра описывается следующим ABNF [RFC5234]. Номера символов (кодовые точки) взяты из Unicode, а терминалы в продуктах ABNF представлены в виде символов, а не байтов.(Формат реестра ABNF)

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

Последовательность ’..’ (U+002E U+002E) в теле поля обозначает диапазон значений. Такой диапазон представляет все вложенные теги одинаковой длины, которые находятся в алфавитном или числовом порядке в пределах этого диапазона, включая значения, явно упомянутые. Например, «a..c» обозначает значения «a», «b» и «c», а «11 ..13» обозначает значения «11», «12» и «13».

Все поля, тело которых содержит значение даты, используют формат «full-date — полная дата», указанный в [RFC3339]. Например, «2004-06-28» представляет 28 июня 2004 года в григорианском календаре.

 

3.1.2. Запись и определения полей

В реестре есть три типа записей: «File-Date», «Subtag» и «Tag».
Первой записью в реестре всегда является запись «File-Date». Эта запись встречается в файле только один раз и содержит одно поле, имя-поля которого равно «Дата-файла». Тело поля этой записи содержит дату (см. Раздел 5.1), что позволяет легко распознавать различные версии реестра.

Пример записи File-Date:

File-Date: 2004-06-28
%%

Последующие записи содержат несколько полей и представляют информацию о вложенных тегах или тегах. Оба типа записей имеют одинаковую структуру, за исключением того, что записи «Subtag» содержат поле с именем поля «Subtag», тогда как неудивительно, что записи «Tag» содержат поле с именем поля «Tag». Имена полей НЕ ДОЛЖНЫ встречаться более одного раза в каждой записи, за исключением полей «Description — Описание», «Comments — Комментарии» и «Prefix — Префикс».

Каждая запись ДОЛЖНА содержать хотя бы одно из следующих полей:

o ’Type’

* Тело поля ’Type’ ДОЛЖНО состоять из одной из следующих строк:

«language», «extlang», «script», «region», «variant», «grandfathered», и «redundant»; оно обозначает тип тега или подтега.

o «Subtag» или «Tag»

* Тело поля Subtag содержит определяемый подтег. Это поле ДОЛЖНО появиться во всех записях, у которых ’Type’ имеет одно из следующих значений: «language», «extlang», «script», «region», «variant».

* Поле тега содержит полный языковой тег. Это поле ДОЛЖНО появиться во всех записях, чей ’Type’ имеет одно из следующих значений: «grandfathered» or «redundant» («унаследованный» или «избыточный»). Если ’Type’ «унаследован», то поле ’Tag’ будет одним из тегов, перечисленных в «обычном» или «нерегулярном» производстве, найденном в Разделе 2.1.

o ’Description’

* Тело поля’Description’ содержит ненормативное описание подтега или тега.

o ’Added’

* В теле поля ’Added’ указана дата, когда была зарегистрирована запись, или, в случае устаревших или избыточных тегов, дата, когда соответствующий тег был зарегистрирован в соответствии с правилами [RFC1766] или [RFC3066].

Каждая запись МОЖЕТ также содержать следующие поля:

o ’Deprecated’

* Тело поля ’Deprecated’ содержит дату, когда запись устарела. В некоторых случаях это значение является более ранним, чем значение поля ’Added’ в той же записи. То есть дата устаревания предшествовала добавлению записи в реестр.

o ‘Preferred-Value’

* Тело поля Preferred-Value содержит каноническое отображение значения этой записи на современный эквивалент, который предпочтителен вместо него. В зависимости от значения поля ’Type’ это значение может принимать различные формы:

+ Для полей типа ’language’, ’Preferred-Value’ содержит основной языковой подтег, который предпочтителен при формировании языкового тега.

+ Для полей типа ’script’, ’region’, or ’variant’, ’Preferred-Value’ содержит подтег того же типа, который предпочтителен для формирования языкового тега.

+ Для полей типа «extlang», «grandfarded» или «’redundant’», «Preferencered-Value» содержит «extended language range — расширенный диапазон языков» [RFC4647], который предпочтителен для формирования языкового тега. То есть тег предпочтительного языка будет содержать по порядку каждый из вложенных тегов, которые появляются в «Preferred-Value»; дополнительные поля могут быть включены в языковой тег, как описано в другом месте в этом документе. Например, заменивший тег «zh-minnan» (Min Nan Chinese) заменен на «nan», который можно использовать в качестве основы для таких тегов, как «nan-Hant» или «nan-TW» (обратите внимание, что также может использоваться расширенная языковая форма подтега, такая как «zh-nan-Hant» или «zh-nan-TW»).

o ’Prefix’

* Тело поля ’Prefix’ содержит допустимый языковой тег, который РЕКОМЕНДУЕТСЯ в качестве одного из возможных префиксов к подтегу этой записи. Это поле МОЖЕТ появиться в записях, чье тело поля ’Type’ является ’extlang’ или ’variant’ (оно НЕ ДОЛЖНО появляться в любом другом типе записи).

o ’Suppress-Script’

* Тело поля Suppress-Script содержит вложенный тег сценария, который НЕ ДОЛЖЕН использоваться для формирования языковых тегов со связанным основным или расширенным языковым вложенным тегом. Это поле ДОЛЖНО появиться только в записях, у которых тело поля ‘Type’ является ’language’ или ’extlang’. Смотрите Раздел 4.1.

о ’Macrolanguage’

* Тело поля Macrolanguage содержит основной языковой подтег, определенный в ISO 639 как «macrolanguage», который охватывает этот языковой вложенный тег. Это поле ДОЛЖНО появиться только в записях, у которых в поле тела «Type» указано «language» или «extlang».

о ’Scope’

* Поле тела Scope содержит информацию о основном или расширенном языковом подтеге, указывающем тип языкового кода в соответствии с ISO 639. Значения, разрешенные в этом поле: «macrolanguage», «collection», «special» и «private-use». Это поле появляется только в записях, у которых в поле «Type» используется поле «language» или «extlang». Когда это поле опущено, язык является отдельным языком.

o ’Comments’

* Текст поля комментариев содержит дополнительную информацию о подтеге, которая считается подходящей для понимания реестра и реализации языковых тегов с использованием подтега или тега.

В будущих версиях этого документа могут быть добавлены дополнительные поля в реестр; реализации ДОЛЖНЫ игнорировать поля, найденные в реестре, которые не определены в этом документе.

 

3.1.3. Поле Type

Поле «Type» содержит строку, идентифицирующую тип записи, в которой она появляется. Значения для тела поля «Type»:

• «language» (раздел 2.2.1);
• «extlang» (раздел 2.2.2);
• «script» (раздел 2.2.3);
• «region» (раздел 2.2.4);
• «variant» (раздел 2.2.5);
• «grandfathered» или «redundant» (раздел 2.2.8).

 

3.1.4. Поля Subtag и Tag

Поле «Subtag» содержит подтег, определенный в записи. Поле ’Tag’ появляется в записях, у которых «Тип» является «унаследованным» или «избыточным» и содержит тег, зарегистрированный в [RFC3066].

Тело поля Subtag ДОЛЖНО следовать соглашениям об использовании обсадных колонн, описанным в разделе 2.1.1. Все вложенные теги используют строчные буквы в fieldbody, с двумя исключениями:

• Вложенные теги, чье поле ’Type’ равно ’script’ (другими словами, вложенные теги, определенные в ISO 15924), ДОЛЖНЫ использовать заглавные буквы.
• Вложенные теги, чье поле ’Type’ равно ’region’ (другими словами, вложенные теги нечислового региона, определенные в ISO 3166-1), ДОЛЖНЫ использовать все прописные буквы.

Тело поля ‘Tag’ ДОЛЖНО быть отформатировано в соответствии с правилами, описанными в разделе 2.1.1.

 

3.1.5. Поле Description

Поле «Description» содержит описание тега или вложенного тега в записи. Поле «Описание» МОЖЕТ появляться более одного раза в каждой записи. Поле «Описание» МОЖЕТ содержать полный диапазон символов Юникода. По крайней мере, одно из полей «Описание» ДОЛЖНО быть написано или переписано на латинице; дополнительные поля «Описание» МОГУТ быть написаны любым шрифтом или языком.

Поле «Описание» используется для идентификации. Описания ДОЛЖНЫ содержать всю и только ту информацию, которая необходима для того, чтобы отличить один вложенный тег от других, с которыми его можно спутать. Они не предназначены для предоставления общей справочной информации или для предоставления всех возможных альтернативных названий или обозначений. Поля «Описание» не обязательно представляют фактическое собственное имя элемента в записи, а также не гарантируется, что любое из описаний будет на каком-либо конкретном языке (например, английском или французском).

Описания в реестре, которые соответствуют кодам ISO 639, ISO 15924, ISO 3166-1 или ООН M.49, предназначены только для указания значения этого идентификатора, как это определено в исходном стандарте во время его добавления в реестр или с последующим изменением в рамках правил стабильности (раздел 3.4) путем последующей регистрации. «Описание» не заменяет содержание самого исходного стандарта. Поля «Описание» не должны быть локализованными английскими именами для вложенных тегов. Локализация или перевод описания языковых тегов и вложенных тегов выходит за рамки этого документа.

Для вложенных тегов, взятых из исходного стандарта (такого как ISO 639 или ISO 15924), поля «Описание» в записи также первоначально взяты из этого исходного стандарта. Несколько описаний в исходном стандарте разделены на отдельные поля «Описание». Описания исходного стандарта МОГУТ быть отредактированы или изменены либо до вставки, либо через процесс регистрации, а дополнительные или посторонние описания опущены или удалены. Каждое поле «Описание» ДОЛЖНО быть уникальным в пределах записи, в которой оно появляется, и вариации форматирования одного и того же описания НЕ ДОЛЖНЫ встречаться в этой конкретной записи. Например, хотя код ISO 639-1 «fy» содержит в этом стандарте и описание «западно-фризский», и описание «западно-фризский», в реестре присутствует только одно из этих описаний.

Чтобы пользователи не запутались в том, какой подтег использовать, поля «Описание», назначенные записи любого конкретного типа («язык», «extlang», «сценарий» и т. д.), ДОЛЖНЫ быть уникальными в пределах данного тип записи со следующим исключением: если конкретное поле «Описание» встречается в нескольких записях данного типа, то самое большее одна из записей может опустить поле ’Deprecated’. Все устаревшие записи, которые имеют «Описание», ДОЛЖНЫ иметь одинаковое ’Preferred-Value’, а все недекларированные записи ДОЛЖНЫ иметь это ’Preferred-Value’. Это означает, что две записи одного типа, которые имеют «Описание», также семантически эквивалентны, и для этого значения предпочтительнее не более одной записи с данным «Описанием».

Например, рассмотрим «language» subtags «zza» (Zaza) и «diq» (Dimli). Так получилось, что zza — это макроязык, заключающий в себе diq, и, следовательно, также имеет описание в ISO 639-3 «Dimli». Это описание было отредактировано, чтобы прочитать «Dimli (macrolanguage)» в записи реестра для «zza», чтобы предотвратить столкновение.

В отличие от этого, подтеги «he» и «iw» имеют значение ’Description’ слова «Hebrew»; это разрешено, потому что «iw» устарело, а «Preferred-Value» — «he».

Для полей типа ’language’ первое поле «Описание», появившееся в реестре, соответствует, по возможности, ссылочному имени, присвоенному ISO 639-3. Это помогает упростить перекрестные ссылки между ISO 639 и реестром.

При создании или обновлении записи из-за действия одного из исходных стандартов рецензент языкового субтега МОЖЕТ редактировать описания для исправления ошибок в форматировании (таких как опечатки, неуместные апострофы или другие знаки препинания, чрезмерные или отсутствующие пробелы) перед отправкой предлагаемая запись в список ietf-languages@iana.org для рассмотрения.

 

3.1.6. Поле Deprecated

Поле ’Deprecated’ содержит дату, когда запись устарела и МОЖЕТ быть добавлена, изменена или удалена из любой записи в процессе обслуживания, описанном в разделе 3.3, или в процессе регистрации, описанном в разделе 3.5. Обычно добавление поля «Устаревшие» связано с тем, что один из органов по стандартизации, например, ISO 3166, отозвал код. Хотя они допустимы в языковых тегах, вложенные теги и теги с полем «Устаревшие» не рекомендуются, и проверяющие процессоры НЕ ДОЛЖНЫ создавать эти вложенные теги. Обратите внимание, что запись, которая содержит поле «Устаревшие» и не имеет соответствующего поля «’Preferred-Value’ — Предпочитаемое значение», не имеет сопоставления замены.

В некоторых исторических случаях было невозможно восстановить первоначальную дату амортизации. Для этих случаев приблизительная дата появляется в реестре. Некоторые вложенные теги и некоторые устаревшие или избыточные теги были исключены до первоначального создания реестра. Точные правила для этого приведены в Разделе 2 [RFC4645]. Обратите внимание, что в этих записях есть поле «Устаревшие» с более ранней датой, чем соответствующее поле ’Added’!

 

3.1.7. Поле Preferred-Value

Поле «Preferred-Value» содержит сопоставление между записью, в которой она появляется, и другим тегом или подтэгом (в зависимости от типа записи). Значение в этом поле используется для канонизации (см. Раздел 4.5). В тех случаях, когда подтэг или тег также имеет поле «Устаревшие», то «Предпочтительное значение» РЕКОМЕНДУЕТСЯ как лучший выбор для представления значения этой записи при выборе языкового тега.

Записи, содержащие «Preferred-Value», попадают в одну из следующих четырех групп:

1. Коды языков ISO 639, которые впоследствии были отозваны в пользу других кодов. Эти ценности в основном историческое любопытство. Соединение «he» / «iw» выше является примером этого.

2. Подтеги (с типами, отличными от языка или расширенного языка), взятые из кодов или значений, которые были изъяты в пользу нового кода. В частности, это относится к субтегам региона, взятым из ISO 3166-1, потому что иногда страна меняет свое название или администрацию таким образом, что требуется новый код региона. В некоторых случаях страны вернулись к более старому названию, которое может быть уже закодировано. Например, при изменении названия этой страны подтег «ZR» (Zaire) был заменен подтэгом «CD» (Демократическая Республика Конго).

3. Теги или подтеги, которые устарели из-за того, что значения, которые они представляют, были позже закодированы. Например, многие из устаревших или избыточных тегов были позже закодированы в ISO 639 и попадают в эту группу. Например, «i-klingon» устарел, когда был добавлен subtag ’tlh’. Запись для «i-klingon» имеет «Preferred-Value» из «tlh».

4. Расширенные языковые подтэги всегда имеют сопоставление с их идентичным основным языковым подтегом. Например, расширенный языковой подтег ’yue’ (кантонский диалект) можно использовать для формирования тега «zh-yue». Он имеет отображение «Preferred-Value» на основной языковой подтег «yue», что означает, что такой тег, как «zh-yue-Hant-HK», может быть канонизирован как «yue-Hant-HK».

Записи, отличные от записей типа «extlang», которые содержат поле «Preferred-Value», ДОЛЖНЫ также иметь поле «Устаревшие». В этом поле указана дата, на которую тег или субтег помечен как предпочтительный.

Для записей типа «extlang» поле «Preferred-Value» отображается без соответствующего поля «Deprecated». Реализация МОЖЕТ игнорировать эти предпочтительные отображения значений, хотя, если она игнорирует отображение, она ДОЛЖНА делать это последовательно. Он также ДОЛЖЕН обрабатывать ‘Preferred-Value’ как эквивалент сопоставленного элемента. Например, теги «zh-yue-Hant-HK» и «yue-Hant-HK» семантически эквивалентны и должны обрабатываться так, как если бы они были одним и тем же тегом.

Иногда устаревший код предпочтителен в определенных контекстах. Например, и «iw», и «he» могут использоваться в языке программирования Java, но «he» преобразуется при вводе в «iw», что, таким образом, является канонической формой в Java.

Отображения «Preferred-Value» в записях типа «регион» иногда не представляют точно того же значения, что и исходное значение. Существует множество причин для изменения кода страны, и влияние, которое это оказывает на формирование языковых тегов, будет зависеть от характера рассматриваемого изменения. Например, подтег региона «YD» (Democratic Yemen — Демократический Йемен) был объявлен устаревшим в пользу подтега «YE» (Yemen — Йемен), когда эти две страны объединились в 1990 году.

«Предпочитаемое значение» МОЖЕТ быть добавлено, изменено или удалено из записей в соответствии с правилами в разделе 3.3. Добавление, изменение или удаление поля «Preferred-Value» в записи не означает, что контент, использующий уязвимый подтэг, необходимо повторно пометить.

Поля «Preferred-Value» в записях типа «унаследованный» и «избыточный» содержат «расширенный языковой диапазон» [RFC4647], который настоятельно РЕКОМЕНДУЕТСЯ использовать вместо значения записи. Во многих случаях эти сопоставления создавались путем устаревания тегов в течение периода до принятия [RFC4646]. Например, тег «no-nyn» не рекомендуется в пользу определенного языкового кода ISO 639-1 «nn».

Поле «Preferred-Value» в записях вложенных тегов типа «extlang» также содержит «extended language range — расширенный диапазон языков». Это позволяет не использовать вложенный тег в пользу одного основного языкового вложенного тега или новой последовательности language-extlang.

Обычно добавление, удаление или изменение поля «Preferred-Value» для подтега выполняется для отражения изменений в одном из исходных стандартов. Например, если код региона ISO 3166-1 устарел в пользу другого кода, это ДОЛЖНО привести к добавлению поля «Preferred-Value».

Изменения в одном вложенном теге также могут повлиять на другие вложенные теги: при предложении изменений в реестре рецензент языкового вложенного тега ДОЛЖЕН проверить реестр на наличие таких эффектов и предложить необходимые изменения, используя процесс, описанный в разделе 3.5, хотя любой МОЖЕТ запросить такие изменения. Например:

Предположим, что подтег «XX» имеет «Preferred-Value» из «YY». Если «YY» позже изменится на «Preferred-Value» в «ZZ», то «Preferred-Value» для «XX» ДОЛЖНО также измениться на «ZZ».

Предположим, что зарегистрированный языковой вложенный тег ’dialect’ представляет язык, еще не доступный ни в одной части ISO 639. Последующее добавление соответствующего языкового кода в ISO 639 ДОЛЖНО привести к добавлению «Preferred-Value» для «диалекта».

 

3.1.8. Поле Prefix

Поле «Префикс» содержит допустимый языковой тег, который РЕКОМЕНДУЕТСЯ в качестве одного из возможных префиксов для подтега этой записи, возможно, с другими вложенными тегами. То есть, если включить расширенный язык или вариантный вложенный тег, который имеет хотя бы один «Префикс» в языковом теге, результирующий тег ДОЛЖЕН соответствовать хотя бы одному из полей «Префикс» вложенного тега с использованием алгоритма «Расширенная фильтрация» (см. [RFC4647]), и каждый из вложенных тегов в этом «префиксе» ДОЛЖЕН появляться перед самим вложенным тегом.

Поле «Префикс» ДОЛЖНО появиться ровно один раз в записи типа «extlang». Поле «Префикс» МОЖЕТ появляться несколько раз (или не появляться) в записях типа «вариант». Дополнительные поля этого типа МОГУТ быть добавлены в «вариантную» запись через процесс регистрации, при условии, что «вариантная» запись уже содержит хотя бы одно поле «Префикс».

Каждое поле «Префикс» указывает определенную последовательность вложенных тегов, которые образуют значимый тег с этим вложенным тегом. Например, расширенный языковой подтег «cmn» (Mandarin Chinese — китайский язык) имеет смысл только с его префиксом «zh» (Chinese — китайский). Точно так же «rozaj» (Resian, диалект словенского языка) будет уместным при использовании с префиксом «sl» (словенский), в то время как такие теги, как «is-1994», не подходят (и, вероятно, не имеют смысла). Хотя префиксом для ‘rozaj’ является «sl», между ними могут появляться другие подтэги. Например, тег «sl-IT-rozaj» (словенский, итальянский, Resian) соответствует префиксу «sl».

«Префикс» также указывает, когда варианты вложенных тегов имеют смысл при совместном использовании (многие из них, которые совместно используют «Префикс», являются взаимоисключающими) и каков должен быть относительный порядок вариантов. Например, вариант ‘1994’ (стандартизированная орфография Resian) имеет несколько полей ‘Prefix’ в реестре («sl-rozaj», «sl-rozaj-biske», «sl-rozaj-njiva», «sl-rozaj- осойс «, и» сл-розайсолба «). Это указывает не только на то, что «1994» подходит для использования с каждым из этих пяти подэтагов варианта Resian («rozaj», «biske», «njiva», «osojs» и «solba»), но и на том, что оно ДОЛЖНО появляться после любой из этих вариантов в теге. Таким образом, языковой тег должен иметь форму «sl-rozaj-biske-1994», а не «sl-1994-rozaj-biske» или «sl-rozaj-1994-biske».

Если в записи нет поля «Префикс», поле «Префикс» НЕ ДОЛЖНО быть добавлено в запись позднее. В противном случае изменения (добавления, удаления или модификации) в наборе полей «Префикс» МОГУТ быть зарегистрированы, если они строго расширяют диапазон рекомендуемых языковых тегов. Например, префикс со значением «be-Latn» (белорусский, латинский алфавит) может быть заменен значением «be» (белорусский), но не значением «ru-Latn» (русский, латинский алфавит) или значение «be-Latn-BY» (белорусский, латинский алфавит, Беларусь), поскольку последние изменяют или сужают диапазон предлагаемых тегов.

Поле body поля «Prefix» НЕ ДОЛЖНО конфликтовать с каким-либо «Prefix», уже зарегистрированным для данной записи. Такой конфликт может возникнуть, когда не может быть создан допустимый тег, который будет содержать префикс, например, когда два вложенных тега имеют каждый «Префикс», который содержит другой вложенный тег. Например, предположим, что subtag ’avariant’ имеет префикс «es-bvariant». Тогда подтегу «bvariant» нельзя присвоить префикс «avariant», поскольку для этого потребуется тег вида «es-avariant-bvariant-avariant», который будет недействительным.

 

3.1.9. Поле Suppress-Script

Поле «Suppress-Script» содержит вложенный тег сценария (запись которого отображается в реестре). Поле ‘Suppress-Script’ ДОЛЖНО появиться только в записях, у которых ‘Type’ field-body » language ‘или’ extlang ‘. Это поле НЕ ДОЛЖНО появляться в записи более одного раза.

В этом поле указывается скрипт, используемый для написания подавляющего большинства документов для данного языка. Таким образом, подтэг для такого сценария не добавляет отличительной информации к языковому тегу и поэтому НЕ ДОЛЖЕН использоваться для большинства документов на этом языке. Исключение подтэга сценария, указанного в этом поле, помогает обеспечить большую совместимость между языковыми тегами, сгенерированными в соответствии с правилами в этом документе, и языковыми тегами и обработчиками тегов или потребителями на основе RFC 3066. Например, практически все исландские документы написаны латинским шрифтом делая избыточный тег «Latn» избыточным в теге «is-Latn».

Многие записи языковых вложенных тегов не имеют поля ‘Suppress-Script’. Отсутствие «подавляющего сценария» может указывать на то, что язык обычно пишется более чем одним сценарием или что язык обычно не пишется вообще. Это также может означать, что при создании записи не было достаточной информации, и, таким образом, она остается кандидатом для будущей регистрации.

 

3.1.10. Поле Macrolanguage

Поле «Macrolanguage» содержит основной языковой подтэг (чья запись появляется в реестре). В этом поле указывается язык, который включает язык этого подтэга в соответствии с заданиями, сделанными в соответствии с ISO 639-3.

ISO 639-3 помечает некоторые языки в реестре как «макроязыки». ISO 639-3 определяет термин «макроязык» для обозначения «кластеров тесно связанных языковых разновидностей, которые […] могут рассматриваться как отдельные отдельные языки, но в определенных контекстах использования необходима единая языковая идентичность для всех». Они соответствуют кодам, зарегистрированным в ISO 639-2 в качестве отдельных языков, которые, как было установлено, соответствуют более чем одному языку в ISO 639-3.

Язык, содержащийся в макроязыке, называется «всеобъемлющим языком». Запись для каждого включенного языка содержит поле «Macrolanguage» в реестре; сами макроязыки специально не обозначены. Обратите внимание, что некоторые охватываемые языки имеют коды ISO 639-1 или ISO 639-2.

Поле «Macrolanguage» может встречаться только в записях типа «language» или «extlang». Только значения, присвоенные ISO 639-3, будут рассматриваться для включения. Поля ‘Macrolanguage’ МОГУТ быть добавлены или удалены с помощью обычного процесса регистрации всякий раз, когда ISO 639-3 определяет новые значения или удаляет старые значения. Макроязыки являются информационными, и МОГУТ быть удалены или изменены, если ISO 639-3 меняет значения. Для получения дополнительной информации об использовании этого поля и выборе между макроязыком и включенными языковыми подтэгами см. Раздел 4.1.1.

Например, языковые вложенные теги «nb» (норвежский букмол) и «nn» (норвежский нюнорск) имеют поле «Macrolanguage» со значением «no» (норвежский). Для получения дополнительной информации см. Раздел 4.1.

 

3.1.11. Поле Scope

Поле «Область действия» содержит информацию о классификации основного или расширенного языкового подтега, полученную из ISO 639. Большинство языков имеют область действия «индивидуальный», что означает, что язык не является макроязыком, коллекцией, специальным кодом или частным использованием. То есть это то, что обычно считают «языком». Любой основной или расширенный языковой вложенный тег, не имеющий поля «Область действия», является отдельным языком.

Информация «Scope» иногда может быть полезна при выборе языковых тегов, поскольку она указывает цель или «область» назначения кода в ISO 639. Доступные значения:

• ’macrolanguage’ — указывает макроязык в соответствии с определением ISO 639-3 (см. раздел 3.1.10). Макроязык — это группа тесно связанных языков, которые иногда считаются одним языком.
• ’collection’- указывает на вложенный тег, представляющий коллекцию языков, обычно связанных каким-либо типом исторической, географической или языковой ассоциации. В отличие от макроязыка, коллекция может содержать языки, которые слабо связаны, и коллекцию нельзя использовать взаимозаменяемо с принадлежащими ей языками.
• ‘special‘ — указывает код специального языка. Это подтэги, используемые для идентификации языковых атрибутов, не связанных конкретно с конкретным языком. К ним относятся коды, когда язык не определен или неязыковой контент.
• ’private-use’ — указывает код, зарезервированный для частного использования в базовом стандарте. Субтеги с этой областью могут использоваться для указания основного языка, для которого не существует ISO 639 или зарегистрированного присвоения.

Поле ‘Scope’ МОЖЕТ появляться в записях типа ‘language’ или ‘extlang’. Обратите внимание, что многие префиксы для расширенных языковых вложенных тегов будут иметь «Scope» из «макроязыка» (хотя некоторые не будут), и что многие языки, имеющие «Scope» из «макроязыка», будут иметь расширенные языковые вложенные теги, связанные с ними.

Поле ‘Scope’ МОЖЕТ быть добавлено, изменено или удалено в процессе регистрации при условии, что изменение отражает изменения, внесенные ISO 639 в классификацию присвоения. Такое изменение, как ожидается, будет редким.

Например, основной языковой подтег «zh» (китайский) имеет «Scope» из «макроязыка», в то время как его вложенный язык «Nan» (Min Nan Chinese) имеет «Scope» «индивидуального». Специальное значение «und» (неопределенное) имеет «Scope» из «special». Коллекция ISO 639-5 «gem» (германские языки) имеет «Scope» из «collection».

 

3.1.12. Поле Comments

Поле «Комментарии» содержит дополнительную информацию о записи, и МОЖЕТ появляться более одного раза в каждой записи. Тело поля МОЖЕТ включать полный диапазон символов Юникода и не ограничивается каким-либо конкретным сценарием. Это поле МОЖЕТ быть вставлено или изменено в процессе регистрации, и гарантия стабильности не предоставляется.

Содержание этого поля не ограничено, за исключением необходимости регистрации информации, пригодности запроса и разумных практических ограничений размера. Основной причиной для поля «Комментарии» является идентификация субтега — чтобы отличить субтег от других, с которыми его можно спутать в качестве помощи при использовании. Большие объемы информации об использовании, истории или общих сведениях о вложенном теге не одобряются, поскольку они, как правило, содержатся в запросе на регистрацию, а не в реестре.

 

3.2. Обозреватель языка подтегов

Рецензент языкового подтега модерирует список рассылки ietf-languages@iana.org, отвечает на запросы о регистрации и выполняет другие обязанности по обслуживанию реестра, описанные в разделе 3.3. Только рецензент языкового подтэга имеет право запрашивать IANA об изменении, обновлении или добавлении записей в реестр языковых подтэгов. Рецензент Language Subtag МОЖЕТ делегировать модерацию списка и другие административные обязанности по мере необходимости.

Рецензент языкового субтага назначается IESG на неопределенный срок и может быть удален или заменен по усмотрению IESG. IESG будет запрашивать кандидатов на должность (после принятия этого документа или при наличии вакансии), а затем запрашивать отзывы о квалификации кандидатов. Квалифицированные кандидаты должны быть знакомы с BCP 47 и его требованиями; быть готовым честно, ответственно и разумно управлять процессом регистрации; и быть надлежащим образом проинформированным о проблемах идентификации языка, чтобы рецензент мог оценить претензии и использовать вклад экспертов по языкам и лиц, запрашивающих подтэги.

Последующее исполнение или решения проверяющего языкового подтега МОГУТ быть обжалованы в IESG по тем же правилам, что и другие решения IETF (см. [RFC2026]). IESG может отменить или отменить решения рецензента по языковым подтэгам, предоставить руководство или предпринять другие соответствующие действия.

 

3.3. Ведение реестра

Ведение реестра требует, чтобы, поскольку коды назначались или отзывались в соответствии с ISO 639, ISO 15924, ISO 3166 и ООН M.49, рецензент языкового подтега ДОЛЖЕН оценивать каждое изменение и определять соответствующий порядок действий в соответствии с правилами, изложенными в этом документе. документ. Такие обновления следуют процессу регистрации, описанному в разделе 3.5. Обычно рецензент языкового субтага начинает процесс для новой или обновленной записи, заполнив регистрационную форму и отправив ее. Если произойдет изменение одного из этих стандартов, и рецензент языкового субтага не сделает это своевременно, то любая заинтересованная сторона МОЖЕТ отправить форму. После этого процесс регистрации продолжается в обычном режиме.

Обратите внимание, что некоторые регистрации влияют на другие вложенные теги — возможно, более чем на один — например, когда региональный вложенный тег считается устаревшим в пользу нового значения. Рецензент Language Subtag отвечает за правильную регистрацию любых таких изменений, причем для каждого изменения требуется собственная форма регистрации.

Специалист по проверке языковых вложенных тегов ДОЛЖЕН обеспечить соответствие новых вложенных тегов требованиям, приведенным в других разделах этого документа (и особенно в разделе 3.4), или предоставить соответствующую регистрационную форму для альтернативного вложенного тега, как описано в этом разделе. Каждый отдельный subtag, затронутый изменением, ДОЛЖЕН быть отправлен в список ietf-languages@iana.org со своей собственной регистрационной формой и в отдельном сообщении.

 

3.4. Стабильность записей реестра IANA

Стабильность записей и их значение в реестре имеет решающее значение для долгосрочной стабильности языковых тегов. Правила в этом разделе гарантируют, что значение определенного языкового тега будет стабильным во времени и не изменится.

Эти правила, в частности, касаются того, как изменения в кодах (в том числе изъятие и устаревание кодов), поддерживаемые ISO 639, ISO 15924, ISO 3166 и UN M.49, отражаются в Реестре языковых подтэгов IANA. Присвоения Реестра языковых вложенных тегов IANA ДОЛЖНЫ соответствовать следующим правилам стабильности:

1. Значения в полях «Type», «Subtag», «Tag» и «Added» НЕ ДОЛЖНЫ изменяться и гарантированно будут стабильными во времени.

2. Значения в полях «Preferred-Value» и «Deprecated» МОГУТ быть добавлены, изменены или удалены в процессе регистрации. Эти изменения ДОЛЖНЫ быть ограничены изменениями, необходимыми для отражения изменений в одном из базовых стандартов (ISO 639, ISO 15924, ISO 3166-1 или UN M.49), и обычно изменение или удаление «Предпочтительной стоимости» конкретно ограничено к региональным кодам.

3. Значения в поле «Описание» НЕ ДОЛЖНЫ изменяться таким образом, чтобы сделать недействительными любые существующие теги. Описание МОЖЕТ быть несколько расширено по объему, изменено для добавления информации или адаптировано для наиболее распространенного современного использования. Например, страны иногда меняют свои названия; исторический пример этого — «Upper Volta — Верхняя Вольта», сменяющаяся на «Burkina Faso — Буркина-Фасо».

4. Значения в поле «Префикс» МОГУТ быть добавлены к существующим записям типа «вариант» в процессе регистрации, при условии, что «вариант» уже имеет хотя бы один «Префикс». Поле «Префикс» НЕ ДОЛЖНО быть зарегистрировано ни для одного «варианта», в котором отсутствует поле «Префикс». Если префикс добавляется к записи варианта, поля «Комментарий» МОГУТ использоваться для объяснения различных случаев использования различных префиксов.

5. Значения в поле «Префикс» в записях типа «вариант» МОГУТ также быть изменены, если модификации расширяют набор префиксов. То есть префикс МОЖЕТ быть заменен одним из его собственных префиксов. Например, префикс «en-US» может быть заменен на «en», но не на префиксы «en-Latn», «fr» или «en-USboont». Если бы понадобилось одно из этих значений префикса, его нужно было бы зарегистрировать отдельно.

6. Значения в поле «Префикс» в записях типа «extlang» НЕ ДОЛЖНЫ быть добавлены, изменены или удалены.

7. Поле «Префикс» НЕ ДОЛЖНО быть удалено из любой записи, в которой оно появляется. Это поле ДОЛЖНО быть включено в первоначальную регистрацию любых записей типа ‘вариант’ и ДОЛЖНО быть включено в любые записи типа ‘extlang’.

8. Поле «Комментарии» МОЖЕТ быть добавлено, изменено, изменено или удалено посредством процесса регистрации или любого из процессов или соображений, описанных в этом разделе.

9. Поле ‘Suppress-Script’ МОЖЕТ быть добавлено или удалено в процессе регистрации.

10. Поле «Macrolanguage» МОЖЕТ быть добавлено или удалено в процессе регистрации, но только в ответ на изменения, внесенные в ISO 639. Поле «Macrolanguage» появляется, когда у языка есть соответствующий макроязык в ISO 639. То есть Поля Macrolanguage ‘в реестре точно совпадают с полями ISO 639. Никакие другие отображения Macrolanguage не будут рассматриваться для регистрации.

11. Поле «Scope» МОЖЕТ быть добавлено или удалено из основного или расширенного языкового подтега после первоначальной регистрации, и оно МОЖЕТ быть изменено для соответствия любым изменениям, внесенным в ISO 639. Изменения в поле «Scope» ДОЛЖНЫ отражать сделанные изменения ISO 639. Обратите внимание, что первичные или расширенные языковые подтэги, записи которых не содержат поля «Область действия» (то есть большинство из них), являются отдельными языками, как описано в разделе 3.1.11.

12. Основные и расширенные языковые подтэги (кроме независимо зарегистрированных значений, созданных с использованием процесса регистрации) создаются в соответствии с присвоениями различных частей ISO 639 следующим образом:

A. Коды, присвоенные ISO 639-1, которые не конфликтуют с существующими двухбуквенными подтегами основного языка и не имеют соответствующих трехбуквенных основных языков, определенных в реестре, заносятся в реестр IANA как новые записи типа «язык». Обратите внимание, что языки с кодом ISO 639-1 не могут иметь расширенные языковые подтэги, даже если они включены в макроязык.

B. Коды, присвоенные ISO 639-3 или ISO 639-5, которые не конфликтуют с существующими трехбуквенными субтегами основного языка и не имеют назначенных (или ожидаемых назначаемых) кодов ISO 639-1, вносятся в реестр IANA как новые записи типа «язык». Обратите внимание, что эти два стандарта теперь содержат расширенный набор кодов ISO 639-2. Коды, которые имеют определенное отображение «макроязыка» во время их регистрации, ДОЛЖНЫ содержать поле «макроязыка».

C. Коды, присвоенные ISO 639-3, МОГУТ также рассматриваться для регистрации расширенного языкового подтэга. Обратите внимание, что им НЕОБХОДИМО назначать запись подтега основного языка типа ‘language’, даже если предлагается запись ‘extlang’. При рассмотрении расширенного языкового субтега применяются следующие критерии:

1. Если у языка есть отображение макроязыка, и у этого макроязыка есть другие включенные языки, которым назначены расширенные языковые подтэги, то новому языку СЛЕДУЕТ также назначить запись ‘extlang’. Например, любому языку с макроязыком «zh» или «ar» будет назначена запись «extlang».

2. Записи «Extlang» НЕ ДОЛЖНЫ создаваться для языков, если другие языки, включенные в макроязык, также не включают записи «Extlang». Например, если будет зарегистрирован новый сербохорватский (’sh’) язык, он не получит запись на внешнем языке, поскольку другие включенные языки, такие как сербский (’sr’), не включают один в реестр.

3. Языки жестов ДОЛЖНЫ иметь запись «extlang» с префиксом «sgn».

4. Записи «Extlang» НЕ ДОЛЖНЫ создаваться для элементов, уже находящихся в реестре. Расширенные языковые подтэги будут рассматриваться только во время первоначальной регистрации.

5. Записи расширенного языкового подтэга ДОЛЖНЫ включать в себя поля «Префикс» и «Предпочтительное значение» со значениями полей, назначенными, как описано в разделе 2.2.2.

D. Любые другие коды, присвоенные ISO 639-2, которые не конфликтуют с существующими трехбуквенными субтегами основного или расширенного языка и не имеют назначенных двухбуквенных кодов ISO 639-1, заносятся в реестр IANA как новые записи типа ’language’. Этот тип регистрации не должен происходить в будущем.

13. Коды, присвоенные ISO 15924 и ISO 3166-1, которые не конфликтуют с существующими вложенными тегами соответствующего типа и значение которых не совпадает с существующими вложенными тегами того же типа, заносятся в реестр IANA в качестве новых записей.

14. Коды, присвоенные ISO 639, ISO 15924 или ISO 3166-1, отозванные их соответствующим обслуживающим или регистрирующим органом, остаются действительными в языковых тегах. Поле «Устаревшие», содержащее дату отзыва, ДОЛЖНО быть добавлено в запись. Если добавляется новая запись того же типа, которая представляет заменяющее значение, тогда МОЖЕТ также быть добавлено поле «Preferred-Value». Процесс регистрации МОЖЕТ использоваться для добавления комментариев об отзыве кода по соответствующему стандарту.

Например: код региона «TL» был присвоен стране «Тимор-Лешти», заменив код «TP» (который был присвоен «Восточному Тимору», когда он находился под управлением Португалии). Подтег «TP» остается действительным в языковых тегах, но его запись содержит «Preferred-Value» из «TL», а его поле «Deprecated» содержит дату, когда был назначен новый код («2004-07-06»).

15. Коды, присвоенные ISO 639, ISO 15924 или ISO 3166-1, которые конфликтуют с существующими вложенными тегами соответствующего типа, включая вложенные теги, которые не рекомендуется использовать, НЕ ДОЛЖНЫ быть внесены в реестр. Следующие дополнительные соображения применимы к значениям вложенных тегов, которые переназначаются:

A. Для кодов ISO 639, если значение вновь назначенного кода не представлено подтэгом в реестре IANA, рецензент языкового субтега, как описано в разделе 3.5, ДОЛЖЕН подготовить предложение для внесения в реестр IANA, как только это станет практически возможным зарегистрированный языковой подтег в качестве альтернативного значения для нового кода. Форма зарегистрированного языкового подтэга будет по усмотрению Обозревателя языковых подтэгов и ДОЛЖНА соответствовать другим ограничениям на языковые подтэги в этом документе.

B. Для всех вложенных тегов, значение которых получено из внешнего стандарта (то есть ISO 639, ISO 15924, ISO 3166-1 или ООН M.49), если новое значение присваивается существующему коду и новому значению расширяет значение этого кода, тогда значение для соответствующего подтега МОЖЕТ быть изменено для соответствия. Однако значение вложенного тега НЕ ДОЛЖНО быть сужено, поскольку это может привести к тому, что неизвестная доля существующих применений вложенного тега станет недействительной. Примечание: орган регистрации ISO 639 (RA) принял аналогичную политику стабильности.

C. Для кодов ISO 15924, если значение вновь назначенного кода не представлено подтэгом в реестре IANA, рецензент языкового субтега, как описано в разделе 3.5, ДОЛЖЕН подготовить предложение для внесения в реестр IANA, как только это станет практически возможным зарегистрированный вариант subtag в качестве альтернативного значения для нового кода. Форма зарегистрированных вариантных вложенных тегов будет оставлена на усмотрение рецензента языковых вложенных тегов и ДОЛЖНА соответствовать другим ограничениям на альтернативные вложенные теги в этом документе.

D. Для кодов ИСО 3166-1, если значение вновь назначенного кода связано с тем же кодом ООН M.49, что и для другого подтега «регион», то существующий подрегион региона остается в качестве предпочтительного значения для этого региона, и новая запись не является создано. Комментарий МОЖЕТ быть добавлен к существующему подтегу региона, указывая на связь с новым кодом ISO 3166-1.

E. Для кодов ИСО 3166-1, если значение вновь назначенного кода связано с кодом ООН M.49, который не представлен существующим подтэгом региона, то рецензент языкового подтега, как описано в разделе 3.5, ДОЛЖЕН подготовить предложение для ввода соответствующего кода страны ООН M.49 в качестве записи в реестре IANA.

F. Для кодов ISO 3166-1, если нет связанного числового кода ООН, тогда рецензент Language Subtag ДОЛЖЕН обратиться в ООН с просьбой создать его. Если в течение 90 дней после отправки запроса от ООН не будет получено ответа, рецензент языкового подтэга ДОЛЖЕН подготовить предложение о внесении в реестр IANA, насколько это будет практически возможно, зарегистрированного альтернативного подтега в качестве альтернативного значения для нового кода. Форма зарегистрированных вариантных вложенных тегов будет оставлена на усмотрение рецензента языковых вложенных тегов и ДОЛЖНА соответствовать другим ограничениям на альтернативные вложенные теги в этом документе. Такая ситуация вряд ли когда-либо произойдет.

16. В ООН M.49 есть коды как для «стран и районов» (например, «276» для Германии), так и для «географических регионов и субрегионов» (например, «150» для Европы). Коды стран или регионов ООН M.49, для которых не существует соответствующего кода ISO 3166-1, НЕ ДОЛЖНЫ регистрироваться, за исключением случаев, когда они заменяют код ISO 3166-1, заблокированный от регистрации существующим подтэгом. Если такой код становится необходимым, тогда агентство по техническому обслуживанию ISO 3166-1 ДОЛЖНО сначала обратиться с просьбой назначить код для региона. Если в ходатайстве о присвоении кода в соответствии со стандартом ISO 3166-1 было отказано или оно не было выполнено своевременно, процесс регистрации, описанный в разделе 3.5, можно затем использовать для регистрации соответствующего кода ООН M.49. Таким образом, коды ООН M.49 остаются доступными в качестве значения последней инстанции в случаях, когда ISO 3166-1 переназначает устаревшее значение в реестре.

17. Избыточные и унаследованные записи вместе образуют полный список тегов, зарегистрированных в [RFC3066]. Избыточные теги — это ранее зарегистрированные теги, которые теперь могут быть сформированы с использованием вложенных тегов, определенных в реестре. Запрещенные записи включают записи, которые никогда не могут быть законными, потому что они «неправильные» (то есть они не соответствуют продукции «langtag» на рисунке 1), ограничены правилом (подтеги, такие как «nyn» и «min») как производство extlang, но не может быть зарегистрировано как расширенные языковые подтэги), или их подтэги не подходят для регистрации. Все обнаруженные теги перечислены либо в «регулярном», либо в «нерегулярном» производстве в ABNF. В соответствии с [RFC4646] дед-теги могли стать избыточными. Однако все теги, для которых это было возможно, стали излишними до того, как этот документ был выпущен. Таким образом, набор избыточных и унаследованных тегов теперь является постоянным и неизменным: новые записи любого типа НЕ ДОЛЖНЫ добавляться, а существующие записи НЕ ДОЛЖНЫ удаляться. Процесс принятия решения о том, какие метки были изначально выделены, а какие стали избыточными, описан в [RFC4645].

Многие из устаревших тегов устарели — на самом деле, они устарели еще до [RFC4646]. Например, тег «art-lojban» устарел в пользу основного языка subtag ’jbo’. Эти теги можно было бы сделать «избыточными», зарегистрировав некоторые из их вложенных тегов в качестве «вариантов». «Вариантоподобные» подтэги в регистрации, выполненной с использованием дедов, НЕ ДОЛЖНЫ регистрироваться в будущем, даже с аналогичным или идентичным значением.

 

3.5. Процедура регистрации подтегов

Приведенная здесь процедура ДОЛЖНА использоваться любым, кто хочет использовать подтэг, которого в настоящее время нет в Реестре языковых подтэгов IANA, или кто хочет добавлять, изменять, обновлять или удалять информацию в существующих записях, как разрешено этим документом.

Только субтеги типа «язык» и «вариант» будут рассматриваться для независимой регистрации новых субтегов. Субтеги, необходимые для стабильности, и субтеги, необходимые для синхронизации реестра с ISO 639, ISO 15924, ISO 3166 и ООН M.49 в пределах, определенных в этом документе, также используют этот процесс, как описано в разделе 3.3 и при условии соблюдения положений о стабильности, как описано в разделе 3.4.

Принимаются запросы на регистрацию, относящиеся к информации в полях «Комментарии», «Устаревшие», «Описание», «Префикс», «Предпочитаемое значение», «Макроязык» или «Подавить-Сценарий» в записи подтеги, как описано в разделе 3.4. Изменения всех других полей в реестре IANA НЕ допускаются.

Регистрация нового вложенного тега или запрос на изменение существующего тега или вложенного тега начинается с того, что запрашивающий участник заполняет регистрационную форму, приведенную ниже. Обратите внимание, что каждый ответ не ограничен по размеру, так что запрос может адекватно описать регистрацию. Поля в разделе «Запрошенная запись» должны соответствовать требованиям в разделе 3.1, прежде чем запись будет утверждена.

Примеры заполненных регистрационных форм можно найти в Приложении B. Полный список утвержденных регистрационных форм можно найти на сайте http://www.iana.org; читатели должны заметить, что реестр языковых тегов устарел и вместо этого следует искать реестр языковых вложенных тегов.

Регистрационная форма подтэга ДОЛЖНА быть отправлена ​​по адресу <ietf-languages@iana.org>. Запросы на регистрацию проходят двухнедельный период рассмотрения, после чего они утверждаются и передаются в IANA для включения в реестр. Если в течение процесса регистрации вносятся изменения в запрос (например, исправления для удовлетворения требований в разделе 3.1 или для того, чтобы поля «Описание» были уникальными для данного типа записи), измененная форма ДОЛЖНА также отправляться по адресу < ietf-languages@iana.org> как минимум за неделю до подачи в IANA.

Список языков ietf является открытым списком, к которому можно присоединиться, отправив запрос по адресу <ietf-languages-request@iana.org>. Список может быть размещен IANA или любой третьей стороной по запросу IESG.

Прежде чем пересылать любую регистрацию в IANA, рецензент языкового подтэга ДОЛЖЕН убедиться, что все требования в этом документе выполнены. Это включает в себя обеспечение того, чтобы значения в поле «Subtag» соответствовали регистру в соответствии с описанием в разделе 3.1.4 и чтобы поля «Description» были уникальными для данного типа записи, как описано в разделе 3.1.5. Рецензент также ДОЛЖЕН убедиться, что в запрос включена соответствующая запись файла-даты, чтобы помочь IANA в обновлении реестра (см. Раздел 5.1).

Некоторые поля как в форме регистрации, так и в самой записи реестра позволяют использовать символы, не входящие в ASCII. Регистрационные запросы ДОЛЖНЫ использовать кодировку UTF-8 для согласованности и ясности. Однако, поскольку некоторые почтовые клиенты не поддерживают эту кодировку, для запроса регистрации МОГУТ использоваться другие кодировки. Рецензент языкового субтага отвечает за то, чтобы правильные символы Юникода появлялись как в заархивированной форме запроса, так и в записи реестра. В случае ошибки транскрипции или кодирования IANA рецензент языкового субтега запросит восстановление реестра, предоставив любую необходимую информацию, чтобы помочь IANA.

Расширенные языковые подтэги (тип ‘extlang’) по определению всегда охватываются другим языком. Поэтому все записи типа «extlang» ДОЛЖНЫ содержать поле «Префикс» во время регистрации. Это поле «Префикс» никогда не может быть изменено или удалено, и запросы на это ДОЛЖНЫ быть отклонены.

Вариантные вложенные теги обычно регистрируются для использования с определенным диапазоном языковых тегов, и поощряются вариантные вложенные теги, основанные на терминологии языка, к которому они применяются. Например, subtag ’rozaj’ (Resian) предназначен для использования с языковыми тегами, которые начинаются с основного языкового subtag «sl» (словенский), поскольку Resian является диалектом словенского языка. Таким образом, subtag ’rozaj’ будет уместным в таких тегах, как «sl-Latn-rozaj» или «sl-IT-rozaj». Эта информация хранится в поле «Префикс» в реестре. Запросы на регистрацию вариантов ДОЛЖНЫ включать в регистрационную форму как минимум одно поле «Префикс».

Запросы на присвоение дополнительной записи заданного типа с существующим значением подтэга ДОЛЖНЫ быть отклонены. Например, вариант subtag ’rozaj’ уже существует в реестре, поэтому добавление второй записи типа ’option’ с подтагом ’rozaj’ запрещено.

Поле «Префикс» для данного зарегистрированного варианта подтега существует в реестре IANA в качестве руководства по использованию. Дополнительные поля «Префикс» МОГУТ быть добавлены путем заполнения дополнительной регистрационной формы. В этой форме поле «Любая другая релевантная информация:» ДОЛЖНО указывать, что это добавление префикса.

Запросы на добавление поля «Префикс» к варианту подтега, которые подразумевают другое семантическое значение, ДОЛЖНЫ быть отклонены. Например, запрос на добавление префикса «de» к подтэгу «1994», чтобы тег «de-1994» представлял некоторый немецкий диалект или орфографическую форму, был бы отклонен. Вложенный тег 1994 года представляет собой конкретную словенскую орфографию, и дополнительная регистрация изменила бы или размыла семантическое значение, назначенное вложенному тегу. Вместо этого СЛЕДУЕТ предлагать отдельный подтег.

НЕОБХОДИМО, чтобы запросы на добавление префикса к дополнительному тегу, у которого нет текущего поля префикса, ДОЛЖНЫ быть отклонены. Варианты регистрируются без префикса, потому что они потенциально полезны для многих или даже для всех языков. Добавление одного или нескольких полей «Префикс» может быть потенциально вредным для использования варианта, поскольку это значительно уменьшает область действия вложенного тега (что недопустимо в соответствии с правилами стабильности (раздел 3.4), а не расширяет область действия вложенного тега). Это то, что обычно делает добавление префикса. Примером такого варианта без префикса является подтег «fonipa», который представляет международный фонетический алфавит, схему, которая может использоваться для расшифровки многих языков.

Поля «Описание», представленные в запросе, ДОЛЖНЫ содержать хотя бы одно описание, написанное или транскрибированное на латинице; запрос МОЖЕТ также включать дополнительные поля «Описание» на любом скрипте или языке. Поле «Описание» используется для целей идентификации и не обязательно представляет фактическое родное название языка или варианта. Оно также не обязательно должно быть на каком-либо конкретном языке, но ДОЛЖНО быть подходящим и достаточным для идентификации элемента в записи. Рецензент языкового подтега проверит и отредактирует любые предложенные поля «Описание», чтобы обеспечить уникальность и предотвратить конфликты с полями «Описание» в других записях того же типа. Если это происходит в независимом запросе на регистрацию, рецензент языкового субтега ДОЛЖЕН повторно отправить запись на <ietf-languages@iana.org>, рассматривая ее как модификацию запроса из-за обсуждения, как описано в разделе 3.5, если только запрос не является единственным. Цель состоит в том, чтобы ввести повторяющееся поле «Описание», в этом случае запрос ДОЛЖЕН быть отклонен.

Поле «Описание» не обязательно будет стабильным. Исправления или разъяснения намерений являются примерами возможных изменений. Попытки обеспечить перевод или расшифровку записей в реестре (которые по определению не предоставляют никакой новой информации) вряд ли будут одобрены.

Вскоре по истечении двухнедельного периода проверки рецензент языкового субтага ОБЯЗАН принять одно из следующих действий:

• o Явно примите запрос и перешлите форму, содержащую запись для вставки или изменения, на <iana@iana.org> в соответствии с процедурой, описанной в разделе 3.3.
• o Явно отклонить запрос из-за существенных возражений, поднятых в списке, или из-за проблем с ограничениями в этом документе (которые ДОЛЖНЫ быть явно указаны).
• o Продлите период обзора, предоставив дополнительный двухнедельный прирост, чтобы можно было продолжить обсуждение. После каждого двухнедельного приращения рецензент языкового подтэга ДОЛЖЕН указывать в списке, была ли регистрация принята, отклонена или продлена.

Обратите внимание, что рецензент языкового субтага МОЖЕТ выдвинуть возражения в списке, если он или она того пожелают. Важно то, что возражение ДОЛЖНО быть сделано публично.

Иногда запрос необходимо изменить в результате обсуждения в течение периода проверки или из-за требований в этом документе. Заявитель, рецензент Language Subtag или другие лица МОГУТ представить измененную версию заполненной регистрационной формы, которая будет рассматриваться вместо первоначального запроса с явным одобрением заявителя. Такие изменения не возобновляют двухнедельный период обсуждения, хотя заявление, содержащее окончательную запись, представленную в IANA, ДОЛЖНО появиться в списке как минимум за одну неделю до того, как рецензент языкового подтэга направит запись в IANA. Заявитель МОЖЕТ изменить отклоненную заявку более подходящей или дополнительной информацией и подать ее снова; это начинает новый период комментариев twoweek.

Регистрации, инициированные в соответствии с положениями Раздела 3.3 или Раздела 3.4, НЕ ДОЛЖНЫ быть полностью отклонены (поскольку они должны в конечном итоге появиться в реестре) и ДОЛЖНЫ быть завершены как можно быстрее. Процесс рецензирования позволяет членам списка комментировать конкретную информацию в форме и содержащуюся в ней запись, что помогает обеспечить ее правильность и согласованность. Рецензент языкового субтега МОЖЕТ отклонить конкретную версию формы, но ДОЛЖЕН предложить подходящую замену, продлевая период проверки, как описано выше, до тех пор, пока форма не будет в формате, достойном одобрения рецензента, и не достигнет приблизительного консенсуса по списку.

Решения, принятые рецензентом Language Subtag, МОГУТ быть обжалованы в IESG [RFC2028] по тем же правилам, что и другие решения IETF [RFC2026]. Это включает в себя решение продлить период рассмотрения или невозможность объявить решение в четкой и своевременной форме.

Утвержденные записи появятся в Реестре языковых подтэгов. Утвержденные регистрационные формы доступны в Интернете по адресу http://www.iana.org.

Обновления или изменения существующих записей следуют той же процедуре, что и новые регистрации. Рецензент языкового подтэга решает, существует ли консенсус по обновлению регистрации после двухнедельного периода проверки; как правило, возражения первоначального регистранта будут иметь дополнительный вес при формировании такого консенсуса.

Регистрация постоянна и стабильна. После регистрации subtags не будут удалены из реестра и останутся действительным способом указать конкретный язык или вариант.

Примечание. Цель раздела «Ссылка на опубликованное описание» в регистрационной форме состоит в том, чтобы помочь проверить, зарегистрирован ли язык или к какому языку или вариации языка относится конкретный подтег. В большинстве случаев, ссылка на авторитетную грамматику или словарь этого языка будет полезна; в случаях, когда такой работы не существует, МОЖЕТ быть уместным другие известные работы, описывающие этот язык или на этом языке. Рецензент Language Subtag решает, что является «достаточно хорошим» справочным материалом. Это требование не предназначено для исключения определенных языков или диалектов из-за размера населения говорящего или отсутствия стандартизированной орфографии. Языки меньшинств будут рассматриваться в равной степени по существу.

3.6. Возможности для регистрации

Возможности регистрации вложенных тегов или информации о вложенных тегах включают в себя:

• o Подтеги основного языка для языков, не перечисленных в ISO 639, которые не являются вариантами какого-либо из перечисленных или зарегистрированных языков, МОГУТ быть зарегистрированы. На момент создания этого документа не было примеров этой формы подтэга. Прежде чем пытаться зарегистрировать языковой подтэг, ДОЛЖНА быть попытка зарегистрировать язык в ISO 639. Подтеги НЕ ДОЛЖНЫ регистрироваться для языков, определенных кодами, которые существуют в ISO 639-1, ISO 639-2 или ISO 639-3; которые находятся на рассмотрении в органах регистрации ISO 639; или что никогда не пытались зарегистрироваться в этих органах. Если ISO 639 ранее отклонял язык для регистрации, разумно предположить, что должны быть дополнительные, очень убедительные доказательства необходимости, прежде чем он будет зарегистрирован в качестве основного языкового фрагмента в реестре IANA (в той степени, в которой это маловероятно что любые subtags будут зарегистрированы этого типа).
• o Диалект или другие подразделения или вариации в пределах языка, его орфографии, системы письменности, регионального или исторического использования, транслитерации или другого преобразования или отличительного варианта МОГУТ быть зарегистрированы в качестве альтернативных подтегей. Примером может служить подтаг ‘rozaj’ (резанский диалект словенского языка).
• o Допускается добавление или ведение полей (как правило, информационного характера) в записях тегов или вложенных тегов, как описано в разделе 3.1. Такие изменения подпадают под условия стабильности в разделе 3.4. Сюда входят поля «Описание», «Комментарии», «Устаревшие» и «Предпочитаемое значение» для устаревших или отозванных кодов, а также добавление полей «Подавить-Сценарий» или «Макроязык» в подтеги основного языка, а также другие изменения, разрешенные этим документом, такие как добавление соответствующего поля «Префикс» к дополнительному тегу.
• o Допускается добавление записей и соответствующих изменений значений полей, необходимых для отражения присвоений, сделанных ISO 639, ISO 15924, ISO 3166-1 и UN M.49, как описано в разделе 3.4.

Подтеги, предложенные для регистрации, которые могут привести к тому, что весь или часть обнаруженного тега станет избыточным, но значение которого противоречит или изменяет значение обнаруженного тега, ДОЛЖНО быть отклонено.

Этот документ оставляет решение о том, какие подтэги или изменения в подтэгах соответствуют (или нет) процессу регистрации, описанному в разделе 3.5.

Примечание. Четырехсимвольные вложенные теги основного языка зарезервированы для обеспечения возможности использования кодов альфа4 в некоторых будущих дополнениях к семейству стандартов ISO 639.

ISO 639 определяет регистрирующий орган для добавления и изменения в списке языков в ISO 639. Это агентство:

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 определяет регистрирующий орган для дополнений и изменений в списке языков в ISO 639-2. Это агентство является:

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 определяет регистрирующий орган для добавления и изменения в списке языков в ISO 639-3. Это агентство является:

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 определяет регистрирующий орган для дополнений и изменений в списке языков в ISO 639-5. Это агентство аналогично ISO 639-2 и является:

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

Агентство по техническому обслуживанию ISO 3166-1 (коды стран):

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

Орган регистрации по ISO 15924 (коды сценариев):

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

Статистический отдел Секретариата Организации Объединенных Наций поддерживает стандартные страновые или региональные коды для статистического использования и может быть доступен по адресу:

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

3.7. Расширения и реестр расширений

Подтегами расширения являются те, которые вводятся односимвольными вложенными тегами («синглетонами»), отличными от «x». Они зарезервированы для генерации идентификаторов, которые содержат языковой компонент и совместимы с приложениями, которые понимают языковые теги.

Структура и форма расширений определяются этим документом, так что могут быть созданы реализации, совместимые с приложениями, которые могут быть созданы с использованием синглетонов в будущем. Кроме того, определение механизма поддержки синглетонов обеспечит стабильность этого документа за счет уменьшения вероятной необходимости будущих изменений или обновлений.

Однозначные вложенные теги присваиваются IANA с использованием политики «Проверка IETF», определенной в [RFC5226]. Эта политика требует разработки RFC, в котором ДОЛЖНЫ быть определены имя, цель, процессы и процедуры для поддержки вложенных тегов. Орган по ведению или регистрации, включая имя, контактный адрес электронной почты, адрес электронной почты для списка обсуждений и URL-адрес реестра, ДОЛЖЕН быть четко указан в RFC. RFC ДОЛЖЕН указать или включить каждое из следующего:

• o Спецификация ДОЛЖНА ссылаться на конкретную версию или редакцию этого документа, которая управляет его созданием, и ДОЛЖНА ссылаться на этот раздел этого документа.
• o Спецификация и все вложенные теги, определенные в спецификации, ДОЛЖНЫ следовать ABNF и другим правилам формирования тегов и вложенных тегов, как определено в этом документе. В частности, он ДОЛЖЕН указывать, что регистр не является значимым, а длина вложенных тегов НЕ ДОЛЖНА превышать восемь символов.
• o Спецификация ДОЛЖНА указывать каноническое представление.
• o Спецификация действительных вложенных тегов ДОЛЖНА быть доступна через Интернет и бесплатно.
• o Спецификация ДОЛЖНА быть в открытом доступе или доступна через лицензию без роялти, приемлемую для IETF и указанную в RFC.
• o Спецификация ДОЛЖНА быть версионной, и каждая версия спецификации ДОЛЖНА быть пронумерована, датирована и стабильна.
• o Спецификация ДОЛЖНА быть стабильной. То есть, дополнительные теги расширения, однажды определенные спецификацией, НЕ ДОЛЖНЫ быть отозваны или изменены в значительном смысле.
• o Спецификация ДОЛЖНА включать в отдельный раздел регистрационную форму, воспроизведенную в этом разделе (ниже), которая будет использоваться при регистрации расширения после публикации в качестве RFC.
• o IANA ДОЛЖНА быть проинформирована об изменениях контактной информации и URL-адреса для спецификации.

IANA будет вести реестр выделенных односимвольных (одноэлементных) вложенных тегов. Этот реестр ДОЛЖЕН использовать формат записи-jar, описанный ABNF в разделе 3.1.1. После публикации расширения в качестве RFC, обслуживающий орган, определенный в RFC, ДОЛЖЕН переслать эту регистрационную форму <iesg@ietf.org>, который ДОЛЖЕН переслать запрос по адресу <iana@iana.org>. Ответственный за добавочный номер ДОЛЖЕН поддерживать точность записи, отправляя обновленную полную копию записи на <iana@iana.org> с темой «ОБНОВЛЕНИЕ РАЗДЕЛЕНИЯ ЯЗЫКА ЯЗЫКА» при каждом изменении содержимого. В этих обновлениях МОГУТ быть изменены только поля «Комментарии», «Контакт_Почта», «Почта_списка» и «URL».

Несоблюдение этой записи, ведение соответствующего реестра или выполнение других условий, налагаемых этим разделом этого документа, МОЖЕТ быть обжаловано в IESG [RFC2028] по тем же правилам, что и другие решения IETF (см. [RFC2026]), и МОЖЕТ привести к полномочия по поддержанию продления были отозваны или переназначены IESG.

’Identifier’ содержит односимвольный вложенный тег (singleton), назначенный расширению. Интернет-проект, представленный для определения расширения, ДОЛЖЕН указать, какую букву или цифру использовать, хотя IESG МОЖЕТ изменить назначение при утверждении RFC.

«Описание» содержит название и описание расширения.

’Comments’ является необязательным полем, и МОЖЕТ содержать более широкое описание расширения.

«Добавлено» содержит дату публикации RFC расширения в формате «полной даты», указанном в [RFC3339]. Например: 2004-06-28 представляет 28 июня 2004 года в григорианском календаре.

«RFC» содержит номер RFC, назначенный добавочному номеру.

«Authority» содержит название обслуживающего органа для продления.

«Контактная почта» содержит адрес электронной почты, используемый для связи с уполномоченным органом.

’Mailing_List’ содержит URL-адрес или адрес электронной почты подписки в списке рассылки, который используется обслуживающим органом.

«URL» содержит URL-адрес реестра для этого расширения.

 

Решение о том, соответствует ли Интернет-проект вышеуказанным условиям, и решение о предоставлении или удержании таких полномочий принимается исключительно IESG и подлежит обычной процедуре рассмотрения и апелляции, связанной с процессом RFC.

Авторы расширений настоятельно предупреждают, что многие (в том числе наиболее правильно сформированные) процессоры не будут знать о каких-либо особых отношениях или значении, присущих порядку вложенных тегов расширения. Авторам СЛЕДУЕТ избегать связей подтегей или механизмов канонизации, которые мешают сопоставлению или ограничениям длины, которые иногда существуют в общих протоколах, где используется расширение. В частности, приложения МОГУТ усекать вложенные теги при выполнении сопоставления или при подгонке к ограниченной длине, поэтому РЕКОМЕНДУЕТСЯ, чтобы наиболее значимая информация находилась в наиболее значимых (крайних левых) вложенных тегах, а спецификация изящно обрабатывала усеченные вложенные теги.

Когда языковой тег должен использоваться в конкретном, известном протоколе, РЕКОМЕНДУЕТСЯ, чтобы языковой тег не содержал расширений, не поддерживаемых этим протоколом. Кроме того, обратите внимание, что некоторые протоколы МОГУТ накладывать верхние ограничения на длину строк, используемых для хранения или транспортировки языкового тега.

3.8. Обновление реестра подтегов языка

После принятия этого документа Реестру языковых вложенных тегов IANA потребовалось обновление, чтобы он содержал полный набор вложенных тегов, допустимых в языковом теге. [RFC5645] описывает процесс, использованный для создания этого обновления.

Регистрация, которая выполняется в соответствии с правилами, определенными в [RFC4646], когда этот документ принят, ДОЛЖНА быть завершена в соответствии с правилами, содержащимися в этом документе.

3.9. Применимость реестра подтегов

Реестр языковых вложенных тегов является источником элементов данных, используемых для создания языковых тегов, следуя правилам, описанным в этом документе. Языковые теги предназначены для обозначения языковых атрибутов различного контента, включая не только текст, но и большинство медиаформатов, таких как видео или аудио. Они также образуют основу для согласования языка и локали в различных протоколах и API.

Таким образом, реестр применим ко многим приложениям, которым требуется определенная языковая идентификация, с такими ограничениями:

• Он не предназначен для использования в качестве единственного источника данных при создании пользовательского интерфейса для выбора языка. Например, реестр не содержит переводов для описаний вложенных тегов или для тегов, составленных из вложенных тегов. Источники для локализованных данных, основанные на реестре, обычно доступны, в частности, [CLDR]. Реестр также не указывает, какие комбинации субтегов особенно полезны или актуальны.
• Он не предоставляет информацию, указывающую отношения между различными языками, например, которая может использоваться в пользовательском интерфейсе для выбора языковых тегов иерархически, регионально или в какой-либо другой организационной модели.
• Он не предоставляет информацию о возможном совпадении между разными языковыми тегами, поскольку понятие того, что составляет язык, не является точным: несколько разных языковых тегов могут быть разумным выбором для одного и того же фрагмента контента.
• Он не содержит информацию о соответствующих альтернативных вариантах при выполнении согласования языка. Хороший запасной язык может быть лингвистически не связан с указанным языком. Тот факт, что один язык часто используется в качестве запасного языка для другого, обычно является результатом внешних факторов, таких как география, история или культура — факторы, которые могут применяться не во всех случаях. Например, большинство людей, которые используют бретонский (кельтский язык, используемый на северо-западе Франции), вероятно, предпочли бы, чтобы его обслуживали по-французски (романский язык), если бретонский недоступен.

4. Формирование и обработка языковых тегов

В этом разделе описывается, как использовать информацию в реестре с синтаксисом тегов для выбора, формирования и обработки языковых тегов.

4.1. Выбор языкового тега

Руководящий принцип при формировании языковых тегов — «мудро маркировать содержимое». Иногда есть выбор между несколькими возможными тегами для одного и того же контента. Выбор того, какой тег использовать, зависит от содержимого и рассматриваемого приложения, и при выборе тега может потребоваться определенная оценка.

Функциональная совместимость лучше всего обеспечивается, когда один и тот же языковой тег используется последовательно для представления одного и того же языка. Если у приложения есть требования, которые делают правила здесь неприменимыми, тогда это приложение рискует повредить совместимость. Настоятельно РЕКОМЕНДУЕТСЯ, чтобы пользователи не определяли свои собственные правила выбора языковых тегов.

Стандарты, протоколы и приложения, которые нормативно ссылаются на этот документ, но применяют различные правила к тем, которые приведены в этом разделе, ДОЛЖНЫ указывать, как выбор языковых тегов отличается от приведенных здесь рекомендаций.

Чтобы обеспечить последовательную обратную совместимость, этот документ содержит несколько положений для учета потенциальной нестабильности в стандартах, используемых для определения подтэгов, составляющих языковые теги.

Эти положения означают, что ни один действительный языковой тег не может стать недействительным, и языковой тег в будущем не будет иметь более узкой области действия (он может иметь более широкую область действия). Наиболее подходящий языковой тег для данного приложения или элемента содержимого может со временем меняться, но после применения сам тег не может стать недействительным или полностью изменить его значение.

Подтег следует использовать только тогда, когда он добавляет полезную отличительную информацию к тегу. Посторонние подтэги мешают пониманию, пониманию и обработке языковых тегов. В частности, пользователям и реализациям СЛЕДУЕТ следовать полям «Prefix» и «Suppress-Script» в реестре (определено в разделе 3.1): эти поля предоставляют руководство относительно того, когда СЛЕДУЕТ использовать или избегать определенных дополнительных подтэгов в теге языка.

Выбор подтэгов, используемых для формирования языкового тега, ДОЛЖЕН соответствовать следующим рекомендациям:

1. Используйте как можно более точную метку, но не более конкретную, чем это оправдано. Избегайте использования вложенных тегов, которые не важны для различения контента в приложении.

* Например, для обозначения электронного письма, написанного на немецком языке, может быть достаточно «de», в то время как «de-CH-1996», вероятно, неоправданно точен для такой задачи.

* Обратите внимание, что некоторые последовательности вложенных тегов могут не соответствовать языку, который может ожидать обычный пользователь. Например, швейцарский немецкий (Schweizerdeutsch) язык представлен как «gsw-CH», а не как «de-CH». Этот последний тег представляет немецкий (’de’), используемый в Швейцарии (’CH’), также известный как швейцарский верхненемецкий язык (Schweizer Hochdeutsch). Оба являются реальными языками, и различение между ними может быть важным для приложения.

2. Субтег тега НЕ ДОЛЖЕН использоваться для формирования языковых тегов, если только скрипт не добавляет в тег некоторую отличительную информацию. Подтеги сценария впервые были формально определены в [RFC4646]. Их использование может повлиять на сопоставление и идентификацию вложенных тегов для реализаций [RFC1766] или [RFC3066] (которые устарели в этом документе), так как эти вложенные теги появляются между основным языком и вложенными тегами региона. Некоторые приложения могут извлечь выгоду из использования вложенных тегов сценариев в языковых тегах, если их использование не противоречит данному контексту. Подтеги скрипта никогда не подходят для неписаного содержимого (например, аудиозаписей). Поле ‘Suppress-Script’ в основной или расширенной языковой записи в реестре указывает вложенные теги сценариев, которые не добавляют отличительную информацию для большинства приложений; это поле определяет, когда пользователям НЕ СЛЕДУЕТ включать вложенный тег сценария с определенным вложенным тегом основного языка.

Например, если реализация выбирает контент, используя базовую фильтрацию [RFC4647] (первоначально описанную в разделе 14.4 [RFC2616]), и пользователь запросил языковой диапазон «en-US», контент с меткой «en-Latn-US» не будет совпадать запрос и, таким образом, не будет выбран. Следовательно, важно знать, когда обычно используются субтеги скрипта, а когда их не следует использовать.

Например:

* Подтег «Latn» не следует использовать с основным языком «en», потому что почти все документы на английском языке написаны латинским шрифтом, и он не добавляет отличительной информации. Однако, если документ был написан на английском языке, смешивая латинский алфавит с другим шрифтом, таким как шрифт Брайля («Brai»), то может быть целесообразным выбрать оба сценария, которые помогут при выборе контента, например, применение таблицы стилей.

* При маркировке содержимого, которое не написано (например, запись человеческой речи), не следует использовать подтэг сценария, даже если язык обычно пишется несколькими сценариями. Таким образом, субтитры к фильму могут использовать тег «uz-Arab» (узбекский, арабский алфавит), но звуковая дорожка для того же языка будет помечена просто «uz». (Тег «uz-Zxxx» также может использоваться там, где содержание не записано, поскольку подтег «Zxxx» представляет «Код для неписаных документов».)

3. Если тег или вложенный тег имеет поле «Preferred-Value» в своей записи реестра, то значение этого поля СЛЕДУЕТ использовать для формирования языкового тега в предпочтении к тегу или вложенному тегу, в котором появляется предпочтительное значение.

* Например, используйте «jbo» для ложбана вместо предпочтительного тега «art-lojban».

4. Используйте вложенные теги или последовательности вложенных тегов для отдельных языков, в отличие от вложенных тегов для языковых коллекций. «Языковая коллекция» — это группа языков, которые произошли от общего предка, на которых говорят в одной и той же географической области или связаны между собой. Некоторым языковым коллекциям присваиваются коды согласно [ISO639-5] (и некоторые из этих [ISO639-5] кодов также определяются как коллекции в [ISO639-2]). Эти коды включены в реестр как основные языковые подтэги. Вложенные теги для языковой коллекции в реестре имеют поле «Область действия» со значением «коллекция».

Вложенный тег для языковой коллекции всегда предпочтительнее менее специфичных альтернатив, таких как ‘mul’ и ‘und’ (см. Ниже), а вложенный тег, представляющий языковую коллекцию, МОЖЕТ использоваться, когда более конкретная языковая информация недоступна. Однако большинство пользователей и реализаций не знают, что существует связь между коллекцией и ее отдельными языками. Кроме того, отношения между отдельными языками в коллекции недостаточно четко определены; в частности, языки обычно не взаимно понятны. Поскольку вложенные теги различаются, запрос на коллекцию обычно создает только элементы, помеченные вложенным тегом коллекции, а не элементы, отмеченные вложенными тегами для отдельных языков, содержащихся в коллекции.

* Например, коллекции интерпретируются включительно, поэтому подтег «gem» (германские языки) может, но НЕ ДОЛЖЕН, использоваться с контентом, который будет лучше помечен как «en» (английский), «de» (немецкий) или «gsw» (швейцарский немецкий, Alemannic). В то время как «gem» собирает все эти (и другие) языки, большинство реализаций не будет соответствовать «gem» отдельным языкам; таким образом, использование subtag не даст желаемого результата.

5. [ISO639-2] определил несколько кодов, включенных в реестр подтегей, которые требуют дополнительной осторожности при выборе языковых тегов. В большинстве этих случаев, когда допускается пропуск языкового тега, такое пропускание предпочтительнее использования этих кодов. Языковые теги НЕ ДОЛЖНЫ включать эти вложенные теги в качестве префикса, если только дополнительная информация не передает некоторую ценность приложению.

* Мультиязык (несколько) основного языка идентифицирует контент на нескольких языках. Этот вложенный тег НЕ ДОЛЖЕН использоваться, если вместо него можно использовать список языков или отдельные теги для каждого элемента содержимого. Например, заголовок «Content-Language» [RFC3282] позволяет использовать список языков, а не только один языковой тег.

* Subtag основного языка (Undefined) определяет языковой контент, язык которого не определен. Этот вложенный тег НЕ ДОЛЖЕН использоваться, если не требуется языковой тег и информация о языке недоступна или не может быть определена. Пропуск языкового тега (где разрешено) является предпочтительным. Subtag «und» может быть полезен для протоколов, которые требуют предоставления языкового тега или когда требуется основной языковой тег (например, «und-Latn»). Подтег «und» МОЖЕТ также быть полезен при сопоставлении языковых тегов в определенных ситуациях.

* Подътег основного языка ’zxx’ (неязыковой, не применимый) определяет контент, для которого классификация языков не подходит или не применяется. Некоторые примеры могут включать инструментальную или электронную музыку; звукозаписи, состоящие из невербальных звуков; аудиовизуальные материалы без повествования, диалогов, печатных заголовков или субтитров; машиночитаемые файлы данных, состоящие из машинных языков или кодов символов; или программирование исходного кода.

* Подтиг «mis» (незакодированный) основного языка идентифицирует контент, язык которого известен, но который в настоящее время не имеет соответствующего подтега. Этот subtag НЕ ДОЛЖЕН использоваться. Поскольку добавление других кодов в будущем может сделать его приложение недействительным, оно по своей природе нестабильно и, следовательно, несовместимо с целями стабильности BCP 47. Всегда предпочтительно использовать другие вложенные теги: либо «und», либо (с предварительным соглашением) private использовать subtags.

6. Используйте вариант subtags экономно и в правильном порядке. Большинство вариантов вложенных тегов имеют одно или несколько полей «Префикс» в реестре, которые выражают список вложенных тегов, с которыми они подходят. Варианты ДОЛЖНЫ использоваться только с вложенными тегами, которые появляются в одном из этих полей «Префикс». Если вариант перечисляет второй вариант в одном из своих полей «Префикс», первый вариант ДОЛЖЕН появляться сразу после второго варианта в любом языковом теге, где встречаются оба. Варианты общего назначения (те, у которых вообще нет полей «Префикс») ДОЛЖНЫ появляться после любых других подтегов вариантов. Закажите все оставшиеся варианты, поместив сначала наиболее значимый подтэг. Если ни один из вложенных тегов не является более значимым или связь не может быть определена, разложите эти теги по алфавиту. Поскольку варианты очень специализированы, использование многих из них вместе обычно делает тег настолько узким, чтобы перекрыть полученную дополнительную точность. Размещение субтегов в другом порядке мешает совместимости, а также общей интерпретации тега.

Например:

* Тег «en-scotland-fonipa» (английский, шотландский диалект, фонетическая транскрипция IPA) правильно упорядочен, так как у «scotland» есть «Prefix» из «en», а у «fonipa» нет поля «Prefix».

* Тег «sl-IT-rozaj-biske-1994» правильно упорядочен: «rozaj» указывает «sl» в качестве единственного «префикса»; «Biske» перечисляет «sl-rozaj» в качестве единственного префикса. У подтэга 1994 года есть несколько префиксов, включая «sl-rozaj». Тем не менее, оно следует как «rozaj», так и «biske», потому что одно из его полей «Prefix» — «sl-rozajbiske».

7. Унаследованный тег «i-default» (язык по умолчанию) был первоначально зарегистрирован в соответствии с [RFC1766] для удовлетворения потребностей [RFC2277]. Он не используется для указания конкретного языка, а скорее для идентификации условий или контента, которые не могут быть установлены в языковых предпочтениях пользователя. Его НЕ СЛЕДУЕТ использовать, кроме как в качестве средства маркировки содержимого по умолчанию для приложений или протоколов, которые требуют, чтобы содержимое языка по умолчанию было помечено этим конкретным тегом. Он также МОЖЕТ использоваться приложением или протоколом для определения того, когда возвращается языковой контент по умолчанию.

4.1.1. Пометка включенных языков

Некоторые записи основного языка в реестре имеют поле «Macrolanguage» (раздел 3.1.10), в котором содержится сопоставление каждого «охватываемого языка» его макроязыку. Отображение «макроязыка» не определяет, каковы отношения между охватываемым языком и его макроязыком, и не определяет, как языки, охватываемые одним и тем же макроязыком, связаны друг с другом. Два разных языка, охватываемых одним и тем же макроязыком, могут отличаться друг от друга больше, чем, скажем, французский и испанский.

Некоторые специфические макроязыки, такие как китайский (’zh’) и арабский (’ar’), обрабатываются по-разному. Смотрите раздел 4.1.2.

Для формирования языкового тега СЛЕДУЕТ использовать более конкретный языковой вложенный тег, хотя МОЖЕТ использоваться либо языковой вложенный язык основного языка, либо вложенный языковой тег. Это означает, например, пометить Plains Cree с помощью «crk», а не «cr» (Cree) и так далее.

Сфера действия каждого макроязыкового подтега, по определению, включает все охватываемые им языки. Так как отношения между включенными языками различаются, пользователи не могут предполагать, что подтаг макроязыка означает какой-либо конкретный охватываемый язык или что любая данная пара охватываемых языков является взаимно понятной или взаимозаменяемой иным образом.

Приложения МОГУТ использовать информацию о макроязыке для улучшения соответствия или согласования языков. Например, информация о том, что «sr» (сербский) и «hr» (хорватский) разделяют макроязык, выражает более тесную связь между этими языками, чем, скажем, между «sr» (сербский) и «ma» (македонский). Однако эти отношения не гарантированы и не являются исключительными. Например, румынский (‘ro’) и молдавский (‘mo’) не имеют общего макроязыка, но гораздо более тесно связаны друг с другом, чем кантонский (‘yue’) и Wu (‘wuu’), которые имеют общий макроязык.

4.1.2. Использование расширенных языковых подтегов

Чтобы приспособить формы языковых тегов, использовавшиеся до принятия этого документа, языковые теги предоставляют специальный механизм совместимости: расширенный языковой подтег. Отдельные языки были снабжены как основными, так и расширенными языковыми подтэгами. К ним относятся макроязыки, такие как малайский («мс») и узбекский («уз»), которые имеют специфическое доминирующее разнообразие, которое обычно является синонимом макроязыка. Другие языки, такие как китайский (‘zh’) и арабский (‘ar’) макроязыки и различные языки жестов (‘sgn’), традиционно использовали свой основной языковой подтэг, возможно, в сочетании с различными региональными подтэгами или как часть зарегистрированный дедушкин ярлык, для обозначения языка.

С принятием этого документа стали доступны специальные подтэги ISO 639-3 для идентификации языков, содержащихся в этих различных языковых семействах или группах. Здесь представлен выбор языковых тегов, которых раньше не было:

• o Каждый вложенный языковой вложенный тег ДОЛЖЕН использоваться в качестве основного языкового вложенного тега. Например, документ на китайском языке будет помечен как «cmn» (подтег для китайского языка) вместо «zh» (китайский).
• o Если совместимость желательна или необходима, включенный вложенный тег МОЖЕТ использоваться в качестве расширенного языкового вложенного тега. Например, документ на китайском языке может быть помечен как «zh-cmn» вместо «cmn» или «zh».
• o Субтег макроязыка или префикса МОЖЕТ использоваться для формирования тэга, а не более специфического языкового субтага. То есть такие теги, как «zh-HK» или «sgn-RU», все еще действительны.

Китайский (’zh’) предоставляет полезную иллюстрацию этого. В прошлом в различном контенте использовались теги, начинающиеся с подтега «zh», причем специфическое значение приложения ассоциировалось с кодами регионов, последовательностями частного использования или зарегистрированными зарегистрированными значениями. Это связано с тем, что исторически для формирования языковых тегов был доступен только макроязыковой подтаг ‘zh’. Однако языки, охватываемые китайским подтэгом ‘zh’, в основном не взаимно понятны, когда на них говорят, и письменные формы этих языков также демонстрируют большие различия в форме и использовании.

Чтобы обеспечить совместимость, китайские языки, охватываемые вложенным тегом ‘zh’, находятся в реестре как в качестве основных языковых вложенных тегов, так и в качестве расширенных языковых вложенных тегов. Например, код ISO 639-3 для кантонского диалекта «yue». Контент на кантонском диалекте мог исторически использовать такой тег, как «zh-HK» (поскольку на кантонском диалекте обычно говорят в Гонконге), хотя этот тег на самом деле означает любой тип китайского языка, используемый в Гонконге. При наличии в реестре кодов ИСО 639-3 контент на кантонском диалекте может быть напрямую помечен с помощью подтега ‘yue’. Контент может использовать его в качестве основного языкового подтега, как в теге «yue-HK» (кантонский диалект Гонконг). Или он может использовать расширенный языковой подтэг с «zh», как в теге «zh-yue-Hant» (китайский, кантонский, традиционный сценарий).

Как отмечалось выше, приложения могут выбрать использование субтага макроязыка для формирования тега вместо того, чтобы использовать более конкретный языковой субтаг. Например, приложение с большими объемами данных, уже использующее теги с вложенным тегом «zh» (китайский), может продолжать использовать этот более общий вложенный тег, даже для новых данных, даже если содержимое может быть более точно помечено с помощью «cmn» (китайский язык) ), ‘юэ’ (кантонский диалект), ‘вуу’ (Ву) и так далее. Точно так же приложение, уже использующее теги, начинающиеся с подэтага ‘ar’ (арабский), может продолжать использовать этот более общий подтаг даже для новых данных, которые могут быть более точно помечены как ‘arb’ (стандартный арабский).

В некоторых случаях включенные языки имели теги, зарегистрированные для них в эпоху RFC 3066. Эти устаревшие теги, которые еще не были объявлены устаревшими или лишними, были исключены из реестра после принятия этого документа. Как устаревшие значения, они остаются действительными для использования, и некоторые материалы или приложения могут их использовать. Как и в случае других обнаруженных тегов, поскольку реализации могут быть не в состоянии связать обнаруженные теги с эквивалентами вложенных языковых вложенных тегов, которые рекомендованы в этом документе, реализациям рекомендуется канонизировать теги для сравнения. Некоторые примеры этого включают теги «zh-hakka» (хакка) и «zh-guoyu» (китайский или стандартный китайский).

Языки жестов имеют общий способ общения, а не языковое наследие. Существует много языков жестов, которые развивались независимо, и подтег ‘sgn’ указывает только на наличие языка жестов. На многих языках жестов также были обнаружены помеченные ярлыки для них в эпоху RFC 3066. Например, унаследованный тег «sgn-US» был зарегистрирован, чтобы представлять «американский язык жестов», в частности, без ссылки на Соединенные Штаты. Это все еще допустимо, но не рекомендуется: документ на американском языке жестов может быть помечен как «ase» или «sgn-ase» (подтег «ase» предназначен для языка под названием «американский язык жестов»).

4.2. Значение языкового тега

Значение языкового тега связано со значением вложенных тегов, которые он содержит. Каждый вложенный тег, в свою очередь, подразумевает определенный диапазон ожиданий, связанных с соответствующим контентом, хотя это не является гарантией. Например, использование субтага сценария, такого как «арабский» (арабский сценарий), не означает, что содержимое содержит только арабские символы. Это означает, что речь идет преимущественно о арабском языке. Таким образом, языковой тег и его подтэги могут охватывать очень широкий диапазон вариаций и при этом оставаться подходящими в каждом конкретном случае.

Срок действия тега — не единственный фактор, определяющий его полезность. Хотя каждый действительный тег имеет значение, он может не отражать использование языка реального мира. Это неизбежно в системе, в которой подтеги могут свободно комбинироваться. Например, такие теги, как «ar-Cyrl-CO» (арабский, кириллический шрифт, используемый в Колумбии) или «tlh-Kore-AQ-fonipa» (клингон, корейский шрифт, используемый в Антарктике, фонетическая транскрипция IPA), являются и действительны, и вряд ли представляют полезную комбинацию языковых атрибутов.

Значение данного тега не зависит от контекста, в котором он появляется. Однако связь между значением тега и информационными объектами, к которым применяется этот тег, может различаться.

o Для отдельного информационного объекта связанные языковые теги могут быть интерпретированы как набор языков, необходимый для полного понимания всего объекта. Пример: простые текстовые документы.

o Для агрегации информационных объектов связанные языковые теги могут быть приняты за набор языков, используемых внутри компонентов этой агрегации. Примеры: хранилища документов и библиотеки.

o Для информационных объектов, целью которых является предоставление альтернатив, связанные языковые теги можно рассматривать как подсказку о том, что контент предоставляется на нескольких языках, и что необходимо проверить каждую из альтернатив, чтобы найти его язык или языки. В этом случае наличие нескольких тегов может не означать, что нужно быть многоязычным, чтобы получить полное представление о документе. Пример: MIME multipart / alternative [RFC2046].

o Для языков разметки, таких как HTML и XML, языковая информация может быть добавлена ​​к каждой части документа, идентифицируемой структурой разметки (включая весь документ). Например, можно написать <span lang = «fr»> C’est la vie. </ Span> в немецком документе; немецкоязычный пользователь может получить доступ к французско-немецкому словарю, чтобы узнать, что означает помеченный раздел. Если бы пользователь слушал этот документ через интерфейс синтеза речи, эта формация могла бы использоваться для подачи сигнала синтезатору надлежащим образом применять французские правила произношения текста в речь вместо этого диапазона текста вместо применения неуместных немецких правил.

o Для языков разметки и форматов документов, позволяющих идентифицировать аудиторию, языковой тег может указывать аудиторию (и), подходящую для этого документа. Например, тот же HTML-документ, описанный в предыдущем пункте, может иметь HTTP-заголовок «Content-Language: de», чтобы указать, что целевой аудиторией для файла является немецкий (даже если в нем есть три слова, которые идентифицируются как французские) ).

o Для систем и API языковые теги образуют основу для большинства реализаций идентификаторов локали. Например, см. Проект UnDRode CLDR (хранилище данных общих локалей) (см. UTS # 35 [UTS35]).

Языковые теги связаны, когда они содержат аналогичную последовательность вложенных тегов. Например, если языковой тег B содержит языковой тег A в качестве префикса, то B обычно «более узкий» или «более специфичный», чем A. Таким образом, «zh-Hant-TW» более специфичен, чем «zh-Hant».

Это соотношение не гарантируется во всех случаях: в частности, языки, начинающиеся с одной и той же последовательности подтэгов, НЕ гарантированно взаимно понятны, хотя они могут быть. Например, тег «az» имеет общий префикс с «az-Latn» (азербайджанский язык пишется с использованием латинского алфавита) и «az-Cyrl» (азербайджанский язык пишется с использованием кириллицы). Человек, бегло говорящий по одному сценарию, может быть не в состоянии прочитать другой, даже если лингвистическое содержание (например, то, что будет слышно, если оба текста будут прочитаны вслух) может быть одинаковым. Контент, помеченный как «az», скорее всего, написан только одним скриптом и, следовательно, может быть непонятным для читателя, знакомого с другим скриптом.

Точно так же не все подтэги указывают фактическое различие в языке. Например, теги «en-US» и «en-CA» означают, приблизительно, английский язык с признаками, которые обычно считаются характерными для США и Канады, соответственно. Они не подразумевают, что существует существенная диалектическая граница между произвольно выбранной точкой в ​​Соединенных Штатах и ​​произвольно выбранной точкой в ​​Канаде. Ни один из субрегионов конкретного региона не подразумевает, что языковые различия не существуют в этом регионе.

4.3. Списки языков

В некоторых приложениях один элемент контента может быть лучше всего ассоциирован с более чем одним языковым тегом. Примеры такого использования включают в себя:

o Элементы контента, которые содержат несколько различных разновидностей. Часто это используется, чтобы указать подходящую аудиторию для данного элемента контента, когда может быть подходящим несколько вариантов. Примеры этого могут включать:

• * Метаданные о соответствующей аудитории для названия фильма. Например, DVD может маркировать свои отдельные аудиодорожки ‘de’ (немецкий), ‘fr’ (французский) и ‘es’ (испанский), но общее название будет содержать «de, fr, es» в качестве общей аудитории.
• * Французский / английский, английский / французский словарь, помеченный как «en» и «fr», чтобы указать, что он в равной степени относится к французскому и английскому языкам.
• * Параллельный или межлинейный перевод документа, как это обычно делается с классическими работами на латыни или греческом языке.

o Элементы контента, которые содержат один язык, но требуют нескольких уровней специфичности. Например, библиотека может пожелать классифицировать конкретную работу как норвежскую («нет») и как нюнорскую («нет») для аудиторий, способных оценить разницу или нуждающихся в более узком выборе контента.

4.4. Соображения длины

Не существует определенного верхнего предела размера языковых тегов. Хотя исторически большинство языковых тегов состояли из языковых и региональных вложенных тегов с общей длиной до шести символов, большие теги всегда были возможны и фактически использовались.

Ни синтаксис языкового тега, ни другие требования в этом документе не накладывают фиксированный верхний предел на количество подтегей в языковом теге (и, следовательно, верхнюю границу на размер тега). Синтаксис языкового тега предполагает, что в зависимости от конкретного языка иногда требуется больше вложенных тегов (и, следовательно, более длинный тег) для полной идентификации языка для определенных приложений; таким образом, можно представить длинные или сложные последовательности субтегов.

4.4.1. Работа с ограниченными размерами буфера

Некоторые приложения и протоколы вынуждены выделять фиксированные размеры буфера или иным образом ограничивать длину языкового тега. Соответствующая реализация или спецификация МОГУТ отказаться от поддержки хранения языковых тегов, длина которых превышает указанную. Любое такое ограничение ДОЛЖНО быть четко задокументировано, и такая документация ДОЛЖНА включать то, что происходит с более длинными тегами (например, генерируется ли значение ошибки или усекается ли языковой тег). Протокол, позволяющий усекать теги с произвольным пределом, без указания того, что это за предел, может нанести вред, существенно изменив значение тегов.

На практике большинство языковых тегов не требуют больше, чем несколько вложенных тегов, и не будут подходить к разумным размерам ограничений буфера; см. раздел 4.1.

Некоторые спецификации или протоколы имеют ограничения по длине тега, но не имеют фиксированного ограничения длины. Например, [RFC2231] не имеет явного ограничения длины: длина, доступная для языкового тега, ограничена длиной других компонентов заголовка (таких как имя кодировки) в сочетании с ограничением в 76 символов в [RFC2047]. Таким образом, «предел» может составлять 50 или более символов, но потенциально он может быть довольно маленьким.

Соображения для назначения ограничения буфера:

• Реализациям НЕ СЛЕДУЕТ усекать языковые теги, если только значение тега не было преднамеренно изменено или если тег не помещается в ограниченный размер буфера, определенный протоколом для хранения или передачи.
• Реализации ДОЛЖНЫ предупреждать пользователя, когда тег усекается, поскольку усечение меняет семантическое значение тега.
• Реализации протоколов или спецификаций, которые ограничены в пространстве, но не имеют фиксированного предела, ДОЛЖНЫ использовать максимально длинный тег в предпочтении к усечению.
• Протоколы или спецификации, которые определяют ограниченные размеры буфера для языковых тегов, ДОЛЖНЫ включать языковые теги длиной не менее 35 символов. Обратите внимание, что в [RFC4646] рекомендуется минимальный размер поля, равный 42 символам, поскольку он включает в себя все три элемента продукции «extlang». Два из них теперь зарезервированы на постоянной основе, поэтому зарегистрированный подтег основного языка с максимальной длиной 8 символов теперь длиннее самой длинной комбинации язык-экстланг. Протоколы или спецификации, которые обычно используют расширения или вложенные теги частного использования, могут пожелать зарезервировать или рекомендовать более длинный «минимальный размер буфера».

На следующем рисунке показано, как была получена рекомендация из 35 символов:

language = 8; самое длинное допустимое зарегистрированное значение длиннее основного + extlang, который требует 7 символов
script = 5; если не подавлено: см. раздел 4.1
region = 4; UN M.49 числовой код региона ISO 3166-1 коды требуют 3
variant1 = 9; нуждается в «языке» в качестве префикса
variant2 = 9; очень редко, так как в качестве префикса ему нужен языковой вариант
total = 35 символов

Рисунок 7: Вывод предела длины тега

4.4.2. Усечение языковых тегов

Усечение языкового тега изменяет значение тега, и поэтому его следует избегать. Однако усечение языковых тегов иногда необходимо из-за ограниченного размера буфера. Такое усечение НЕ ДОЛЖНО допускать обрезание промежуточного тега посередине или образование недопустимых тегов (например, один из которых заканчивается символом «-«).

Это означает, что приложения или протоколы, которые усекают теги, ДОЛЖНЫ делать это путем постепенного удаления вложенных тегов вместе с их предшествующим «-» с правой стороны тега языка до тех пор, пока тег не станет достаточно коротким для данного буфера. Если результирующий тег заканчивается субтегом с одним символом, этот субтег и его предшествующий символ «-» также ДОЛЖНЫ быть удалены. Например:

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

4.5. Канонизация языковых тегов

Поскольку определенный языковой тег может использоваться многими процессами, языковые теги СЛЕДУЕТ всегда создавать или генерировать в канонической форме.

Языковой тег находится в «канонической форме», когда тег правильно сформирован в соответствии с правилами в разделах 2.1 и 2.2, и он был канонизирован путем применения каждого из следующих шагов по порядку, используя данные из реестра IANA (см. Раздел 3.1 ):

1. Последовательности расширения упорядочены в регистр ASCII без учета регистра по одноэлементному подтэгу.

* Например, последовательность subtag ‘-a-babble’ предшествует ‘-b-warble’ ‘.

2. Избыточные или унаследованные теги заменяются их «Preferred-Value», если таковые имеются.

* Тело поля ‘Preferred-Value’ для выделенных и избыточных тегов является «расширенным языковым диапазоном» [RFC4647] и может состоять из нескольких вложенных тегов.
Поля «Preferred-Value» в реестре обеспечивают сопоставление устаревших тегов с современными эквивалентами. Многие из них были созданы до принятия этого документа (например, отображение «no-nyn» в «nn» или «i-klingon» в «tlh»). Другие являются результатом более поздних регистраций или дополнений в реестре, как это разрешено или требуется данным документом (например, «zh-hakka» устарела в пользу кода ISO 639-3 «hak», когда этот документ был принят).

3. Подтеги заменяются их «Preferred-Value», если таковые имеются.

Для экстлангов исходный основной тег языка также заменяется, если в «Preferred-Value» есть основной тег языка.

* Тело поля ‘Preferred-Value’ для extlangs является «расширенным языковым диапазоном» и обычно отображается на основной языковой подтег. Например, последовательность subtag «zh-hak» (китайский, хакка) заменяется на subtag ’hak’ (хакка).

* Большинство неэлементных подтэгов являются либо субтагами региона, где название или обозначение страны изменилось, либо канцелярскими исправлениями в соответствии с ISO 639-1.

Каноническая форма не содержит никаких внешних тегов. Существует альтернативная «форма внешнего языка», которая поддерживает или восстанавливает внешние теги. Эта форма может быть полезна в средах, где присутствие подтега «Префикс» считается полезным при сопоставлении или выборе (см. Раздел 4.1.2).

Языковой тег находится в «внешней форме», когда тег правильно сформирован в соответствии с правилами в разделах 2.1 и 2.2, и он был обработан путем применения каждого из следующих двух шагов по порядку с использованием данных из реестра IANA:

1. Языковой тег сначала преобразуется в каноническую форму, как описано выше.

2. Если языковой тег начинается с основного языкового вложенного тега, который также является вложенным тегом extlang, то перед языковым тегом добавляется префикс extlang.

* Например, «hak-CN» (Хакка, Китай) имеет основной языковой подтег «hak», который, в свою очередь, имеет запись «extlang» с префиксом «zh» (китайский). Экстланг форма «zh-hak-CN» (китаец, хакка, китай).

* Обратите внимание, что Шаг 2 (с добавлением префикса) может восстановить подтэг, который был удален Шагом 1 (канонизация).

Пример: языковой тег «en-a-aaa-b-ccc-bbb-x-xyz» имеет каноническую форму, в то время как «en-b-ccc-bbb-a-aaa-X-xyz» является правильно сформированным и потенциально допустимый (расширения ‘a’ и ‘b’ не определены на момент публикации этого документа), но не в канонической форме (расширения не в алфавитном порядке).

Пример: хотя тег «en-BU» (английский как используется в Бирме) сохраняет свою действительность, языковой тег «en-BU» не имеет канонической формы, поскольку подтег «BU» имеет каноническое отображение на «MM» (Мьянма ).

Канонизация языковых тегов не подразумевает использование заглавных или строчных букв при обработке или сравнении подтегей (как описано в разделе 2.1). Все сравнения ДОЛЖНЫ выполняться без учета регистра.

При выполнении канонизации языковых тегов процессоры МОГУТ упорядочить регистр подтегов (то есть этот процесс НЕОБЯЗАТЕЛЬНЫЙ) в соответствии с регистром, использованным в реестре (см. Раздел 2.1.1).

Если в теге присутствует более одного варианта, процессоры МОГУТ переупорядочить варианты для получения лучшего поведения соответствия или более согласованного представления. Изменение порядка вариантов СЛЕДУЕТ следовать рекомендациям по порядку вариантов в разделе 4.1.

Если поле «Устаревшие» отображается в записи реестра без сопровождающего поля «Предпочитаемое значение», то этот тег или вложенный тег не рекомендуется заменять. Эти значения являются каноническими, когда они появляются в теге языка. Однако теги, которые включают эти значения, НЕ ДОЛЖНЫ выбираться пользователями или генерироваться реализациями.

Расширение ДОЛЖНО определять любые отношения, которые существуют между различными вложенными тегами в расширении, и, таким образом, МОЖЕТ определять альтернативную схему канонизации для вложенных тегов расширения. Расширения МОГУТ определять порядок интерпретации подтегей расширения. Например, расширение может определить, что его вложенные теги находятся в каноническом порядке, когда вложенные теги размещены в порядке ASCII: то есть «en-aaaa-bbb-ccc» вместо «en-a-ccc-bbb-aaa». Другое расширение может определять, что порядок вложенных тегов влияет на их семантическое значение (так что «en-b-ccc-bbb-aaa» имеет значение, отличное от «en-baaa-bbb-ccc»). Однако спецификации расширения ДОЛЖНЫ быть разработаны так, чтобы они были терпимы к типичным процессам, описанным в разделе 3.7.

4.6. Соображения для частного использования подтегов

Вложенные теги частного использования, как и все другие вложенные теги, ДОЛЖНЫ соответствовать формату и ограничениям содержимого в ABNF. Подтеги частного использования не имеют никакого значения вне частного соглашения между сторонами, которые намерены использовать или обмениваться языковыми тегами, которые их используют. Одни и те же подтэги МОГУТ использоваться в другом частном соглашении с другим значением. Они НЕ ДОЛЖНЫ использоваться там, где существуют альтернативы, и НЕ ДОЛЖНЫ использоваться в контенте или протоколах, предназначенных для общего использования.

Subtags частного использования просто бесполезны для обмена информацией без предварительной договоренности. Значение и семантическое значение тегов частного использования и вложенных тегов, используемых внутри такого языкового тега, не определены в этом документе.

Последовательности частного использования, представленные синглтоном x, полностью непрозрачны для пользователей или реализаций вне соглашения о частном использовании. Таким образом, в дополнение к последовательностям вложенного тега частного использования, введенным одноэлементным вложенным тегом ’x’, Реестр языковых вложенных тегов предоставляет вложенные теги языка, сценариев и регионов частного использования, полученные из кодов частного использования, назначенных соответствующими стандартами.

Эти подтэги действительны для использования при формировании языковых тегов; они РЕКОМЕНДУЕТСЯ для последовательностей одноэлементных вложенных тегов «x» для частного использования, поскольку они передают больше информации через свою связь с внутренней структурой языкового тега.

Например, подтеги региона «AA», «ZZ» и те, которые находятся в диапазонах «QM» — «QZ» и «XA» — «XZ» (полученные из кодов частного использования ISO 3166-1), могут использоваться для сформировать языковой тег. Тэг, такой как «zh-Hans-XQ», передает много общедоступной, взаимозаменяемой информации о языковых материалах (что это на китайском языке в упрощенном китайском языке и подходит для некоторого географического региона «XQ»). Хотя точный географический регион не известен вне частного соглашения, тег передает гораздо больше информации, чем непрозрачный тег, такой как «x-somelang» или даже «zh-Hans-x-xq» (где значение подтега «xq» имеет значение полностью непрозрачный).

Однако в некоторых случаях контент, помеченный частными тегами частного использования, может взаимодействовать с другими системами другим и, возможно, неподходящим образом по сравнению с тегами, которые используют непрозрачные частные теги частного использования, поэтому выбор наилучшего подхода иногда зависит от конкретного рассматриваемого домена.

5. Соображения IANA

В этом разделе рассматриваются процессы и требования, необходимые IANA для ведения реестров вложенных тегов и расширений, как определено в этом документе и в соответствии с требованиями [RFC5226].

Воздействие на сопровождающих IANA двух реестров, определенных в этом документе, будет незначительным увеличением частоты новых записей или обновлений. IANA также должна создать новый список рассылки (описанный ниже в разделе 5.1), чтобы объявлять об изменениях и обновлениях реестра.

5.1. Реестр языковых подтегов

IANA обновила реестр, используя инструкции и контент, предоставленный в сопроводительном документе [RFC5645]. Критерии и процесс выбора обновленного набора записей описаны в этом документе. Обновленный набор записей не оказывает влияния на IANA, поскольку работа по его созданию будет выполняться внешне.

Дальнейшая работа над Реестром языковых вложенных тегов включает следующие действия:

• Вставка или замена целых записей. Эти записи предварительно отформатированы для IANA рецензентом языкового подтэга, как описано в разделе 3.3.
• Архивирование и обнародование регистрационных форм.
• Объявление каждой обновленной версии реестра в списке рассылки «ietf-languages-announcements@iana.org».

Каждая форма регистрации, отправленная в IANA, содержит одну запись для включения в реестр. Форма будет отправлена ​​<iana@iana.org> рецензентом языкового субтага. Он будет иметь строку темы, указывающую, представляет ли вложенная форма вставку новой записи (обозначается словом «ВСТАВКА» в строке темы) или замену существующей записи (обозначается словом «ИЗМЕНИТЬ» в строке темы). ). Ни при каких обстоятельствах запись не может быть удалена из реестра.

IANA извлечет запись из формы и поместит вставленную или измененную запись в соответствующий раздел Реестра языковых вложенных тегов, сгруппировав записи по их полю «Тип». Вставленные записи могут быть размещены в любом месте в соответствующем разделе; нет никакой гарантии, что записи реестра будут размещены в каком-либо конкретном порядке, за исключением того, что они всегда будут сгруппированы по типу. Измененные записи перезаписывают записи, которые они заменяют.

Всякий раз, когда запись создается или изменяется в реестре, запись «File-Date» в начале реестра обновляется, чтобы отразить самую последнюю дату изменения. Формат даты ДОЛЖЕН быть форматом полной даты [RFC3339]. Дата ДОЛЖНА быть датой, когда IANA впервые опубликовала эту версию реестра. В течение дня должна быть опубликована не более одной версии реестра. Запись «File-Date» также включается в каждый запрос IANA на добавление или изменение записей, указывая дату принятия записей в запросе.

Обновленный файл реестра ДОЛЖЕН использовать кодировку символов UTF-8, а IANA ДОЛЖНА проверить правильность кодирования файла реестра. Символы, не входящие в ASCII, можно отправить в IANA, прикрепив форму регистрации к сообщению электронной почты или используя различные кодировки в теле почтового сообщения (рекомендуется UTF-8). IANA проверит любые неясные или поврежденные символы с помощью рецензента языкового подтэга до публикации обновленного реестра.

IANA также будет архивировать и публиковать на сайте http://www.iana.org каждую регистрационную форму. Обратите внимание, что несколько регистраций могут относиться к одной и той же записи в реестре.

Разработчики, зависящие от Реестра языковых вложенных тегов, иногда хотели бы получать информацию об изменениях в реестре, чтобы они могли обновить свои реализации. При внесении каких-либо изменений в Реестр языковых вложенных тегов IANA отправляет сообщение с объявлением на <ietf-languages-announcements@iana.org> (список самоподписки, в который может публиковать только IANA).

5.2. Реестр расширений

Реестр расширений языковых тегов может содержать не более 35 записей, поэтому изменения в этом реестре, как ожидается, будут очень редкими.

Дальнейшая работа IANA в реестре расширений языковых тегов ограничена двумя случаями. Во-первых, IESG МОЖЕТ время от времени запрашивать новые записи в этом реестре. Эти запросы ДОЛЖНЫ включать запись для вставки в точном формате, описанном в разделе 3.7. Кроме того, МОЖЕТ быть случайный запрос от обслуживающего органа на конкретное расширение для обновления контактной информации или URL-адресов в записи. Эти запросы ДОЛЖНЫ включать полную обновленную запись. IANA не несет ответственности за проверку предоставленной информации, только за то, что она правильно отформатирована. IANA СЛЕДУЕТ принять разумные меры, чтобы удостовериться, что запрос исходит от обслуживающего органа, указанного в записи, представленной в реестре.

6. Вопросы безопасности

Языковые теги, используемые при согласовании контента, как и любая другая информация, которой обмениваются в Интернете, могут быть источником беспокойства, поскольку они могут использоваться для определения национальности отправителя и, таким образом, определения потенциальных целей для наблюдения.

Это частный случай общей проблемы, когда все отправленные сообщения видны принимающей стороне и, возможно, третьим сторонам. Полезно знать, что такие проблемы могут существовать в некоторых случаях.

Оценка точного масштаба угрозы и любых возможных контрмер оставлена ​​на усмотрение каждого протокола приложения (см. BCP 72 [RFC3552] для получения рекомендаций по передовой практике в отношении угроз и защиты).

Языковой тег, связанный с конкретным информационным элементом, не имеет никакого значения при определении того, может ли этот контент содержать возможные гомографии. Тот факт, что текст помечен как находящийся на одном языке или с использованием определенного подтега сценария, не дает никаких гарантий того, что он не содержит символов из сценариев, отличных от тех, которые связаны с этим языковым тегом или указаны в нем.

Поскольку не существует ограничений на число подтегов варианта, частного использования и расширения и, следовательно, нет ограничения на возможную длину тега, реализации должны быть защищены от атак переполнения буфера. См. Раздел 4.4 для получения подробной информации об усечении языковых тегов, которое может произойти вследствие защиты от переполнения буфера.

Чтобы предотвратить атаки типа «отказ в обслуживании», приложения НЕ ДОЛЖНЫ зависеть от того, что реестр языковых вложенных тегов или реестр расширений языковых тегов всегда доступны. Кроме того, хотя спецификация допустимых вложенных тегов для расширения (см. Раздел 3.7) ДОЛЖНА быть доступна через Интернет, реализации НЕ ДОЛЖНЫ механически зависеть от того, что эти источники всегда доступны.

Реестры, указанные в этом документе, не подходят для частого доступа или поиска в реальном времени полного содержимого реестра. Большинству приложений вообще не нужны данные реестра. Для других будет достаточно проверить или канонизировать языковые теги на определенную дату реестра, так как содержимое реестра изменяется только изредка. Изменения объявляются на <ietf-languages-announcements@iana.org>. Этот список рассылки предназначен для заинтересованных организаций и частных лиц, а не для массовой подписки для автоматического обновления программного обеспечения. Размер реестра делает его непригодным для автоматического обновления программного обеспечения. Разработчикам, которые рассматривают возможность интеграции реестра Language Subtag в схему автоматического обновления, настоятельно рекомендуется распространять только надлежащим образом закодированные различия и только через собственную инфраструктуру, а не напрямую из IANA.

Изменения или их отсутствие также можно легко обнаружить, просматривая запись «File-Date» в начале реестра или используя функции протокола, используемого для загрузки, без необходимости загрузки полного реестра. На момент публикации этого документа IANA делает доступным реестр языковых тегов через HTTP 1.1. Правильный способ обновить локальную копию реестра языковых вложенных тегов с использованием HTTP 1.1 — это использовать условный GET [RFC2616].

7. Особенности набора символов

Синтаксис в этом документе требует, чтобы языковые теги использовали только символы A-Z, a-z, 0-9 и HYPHEN-MINUS, которые присутствуют в большинстве наборов символов, поэтому у композиции языковых тегов не должно быть проблем с набором символов.

Рендеринг текста на основе языкового тега здесь не рассматривается. Исторически, некоторые процессы полагались на использование информации о наборе символов / кодировке (или другой внешней информации), чтобы сделать вывод, как должна отображаться конкретная строка символов. В частности, это относится к вариациям иероглифов Хань, характерным для языка и культуры, которые используются в японском, китайском и корейском языках, где использование, например, японской кодировки символов, такой как EUC-JP, подразумевает, что сам текст написан на японском языке. Когда языковые теги применяются к областям текста, движки рендеринга могут использовать эту информацию для лучшего выбора шрифтов или других вариантов рендеринга, особенно когда языки с разными традициями письма используют одни и те же символы.

8. Отличия от RFC 4646

Основная цель этого пересмотра RFC 4646 состояла в том, чтобы включить две новые части ISO 639 (ISO 639-3 и ISO 639-5) и сопровождающие их наборы языковых кодов в Реестр языковых подтэгов IANA. Это позволяет идентифицировать гораздо больше языков и языковых коллекций, чем ранее поддерживалось.

Конкретные изменения в этом документе для достижения этих целей:

o Определено включение кодов ISO 639-3 и ISO 639-5 для использования в качестве основных и расширенных языковых подтэгов. Он также постоянно резервирует и запрещает использование дополнительных «дополнительных тегов».

Изменения, необходимые для достижения этой цели:

* Изменены комментарии ABNF.

* Обновлены различные разделы требований к регистрации и стабильности для ссылки на ISO 639-3 и ISO 639-5 в дополнение к ISO 639-1 и ISO 639-2.

* Отредактировал текст, чтобы исключить ссылки на расширенные языковые подтэги, где они больше не используются.

* Объяснил изменение в разделе о расширенных языковых подтэгах.

o Изменены ABNF, связанные с дедушкиными метками. Нерегулярные теги теперь перечислены. Правильно сформированные теги «дедушкины» теперь описываются производством «langtag», и в результате производство «дедушкины» было удалено. Также: в раздел 2.2.8 добавлено описание обоих типов вышедших из употребления тегов.

o Добавлен параграф «Коллекции» в Раздел 4.1.

o Изменены правила использования заглавных букв для полей ‘Tag’ в разделе 3.1.

o Разделить Раздел 3.1 на подразделы.

o Изменен раздел 3.5, чтобы поля ‘Suppress-Script’ могли быть добавлены, изменены или удалены в процессе регистрации. Это была ошибка из RFC 4646.

o Измененные примеры, в которых вместо кода «RS» (Сербия) использовался код региона «CS» (ранее Сербия и Черногория).

o Изменены правила создания и ведения полей «Описание» записи для предотвращения дублирования, включая инвертированные дубликаты.

o Удалено длинное описание того, почему RFC 4646 был создан из этого раздела, что также привело к удалению ссылки на XML-схему.

o Изменен текст в Разделе 2.1, чтобы больше подчеркнуть тот факт, что языковые теги не чувствительны к регистру.

o Заменен пример «fr-Latn-CA» в разделе 2.1 на «sr-Latn-RS» и «az-Arab-IR», потому что «fr-Latn-CA» не относится к «Suppress-Script» on » Latn ‘с’ fr ‘.

o Изменены требования к правильности формы, чтобы сделать необязательную проверку повторения необязательной (это необходимо для проверки достоверности) в разделе 2.2.9.

o Изменен текст в Разделе 2.2.9, относящийся к проверке дедов, чтобы отметить, что список теперь включен в ABNF.

o Изменен и добавлен текст в раздел 3.2. Описание работы было размещено первым. Была добавлена ​​заметка, поясняющая, что рецензент языкового подтега может делегировать различные некритические обязанности, включая модерирование списка. Наконец, был добавлен дополнительный текст, чтобы прояснить процесс назначения и уточнить, что решения и результаты работы рецензента могут быть обжалованы.

o В раздел 3.5 добавлен текст, поясняющий, что список ietf-languages@iana.org управляется тем, кого назначает IESG.

o Добавлен текст в раздел 3.1.5, поясняющий, что первое описание в «языковой» записи соответствует соответствующему справочному названию для языка в ISO 639-3.

o Изменен раздел 2.2.9 для определения классов соответствия, связанных с конкретными тегами (ранее «правильно сформированные» и «действительные» относились к реализациям). Были добавлены примечания об удалении «extlang» из ABNF, представленной в RFC 4646, что позволяет обеспечить правильное формирование с использованием этого более старого определения. Ссылка на RFC 3066 также была добавлена.

o Добавлен текст в конце Раздела 3.1.2, в котором отмечается, что в будущих версиях этого документа могут добавляться новые типы полей в формат реестра, и рекомендуется, чтобы реализации игнорировали любые нераспознанные поля.

o Добавлен текст о том, что означает отсутствие поля ‘Suppress-Script’ в записи в Раздел 3.1.9.

o Добавлен текст, позволяющий исправлять опечатки и опечатки в разделе 3.1.5.

o Добавлен текст в раздел 3.1.8, запрещающий конфликты полей «Префикс» (например, ссылки на циклические префиксы).

o Измененный текст в Разделе 3.5, требующий, чтобы рецензент subtag объявлял о своем решении (или продлении) после двухнедельного периода. Также уточняется, что любое решение или решение не может быть обжаловано.

o Изменен текст в Разделе 4.1, чтобы включить (до сих пор анекдотичный) руководящий принцип выбора тега и разъяснить неиспользование подтегей сценария в неписаных приложениях.

o Запрещено многократное использование одного и того же варианта в теге (т. е. «де-1901-1901»). Раньше это была только рекомендация («СЛЕДУЕТ»).
o Удален неподходящий язык [RFC2119] из иллюстрации в Разделе 4.4.1.

o Заменен пример отказа от «zh-guoyu» на «zhhakka» -> «hak» в Разделе 4.5, отметив, что именно этот документ вызвал изменение.

o Заменен раздел в разделе 4.1, касающийся «mul» / «und», чтобы включить подтеги «zxx» и «mis», а также тег «i-default». Добавлена ​​нормативная ссылка на RFC 2277.

o В раздел 3.5 добавлен текст, поясняющий, что любые изменения в запросе на регистрацию должны быть отправлены в список ietf-languages@iana.org до подачи в IANA.

o Изменил ABNF для формата записи-jar с использования продукции LWSP на использование складывания пробелов, аналогично obs-FWS в [RFC5234]. Это эффективно предотвращает непреднамеренные пустые строки внутри поля.

o Уточненный и пересмотренный текст в разделах 3.3, 3.5 и 5.1, чтобы уточнить, что рецензент языкового подтега отправляет в IANA полные регистрационные формы, что IANA извлекает запись из формы и что формы также должны архивироваться отдельно от реестра.

o В раздел 5 добавлен текст, требующий от IANA отправлять объявление в список объявлений ietf-languages-каждый раз, когда обновляется реестр.

o Модификация реестра для использования UTF-8 в качестве кодировки символов. Это также влечет за собой дополнительные инструкции для IANA и рецензента языкового подтэга в процессе регистрации.

o Изменены правила в Разделе 2.2.4, чтобы «исключительно зарезервированные» коды ISO 3166-1, кроме «UK», были включены в реестр. В частности, это позволяет использовать код «EU» (Европейский союз) для формирования языковых тегов или (чаще) для приложений, которые используют реестр для кодов регионов для ссылки на этот подтег.

o Изменен раздел соображений IANA (раздел 5), чтобы удалить ненужный нормативный язык [RFC2119].

9. Ссылки

9.1. Нормативные ссылки

[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.

9.2. Информационные ссылки

[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», RFC 5645, 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>.

Приложение А. Примеры языковых тегов (информативный)

Простой языковой подтэг:

de (German)
fr (French)
ja (Japanese)
i-enochian (пример дедушкиной метки)

Языковой вложенный тег плюс сценарий:

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)

Расширенные языковые подтэги и их основные языковые подтэги:

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)

Подтеги личного пользования:

de-CH-x-phonebk
az-Arab-x-AZE-derbend

Значения реестра для частного использования:

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)

Теги, которые используют расширения (ТОЛЬКО примеры. Расширения ДОЛЖНЫ быть определены путем пересмотра или обновления этого документа или RFC):

en-US-u-islamcal
zh-CN-a-myext-x-private
en-a-myext-b-another

Некоторые недействительные теги:

de-419-DE (два тега региона)
a-DE (использование односимвольного подтэга в основной позиции; обратите внимание, что есть несколько выделенных тегов, которые начинаются с «i-» и являются действительными)
ar-a-aaa-b-bbb-a-ccc (два расширения с одинаковым однобуквенным префиксом)

Приложение B. Примеры регистрационных форм

РЕГИСТРАЦИОННАЯ ФОРМА ЯЗЫКА ПОДТЕГОВ

1. Имя запрашивающей стороны: Хан Стинвейк
2. Адрес электронной почты запрашивающего: han.steenwijk @ unipd.it
3. Запрошенная запись:

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. Предполагаемое значение подтэга:

Местное разнообразие Resian, как говорят в Сан-Джорджо / Била

5. Ссылка на опубликованное описание языка (книга или статья):

— Ян И.Н. Baudouin de Courtenay — Опыт фонетики режиссеров, Варшава — Петербург: Ванде — Козанчиков, 1875.

РЕГИСТРАЦИОННАЯ ФОРМА ЯЗЫКА ПОДТЕГОВ

1. Имя запрашивающей стороны: Яска Зедлик
2. Адрес электронной почты заявителя: jz53 @ zedlik.com
3. Запрошенная запись:

Тип: вариант
Subtag: Тарас
Описание: Белорусская в Тараскивице орфография
Префикс: быть
Комментарии: Подтег представляет белорусскую орфографию Бранислау Тараскиевича, опубликованную в «Bielaruski klasycny pravapis» Юрасом Буслакоу, Винчуком Вякоркой, Змисьером Санько и Змисьером Саукой (Вильня-Миенск, 2005).

4. Предполагаемое значение подтэга:

Подтег предназначен для представления белорусской орфографии, опубликованной в «Bielaruski klasycny pravapis» Юрасом Буслакоу, Винчуком Вякоркой, Змисьером Санько и Змисьером Саукой (Вильня-Миенск, 2005).

5. Ссылка на опубликованное описание языка (книга или статья):

Тараскиевич, Бранислав. Белярусская граматика для скол. Вильня: Выд. «Беляруска камитету», 1929, 5-е издание.
Буслаку, Юрас; Вьякорка, Винчук; Санько Змисьер; Sauka, Zmicier.
Белярусский класический правопис. Вильня-Миенск, 2005.

6. Любая другая соответствующая информация:

Белорусская в Тараскивице широко использовалась орфография, особенно в белорусскоязычном интернет-сегменте, но помимо этого некоторые книги и газеты также печатаются с использованием этой белорусской орфографии.

Приложение C. Благодарности

Любой список участников обязательно будет неполным; пожалуйста, рассмотрите следующее как выбор из группы людей, которые внесли свой вклад, чтобы сделать этот документ тем, чем он является сегодня.

Авторы RFC 4646, RFC 4647, RFC 3066 и RFC 1766, предшественники этого документа, внесли огромный вклад прямо или косвенно в этот документ и в целом несут ответственность за успех языковых тегов.

Следующие люди внесли свой вклад в этот документ:

Стефан Борцмейер, Карен Брум, Питер Констебл, Джон Коуэн, Мартин Дюерст, Фрэнк Эллерман, Даг Юэлл, Дебора Гарсайд, Марион Ганн, Альфред Хоэнс, Кент Карлссон, Крис Ньюман, Рэнди Пресун, Стивен Сильвер, Шон Стил и многие другие.

Особая благодарность следует выразить Харальду Твайту Альвестранду, который создал RFC 1766 и 3066 и без которого этот документ был бы невозможен.

Особая благодарность выражается Майклу Эверсону, который работал рецензентом языковых тегов почти весь период RFC 1766 / RFC 3066, а также рецензенту языкового субтага с момента принятия RFC 4646.

Особая благодарность также выражается Дагу Юэллу за его создание первого полного реестра subtag, его работу по поддержке и ведению новых регистраций, а также за его тщательную редакцию RFC 4645 и [RFC5645].

Адрес автора

Addison Phillips (editor)
Lab126
EMail: addison@inter-locale.com
URI: http://www.inter-locale.com

Mark Davis (editor)
Google
EMail: markdavis@google.com