Ускоряющая клавиша n предназначена для пропусков при навигации по страницам. Пропуск для перехода на начало контента.

Данный документ является переводом. В случае каких-либо несоответствий и ошибок последняя версия документа на английском языке должна рассматриваться в качестве официальной. Первоначальное авторское право принадлежит W3C, как то указано ниже.

Переводчик: Alexandr Shlapak

s_gotoW3cHome Internationalization
 

Понимание Новых Language Тэгов

Предполагаемая аудитория: пользователи, шифровальщики XHTML/HTML (используя редакторы или скрипты), разработчики скриптов (PHP, JSP, и т.д.), шифровальщики CSS, разработчики схем (DTDs, XML Schema, RelaxNG, и т.д.), разработчики XSLT, менеджеры Веб проектов, и каждый кто, вероятно, будет использовать language тэги.

Редакционная заметка: Статья содержит информацию с точки зрения исторической перспективы, поскольку предложенный новый подход, она ссылается на опубликованные RFC 4646 и RFC 4647 (вместе известные как BCP 47) в Сентябре 2006. Последнюю актуальную информацию о том, как построить language тэги можно найти в статье Language тэги в HTML и XML.

Так как начинают появляться новые language тэги и программное обеспечение основанные на RFC 3066bis, соредактор RFC3066bis Addison Phillips вместе с Mark Davis, рассмотрели как новый стандарт изменяет language тэги, и что еще осталось сделать.

Введение

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

Также language тэги могут использоваться для определения аудитории для документа или в механизме language negotiation (согласования языка) для выбора контента который будет отображаться. Приложения, основанные на Сети часто используют language тэги для вывода локали, которую пользователь предпочитает (влияют на числовой формат или формат даты например, на Веб сайте).

Стандарт для language тэгов в Интернете, который включает Веб технологии, электронную почту, заголовки протокола, HTML, XML, IMAP, LDAP, RDF, RSS, и попурри из других сокращений, называется "BCP 47".

В Ноябре 2005 года IETF (Специальная Комиссия Интернет Разработок), составляющая основу стандарта, который определяет эти тэги, утвердила ряд документов для обновления BCP 47, внесла изменения в структуру language тэгов и их использование. Никогда не слышали о BCP 47? Возможно, вы слышали о RFC 1766 (который был основой BCP 47) или его преемник, RFC 3066, который еще был BCP 47 до этого прошлого Ноября. Это были документы, определяющие использование кодов ISO 639 и ISO 3166 для формирования таких language тэгов "fr", "en-US", "de-CH", или "ja", так как реестр для других, более специализированных, тэгов.

BCP обозначает Лучшую Нынешнюю Практику. RFC обозначает Запросы для Комментариев. RFCs являются стабильными и официальными спецификациями IETF , перенесенным на прошлом этапе Интернет Проектом.

Обзор нового подхода

RFC 3066bis накладывает дополнительные ограничения на формат language тэга, то есть, language тэги не могут так широко изменяться в RFC 3066bis так, как они могли это делать в предшественнике. Поскольку только несколько тэгов, были действительно зарегистрированы, то это не накладывает новый груз на пользователей или программное обеспечение. Любой тэг, который был действителен в RFC 3066 по-прежнему действителен в RFC 3066bis тэге. Это, как правило, правильный тэг, так как пользователи на сегодняшний день, как правило, не захотят выбрать другой тэг вместо вчерашнего RFC 3066 тэга.

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

Language тэги до сих пор состоят из последовательности "subtags",которые разделены дефисами. Subtag может содержать от одного до восьми символов и ограничен буквами ASCII и номерами (то есть, a-z, A-Z, и 0-9). Заглавные и строчные буквы не различаются, поэтому тэг "EN" считается тем же самым, что и "en" или "eN".

RFC 3066bis определяет каждый тип subtag согласно его позиции и размеру в тэге. Полный синтаксис для этих тэгов показано здесь:

Language-Tag состоит с:
                   langtag                ; сгенерированный тэг
              -or- private-use            ; тэг частного использования
              -or- grandfathered          ; одобренные регистрации

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

language      = "en", "ale", или зарегистрированное значение

script        = "Latn", "Cyrl", "Hant" ISO 15924 коды

region        = "US", "CS", "FR" ISO 3166 коды
                "419", "019",  или UN M.49 коды

variant       = "rozaj", "nedis", "1996", multiple subtags могут использоваться в тэге

extension     = одна буква за которой следуют дополнительные subtags; более одного расширения
                могут использоваться в language тэге

private-use   = "x-" за которым следуют дополнительные subtags, столько сколько нужно
                Обратите внимание, что они могут располагаться в начале тэга или появляться в конце (но не
                в середине)

grandfathered = тэги перечисленные в старом реестре, которые не являются redundant (избыточными) (закрытый список)

Как отмечалось выше, любой допустимый RFC 3066 language тэг справедлив и по новой схеме. Большая часть тэгов в настоящее время состоят из последовательности subtags используя генеративный синтаксис.

Некоторыми исключениями являются "grandfathered" (одобренные) тэги: это тэги зарегистрированные в RFC 3066, которые не вписываются в синтаксис (или устарели до их принятия). Любой существующий контент или программное обеспечение, таким образом, продолжают использовать эти тэги. Их есть 34, из которых восемь являются устаревшими и десять станут устаревшими в ближайшем будущем. Четыре одобренные тэги подходят для RFC 3066bis образца, но они изначально не были сделаны избыточными.

Большое отличие от RFC 3066bis в том, что за исключением нескольких одобренных заявок, все тэги теперь генеративные. Так как списки ISO кодов не всегда были свободными и потому, что они меняются со временем, ключевой идеей было создать постоянный, стабильный реестр всех subtags доступных в language тэге. Это означает, что вместо пяти отдельных списков кодов, есть одна таблица, содержащая значения, расположенные в одном месте. IANA Language Subtag Реестр как и раньше следит за стандартами ISO, за исключением того, что subtags никогда не отзывались и есть четкие правила, имеющие дело с противоречивыми задачами, если они возникают.

Каждый тип subtag имеет уникальную длину и ограничения контента. Тэг всегда начинается с language subtag - или одного из ISO 639 кодов или зарегистрированного значения. Затем, по желанию, за ним могут следовать разные subtags. Сейчас есть пять видов subtags которые следуют за идентификатором языка: скриптовые, региональные, вариантные, расширение, и частного использования. Порядок, длина и контент каждого типа subtag фиксированная, так тэговый процессор может всегда точно определить который он имеет тип subtag, даже если процессор не имеет того subtag в его копии реестра (или вообще не имеет копии реестра!)

Script (Скриптовый).Скриптовые subtags нам уже встречались. Они основанные на ISO 15924 и указывают письменность. Скриптовый subtag может встречаться не чаще одного раза (его можно пропустить) и должен появиться сразу после language. Некоторые языки имеют поле в реестре, которое указывает, что особый скриптовый код нужно "suppressed" (запретить). Например, "zh-Hant" и "zh-Hans" отражает Китайский письменный язык соответственно на Традиционному и Упрощенном скриптах, в то время как language subtag "en" в реестре имеет поле "Suppress-Script" (Запретить Скрипт) указывает что большинство Английских текстов написанные на Латинском скрипте, подавляя такой тэг, как "en-Latn-US".

Region (Региональный). Региональные subtags мы также встречали: они основанные преимущественно на коде ISO 3166-1 и указывают государственные или региональные различия. Региональный код может также включать выбранные UN M.49 региональные коды. UN M.49 коды охватывают большие территории земли или обеспечивают, чтобы конфликтные решения ISO 3166 перепризначалы код уже в реестре. На самом деле, ISO 3166 зависит от UN M.49 чтобы определить, что является или не является "страной" или регионом согласно коду. Региональный код может встречаться не более одного раза (его можно пропустить) и он должен следовать за любыми языковыми и скриптовыми кодами. Например, тэг "es-419" представляет "Испанский, который используется в Латинской Америке и Карибах" в то время как "es-CO" представляет "Испанский, который используется в Колумбии".

Variants (Вариантные). Вариантные subtags не основанные на внешнем стандарте. Они все являются индивидуально зарегистрированными значениями, главным образом указывает особые диалекты или другие варианты языка, на которые не распространяются скрипты или регионы. Multiple variant (многовариантные) subtags могут включаться в тэг. Каждый вариант имеет поля в реестре хотя и указывает, какие subtags назначены для использования. Например, "nedis" subtag имеет префикс "sl" (Словенский) поскольку он отображает диалект Словенского языка. Вариантные не должны использоваться вместе, если только один из вариантов содержит другой в своем "prefix" (префиксе). Например, Тэг "sl-IT-nedis" определяет Nadiza - диалект Словенского, который используется в Италии.

Extensions (Расширения). Расширение - механизм, с помощью которого могут быть стандартизированы будущие дополнения к language тэгам. Каждое расширение имеет односимвольный subtag ("singleton" (одиночка)), что его определяет. Различные ограничения применяют к расширениям, и как они формируются, используются, и управляются. Расширения формируют основу для будущего добавления функций к language тэгам.

Private use (Частного использования). Subtags частного использования вообще не основанные на любом стандарте. Они предназначены для использования отдельными лицами или группами, которые должны распознавать то, что касается языка, и что не может подняться до уровня стандартизации. RFC 3066 включал тэги частного использования, но и весь тэг был частного использования (конечно, это по-прежнему справедливо). Сейчас генеративные subtags и subtags частного использования могут использоваться вместе. Однобуквенный subtag "x" определяет, где начинаются subtags частного использования. Например en-US-x-twain может определить произведение, которое написано Марком Твеном среди работ двух коллег, изучающих Американскую литературу. Одним из преимуществ этой возможности смешивать два subtags является то, что поставщики, которые распространяют language тэги из собственных причин в будущем могут так сделать тогда, и при этом сохранят максимальное взаимодействие между их системой и другими системами.

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

Тэг Форма Значение
en language Английский
de-AT language-region Немецкий, используемый в Австрии
es-419 language-region (UN M.49) Испанский, который используется в Центральной и Южной Америке
de-CH-1901 language-region-variant Немецкий, используемый в Швейцарии, орфография 1901
sr-Cyrl language-script Сербский, который написан на Кириллице
sr-Cyrl-CS language-script-region Сербский, который написан на Кириллице, что используется в Сербии и Черногории
sl-Latn-IT-rozaj language-script-region-variant Словенский, написанный на Латыни, используемый в Италии, Резьянський диалект

Большой спор скриптов

Критической точкой дебатов в ходе разработки новых language тэгов было размещение скриптового subtag после language subtag, но перед региональным subtag. Ничто в RFC 1766 или RFC 3066 не гарантирует то, что региональный subtag появиться на второй позиции и, прежде в 2003, когда появились первые попытки, не существовало ни одного зарегистрированного тэга, который позволил бы уточнить, было ли это правомерно предположить, что региональный код, если бы он существовал, всегда появлялся вторым (было абсолютно ясно, что другое значение, такое как скрипт, может появиться вторым).

Некоторые люди считают, что размещение скриптов на второй позиции приносит некоторые проблемы. В частности, некоторые опасались, что скриптовый subtag будет мешать обычному выбора языка или механизмам согласования языка. Эти механизмы, такие же, как описаны в RFC 2616 (HTTP 1.1) использовать префикс, который называется "language range" (речевой диапазон) указанный пользователем для того, чтобы выбрать контент.

Эта форма согласования предполагает, что предпочтения пользователя "отвечает" части контента, если language тэг пользователя является префиксом для этого контента. Этот механизм отбора основывается на предположении, что языки, которые разделяют префикс, как правило, "взаимно понятны". (Заметим, что это предположение часто является ошибочным.) Вот несколько примеров согласования префикса:

Языковой Диапазон ... подходит ... не подходит
de de, de-CH, de-AT, de-DE, de-1901, de-AT-1901 en, fr-CH
de-CH de-CH, de-CH-1901, de-CH-1996 de, de-DE, de-1901, de-AT, etc.
zh-TW zh-TW zh-Hant-TW, zh-Hans-TW
zh-Hant zh-Hant, zh-Hant-TW, zh-Hant-HK zh, zh-Hans, zh-TW

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

С другой стороны, скрипт, как правило, более тесно связан с языком, чем региональные вариации. Указание префикса производит более разумные результаты, когда скриптовый subtag расположен к language subtag ближе чем региональный. Для того чтобы работать, пользователи которые нуждаются в скриптовых subtags должны использовать (или отменить) их последовательным образом, как в их запросах так и в контенте.

Другой проблемой была двусмысленность RFC 3066 относительно генеративного синтаксиса. Идею "language-dash-region" (речь-тире-регион) language тэгов было достаточно легко понять; Большинство пользователей непосредственно не читали RFC 3066 или рассмотрели неустановленный но реализованный вывод, что другие subtags иногда могут встречаться на второй позиции.

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

В дополнение к самим subtags, новый subtag реестр содержит информацию, чтобы помочь пользователям выбрать лучшую комбинацию, чтобы определять обычный язык. Решающим для принятия позиции скриптового subtag стало включение информации к реестру, чтобы ясно дать понять необходимость избегать скриптовых subtags за исключением случаев, когда они добавляют полезную для распознания информацию. Таким образом, запись в реестре для language subtag "en" (Английский) имеет поле, которое называется "Suppress-Script" (Запретить Скрипт) указывает, что скриптового subtag "Latn" следует избегать из тем языком, так как практически все Английские документы используют Латинский скрипт.

Отметим, что это не означает, что "en-Latn" тэги никогда не будут использоваться. Есть случаи, когда скрипт будет предоставлять информацию, которая различает контент. Например, в документе, который содержит как Латинский скрипт так и шрифт Брайля, возможно, необходимо различать две формы. Однако это исключительные случаи и исключение в тех случаях будет разумным (и даже очевидным).

В каждом случае, практически для любого контента что сегодня не использует скриптовый subtag, будет лучше не использовать его и в будущем. Языки которые не используют более одного скрипта или испытывают переход скрипта - например, перечисленные выше - могут и должны извлечь выгоду из определения контента используя скриптовые subtags. Чуть больше года с его регистрации, быстрый поиск в поисковике показывает более 8000 страниц на Упрощенном Китайском отмечая только тэг "zh-Hans". Генеративный синтаксис во многом поможет при использовании и принятии скриптовых subtags для языков, которые в них нуждаются.

IANA Language Subtag Реестр

Новый IANA Language Subtag Реестр содержит информацию о каждом subtag который действителен для использования в language тэге. Реестр - текстовый файл в специальном формате, который читают машины, что называется "record-jar". Каждый subtag имеет свою ​​собственную запись, состоящую из нескольких строк текста, которые определяют subtags, их использование, и некоторую полезную при выборе информацию, которые subtags правильные для конкретных обстоятельств.

Вот некоторые примеры некоторых записей "language" subtag:

   %%
   Type: language
   Subtag: cs
   Description: Czech
   Added: 2005-10-16
   Suppress-Script: Latn
   %%
   Type: language
   Subtag: cu
   Description: Church Slavic
   Description: Old Slavonic
   Description: Church Slavonic
   Description: Old Bulgarian
   Description: Old Church Slavonic
   Added: 2005-10-16
   %%
   Type: language
   Subtag: cv
   Description: Chuvash
   Added: 2005-10-16
   %%

Каждая запись содержит сам subtag, его тип (в данном случае "language"), описание (или набор описаний), и дату, когда запись добавили к реестру. Как показано выше: все исходные записи имеют дату "2005-10-16".

Иногда доступна дополнительная информация. Например, выше, в записи для Чешского языка (cs) вы заметите, так называемое поле "Suppress-Script" (Запретить Скрипт). Это поле указывает, что большинство текстов на Чешском написаны на Латинском скрипте и то, что скриптовый код "Latn" не подходит для большинства language тэгов, определяющих контент на Чешском языке. То есть, тэг подобен "cs-CZ" рекомендуется, в то время как такой тэг, как "cs-Latn-CZ" настоятельно не рекомендуется.

Другие поля, которые могут появиться включают поле "Deprecated" (устаревший), которое показывает дату, когда конкретный код устарел. Оно почти всегда появляются с другим полем, так называемым "Preferred-Value" (значение, которым отдают предпочтение), что указывает более подходящий subtag для использования для того значения. Например, код "TP" устарел после появления ISO 3166, когда в 2002 их страна изменила свою администрацию и название:

   %%
   Type: region
   Subtag: TP
   Description: East Timor
   Added: 2005-10-16
   Preferred-Value: TL
   Deprecated: 2002-11-15
   %%

Регистрационный процесс может до сих пор использоваться, чтобы добавить информацию или обновить информацию о специфических записях, так же, как добавлять полностью новые subtags. Записи нельзя удалить и есть правила, чтобы предотвратить "mutated" (мутации) значений subtag в нечто совершенно другое.

Сам файл содержит запись "File-Date", что показывает когда последний раз был обновлен реестр. В сочетании с различными полями даты в самих записях, возможно проверить любой конкретный тэг или его subtags для любой заданной даты, в прошлом или сейчас.

Современное состояние и работа, что еще осталась

Сучасний стан

RFC 3066bis на самом деле состоит из трех частей. Первая - документ описывающий синтаксис language тэгов и реестр, так же, как поддерживаются language тэги и т.д. Этот документ является Интернет Проектом, который называется "draft-ietf-ltru-registry-14" и содержит около 62 страниц. Тогда есть начальный контент IANA Language Subtag Реестра, который, содержится в Интернет Проекте , что называется "draft-ietf-ltru-initial-05". Этот документ был отредактирован и поддерживается Doug Ewell.

IANA Language Subtag Реестр в настоящее время запущен и работает, и даже получал регистрации.

Последняя часть головоломки - Интернет Проект о соответствии language тэгов. Этот документ работал в то время, когда это было написано и его нынешнее название - "draft-ietf-ltru-matching-12".

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

Согласование

Сопоставление, как отмечалось ранее, достаточно хорошо понято в его самой простой форме - "prefix matching" (согласование префикса), которая описана выше в разделе о скриптах. Однако, есть некоторые интригующие, применения RFC 3066bis тэгов стиля для согласования, так же, как некоторых известных схем согласования, которые не были хорошо задокументированы в RFC 3066. На момент написания, эта работа ожидает завершения процесса Последнего Вызова.

ISO 639-3 и Макро Языки

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

Заметной проблемой является выявление вариаций языка или вариаций в пределах семьи языков. Пока вариантные или региональные subtags часто используются для этой цели, до тех пор некоторые языки будут долго жить: стабильные, хорошо описанные изменения, которые не особенно хорошо описываются национальными границами. В дополнение, ISO 639 имеет случайно назначенные коды для "macro-languages​​" (макро языков), которые являются языковыми семействами, содержащими ряд узнаваемо связанных (но не обязательно взаимно понятных) языков.

Прекрасным примером является еще раз Китайский. ISO 639-1 код 'zh' определяет "Китайский", но концепция Китайского язхыка охватывает ряд разных языков или диалектов, которые разделяют некоторые черты. Хотя эти языки написаны очень похоже (изготовление таких тэгов, как "zh-Hant" и "zh-Hans" является полезным), разговорный контент действительно сильно отличается. И, снова, доступные региональные опции являются плохими поручениями для разговорных диалектов (много из которых ограничены материковым Китаем).

RFC 3066bis обеспечивает часть решения этой головоломки, зарезервировав место для еще одного вида специализированного subtag, так называемый "Extended language subtag" (расширенный). Это трехбуквенные коды которые следуют за primary (основным) language subtag, но встречаются перед скриптовым subtag. Есть очень четкие правила для того, когда может использоваться один из этих subtags (они должны использоваться только с указанным prefix (префиксом)), и ожидается, что очень маленькая переработка в RFC 3066bis будет проходить в mid-2006, чтобы сделать их доступными.

Можно было бы спросить: "Если требования к этим кодам существуют уже сейчас, и мы их знаем, то почему бы эти коды не включить в RFC 3066bis?" Причина задержки в том, что основой для определения расширенных language subtags, как ожидается, будет ISO 639-3. Подобно как ISO 639-2 есть подмножеством ISO 639-1, ISO 639-3 определяет еще больший набор языковых кодов, изначально основанных на кодах в SIL Ethnologue (SIL, в действительности, является "Регистрационным Органом" в ISO 639-3, то есть, люди, которые будут поддерживать список кодов в будущем). ISO 639-3 также определяет, какие языки закрытые которыми Макро Языками. Таким образом Мандаринский язык (разговорный вариант) будет определен ISO 639-3 кодом 'cmn' и правила будут требовать тот код, когда он используется как subtag, чтобы всегда появляться со своим Макроязыком "zh" (Китайский). Это, наконец, сделает возможным отметить Китайский контент точно во всех измерениях:

Тэг Значение
zh-cmn Мандаринский язык
zh-cmn-Hant Мандаринский язык, написанный на Традиционному скрипте
zh-cmn-Hans Мандаринский язык, Упрощенный скрипт
zh-cmn-Hant-HK Мандаринский язык, Традиционный скрипт, используемый в Гонконге SAR (Особом административном районе)
zh-cmn-Hans-CN Мандаринский язык, Упрощенный скрипт, используемый в Китае
zh-gan Ган Китайский
zh-hak Хакка Китайский
zh-yue Юэ Китайский (Кантонский)
zh-hsn Сян Китайский
zh-yue-Hant-HK Кантонский, Традиционный скрипт, Гонконгский SAR (Особый административный район)

Есть около сорока различных языков, отличающихся от Китайского, которые определены как Макро Языки в прототипе ISO 639-3. Большая часть из них являются языками меньшинств и не исключено, что способность точно определить эти языковые изменения в контенте может повлиять на их хранение среди существующих языков.

В любом случае, расширенные language subtags уже полностью определены и просто ждут ISO 639-3 чтобы, наконец, стать официальными и завершенными до включения в список language subtags. Обратите внимание, что исполнителям просто необходимо обновить свою копию, когда добавлен ISO 639-3, до тех пор, пока они придерживаются требований уже в RFC 3066bis.

Вывод

Новая версия BCP 47 позволяет точно обозначить или сделать запрос контента используя стабильные, четко определенные тэги. Эти тэги направляют ряд давних проблем с определением языка, и мы надеемся что доводят их к расширенным функциям в нашем программном обеспечении, которые относятся к языку и улучшают поддержку языка в наших документах. Понимание этих тэгов и их формата поможет пользователям принять их и использовать их разумно и последовательно.

Выскажите своё мнение (по-английски).

Подпишитесь на ленту новостей RSS.

Новые публикации

Новости главной страницы

Twitter (Новости главной страницы)

‎@webi18n

Дополнительные материалы

Автор: Addison P. Phillips, Yahoo! Inc.. Переводчик: Alexandr Shlapak.

Допустимый XHTML 1.0!
Допустимый CSS!
Кодировка UTF-8!

Перевод с английского: 2006-05-15. Последнее внесение изменений в перевод: 2011-07-31 12:00 GMT

Для просмотра истории внесения изменений нажмите article-bcp47 в блоге i18n.