Привет! Меня зовут Александр Поляков, я руководитель команды i18n‑разработки в Фантехе Яндекса. Мы помогаем сервисам компании выходить на международные рынки, а именно решаем задачи, связанные с интернационализацией и локализацией интерфейсов.

В этом посте расскажу:

• какие именно решения для интернационализации фронтенда мы разрабатываем;

• какие есть правила форматирования данных для разных локалей и как определять эти локали;

• о проблемах переводов в современных реалиях.

Помогут мне в этом коллеги из фронтенда — Павел Петрухин и Алексей Ершков.

Термины

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

Интернационализация — совокупность технологических приемов разработки, которые упрощают адаптацию продукта к языковым и культурным особенностям регионов, отличных от того, в котором разрабатывался продукт. Проще говоря — это проектирование софта с целью максимального упрощения локализации. По-английски internationalization сокращают как i18n, где 18 — это число символов между буквами i и n в этом слове.

Локализация — процесс адаптации ПО к культуре какой-либо страны, например, перевод пользовательского интерфейса. По аналогии с i18n, l10n — сокращение localization, и 10 — это число символов между первым l и последним n. То есть локализация — это не просто перевод «Hello» на «Привет», но и использование местной валюты, десятичных разделителей и работа над другими деталями и элементами. Основная задача l10n — сделать софт более привычным для пользователя, а не просто его перевести.

Computer-Assisted Translation (CAT) tools — программное обеспечение для помощи переводчикам. Эти инструменты предоставляют различные функции, которые упрощают и улучшают процесс перевода текстов с одного языка на другой.

Главная цель нашей команды — сделать сервисы Фантеха доступными и удобными для пользователей во всех странах присутствия, при этом не сильно уронив скорость нашей разработки в РФ. 

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

Интернационализация Фантеха

Интерфейс почти всех продуктов Фантеха изначально был реализован на русском языке. Поэтому при выходе любого из сервисов в новую страну нужно оперативно перевести весь интерфейс на соответствующий язык. Для этого в первую очередь нужно интернационализировать свой код и добиться того, чтобы он умел работать с переводами и был готов к l10n. Это достигается путём выбора и внедрения в проект правильных i18n-библиотек, которые умеют работать как с языковыми, так и с культурными особенностями регионов.

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

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

Важно было унифицировать на старте сразу несколько вещей:

• выработать единый подход к определению локали пользователя;

• определиться с универсальным форматом переводов;

• зафиксировать одинаковые правила форматирования данных для разных локалей;

• создать общую библиотеку для интернационализации;

• разработать методологию качественного внедрения переводов;

• начать использовать Code First-подход;

• выработать единый подход к работе с RTL;

• написать инструмент синхронизации переводов с CAT tool.

Единый подход к определению локали пользователя

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

Существуют лучшие современные практики кодирования языковых тегов — BCP47, лежащие в основе Intl API (браузерного API для I18n и l10n).

Вы наверняка встречали подобное объявление локалей. Взять хотя бы те же языковые теги: ru для русского языка, en для английского. Рекомендации позволяют ещё и уточнять регионы, например, en-US — это английский язык в США, а he-IL — иврит в Израиле. Ряд языков может быть написан как кириллическими символами, так и латинскими, что тоже можно отразить в теге: сербский язык, sr-Cyrl (сербский кириллический) и sr-Latin (сербский латинский). Кроме этого, в стандарте есть поддержка unicode-расширений, которые позволяют дополнять его.

Очень важно корректно определять локаль для пользователя и грамотно использовать ее при SEO-оптимизации.

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

Разметка — это метатекст, который несёт дополнительную информацию. Например, она может выглядеть вот так: «Купить подписку за {price} с триальным периодом {duration}». Вместо переменных в фигурных скобках могут подставляться нужные данные. В нашем примере — это стоимость подписки и её длительность.

Мы выбрали ICU Message Format — он довольно удобен для представления переводов, а ещё интуитивно понятен как разработчикам, так и переводчикам. Кроме этого, формат позволяет учитывать грамматическое многообразие и богатство естественных языков.

Вот список основных фич этого формата, которые мы активно используем.

• Плюрализация

{
  "mail.range":  "Напишем на почту за {days, plural, one {# день} few {# дня} other {# дней}}",
}

• Интерполяция

const title = 'Агата Кристи'

{
  "OnBoardingSubscriptionButton": "Слушать альбом {title}"
}

• Условный выбор (select)

{
  "subsriptionPurchase": "{availability, select, true {Доступна до} other {Недоступна с}} {date}"	
}

Причины выбора ICU весьма прозаичны:

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

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

• Наличие валидации.

• Поддержка со стороны CAT tools.

• Наличие большого количества библиотек на разных язык программирования.

Одинаковые правила форматирования данных для разных локалей

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

Полный список локальных особенностей должен где-то храниться и как-то описываться. Поэтому Unicode собрал огромную базу данных (CLDR, Common Locale Data Registry) и продолжает её поддерживать. Де-факто это набор XML-файлов, в которых и хранится вся нужная информация по отображению данных для каждой из существующих локалей.

К примеру, вот так выглядит файл с информацией обо всех мировых валютах.

Вот еще несколько примеров:

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

Общая библиотека для интернационализации

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

Для нас важно, что библиотека использует BCP47 и является обёрткой над Intl API для форматирования данных, а также поддерживает ICU Message Format.

Методология качественного внедрения переводов

Кроме внедрения i18n, интернационализацию нужно поддерживать, и важно не смещать фокус продуктовых команд с самого продукта на инфраструктурные задачи. А это значит, что вокруг i18n и l10n необходимо навесить множество автоматики и линтеров. Они будут подсказывать разработчикам, как корректно писать код, и позволят не забывать при этом про локализацию проекта. 

Бо́льшая часть подобной автоматики идет из коробки с Format.js, которая позволяет валидировать наличие переводов, их контекстов и заполнение всех полей в ICU-сообщениях. Однако часть автоматики необходимо реализовать руками. Яркий пример — генератор id для сообщений (мы планируем опубликовать его в опенсорс), а также автоматизированное получение, создание и разделение переводов.

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

Code First Approach Translations

В современных реалиях проектов есть две большие проблемы:

• устаревание переводов;

• сложная валидация.

Изначально мы не использовали Code First Approach Translations. Это приводило к проблеме, когда переводы становились неактуальными, потому что менеджеры вручную меняли что-то в CAT tool в обход разработки, и часто не на всех языках. Поэтому в рамках одного ключа возникали различия. 

Валидировать такие переводы сложно, так как источником правды являлся CAT tool, в котором нельзя понять, какие переводы устарели и не используются, а какие — актуальны.

Чтобы решить эти проблемы, мы ввели два изменения:

• Источником правды становится код.

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

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

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

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

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