Содержание
В этом разделе обсуждаются два важных вопроса, которые влияют на интернационализацию HTML: спецификация языка (атрибут lang) и направление (атрибут dir) текста в документе.
Информация о языке, определённая
атрибутом lang,
может быть использована Пользовательским
Агентом (ПА) для управления представлением
различными путями.
Вот некоторые ситуации, где
предоставленная автором информация о языке
может быть полезной:
Атрибут lang определяет язык содержимого элемента и значений атрибутов. Относится ли это к соответствующему атрибуту, зависит от синтаксиса и семантики атрибута и выполняемой операции.
Цель атрибута lang - создать ПА условия для более понятного представления содержимого на базе принятой для данного языка культурной практики. Это не означает, что ПА должны отображать нетипичные для конкретного языка символы менее осмысленным способом. ПА обязаны действовать наилучшим образом для отображения всех символов независимо от значений атрибута lang.
Например, если символы греческого алфавита появляются в окружении английского текста:
<P><Q lang="en">Her super-powers were the result of γ-radiation,</Q> he explained.</P>
ПА должен
(1) попытаться представить
английское содержимое соответствующим
образом (например, при обработке знаков
кавычек) и
(2) обязан попытаться представить
символ γ наилучшим образом, несмотря на
то, что этот символ не является английской
буквой.
См. дополнительную информацию в разделе неотображаемые символы.
Значением атрибута lang является код языка, идентифицирующий язык, используемый людьми для разговора, письма и других видов общения. Компьютерные языки исключены из кодов языка.
[RFC1766] определяет и разъясняет коды языка, которые должны использоваться в документах HTML.
Если говорить кратко, коды языка состоят из первичного кода и, возможно пустых, серий субкодов:
language-code = primary-code ( "-" subcode )*
Вот примеры кодов некоторых языков:
Двухсимвольные первичные коды
зарезервированы для аббревиатур [ISO639].
Двухсимвольные коды включают fr (французский), de (немецкий), it (итальянский),
nl (фламандский), el (греческий), es (испанский), pt (португальский), ar (арабский), he
(еврейский), ru (русский), zh (китайский), ja (японский), hi (хинди), ur (урду)
и sa (санскрит).
Любые двухбуквенный субкод понимается как код страны в [ISO3166].
Элемент наследует информацию кода языка в следующем порядке (приоритет от высшего к низшему):
Content-Language: en-cockney
В этом примере основной язык документа - французский ("fr"). Один параграф объявлен как испанский ("es"), после которого возвращается основной язык (французский). Следующий параграф содержит фразу на внедрённом японском ("ja"), после чего возвращается основной язык (французский).
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML lang="fr"> <HEAD> <TITLE>Un document multilingue</TITLE> </HEAD> <BODY> ...интерпретируется как французский... <P lang="es">...интерпретируется как испанский... <P>...снова интерпретируется как французский... <P>...французский текст прерывается японским... <EM lang="ja">что-нибудь на японском</EM>здесь снова продолжается французский... </BODY> </HTML>
В контексте HTML код языка должен интерпретироваться ПА как иерархия понятий, а не отдельное понятие. Когда ПА уточняет отображение, используя информацию о языке (путём сравнения кодов языка таблиц стилей и значений атрибута lang), он всегда должен находить точное совпадение, но должен также учитывать совпадение основных кодов. Таким образом, если значение атрибута lang "en-US" установлено для элемента HTML, ПА должен сначала отдать предпочтение информации, совпадающей с "en-US", а уже затем - с более общим значением "en".
Примечание. Иерархии кодов языка не гарантируют, что все языки с обычным префиксом будут свободно пониматься, но они (иерархии) позволяют пользователю запрашивать эту сообщность, если для пользователя это является верным.
Определение атрибута
В дополнение к спецификации языка документа с помощью атрибута lang, авторам может понадобиться определить базовое направление (слева-направо или справа-налево) части текста документа, структуры таблицы и т.д. Это устанавливается в атрибуте dir.
Спецификация [UNICODE] назначает направление символам и определяет (сложный) алгоритм для определения соответствующего направления текста. Если документ не содержит отображаемых справа-налево символов, то от соответствующего ПА не требуется применять двунаправленный алгоритм [UNICODE]. Если документ содержит отображаемые справа-налево символы и если ПА отображает эти символы, ПА обязан использовать двунаправленный алгоритм.
Хотя Unicode специфицирует символы с направлением текста, HTML предлагает высокоуровневые конструкции разметки, которые делают то же самое: атрибут dir (не путайте с элементом DIR) и элемент BDO. Таким образом, для отображения еврейских кавычек более интуитивно понятно будет записать:
<Q lang="he" dir="rtl">...еврейские кавычки...</Q>
чем то же самое в мнемониках Unicode:
‫״...еврейские кавычки...״‬
ПА не должны использовать атрибут lang для определения направления текста.
Атрибут dir наследуется и может быть переопределён. См. детали в разделе информация о наследовании направления текста.
Следующий пример иллюстрирует ожидаемое поведение двунаправленного алгоритма. Он включает английский, скрипт слева-направо, и еврейский языки, скрипт справа-налево:
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
Символы в этом примере (и во всех подобных) хранятся на компьютере таким образом: первый символ в файле - "e", второй - "n" и последний - "6".
Предположим, преобладающий язык документа, содержащего этот параграф, английский. Это означает, что базовое направление - слева-направо. Корректное представление этого:
english1 2WERBEH english3 4WERBEH english5 6WERBEH
<------ <------ <------
H H H
------------------------------------------------->
E
Линии обозначают структуру предложения: английский - основной, а еврейский - внедрён. Достичь корректного представления можно без дополнительной разметки, поскольку еврейские фрагменты корректно повёрнуты ПА с применением двунаправленного алгоритма.
Если наоборот, преобладающий язык документа - еврейский, то базовое направление - справа-налево. Тогда корректное представление:
6WERBEH english5 4WERBEH english3 2WERBEH english1
-------> -------> ------->
E E E
<-------------------------------------------------
H
В этом случае, всё предложение представлено как текст справа-налево, и внедрённая последовательность символов на английском соответствующим образом повёрнута с помощью двунаправленного алгоритма.
Двунаправленный алгоритм Unicode требует наличия базового направления для текстовых блоков. Чтобы определить базовое направление элементов на уровне блока, установите атрибут dir в элементе. Значение атрибута dir по умолчанию - "ltr" (left-to-right/слева-направо).
Если атрибут dir установлен для элементов уровня блока, он действует на период существования самого элемента и всех вложенных элементов уровня блока. Установка атрибута dir во вложенном элементе переопределяет наследованное значение.
Чтобы установить базовое направление текста для всего документа, установите атрибут dir элемента HTML.
Например:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML dir="RTL"> <HEAD> <TITLE>...заглавие справа-налево...</TITLE> </HEAD> ...текст справа-налево... <P dir="ltr">...текст слева-направо...</P> <P>...снова текст справа-налево...</P> </HTML>
В то же время, инлайн-элементы не наследуют атрибут dir. Это значит, что инлайн-элемент без атрибута dir не открывает дополнительный уровень в установке двунаправленного алгоритма. (Элемент рассматривается здесь как уровня инлайн или блока на основе его представления по умолчанию. Обратите внимание, что элементы INS и DEL могут быть уровня блока или инлайн в зависимости от контекста.)
Двунаправленный алгоритм [UNICODE] автоматически поворачивает внедрённые последовательности символов в соответствии с их унаследованным направлением (как показано в предыдущих примерах). Однако в целом только один уровень внедрения может быть просчитан. Чтобы установить дополнительные уровни внедрённых изменений направления, придётся использовать атрибут dir в инлайн-элементах.
Рассмотрим тот же текст, что и ранее:
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
Предположим, преобладающим языком документа, содержащего этот параграф, является английский. С другой стороны, это предложение на английском содержит раздел на еврейском от HEBREW2 до HEBREW4, и раздел на еврейском содержит в себе английский (english3). Нужное представление предложения таково:
english1 4WERBEH english3 2WERBEH english5 6WERBEH
------->
E
<-----------------------
H
------------------------------------------------->
E
Чтобы выполнить два изменения направления, мы должны предоставить дополнительную информацию путём явного разграничения. В этом примере мы используем элемент SPAN и атрибут dir для разметки текста:
english1 <SPAN dir="RTL">HEBREW2 english3 HEBREW4</SPAN> english5 HEBREW6
Авторы могут также использовать специальные символы Unicode для выполнения множественных внедрённых изменений направления текста. Для получения внедрения "слева-направо", окружите внедряемый текст символами LEFT-TO-RIGHT EMBEDDING ("LRE", 16-ричная 202A) и POP DIRECTIONAL FORMATTING ("PDF", 16-ричная 202C). Для получения внедрения "справа-налево", окружите внедряемый текст символами RIGHT-TO-LEFT EMBEDDING ("RTE", 16-ричная l 202B) и PDF.
Использование разметки направления HTML с символами Unicode. Авторы и разработчики авторских программных продуктов должны знать, что конфликты могут увеличиться, если атрибут dir в инлайн-элементах (включая BDO) соседствует с символами форматирования [UNICODE]. Лучше использовать то или другое. Метод разметки даёт больше гарантии структурной целостности документа и облегчает решение некоторых проблем при редактировании двунаправленного текста HTML в простом текстовом редакторе, но некоторые программы могут быть более адаптированы к использованию символов [UNICODE]. Если используются оба метода, нужно быть очень внимательным, устанавливая вложенную разметку и внедрённые изменения направления, иначе результаты отображения могут быть непредсказуемыми.
<!ELEMENT BDO - - (%inline;)* -- I18N BiDi over-ride --> <!ATTLIST BDO %coreattrs; -- id, class, style, title -- lang %LanguageCode; #ПРЕДПОЛАГАЕТСЯ -- код языка -- dir (ltr|rtl) #НЕОБХОДИМ -- направление -- >
Начальный тег: необходим, Конечный тег: необходим
Определение атрибута
Атрибут, определённый в другом месте
Двунаправленного алгоритма и атрибута dir обычно достаточно для обслуживания внедрённых изменений направления. Однако, в некоторых ситуациях двунаправленный алгоритм может быть причиной некорректного представления. Элемент BDO позволяет авторам отключить двунаправленный алгоритм в определённом фрагменте текста.
Рассмотрим документ, содержащий текст:
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
и представим, что этот текст уже выведен в
таком визуальном порядке. Причиной этого
может быть то, что стандарт MIME ([RFC2045],
[RFC1556]) отдаёт преимущество визуальному
расположению, т.e. что последовательности
текста "справа-налево" вставляются
справа-налево в потоке байтов.
В email этот пример может быть сформатирован с
включением символов новой строки:
english1 2WERBEH english3 4WERBEH english5 6WERBEH
Это конфликтует с двунаправленным алгоритмом [UNICODE], поскольку этот алгоритм повернёт 2WERBEH, 4WERBEH и 6WERBEH вторично, отображая еврейские слова слева-направо вместо справа-налево.
Решением в данном случае будет переопределение двунаправленного алгоритма помещением отрывка Email в элемент PRE (для сохранения символов новой строки) и каждой строки в элемент BDO, атрибут dir которого установлен в LTR:
<PRE> <BDO dir="LTR">english1 2WERBEH english3</BDO> <BDO dir="LTR">4WERBEH english5 6WERBEH</BDO> </PRE>
Это говорит двунаправленному алгоритму "Оставь меня слева-направо!" и должно создать желаемое представление:
english1 2WERBEH english3 4WERBEH english5 6WERBEH
Элемент BDO должен использоваться в конструкциях, где нужен полный контроль за порядком расположения (напр., несколько многоязычных частей). Наличие атрибута dir для этого элемента обязательно.
Авторы могут также использовать специальные символы Unicode для переопределения двунаправленного алгоритма. -- LEFT-TO-RIGHT OVERRIDE (202D) или RIGHT-TO-LEFT OVERRIDE (202E). Символ POP DIRECTIONAL FORMATTING (202C) заключает любое переопределение двунаправленного алгоритма.
Примечание. Напоминаем, что может увеличиться количество конфликтов, если атрибут dir в инлайн-элементах (включая BDO) соседствует с символами форматирования [UNICODE].
Двунаправленность и кодировка символов. В соответствии с [RFC1555] и [RFC1556], существуют несколько специальных соглашений об использовании значений параметра "charset" для обозначения двунаправленного представления в MIME mail, в особенности для различения визуального, подразумеваемого, и явного указания направления. Значение параметра "ISO-8859-8" (для еврейского языка) обозначает визуальное кодирование, "ISO-8859-8-i" обозначает подразумеваемую двунаправленность и "ISO-8859-8-e" обозначает явную двунаправленность.
Поскольку HTML использует двунаправленный алгоритм Unicode, соответствующие документы, кодированные с использованием ISO 8859-8, должны быть помечены как "ISO-8859-8-i". Явный контроль направления также возможен в HTML, но он не может быть выражен в ISO 8859-8, так что "ISO-8859-8-e" не должен использоваться.
Значение "ISO-8859-8" подразумевает, что документ сформатирован визуально, с потерей некоторой разметки (такой как TABLE с правым выравниванием и запретом переноса слов), чтобы обеспечить верное отображение в более старых ПА, не обрабатывающих двунаправленность. Такие документы не соответствуют настоящей спецификации. При необходимости они могут быть оформлены в соответствии с настоящей спецификацией (и одновременно будут корректно отображаться в более старых ПА) путём добавления разметки BDO там, где это необходимо. В противоположность уже сказанному в [RFC1555] и [RFC1556], ISO-8859-6 (арабский язык) визуально не упорядочивается.
Поскольку иногда возникают двусмысленные ситуации при установке направления определённых символов (напр., знаки препинания), спецификация [UNICODE] содержит символы для соответствующего разрешения таких ситуаций. Также Unicode включает некоторые символы управления поведением сращивания там, где это необходимо (напр., некоторые ситуации с арабскими буквами). HTML 4 включает символьные ссылки-мнемоники для таких символов.
Следующий отрывок ОТД представляет некоторые мнемоники направления:
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner--> <!ENTITY zwj CDATA "‍"--=zero width joiner--> <!ENTITY lrm CDATA "‎"--=left-to-right mark--> <!ENTITY rlm CDATA "‏"--=right-to-left mark-->
Мнемоника zwnj используется для
блокировки сращивания в контексте, когда
сращивание есть, но нежелательно.
Мнемоника zwj действует наоборот: она
форсирует сращивание, когда его не должно
быть, но оно необходимо. Например, арабская
буква "HEH" используется как сокращение от "Hijri",
названия исламской календарной системы.
Поскольку изолированно форма "HEH" похожа на
цифру пять, как принято в арабском письме (на
базе индийской нумерации), для
предотвращения конфликтов "HEH" с конечной
цифрой пять в обозначении года
используется начальная форма "HEH". В то же
время, отсутствует контекст (т.е.
сращивание букв), к которому "HEH" можно
присоединить. Символ zwj
обеспечивает такой контекст.
Также в персидских текстах встречаются случаи, когда буквы, которые обычно могут сращиваться с последующими, в курсивном соединении не делают этого. Символ zwnj используется для блокировки сращивания в таких случаях.
Другие символы, lrm и rlm, используются для форсирования направленных или нейтрально направленных символов. Например, если знак двойной кавычки вставляется между арабскими (справа-налево) и латинскими (слева-направо) буквами, направление знака кавычки на определено (закавычивает ли она арабский или латинский текст?). Символы lrm и rlm имеют свойство направления, но не имеют свойств ширины и разрыва слов/строки. См. детали в [UNICODE].
"Зеркальные" глифы символов. Вообще двунаправленный алгоритм не отражает "зеркально" глифы символов, а оставляет их без воздействия. исключение составляют символы, такие как скобки (см. [UNICODE], таблица 4-7). В тех случаях, когда зеркальное отражение необходимо, например, для египетских иероглифов или греческих Bustrophedon, или для достижения специальных дизайнерских эффектов, этим можно управлять с помощью стилей.
В целом, использование таблиц стилей для изменения визуального представления элементов с уровня блока на инлайн и наоборот является более прямым путём. Однако, поскольку двунаправленный алгоритм основывается на различении уровней блок/инлайн, необходимо особое внимание при обеспечении трансформации.
Если инлайн-элемент, не имеющий атрибута dir, трансформируется в элемент уровня блока с помощью таблицы стилей, он наследует атрибут dir от ближайшего родительского блок-элемента для определения базового направления блока.
Если блок-элемент, не имеющий атрибута dir, трансформируется в стиль инлайн-элемента с помощью таблицы стилей, результат представления должен быть эквивалентным, в плане двунаправленного форматирования, форматированию, получаемому путём явного добавления атрибута dir (с установкой наследуемого значения) к трансформируемому элементу.