Îñţérñåţîöñåļîžåţîöñ

Sunday, September 11, 2011

Итак, вы выходите на мировой уровень, и ваш сайт должен следовать за вами. По идее, это простой вопрос перевода текста — и все готово, верно? Вероятно, нет. Команда Google Webmaster

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

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

Больше языков != больше HTML-шаблонов

Мы не устаем это повторять: используйте один и тот же шаблон для всех языковых версий и всегда старайтесь делать HTML вашего шаблона простым.

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

Какова длина куска веревки? Если ваш дизайн зависит от того, как текст взаимодействует с элементами фиксированного размера, то перевод текста может все разрушить. Например, текст вашей левосторонней навигации на нескольких языках, скорее всего, превратится в гораздо более длинные строки текста — сравните разницу в длине строк для
английской
и голландской

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

Переменная длина слов создает особые проблемы в метках форм и элементах управления. Если в макете вашей формы метки расположены слева, а поля справа, то более длинные строки текста могут занимать две строки, в то время как более короткие строки текста могут визуально не ассоциироваться с полями ввода. Оба сценария портят дизайн и ухудшают читаемость формы. Также учтите дополнительные стили, которые вам понадобятся для макетов с письмом справа налево (RTL) (подробнее об этом позже). По этим причинам мы проектируем формы с метками над полями для удобства чтения и стилизации, которая будет хорошо адаптироваться к разным языкам.
Также избегайте колонок фиксированной высоты: если вы пытаетесь упорядочить свой макет с помощью фоновых блоков одинаковой высоты, велико шансы, что при переводе текст выйдет за пределы областей, которые были достаточно высокими только для английского контента. Подумайте, будут ли элементы пользовательского интерфейса, которые вы планируете использовать в дизайне, работать при изменении объема текста — например, горизонтальные
и вертикальные

вкладки.

С другой стороныРедактирование исходного кода для двунаправленного HTML может быть проблематичным, поскольку многие редакторы не созданы для поддержки двунаправленного алгоритма Unicode(

подробнее об исследованиях проблем и решений

). Короче говоря, отображение вашей разметки может исказиться: Наша собственная повседневная практика показала, что следующие редакторы в настоящее время обеспечивают достойные решения для двунаправленного редактирования: в частности Coda, а также Dreamweaver, IntelliJ IDEA и JEditX. При проектировании для языков RTL вы можете встроить большую часть необходимой поддержки в основной CSS и использовать атрибут directional у элемента html (для обратной совместимости) в сочетании с классом у элемента

body

. Как всегда, хранение всех стилей в одной основной таблице стилей повышает удобство сопровождения.
Несколько ключевых проблем со стилями, на которые следует обратить внимание: любые элементы с обтеканием справа должны быть переведены на обтекание слева и наоборот; дополнительные отступы (padding или margin), примененные к одной стороне элемента, нужно будет переопределить и поменять местами, а любые атрибуты text-align следует инвертировать. Мы обычно используем следующий подход, включая применение класса к тегу body вместо CSS-селектора html[dir=rtl], так как это совместимо со старыми браузерами:

Элементы:

Стили слева направо (по умолчанию):

Стили справа налево:

(Посмотрите на это в действии на
английском и
арабском.)

языках)

Одно последнее примечание на эту тему: большую часть времени ваш контент для страниц на языках с письмом справа налево будет двунаправленным, а не чисто RTL, поскольку некоторые строки, вероятно, должны будут сохранить направление LTR — например, названия компаний на латинице или номера телефонов. Чтобы браузер правильно обрабатывал это в документе, который преимущественно написан справа налево, следует обернуть встроенные строки текста строчным элементом с атрибутом направления, вот так: ‫ В тех случаях, когда у вас нет контейнера HTML для привязки атрибута dir (например, в элементах title или исходном коде JavaScript для всплывающих сообщений), вы можете использовать этот эквивалент для установки направления, где ‬‬ и

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

Пример использования в коде JavaScript:
(Для получения более подробной информации см. статьи W3C о
создании HTML для арабского, иврита и других языков с письмом справа налево
и.)

разработке скриптов с письмом справа налево

)

Для меня это темный лес…
Если вы никогда раньше не работали с нелатинскими наборами символов (кириллица, греческий и множество азиатских и индийских языков), вы можете обнаружить, что и редактор, и браузер отображают контент не так, как задумывалось. Убедитесь, что кодировка вашего редактора и браузера установлена в UTF-8 (рекомендуется), и подумайте о добавлении элемента <span> и атрибута lang
элемента html в ваш HTML-шаблон, чтобы браузеры знали, чего ожидать при рендеринге вашей страницы. Это дает дополнительное преимущество: обеспечивается правильное отображение всех символов Unicode, поэтому использование HTML-сущностей, таких как
é
(é), не потребуется, что сэкономит ценные байты! Ознакомьтесь с

руководством W3C по кодировке символов

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

ISO 639-1

, помогает при работе с несколькими языковыми версиями одного и того же документа.
Применение общепринятого стандарта поможет пользователям понять структуру вашего сайта, а также облегчит его поддержку для всех веб-мастеров, которые могут заниматься его разработкой. Использование кодов языков для других ресурсов сайта (изображения логотипов, PDF-документы) удобно для быстрого поиска файлов.
Ознакомьтесь с предыдущими публикациями Webmaster Central с советами по структуре URL и другим вопросам,
связанным с работой с многорегиональными сайтами.

и

многоязычными сайтами
Это краткий обзор основных трудностей, с которыми мы сталкиваемся ежедневно; но мы можем подтвердить, что планирование и предварительная работа над хорошо структурированным HTML и надежным CSS окупаются во время локализации!Опубликовано