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

По большому счету, есть что сказать по каждой из такой типичной хотелке. Но по языкам последнее время наболело сильнее всего. Заодно попробую объяснить, почему мы не сильно торопимся делать это у себя в JBZoo (хотя примерно начиная с 3.x фича скорее всего появится).

Замечу, что все сказанное мной ниже по большей части относится к любой CMS, любому типу сайтов и современному ПО… и вообще.

Итак, типичная ситуация. Заказчик (клиент), сам того не понимая, хочет, чтобы его сайт был переведен на английский язык. Зачем? Ну конечно же, чтобы по-быстрому покорить западный рынок. Перевод должен быть обязательно синхронным (т. е. каждая страница может переключаться на себе подобную). Тратиться естественно, никто не собирается. А смысл? Если есть бесплатные программы-переводчики, а в панели управления есть ссылочка — «добавить язык».

Конечно же такие люди обращаются и к нам c вопросом о JBZoo, есть ли поддержка мультиязычности или нет. Мы пытаемся узнать больше деталей, но обычно все заканчивается «ссылкой» на подобную страницу. В голове при этом бьется вопрос: «Зачем… зачем вам этот геморрой, люди?!»

Чтобы вам не томиться и не искать итог, к которому пришел лично я — каждый язык должен быть реализован на отдельном, независимом домене и сайте. И вот почему…

Удобства при работе с отдельными сайтами-языками

Нет лишнего функционала в движке сайта

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

Обычно это выливается в следующее:

• Такие компоненты как JoomFish, Falang, ZOOlanders пытаются заменить контент всеми честными и не честными способами (хаки, куча плагинов, переопределение коробочных функций и т. д.). Как это работает внутри — жутковато. Примерно та же история практически со всеми CMS (кажется только у Drupal это реализовано более-менее удобно и быстро на уровне ядра).

• Минус 1 к скорости вашего сайта.

• +10 к зуду от геморроя при настройке языков и каждого модуля.

• Путаница при наполнении сайта.

• Бывают проблемы с файлами, т. к. хранятся они не в базе данных. А ведь бывает нужно локализовать и картинки. Делать отдельную папку?

По мне так, это все — лишний балласт.

Нет проблем со сбором статистики посещаемости

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

Кто-то скажет — а зачем разделять? Я отвечу — чтобы понять почему с вашего сайта идут покупки для русской аудитории и нет продаж на запад при прочих равных условиях.

Вы пользуетесь «чистой» панелью управления

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

Никаких плясок с хитрой структурой сайта

Синхронный вариант перевода подразумевает, что меню будет одинаковым для всех языков. Но вот беда, они должны быть разными, потому что компания предоставляет совершенно иные услуги для других стран. Что делать? Правильно. Наворачиваем костыли в виде нескольких групп меню, дублирование функционала… А если языков не два, а три? Удачи в лабиринтах панели управления…

Обходим сложности продвижения

В этом месте меня закидают помидорами SEO-шники и, не побоюсь этого слова, «маркетологи». Они скажут, что у них теперь будет много страниц, поэтому легче продвигать и т. д. Скажите, зачем мне как пользователю Рунета нужен на сайте английский язык? И я не знаю… Ну ладно, есть и есть.

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

Легко разделить социальные сети, виджеты и прочие сервисы

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

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

Типичная головная боль с языками

Каждому языку — своя директория

Например, http://site.com/ru/ и http://site.com/en/ .Не считаю это самой лучшей идеей. С одной стороны, у вас будет больше страниц на сайте и все вроде отдельно, но к каждой странице добавляется + 1 вложенность, и встречаются некоторые трудности в популярных CMS разделить дизайн на разные языки. Это все влечет за собой следующую неприятность.

Неудачная поисковая выдача

Например, сайт продает деталь марки «GFT739». Когда я наберу это в Google, какая из страниц будет в выдаче (язык)? А вы уверены?

Зачастую, мне в поисковой выдаче попадается не та страница, хотя все настроено на русском языке. Возможно робот считает, что две страницы на разных языках об одном и том же — это дубли. Или какая-то из страниц лучше продвинута. Почему такое происходит? Не знаю. А в результате такие мелочи отпугивают посетителей. Те тупо уходят к конкурентам и читают на родном языке. Современный интернет — ленивый. Если поисковик кинул не туда, пользователь просто разворачивается и уходит. По идее сайт должен мягко подправлять первый вход пользователя с помощью Гео-таргетинга.

Дизайн и прочие тонкости GUI

Надеюсь не нужно говорить о том, что в каждом языке присутствуют свои «фишки» ? Самый яркий пример — арабский язык. Все справа налево. А то и вообще иногда сверху вниз. Список различий и тонкостей на самом деле огромный. Вот только некоторые пункты:

• Множественные формы существительных.

• Обозначение даты, времени, денежных сумм.

• Конвертирование единиц измерения (переводим килограммы в фунты на автомате).

• Направление письма и пунктуация.

• Обращение к пользователю.

• Зависимость от пола (для некоторых стран это очень даже важно).

• Стилистика речи и терминология.

• Я уж не говорю о диалектах.

Борьба за «длину слова»

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

Например, слово «просмотры» (Данные взяты с хабра)

Сочленённые существительные

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

Например, английское словосочетание «Input processing features» (Функции обработки ввода) превращается в «Eingabeverarbeitungsfunktionen» на немецком языке. Текст на английском легко разбивается на две строки, если есть ограничение по ширине блока, например, рядом с полями ввода в форме, или на вкладках или кнопках, или в узких колонках. Немецкое «супер-слово» не может переноситься автоматически и может создать существенную проблему в макете.

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

Разные тексты на каждый из сайтов

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

Внезапно оказывается, что какая-то страница в принципе не нуждается в переводе на английский и теперь вместо неё будет висеть 404 страница или редирект на главную (в лучшем случае). В худшем случае западный посетитель получит русский текст и просто уйдет от вас. Зачем ему эти мучения?

Хозяйке на заметку — Человеческий перевод ВСЕГДА лучше любого SkyNet-translate

Люди, почему… ну почему вы думаете, что автоматический перевод — это хорошая идея? Я не понимаю. Кто действительно так считает, ударьте себя по рукам… с разбегу! с криком! линейкой! …железной!

Гарантирую, что:

• Это не приведет к вам носителя языка и целевого трафика. Он просто посмотрит, по плюется и уйдет. И уже не вернется, даже(!) если вы все исправите.

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

• Поисковики давно считают подобный контент — мусором. Думаю Google в состоянии отличить хороший текст от собственного сервиса.

• Ваши посетители будут над вами смеяться и никогда не поверят в качество сервиса / продукта.

• К вам придут китайцы. У них с английским так же как у меня с французским. Ничего хорошего не ждите, они такие…

• И вообще это мерзко! Даже не начинайте.

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

Тут только одно правильное решение — наймите профессионального переводчика! Желательно, который жил за рубежом не менее года. В наши дни это довольно просто сделать (как минимум английский в моде). Тройным плюсом будет, если это специалист из вашей же области.

А что делать если у вас тексты про синхрофазотрон (такая разрезанная консервная банка с магнитами)? Всегда можно перевести своим ломаным pre-intermediate, но это все равно лучше, чем доверять текст машине.

Поверьте, даже через 10 лет не появится качественного автоматического перевода. По мне так, это где-то в районе пройденного теста господина Тьюринга.

История жизни одного проекта

Разрабатываем русский сайт — все отлично. Подогнали, наполнили, сдали и успокоились и даже собрали тонну положительных отзывов. Клиент доволен как слон. Проходит время, теперь он хочет добавить английский язык. Не вопрос! Лингвисты перевели все тексты и константы локализации и понеслась…

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

• Номенклатура товаров и верхнее меню должно быть чуть-чуть разное. Окей! +1 раздел к главному меню +7 в категориях и их новая вложенность.

• Title страницы не подходит для продвижения в западном Google (да-да, он там «другой» и ваш sape-спам уже не проканает). Ну ладно, небольшое условие в PHP сделает свое грязное дело.

• Поехала ширина блока новости, потому что изменилась длина текста. Не много, всего на 10px. Но блин, выглядит то это противно! Ок, втыкаем в CSS нерушимый «important» через родительский html[lang=en].

• Опс… разъехалось еще 26 мест. Отдел тестирования не дремлет! Бггг… Ладно, тут всего лишь переверстать, ну подумаешь изменилось три сотни строк в стилях.

• Боже мой! Баги в русской версии! За что? Когда все это кончится?!!

• Ура, сдал проект!

• …

• Клиент хочет перевод на немецкий и уже честно подготовил все тексты.

• Бгггг… окей, это всего лишь небольшая подработка. Я уже знаю все подводные валуны и даже течения. Сейчас по быстрому добавим новую локализацию в нашей супер-пуперCMS и наполним текстами.

• Отдел тестирования не дремлет! Блииннн, дизайн поехал в русском и английском сайте одновременно. Что? еще 146 багов???

• Звуки из программерской: «Во всем виноват дизайнер, верстальщик и клиент со своими языками… кстати, менеджер тоже! Нашел, блин, клиента на мою голову!»

• Ура, сдал проект!

• …

• Клиент хочет перевод на испанский, а отдел тестирования опять не дремлет.

• Первый разработчик больше не хочет работать с «этим», отказывается и покидает сцену.

• Клиент ищет нового подрядчика и находит.

• «Может новый отдельный сайт сделаем? А то ваш предыдущий программист сделал тут какое-то гавно…»

Итого, в сухом остатке

Делайте как надо, а как не надо — не делайте!

А если честно, то…

Цель локализации в том, чтобы пользователи чувствовали себя комфортно в вашем приложении/сайте, независимо от языка и места проживания. Зачастую это требует не очевидных и сложных решений. Поэтому сделать это в рамках одной CMS / компонента — практически невозможно. Либо вы будете один из многих, кто решил потанцевать на граблях.

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

С моей точки зрения, большинство проблем, перечисленных выше, решается банальным созданием двух отдельных сайтов. Желательно, чтобы они находились на разных доменах (jbzoo.ru и jbzoo.com) или поддоменах (en.jbzoo.com и ru.jbzoo.com). Важно чтобы они не зависели друг от друга (базы данных, файлы, картинки). Код между сайтами легко синхронизируется через Git или SVN. Как минимум у вас будет намного меньше проблем при разработке и наполнении, а на выходе — более качественный продукт и меньше затрат на его ведение и техподдержку.

Я не утверждаю, что это единственное правильное решение, но кажется — самое простое. Кто что думает?

Кстати, всем бобра! … т.е. бабла… а нет, добра же! =)