Эта статья была первоначально опубликована на 99designs Tech Blog .
Два года назад у 99designs были локализованные сайты для нескольких англоязычных стран, и наша команда разработчиков не имела большого опыта в многоязычной веб-разработке. Но мы чувствовали, что перевод нашего сайта был важным шагом, сняв еще один барьер для совместной работы дизайнеров и клиентов по всему миру.
Сегодня мы предоставляем локализованный контент клиентам в 18 странах на шести языках. Вот как мы туда попали, и некоторые из дорожных блоков, с которыми мы столкнулись.
Начиная местный
Самым сложным аспектом интернационализации является язык, поэтому мы начали с локализации: все, кроме языка. В частности, это означает соответствующий региону контент и валюту. Шестимесячные усилия по разработке позволили нам провести реорганизацию нашей базовой базы PHP-кода для поддержки локальных доменов для большого числа стран (например, 99designs.de ), где клиенты могли видеть местный контент, а пользователи могли платить и получать платежи в местной валюте.
В конце этого процесса, каждый раз, когда мы запускали региональный домен, мы начинали перенаправлять пользователей в этот домен из нашего слоя Varnish, основываясь на поиске GeoIP. С тех пор этот процесс мало изменился и продолжал служить нам в нашем недавнем запуске в Сингапуре.
Языки и перевод
Когда локализация работала, пришло время принять жесткие решения о том, как мы будем устранять языковой барьер для не говорящих по-английски (то есть для большинства людей в мире). Нам нужно было ответить на множество вопросов.
- Какие языки мы будем предлагать пользователям в данном регионе?
- Как пользователи будут выбирать свой язык?
- Как мы представим переведенные строки пользователям?
- Как строки будут поставлены в очередь для перевода?
- Кто будет переводить?
Какие языки предложить?
Вместо того, чтобы выбирать регион, язык и валюту по выбору пользователя, мы решили ограничить доступность языка и валюты регионом пользователя. Это было компромиссом, который упростил работу с местным контентом: если наш немецкий регион не поддерживает испанский, мы избегаем писать для него маркетинговую копию на испанском языке.
Наша единственная оговорка была для всех регионов, чтобы поддержать английский как действительный язык. Как международный язык торговли, это уменьшает любое негативное влияние закрепления региона.
Перевод строки
Для перевода мы рассмотрели два основных подхода: использовать традиционный подход gettext в GNU и начать экранирование строк, или использовать прокси-сервер перевода, такой как Smartling . У gettext было несколько преимуществ: он имеет долгую историю и хорошо поддерживается веб-фреймворками; это легко встраивается; и переводы просто становятся дополнительными артефактами, которые можно легко контролировать по версии. Тем не менее, это потребовало бы приличного рефакторинга нашей существующей базы кода PHP и оставило бы открытые вопросы о том, как получать переводы.
В подходе Smartling запрос пользователя передается через серверы Smartling, в свою очередь запрашивая английскую версию нашего сайта и применяя переводы к ответу до того, как пользователь его получит. Если перевод отсутствует, английская версия подается, и строка добавляется в очередь для перевода. Отказ от этого означал бы значительное сокращение количества кода, который нужно изменить, и это большая победа. Тем не менее, это рисковало нам полагаться на сторонних разработчиков для обеспечения работоспособности и производительности.
В итоге мы пошли с Smartling по нескольким причинам. Они предоставили источник переводчиков и опыт в интернационализации, которого нам не хватало. Риски работоспособности и производительности были несколько смягчены двумя факторами. Во-первых, прокси-сервер Smartling будет обслуживаться из региона AWS США-Восток, того же региона, из которого обслуживается весь наш стек, что повышает вероятность того, что их стек и наш будут тонуть или плавать вместе. Во-вторых, поскольку наши англоязычные домены будут по-прежнему обслуживаться в обычном режиме, большая часть нашего трафика будет по-прежнему обходить прокси-сервер и находиться под нашим прямым контролем.
Готовим наш сайт
Мы установили наш курс и приступили к работе. Намного больше было нужно сделать, чем мы впервые поняли, в основном в трех областях.
Экранирование пользовательского контента
Строки на нашем сайте, которые содержали пользовательский контент, быстро заполнили нашу очередь перевода (подумайте «Дизайн логотипа для Грега » против «Дизайн логотипа для Сары »). Заголовки конкурса, описания, имена пользователей, комментарии, вы называете это, все, что получено от пользователя, должно быть найдено и обернуто в <span class="sl_notranslate"> Это означало значительный постоянный аудит страниц нашего сайта, исправление их по мере нашего продвижения.
Подготовка JavaScript к переводу
Наш JavaScript также должен был быть подготовлен к переводу, с худшими хитами на стороне клиента. Все строки необходимо было перенести в часть файла JS, которую можно разметить для перевода. Конкатенация строк больше не была в порядке, поскольку она допускала ошибочные предположения о грамматике других языков. Строки, обслуживаемые через JSON API, также были скрыты от перевода, что означало, что нам пришлось искать другие способы обслуживания тех же данных.
Делаем наш дизайн более гибким
В нашем дизайне и компоновке мы больше не могли быть идеальными по пикселям, поскольку переведенные строки для общих элементов навигации часто были намного длиннее на целевом языке. Вместо этого это заставило нас разработать более надежную конструкцию, которая могла бы приспособиться к изменению ширины струны. Мы перестали использовать CSS-преобразования, чтобы стилистически изменять регистр текста, поскольку другие языки более чувствительны к изменениям регистра, чем английский.
Снежок побед
После 9 месяцев напряженной работы мы с гордостью выпустили немецкую версию нашего сайта, что стало для нас огромной вехой. После самой тяжелой работы в течение следующих 9 месяцев мы запустили сайты на французском, итальянском, испанском и голландском языках. Со временем количество новых инженерных работ уменьшалось с каждым запуском, так что нетехнические аспекты маркетинга, поддержки и перевода нового региона теперь доминируют во времени запуска нового языка.
Испытания
Мы также столкнулись с несколькими неожиданными проблемами.
Шаблонирование на стороне клиента
Ранее мы упоминали, что чем богаче JS на стороне клиента, тем больше работы требуется для обеспечения плавного перевода. Самым большим препятствием для нас было использование шаблонов усов , которые изначально были непереводимы на лету. К их чести, Smartling значительно улучшил поддержку Усов во время нашего развития, что позволило нам преодолеть это препятствие.
Перевод не веб-артефактов
Это не должно удивлять: перевод по доверенности является стратегией для веб-страниц, но не является сильной для других не-веб-артефактов. В частности, долгое время перевод писем был трудным делом, и в худшем случае он состоял из инженеров и национальных менеджеров, которые в основном отправляли по электронной почте шаблоны для перевода туда и обратно. Через некоторое время мы решили эту проблему, используя API Smartling в сочетании с gettext
Экспоненциальный рост строк перевода
Со временем мы неоднократно находили нашу очередь переводов забитой огромным количеством строк, ожидающих перевода. Многие из этих случаев были ошибками, из-за которых мы должным образом не разметили пользовательский контент, но наиболее упрямые были связаны с нашими маркетинговыми усилиями. Наличие страницы для каждой комбинации отрасли, категории продукта и города привело к взрыву строк для перевода. Правильное решение этих проблем потребует механизма генерации естественного языка с некоторым пониманием грамматики каждого языка. На данный момент мы просто исключили эти страницы из наших усилий по переводу.
Будущее
Это был обзор инженерных работ, связанных с локализацией и переводом сайта, подобного нашему, на другие языки. В конечном счете, мы чувствуем, что подход с использованием прокси-серверов перевода значительно сократил наше время для выхода на рынок; мы бы порекомендовали это другим компаниям, которые также расширяются. Теперь, когда несколько сайтов запущены и работают, мы продолжим использовать сочетание подходов прокси и gettext, где каждый наиболее подходит.
Мы гордимся тем, что можем разместить наш сайт на нескольких языках, и стремимся продолжать разрушать барьеры между компаниями и дизайнерами, где бы они ни находились, позволяя им работать вместе на тех языках, на которых они наиболее удобны.
Эта статья была первоначально опубликована на 99designs . Воспроизводится с разрешения.