Разработка программ не заканчивается с первым релизом. После этого может быть выпущено n-ое количество новых полноценных версий, а также просто текущие обновления внутри версий. Локализация программного обеспечения позволяет расширить целевую аудиторию, разрабатываемого ПО, но в чем смысл быстрой разработки, если вы не сможете выпустить обновленную версию для всех ваших клиентов сразу? Зачастую локализации продуктов не дается первоочередной приоритет, исходя из чего, многие пользователи используют более ранние версии программы, которые поддерживают их локальный язык.

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

При непрерывной локализации способ должен иметь туже структуру, что и разработка. При настройке автоматизации процесса новые строки на перевод будут импортированы в CAT-систему буквально за считанные минуты. При реализации процесса локализации для связи репозитория и CAT-системы в основном используют: коннекторы, либо соединение по средствам API.

Также очень важно понять, как конкретные строки будут попадать в каталог. Один из самых популярных способов - это использование библиотеки интернационализации gettext (https://ru.wikipedia.org/wiki/Gettext) проекта GNU, которая имеет поддержку множественного числа. Ее основное отличие от подобных инструментов заключается в том, что для обозначения переводимых строк в тексте программы используются английские оригиналы, что сильно упрощает работу, так как в основном разработка идет на английском.

Основные форматы, используемые при работе с данной библиотекой, - .mo (Machine Object), .po (Portable Object), .gmo (GNU .mo). Там содержатся, как строки на перевод, так и комментарии переводчика.

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

Также в продолжение темы множественного числа при локализации необходимо упомянуть Fluent Syntax, первая версия которого была выпущена весной 2019. Это спецификация для хранения переводов, а так же бета-релиз парсеров на JavaScript, Python и Rust.

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

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

Fluent использует ссылки на сообщения – инструмент для поддержки единообразия переводов, при выполнении ссылки разрешаются в наборе bundles. Благодаря ассиметричной природе данной спецификации, также функционал Fluent помогает рещить вопрос с капитализацией терминов. Более подробно о работе Fluent можно почитать тут (https://habr.com/ru/post/448944/).

Говоря об инструментах локализации, также необходимо упоминать про такую платформу, как Serge (String Extraction and Resource Generation Engine). Строки, закоммиченные в репозитории, автоматически отправляются на перевод и автоматически возвращаются в систему контроля версий, что позволяет разработчикам оградиться от лингвистической составляющей проекта. При разработке с использование Serge при изменении в каком-то из файлов локализационный робот фиксирует изменения во всех версиях в течении 15 минут.

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