На главную

Локализация

Вы делаете продукт для другой страны другой страны на существующей платформе.

Очевидно, что локализация ≠ перевод.

Что же туда входит.

Перевод текстов сайта

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

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

Допустим, вы благополучно перевели весь статичный текст на сайте. Переводчик перевёл страницу, а верстальщик вставил новые тексты на сайт.

Если страница целиком статическая, то проще всего её скопировать (index.html.ru -> index.html.en) и поправить текст прямо в html.

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

В системе, динамические тексты, как правило, состоят из пар "ключ-значение", где значение представляет собой шаблон:

hello: "Hello, %{username}"

А в самом html у вас будет ещё одна интерполяция:

{{ translate('hello', {username: "John"}) }}

Это условный пример, шаблонизация будет варьироваться в зависимости от инструмента (j2, mustache, erb, slim).

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

Также в текстах будут разные окончания, когда вам нужно указать количество: 1 молоток, 2 молотка, 5 молотков.

hammer:
  one: "У вас %{count} молоток"
  two: "У вас %{count} молотка"
  many: "У вас %{count} молотков"

Как править править тексты?

YAML

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

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

Выгрузка-загрузка

Разумеется, вы можете хранить тексты где-то отдельно, и даже не в коде, а например в базе данных. Будь то Redis или Postgres. В любом случае, для переводчиков лучше подготовить для выгрузку в XLS. А также обратную загрузку из XLS (в YAML, Redis, Postgres) с определённой валидацией. При массовом переводе выгруженных текстов (Excel или в любой другой выгрузке) потеряется контекст. Так как то, что будет выгружено - это пара "ключ-перевод/шаблон" для каждого конкретного языка. И для переводчика, они никак не привязаны к тому месту, где они размещены на сайте. Это косвенно можно сделать по ключу, но где встречается тот или иной текст точно может сказать только разработчик. Если ваши тексты состоят из каких-то небольших фрагметнов, это ещё сильнее уменьшит контекст и добавит сложности.

Inline / In-place редактирование

Можно воспользоваться также inline-редактированием. Для этого вам придётся прикрутить к вашему сайту некие инструменты, которые позволяют нажать на определённое слово на сайте, исправить его и сохранить результат. Подробного обзора на такие инструменты здесь не будет, т.к. это всё сильно зависит от выбранных технологий. И даже с таким редактированием придётся плотно взаимодействовать с переводчиком, потому что он не будет знать всех пользовательских сценариев на сайте. Часть текстов будет просто пропущена. Зато внесение отдельных точечных правок здесь оказывается довольно простым. Кроме того и разработчик и переводчик будут одновременно видеть самую свежую информацию.

Сторонние сервисы

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

Качество и скорость перевода и обратная связь будут зависеть от сервиса и специалистов в нём работающих.

Сравнение

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

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

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

Соберём воедино разные варианты:

Плюсы YAML XLS INLINE EXTERNAL SERVICE
Лёгкость внедрения + +/− +/−
Наличие контекста + ?
Отсутствие спец. разметки + + +
Массовый перевод +/− + +
Внесение отдельных правок +
Редактирование интерполяции +/− +/− +/− ?
Синхронность перевода и разработки + ?

Вёрстка

Часть веб-сайта просто разъедется из-за разной длины слов в разных языках. (например в китайском), поэтому вам придётся подогнать и стили.

html:

<body lang='ru'>
</body>

css:

body.ru {}

Отдельно стоит упомянуть языки с написанием справа-налево.

Региональные особенности

Также будут отличаться:

Тексты рассылок

Как правило, шаблоны для рассылки писем лежат где-то отдельно в почтовой системе. И их текст не лежит в back или front приложении.

Пользовательские соглашения

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

Content

Проверяйте смысловое наполнение.

Допустим, вы составили задачу:

Один огурец стоит 15 рублей. Сколько будут стоить 4 огурца?

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

Огурец стоит 15 долларов.

Возможно где-то он столько и стоит. Но в моменте информация оказывается искажена. Если вслед за этим поменять и цену, меняется методическая часть задачи.

Огурец стоит 30 центов. Сколько будут стоить 4 огурца?

Мы хотели задавать задания по умножению двузначных чисел, а в итоге оказались либо в дробях (0.3 доллара), либо вообще в других единицах измерения (центы), либо появились трёхзначные числа.

Можно заменить огурец на другой овощ или фрукт который отразит желаемое. И поменять соответствующие картинки, если таковые имеются.

Знакомые нужные вещи

Сразу расшифрую - это отсылка к роману Кинга "Нужные вещи"

Всё, что пользователь видит на сайте, должно быть ему знакомо. А именно:

Изображения

Придётся поменять многие картинки на сайте, если они изображают людей и/или предметы таким образом, чтобы изображения были интернациональны, а предметы знакомы.

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

Отдельно стоит обсудить рисованые и/или стилизованные изображения. Например, если вы захотите нарисовать японца, то лучше подойдёт "аниме" стиль, нежели буквальное изображение действительности.

Озвучивание

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

Анимация

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

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

Адреса

Вы внедрили КЛАДР (уже не поддерживается) или ФИАС на сайте, рассчитанном на российскую аудиторию. Придется внедрить что-то другое. Глобальные адресные системы очень часто не полные. Специальные системы и/или базы внутри страны тоже грешат, но меньше.

Платёжные системы

У вас будет интеграция с другой платёжной системой, даже если ваша универсальная. То, что использовать, будет диктовать ваша аудитория, т.к. распределение использования платёжных систем в разных странах разное. А также у разных систем разная комисия.

Лично я сталкивался с xsolla, cloudpayments, stripe, alipay. Из перечисленных, у alipay самая жуткая документация и самая сложная интеграция. У stripe очень хорошая и приятная. Также очень хорош cloudpayments. xsolla чуть менее прозрачная.

Поля при регистрации

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

Если на сайте регистрируется компания, то надо отразить многие юридические моменты. Например - адрес компании.

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

От страны к стране могут варьироваться возрастные ограничения, и если при регистрации вы просите указать email, то имейте в виду, что может потребоваться предоставить и родительское согласие, если сайт ориентирован на детей. А также указывать родительский email при оплате, т.к. вы будете обязаны куда-то отправить электронный чек.

Разумеется, будет отличаться валидация.

Кроме того может отличаться порядок полей, например ФИО.

Другие способы аутентификации (и платежей)

Даже если при наличии OAuth может оказаться всё не так универсально. Посмотрите на локальные мессенджеры/системы для каждой конкретной страны, нарпример WeСhat для китайского сектора.

Домен

Возможно вы зарегистрируете новый домен. Превращение example.com -> example.org может оказаться не самым удачным. Выберите что-нибудь благозвучное для указанного региона.

CDN

Снова скажу очевидную вещь. Размещайте сервера ближе к получателю. Настраивайте CDN для статичного контента. Настраивайте реплику базы данных для чтения. Или размещайте всю базу, если возможно, в целевом регионе. Сайт размещённый на серверах в России будет открываться в Южной Америке в три раза дольше. Проверено.

На главную