Технический перевод для IT и SaaS-продуктов

Строки интерфейса, документация API и справочные центры — переведены с сохранением плейсхолдеров и разметки.

Локализация IT-продукта — это не «перевод текста», а работа с интерфейсом, документацией и юридическими текстами одновременно, так, чтобы продукт выглядел родным на новом рынке. Строки интерфейса, API-документация, справочный центр, пользовательские соглашения — разные жанры с разными требованиями, и переводить их «одной кистью» нельзя. Мы работаем с продуктовой документацией, сохраняя переменные, плейсхолдеры, разметку и тон продукта.

В UI-строках важнее всего не сломать продукт: переменные {count}, плейсхолдеры %s, ICU-конструкции для множественного числа и ограничения по длине кнопок должны остаться нетронутыми, иначе интерфейс поедет или упадёт. Мы переводим строки в родных форматах — JSON, YAML, .po/.pot, .strings, XLIFF, .resx — сохраняя ключи и структуру, а не «плоский текст». Термины интерфейса держим согласованными со справкой: если в меню Settings → «Настройки», то и в документации то же слово, а не «параметры».

API-документацию переводим, не трогая код: имена методов, эндпоинты, примеры запросов и параметры остаются как есть, а переводится только описательная часть — иначе разработчик не сможет скопировать пример. Справочные центры и базы знаний адаптируем под тон продукта и реальные вопросы пользователей, а не переводим дословно. Юридические тексты — EULA, политику конфиденциальности, условия использования — переводит специалист с юридическим уклоном: здесь важна точность формулировок, а не гладкость.

По каждому продукту ведём термбазу и память перевода: новая версия интерфейса или документации сравнивается с предыдущей, переводятся только изменённые строки, а терминология гарантированно совпадает между релизами. Это критично для SaaS с частыми обновлениями — вы не платите за повторную локализацию всего продукта при каждом апдейте и не получаете «разъехавшийся» перевод между версиями.

Что мы переводим

UI-строки и локализация

Строки интерфейса с сохранением переменных, плейсхолдеров и ограничений по длине.

API-документация

Референсы эндпоинтов, SDK-гайды и примеры кода — без искажения синтаксиса.

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

EULA, политика конфиденциальности, условия использования с юридической точностью.

Справочные центры

Базы знаний и статьи поддержки, адаптированные под тон продукта.

Как проходит перевод

IT и SaaS: от загрузки документа до сдачи готового перевода в исходном формате.

01

Загрузка

Загрузите YAML/JSON-строки, Markdown-документацию или экспорт справочного центра.

JSON, YAML, Markdown
Git-совместимые форматы
02

AI-оркестрация

Роутер выбирает модель, обученную на технической и IT-терминологии.

03

Редактор-инженер

Редактор с опытом в разработке проверяет термины и плейсхолдеры.

04

Сдача

Готовые строки — с сохранением исходной структуры файла.

Форматы, с которыми мы работаем в этой отрасли

JSONYAMLPOXLIFFMarkdownXML

Тарифы

Те же три уровня, адаптированные под объём и срочность отраслевой документации

Full

Перевод + редактура инженером профильной специализации.

  • Инженер-переводчик по отрасли
  • Полная редактура
  • Персональная термбаза
Express

Срочная сдача, приоритетная очередь.

  • Приоритетная очередь
  • Сдача от 24 часов

Частые вопросы

В каких форматах вы принимаете строки на локализацию?

В родных форматах локализации: JSON, YAML, gettext (.po/.pot), Apple .strings, XLIFF, .resx и других. Ключи, структуру и порядок сохраняем — вы получаете файл, который сразу встаёт обратно в проект, а не «текст, который надо разложить руками».

Не сломаете ли переменные и плейсхолдеры в строках?

Нет, это базовое требование. Переменные {name}, плейсхолдеры %s/%d, ICU-конструкции для множественного числа и HTML-разметку мы не трогаем — переводится только текст вокруг них. Дополнительно проверяем, что перевод укладывается в ограничения по длине для кнопок и меню.

Как обеспечиваете единство терминов между интерфейсом и документацией?

Ведём общую термбазу продукта: слово из меню и то же слово в справке и API-доках берутся из одного источника. Если в интерфейсе Settings переведено как «Настройки», документация не назовёт это «параметрами». Термбаза остаётся у вас и работает на всех следующих релизах.

Продукт обновляется каждую неделю. Переводить всё заново?

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

Переводите ли API-документацию, не ломая примеры кода?

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