Краткое содержание

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

Однако услуги сторонних переводчиков стоят денег. Хуже того — наш контент бурлит программированием и математикой, поэтому годится не любой переводчик.

Прикинув цену на бумажке я сразу поняла что в наш бюджет она пока не вписывается. Мы стали искать другие пути.

Я попробую рассказать о том решении к которому мы пришли, а именно:

• как мы дешево-сердито использовали github для пользовательских переводов
• как специфика сайта мешает при переводе
• насколько реально получить помощь от пользователей
• как отметить переводы для поисковика Google
• наконец, насколько виден (или не виден) эффект от переведенного контента

За подробностями добро пожаловать под кат!


 

Предварительные расчеты

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

Я начала с выяснения стоимости услуг профессиональных переводчиков. В тематической ветке на Reddit мне назвали минимум — 5 центов за слово. А на ProZ есть даже табличка — тут цифры вовсе неутешительные.

Представим — у нас как минимум 200 основных текстов (по смыслу это задачи для новичков, студентов) — не считая статей вики. Длина текстов от 100 до 400 слов.

Взяв среднюю длину 200 слов и умножив на 200 задач получаем 40000 слов. По 5 центов за слово это 2000 долларов. Если перевести на 5 языков — 10 тысяч. Если считать по 10 центов — то $20000. Если языков будет больше — денег надо больше.

Это небольшие деньги — миллион рублей по ценам 2015 года — для какого-нибудь средне-солидного бизнеса. Но наша команда — всего парочка энтузиастов — а наш сайт не предназначен для генерации профита. От пользователей мы получаем не деньги а лучи добра — и в целом этим довольны.

Однако лучами добра сайт не переведешь.

Есть и еще вопросы с таким подходом:

• как проверить качество работы переводчика — соответствует ли оно оплате? переводить гугл-транслейтом с испанского, французского, китайского обратно на английский?
• как заранее узнать актуальны ли эти затраты? а вдруг переводы не будут пользоваться значительным спросом?
• формат исходных текстов и переводов — не каждый переводчик захочет работать с MarkDown который мы активно используем.

 

Пользователи как волонтёры-переводчики

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

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

Однако, захотят ли участники помогать безвозмездно? Ведь для многих проблема даже не в «безвозмездности» — а просто кому-то скучно этим заниматься, у кого-то нет времени.

Это предстояло узнать. Сразу расскажу о результатах — у нас пока меньше 10 тысяч более-менее активных пользователей (не считая однократно заглядывающих на сайт и т.п.) — на текущий момент в переводе поучаствовали человек 10. Т.е. около 0.1% — в любом случае это гораздо лучше чем если бы не помог никто!

Но как организовать процесс перевода технически?

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

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

 

Хранение переводов на GitHub

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

Создали проект на GitHub, в него добавили папочки с именами соответствующими двухбуквенным кодам языков (ru, fr, de, es и так далее). Внутри папок размещаем файлы с переводами контента. Просто task-1.md, task-2.md.

Сайт используя API гитхаба легко подтягивает тексты прямо оттуда (для GET-запросов к АПИ на гитхабе не нужна даже авторизация). Т.е. если человек переключается на испанскую версию задачи — сайт рендерит её не из базы а прямо с гитхаба.

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

Другие плюсы — в способах добавления переводов. Мы используем два:

• Пользователи хорошо знающие Git могут клонировать репозиторий себе, добавить несколько файлов-переводов — и сделать пулл-реквест.
• Остальные могут тут же на гитхабе написать перевод в виде gist-а, и завести в проекте тикет (issue) в котором оставить ссылку на этот гист — а в файл содержимое могу перенести, например, уже я сама.

Конечно подробный процесс мы описали в README.md в корне проекта, так что участники обычно даже не задают вопросов.

Конечно, переводы не всегда идеальны — но сбитое форматирование мы можем поправить (отредактировав файл там же на гитхабе) — ну а если что поважнее — надеюсь, другие пользователи впоследствии смогут предложить коррективы.

 

Техническое допиливание сайта

Конечно, потребовалось немного расширить функционал сайта.

Переводные статьи у нас имеют суффикс с тем же двухбуквенным кодом языка.

Для страниц которые сайт извлекает с гитхаба сделали кэш на сервере. Правда пока отключили за ненадобностью (редактировать-то удобнее без кэша).

По SEO — открыли для себя нечто новое — в head-части страниц нужны link-и с атрибутом hreflang — чтоб гугл не жаловался. Это было несложно допилить — легче чем понять как именно они должны выглядеть (для каждой страницы нужны ссылки на все переводы включая ее саму!)

Пользователь сделавший переводы на арабский язык внезапно поставил нас перед задачей отображения текста справа-налево. Справились.

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

 

Достигнутые результаты

Это то что интересовало с самого начала. А что если эта затея бесполезна — что если волонтёры не придут помогать — а если переводы никто не станет читать?

Прошло 3 месяца. У нас есть переводы первых задач на следующие языки: немецкий (DE), испанский (ES), французский (FR), арабский (AR), китайский (ZH), румынский (RO), русский (RU).

В среднем переведено по 15 задач на язык. Это далеко не 200, однако, думаю, это неплохо: ведь переводы актуальны для «совсем новичков», из которых многие решают всего 5-10 задач. Те же кто переваливает за сотню обычно неплохо знают английский.

Гугл-аналитика показывает — просмотры страниц с переводами составляют сейчас около 10% от общего числа просмотров страниц с задачами. Конечно здесь еще сказываются два фактора:

Гугл-вебмастер сообщает что на переведенные страницы пришли 2% кликов (я думала — мало, но потом сообразила что переведено-то в среднем 7%, если без учета вики и т.п. — так что пропорция адекватная).

• сам интерфейс сайта не переведен, так что базовые способности в английском языке от пользователя требуются — ну слова в меню распознать и т.п.
• процесс вовлечения пользователей которым актуальны переводы — конечно, тоже обладает некоторой инерционностью.

В целом этот опыт нам очень понравился — поэтому я и захотела им поделиться. Пусть с технической точки зрения мы избрали довольно примитивный способ (да-да, гитхаб, это все) — но зато не погрешили против важного принципа KISS — keep it simple, stupid (который я сама очень люблю).