Локализация ПО и перевод API-документации
Строки интерфейса, плейсхолдеры и разметка остаются целыми: JSON, YAML, XLIFF, PO — и перевод прямо из CI через API.
Локализация — это работа со строками, а не с текстом. В строке «{count} files selected» переводчик обязан сохранить плейсхолдер, учесть три формы русского множественного числа и не вылезти за ширину кнопки. В API-документации наоборот: имена параметров, код-блоки и пути эндпоинтов не переводятся вовсе, а описания — переводятся, и граница между ними должна соблюдаться в каждом абзаце. Мы валидируем плейсхолдеры и разметку автоматически: если в переводе потерялся {var} или разорвался тег, файл не пройдёт проверку и не уедет к вам.
Локализация встраивается в ваш цикл релизов: подключите репозиторий или отправляйте файлы через API — новые строки уходят в перевод при каждом обновлении, готовые возвращаются pull request'ом или ответом API в том же формате. Память переводов гарантирует, что при релизе вы платите только за новые и изменённые строки, а глоссарий продукта следит, чтобы названия фич и пунктов меню не переводились каждый раз по-новому.
Что мы переводим
JSON, YAML, PO, XLIFF, .strings — с сохранением ключей, плейсхолдеров, ICU-формата и ограничений по длине.
Markdown и OpenAPI: описания переводятся, код-блоки, параметры и примеры запросов остаются нетронутыми.
Базы знаний, туры по продукту и обучающие статьи — в тоне продукта и с терминами из интерфейса.
Заметки о выпуске к каждому релизу — быстро, в фиксированном стиле и с той же терминологией.
Почему это стоит доверить нам
Автоматическая проверка: {var}, %s, теги и ICU-конструкции на месте — битая строка не пройдёт в сдачу.
Новые строки уходят в перевод при каждом релизе, готовые возвращаются pull request'ом в том же формате.
Названия фич, пунктов меню и ролей переводятся одинаково во всех строках, доках и статьях поддержки.
Формы «1 файл / 2 файла / 5 файлов» разводятся корректно — включая ICU MessageFormat и gettext-плюралы.
Форматы, с которыми работаем
Частые вопросы
Как встроить перевод в наш CI/CD?
Два сценария. Простой: шаг пайплайна отправляет файлы локализации в наш API и забирает готовые — обычно это 20–30 строк конфигурации. Полный: подключаем репозиторий, отслеживаем изменения в файлах строк и открываем pull request с переводом. Новые строки при этом переводятся инкрементально, без пересдачи всего файла.
Что будет с плейсхолдерами и HTML-тегами внутри строк?
Они защищаются ещё до перевода: система размечает {переменные}, %-подстановки и теги как неизменяемые элементы, а после перевода проверяет, что все они на месте и в допустимом порядке. Строка с потерянным плейсхолдером просто не проходит контроль качества — вы не получите её в сдаче.
Короткие строки вроде «Save» невозможно перевести без контекста. Как вы с этим работаете?
Передавайте контекст любым доступным способом: ключи строк, комментарии разработчиков, скриншоты экранов. В нашем формате у каждой строки есть поле контекста, и редактор его видит. Если контекста нет, а строка неоднозначна, мы не гадаем — собираем список вопросов и уточняем у вас.
У нас ограничения по длине: русский текст не влезает в кнопки. Что делаете?
Если в файле задан лимит длины, он соблюдается автоматически — редактор подбирает компактную формулировку. Русский в среднем на 15–20% длиннее английского, поэтому для критичных экранов имеет смысл передать нам скриншоты: увидим, где перевод упрётся в вёрстку, до того как это увидят пользователи.
Переводите ли документацию со скриншотами интерфейса?
Да, и рекомендуем правильный порядок: сначала локализуются строки продукта, затем вы переснимаете скриншоты в русском интерфейсе, а мы переводим текст статей с терминами, совпадающими с UI. Надписи на статичных схемах и диаграммах переводим отдельным слоем или таблицей-легендой.
Смежные отрасли
Объём, стоимость и срок вы увидите сразу после загрузки, до оформления заказа.