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

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

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

• Перевод, то есть замена одних строк на другие. Скажем, при локализации команд меню программы: “New file” заменяется на «Новый файл», переводятся названия месяцев, дней недели и так далее.

• Адаптация. Здесь мы трансформируем форматы данных, логически зависимые от той страны, для которой создается модель локализации. Простейший пример — символ местной валюты ($ или какой-либо другой) и отображение числовых значений (с соответствующими десятичным и тысячным разделителями).

Ниже мы расскажем о подходах и инструментах, которые помогают нам с коллегами в локализации продуктов МойОфис для операционных систем Windows, Linux и macOS.

1. Всегда учитывайте важность основных составляющих локали

Ключевое понятие процесса локализации — локаль пользователя, которая является составным параметром. Полная локаль состоит из языка и региона, но также она может содержать добавочные параметры: найти их можно в настройках операционной системы (раздел «Язык и регион»).

Язык локали крайне важен. Однако если локаль включает в себя только язык, то часть сведений, такие как форматы даты/времени и обозначения валют, могут быть установлены неправильно. Иногда в зависимости от региона отличается даже правописание на одном и том же языке: например, в случае с локалями английский — США (en_US) и английский — Британия (en_GB). Таким образом, если вы игнорируете регион — вторую существенную составляющую локали, — ваше приложение может оказаться недостаточно адаптированным под пользователя. Помните также, что зачастую библиотеки и внешние инструменты требуют дополнительной локализации: большинство распространенных инструментов поддерживают небольшое количество языков и знают небольшое количество локалей. Но как только вы выйдете на специфический регион, то вам нужно будет дорабатывать библиотеку, так как вам могут потребоваться и специфические языки.

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

2. Используйте системные настройки в своих интересах

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

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

Корректная работа с системными настройками довольно сложна. Вы поддерживаете ограниченное количество локалей, в том время как из системы могут исходить самые разные варианты. Что будет при обнаружении системой неконсистентной локали? Например, если в настройках ОС указана связка голландский — Перу (nl_PE; т.е. голландский в качестве языка и Перу в качестве страны), немецкий — Вьетнам (de_VN) или английский — Россия (en_RU)? Изначально мы в МойОфис размышляли, разрешать ли работу с неконсистентными локалями, но пришли к отрицательному выводу. Наш механизм всегда выбирает из числа поддерживаемых локалей ту, которая, по нашему мнению, наиболее подходит пользователю, без потери возможности использовать региональные настройки как «заданные пользователем». Например, со стороны пользователя нам поступает локаль финский — Финляндия (fi_FI). Мы видим, что не поддерживаем ни этот язык, ни этот регион. Смотрим, должны ли мы выбрать конкретный язык или регион, если нет — применяем дефолтную локаль, в данном случае это английский — США (en_US). При этом подтягиваем параметры из системных настроек: десятичный и тысячный разделители, валюту, ее позицию, паттерн даты и времени.

Такое решение оказалось верным и минимизировало рассинхрон. Плюс позволило нам работать с четко определенными файлами ресурсов и добавлять внешние библиотеки, которые мы смогли правильно настроить с самого начала (подробнее о них читайте в пункте 8).

Подытоживая, локализации можно добиться двумя способами:

1. Сохранить локаль, применяемую в процессе локализации, вместе со всеми локализованными элементами, такими как шаблоны формул и алгоритмы сортировки. Напрямую повлиять на процесс локализации путем гибкой работы с системными настройками пользователя.

2. Напрямую повлиять на процесс локализации путем гибкой работы с системными настройками пользователя.

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

3. Храните код и логику локализации отдельно

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

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

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

4. Обеспечьте независимость внутренних механизмов от локали

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

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

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

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

5. Подозрительные локалезависимые элементы — повсюду

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

Предположим, что два сотрудника, чьи локали: английский — США (en_US) и русский — Россия (ru_RU), выступают соавторами документа. Каждый из них может видеть одно и то же число, локализованное как «1,000.1» и «1 000,1» соответственно. В упомянутом случае локализация нацелена на форматирование чисел, а именно на символы десятичного и тысячного разделителя. В США в качестве десятичного разделителя используется знак точки (.). В России это запятая (,). Тысячным разделителем в США выступает запятая (,), в России — пробел. Аналогично локализация определяет внешний вид других символов (например, символов валюты), шаблонов (таких как шаблоны формул, времени и даты) и системы измерений для разных культур.

6. Информируйте переводчиков и дважды проверяйте качество их работы

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

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

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

2. Второй подход используем мы в МойОфиc, и заключается он в том, что две основные локали наших продуктов (en_US и ru_RU) мы ведем сами, а для остальных случаев задействуем пул проверенных внешних переводчиков. Мы сами выбирали подрядчиков под конкретные собственные требования и сотрудничаем с ними уже длительное время; это обеспечивает погруженность переводчиков в контекст.

Компании-разработчику стоит тщательно подбирать переводчиков, контролировать их работу и, что немаловажно, проверять конечный продукт на качество. Никогда не пропускайте этот последний этап: и разработчики, и инженеры по контролю качества, и владельцы продукта (product owners) всегда должны участвовать в нем. Специальный отдел в нашей компании взаимодействует с переводчиками и также постоянно поддерживает связь с командой разработки.

7. Никогда не игнорируйте кодировки символов

Работая со строками, помните о разных стандартах кодировки символов (Unicode). Рассмотрим реальную ситуацию из нашей практики: в русской локали используется один символ пробела (обычный, U+0020), в то время как во французской локали – другой (non-breaking space, U+202F). При этом в системе устанавливается именно обычный пробел, а для конкретной локали "под капотом" из ресурсов вроде Общего репозитория языковых данных Unicode (CLDR) приходит другой. Затем в какой-то момент приложение выходит из строя из-за множества пробелов, обнаруженных системой.

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

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

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

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

8. Используйте внешние инструменты

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

Еще один аргумент в пользу внешних инструментов — тот факт, что существенная часть функциональности зависит от календарей. Мы много работаем со временем, датами и числами с точки зрения формул и форматирования. Например, даты в электронных таблицах могут быть записаны во множестве форматов — DDMM, MMDD, DDMMYY и так далее. И при вычислений формул, содержащих ссылки на такие данные, необходимо правильно их локализовать и внутренне приводить к единому формату. Это позволит корректно вычислять, скажем, какой день по отношению к тому или иному дню является пятым; или каков результат, когда вы вычитаете дату из даты или добавляете год или 25 дней к дате. Именно календари выполняют такие операции.

Для произведения календарных вычислений мы используем Общий репозиторий языковых данных Unicode (CLDR), который предоставляет приложениям информацию о локали, и Международные компоненты для Unicode (ICU), кросс-платформенную библиотеку на Unicode с поддержкой глобализации для программных приложений. ICU является обширной, всеобъемлющей библиотекой и используется в некоторых операционных системах Linux и в офисном ПО LibreOffice. Используйте ICU, если вы разрабатываете крупномасштабное решение для локализации.

9. Помните, что разные платформы имеют разные локализации

Мы разрабатываем ПО для различных платформ, таких как Windows, Linux, iOS, Web и Android. Приложения для разных платформ (например, в случае с Android и Windows) используют разные локализации. Поскольку изменить эту ситуацию нельзя, стоит просто принять ее. Имейте в виду, что у вас будут разные локализации, и с самого начала планируйте весь процесс с учетом этого.

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

Скажем, версии МойОфис для macOS и iOS поддерживают локаль французский_Бурунди (fr_BI), в то время как некоторые версии для Windows ее не поддерживают. Другой пример — наша настольная версия для Windows поддерживает локали башкирский — Россия (ba_RU) и татарский — Россия (tt_RU), однако другие платформы их не поддерживают.

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

10. Делайте запуск новых локалей эффективным с точки зрения ресурсов

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

Запуск новых локалей должен быть простым с точки зрения всех задействованных процессов и элементов, включая код, ресурсы, ваше взаимодействие с переводчиками, использование внешних библиотек, методы тестирования и автоматизации. Масштабирование механизмов в контексте локализации тесно связано с процессами тестирования и автоматизации. Протестируйте функциональность максимум в одной или двух локалях. В нашем случае это локали английский — США (en_US) и русский — Россия (ru_RU). Тестирование других локалей должно быть гораздо менее ресурсоемким. Создавайте меньше тестовых случаев и делайте тестирование более целенаправленным. На данный момент мы создали множество структур тестирования шаблонов, которые автоматизируют и облегчают тестирование новых локалей.

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

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

***

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