Как создавать сайты, готовые к локализации

http://sixrevisions.com/content-strategy/localization-website-tips/
  • Перевод


Локализовать можно любой сайт – по крайней мере, мы в Alconost еще не отказали в этом ни одному клиенту. Тем не менее, результат локализации может сильно зависеть не только от наших переводчиков, а и от ваших веб-дизайнеров. Почему? Ответ на этот вопрос и еще много полезных идей – в переводе статьи опытного проджект-менеджера по локализации Роберта Ханта.


Подготовка к локализации сайтов требует адаптивного дизайна


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

Да потому, что обычно в разных языках один и тот же текст имеет разную длину. Английский – компактный язык, на других языках текст обычно длиннее.

Сравните английское предложение и немецкий аналог:


При переводе на немецкий текст удлиняется.

Простое правило – планируйте возможность увеличения текста как минимум на 30%. Разные источники советуют ориентиры от 20% до 50%, но мой опыт подсказывает, что 30% обычно достаточно.

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

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

Вместо фиксированных используйте относительные единицы, em и проценты (%) – это позволит контейнеру адаптироваться под содержимое.

Для примера взгляните, что происходит при переводе надписи с английского на филиппинский язык для кнопки фиксированной ширины:



.button {
  display: block;
  width: 120px;
  text-align: center;
}



В данном случае ширина кнопки зафиксирована в 120 пикселей, что подходит для надписи на английском языке, но при переводе текст вырос на 50% (с 105px до 175px), что и привело к переносу строки.

Для решения проблемы нужно создать адаптивную вёрстку, которая позволит кнопкам автоматически расширяться до нужных размеров.

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

Уберём свойство width вовсе, и позволим кнопке адаптироваться к родительскому элементу:


Кнопка без указания ширины

.button {
  display: block;
  text-align: center;
}


Чтобы лучше контролировать ширину, мы можем задать минимальную и максимальную ширину кнопки в процентах.
Задав значение min-width в 30% и max-width в 60%, в результате мы получим:


Ширина кнопки при использовании параметров CSS min-width и max-width

.button {
  display: block;
  min-width: 30%;
  max-width: 60%;
  text-align: center;
}


При разработке вариантов дизайна для разных экранов (media-queries) учитывайте, что текст на разных языках может иметь разную длину и размер шрифта (примечание переводчика: например, для китайских или японских иероглифов, изобилующих мелкими деталями, шрифт должен быть на 15-30% крупнее). Предусмотрите возможность уменьшать размер шрифта или изменять относительный размер элементов, чтобы дизайн не ломался.

Полезные советы по локализации сайтов


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

Используйте шрифты Unicode
Шрифты Unicode содержат большое количество букв, знаков, цифр и других элементов для отображения текстов на разных языках. В качестве примеров популярных шрифтов, поддерживающих юникод, можно привести Arial и Times New Roman.

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

Не используйте картинки с текстом
Если ваш сайт содержит картинки с надписями, замените их на HTML, а потом стилизуйте при помощи атрибутов CSS и @font-face. Тогда текст можно будет перевести при помощи автоматических переводчиков (примечание переводчика: хотя куда лучше пользоваться услугами агентств по локализации, чтобы получить действительно качественный перевод).

Планируйте структуру URL, которая будет пригодна для локализации
Когда разрабатываете архитектуру сайта, учитывайте, что рано или поздно вам придется локализовать его на другие языки. Время, потраченное на оценку того, как будут выглядеть URL сайта в разных языковых версиях, окупится потом, когда придётся переводить сайт на другой язык.

Два популярных метода организации локальных версий:
  • Поддомены: example.com/webpage.html превращается в ru.example.com/webpage.html (для русскоязычной версии)
  • Поддиректории: example.com/webpage.html превращается в example.com/ru/webpage.html (русскоязычная локализация)



Nike.com (U.S.)


Nike.com (France)

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

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

Документация для наиболее популярных платформ и фреймворков:

Есть вопросы или сложности с локализацией? Пишите нам на info@alconost.com, поможем!


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com

Alconost 76,44
Локализуем на 68 языков, делаем видеоролики для IT
Поделиться публикацией
Комментарии 17
  • +1
    ух ты! ссылки на документацию!
    • +4
      поверхностная статья для тех кто никогда в жизни не занимался локазизацией интерфейсов даже для языковой пары RU/EN.
      • +9
        Пустой рекламный перевод, суть которого дать ссылку на сайт конторы в начале и адрес конторы в конце.
      • 0
        По поводу URL для локализации. Не всегда необходим свой URL для каждого языка. Мне даже больше нравится подход, когда где-то внутри хранится текущий язык (в cookie, например). При первом заходе на сайт определять этот язык автоматически. Таким образом будет одинаковая ссылка для филиппинца и русского. Но у каждого будет на своём языке. И русский сможет отправить ссылку немцу и она откроется не на русском, а на немецком. Для примера, так сделано в Tuffle.
        • +1
          А если необходимо именно на том языке на котором ты смотришь? Правильнее чтобы ссылка содержала идентификатор языка, а при переключении языка сайт переходил на версию страницы с требуемым языком.
          • 0
            А вот скажите, в каком практическом случае (хотя я не отрицаю их), может понадобиться такой случай, чтобы было именно на том языке? Да, такие ситауции могут быть, но в основном совсем наоборот, человеку нужен именно контент на его языке.
            • +1
              Ну например, браузер автоматически определил язык как китайский, и что я увижу — кучку иероглифов?!
              • 0
                1) Очень странно что твой браузер определит китайский, если ты его не знаешь
                2) Рекомендуется делать смену языка на самом видном месте, чтоб его можно сменить язык совсем не знаю текущего.
              • +2
                Второй пример, индексация контента поисковыми роботами
                • –1
                  В современном мире поисковые роботы умеют индексировать мультиязычный контент, нужно всего лишь пару мета-тегов добавить
            • 0
              Прокси-серверы, а также кэш браузера в таком случае будут против. Тут можно на заголовок Accept-Language завязаться, но тогда пользователь не сможет поменять язык на самом сайте.

              Можно, конечно, использовать смешанный вариант — смотреть на заголовок, а если пользователь сменил язык — то записывать его в URL.
            • 0
              Разве добавление поддоменов/поддиректорий не является сегодня атавизмом? Контекст сервера хранит дефолтную локаль, а куки клиента указывают на предпочтительную, в результате чего всегда доступна текущая локаль пользователя. Содержимое страницы либо меняется языковыми метками при перегрузке, либо уже есть фреймворки «из коробки» на js, позволяющие динамически поменять текст на метках (и графическое сопровождение). Текущий язык отображается на странице.
              Кстати, со статическим графическим сопровождением все тоже весьма неплохо, если организовать хранение графики на сервере упорядоченно: ссылки будут иметь вид src=«path/${lang}/some_picture.png», сервер подставляет язык и картинка с нужной языковой приявязкой отобразится на странице (понятно, многое зависит от платформы, но шаблонизаторы есть у всех).
              • 0
                Мне кажется, Вы слегка сами себе противоречите: с одной стороны «Разве добавление поддоменов/поддиректорий не является сегодня атавизмом?», и при этом: ссылки будут иметь вид src=«path/${lang}/some_picture.png». Понятно, что можно заранее подготовить локализованные картинки и разложить их в поддиректории по языкам, но если уж отказываться от поддиректорий, то внешне это должно выглядеть одинаково, что для URL всей страницы, что для отдельных ее элементов
                • 0
                  В принципе, да, согласен, определенное противоречие есть. Просто подходил с точки зрения практичности, хотя пару манипуляций на сервере легко исправили этот нюанс — то есть абсолютный путь к статике на сервере может определяться в том числе на основе локали из контекста сервера, а публичный url к нему — единый. И это было бы правильно, и «в одном стиле». Банальный недосмотр ))).
              • 0
                Европеоидные советы. под ту же Азию надо менять само визуальное представление, например (макеты и верстка совсем другие).
                • 0
                  Кроме совета о размерах элементов ничего нового или оригинального не узнал. Слишком много букаф для такого откровения

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое