Программный продукт, будь то десктопное приложение, SaaS-платформа, ERP-система или технический инструмент, разговаривает с пользователем тысячами строк: меню, диалогами, кодами ошибок, логами, подсказками, статьями помощи. Если этот голос непоследователен, если «Export» на одном экране становится одним грузинским словом, на другом - другим, а на третьем вообще остаётся на английском, пользователь воспринимает продукт как ненадёжный, а отдел поддержки получает поток лишних вопросов. Локализация программного обеспечения (software localization, L10n) обеспечивает именно эту последовательность и техническую точность.
Интернационализация и локализация: два этапа, одна цель
В профессиональной практике два понятия дополняют друг друга:
- Интернационализация (i18n) - задача разработчика: код должен быть построен так, чтобы текст хранился в отделённых от кода файлах ресурсов, даты и числа форматировались по системной локали, а интерфейс выдерживал изменение длины текста.
- Локализация (L10n) - наша задача: языковая, культурная и техническая адаптация этих файлов ресурсов для конкретного рынка.
Если продукт создан без интернационализации (текст записан прямо в коде, строки собираются из нескольких частей), локализация становится сложной и ненадёжной. Поэтому в начале проекта мы проводим технический аудит и даём команде разработчиков конкретные рекомендации, прежде чем начать переводить.
Что включает локализация программного обеспечения
- Строки интерфейса: меню, кнопки, диалоги, панель настроек, строка состояния, контекстное меню, описания горячих клавиш.
- Сообщения об ошибках и системные сообщения: коды ошибок, предупреждения, записи логов, которые часто должны быть однозначно идентифицируемы и для технической поддержки.
- Установщик и лицензия: мастер установки, лицензионное соглашение (EULA), уведомления об обновлении.
- Система помощи и документация: руководство пользователя, онлайн-центр помощи, база знаний, субтитры видеоуроков, технические спецификации.
- API и документация для разработчиков: где локализуется пояснительный текст, а примеры кода остаются без изменений.
- Учебные и маркетинговые материалы: туры по продукту, onboarding-письма, примечания к выпуску (release notes).
Строковые ресурсы: где скрываются технические риски
Программная строка редко бывает «простым предложением». Типичный файл ресурсов содержит:
- Переменные и placeholder: «%s», «%d», «{0}», «{{name}}», «${count}». Каждый должен остаться без изменений и попасть в грамматически правильное место в предложении.
- Правила множественного числа: ICU MessageFormat, .stringsdict, Android plurals. Грузинский, русский, польский и арабский используют радикально разную логику.
- Горячие клавиши и амперсанды: в приложениях Windows «&File» означает, что буква F активируется комбинацией с Alt. В локализованном меню эти буквы не должны повторяться.
- Фрагменты HTML и Markdown: строки часто содержат ссылки, полужирный текст, символы переноса строки.
- Конкатенацию: когда предложение собирается из нескольких строк («You have» + count + «new messages»), порядок слов на целевом языке может не совпасть. Такие случаи мы фиксируем и советуем разработчику объединить строку.
- Комментарии и контекст: msgctxt, комментарии разработчика, скриншоты. «Open» может быть глаголом (открыть) или прилагательным (открытый), и без контекста выбор зависит от догадки.
Наши CAT-инструменты автоматически защищают переменные и теги, а модуль QA проверяет каждую строку на потерю переменной, дублирование, превышение лимита длины и отклонение от терминологической базы.
Форматы файлов, с которыми мы работаем
- .NET: .resx, .resw
- Java: .properties, ResourceBundle
- Windows: .rc, ресурсы .dll, файлы установщика WiX
- macOS и iOS: .strings, .stringsdict, .xcstrings
- Qt: файлы .ts
- GNU: PO/POT (gettext)
- веб и кроссплатформенные: JSON, YAML, XLIFF 1.2 и 2.0, ARB, TOML
- документация: Markdown, DITA, DocBook, HTML, AsciiDoc, экспорт Confluence
- платформы: Crowdin, Lokalise, Phrase, Transifex, Weblate, а также прямая интеграция с Git-репозиторием и включение в процесс CI/CD
Файл мы возвращаем в той же структуре, с сохранением кодировки (UTF-8) и стиля переноса строк (LF/CRLF), так что перевод идёт прямо в процесс сборки.
Управление терминологией: язык продукта, который не меняется
Программный продукт развивается годами, часто руками разных команд. Единственная гарантия последовательности - централизованная терминологическая база и память переводов:
- Глоссарий фиксирует каждый ключевой термин продукта, его утверждённый перевод, определение и запрещённые варианты. Например: «workspace» = один утверждённый грузинский термин, а не транслитерация и не близкий синоним.
- Руководство по стилю устанавливает форму обращения (вы/ты), форму глагола на кнопках (повелительная или инфинитив), пунктуацию и использование заглавных букв.
- Память переводов обеспечивает, что однажды утверждённая строка автоматически повторяется в каждом обновлении, что сокращает сроки: в типичном обновлении новые строки составляют 5-15% всего объёма.
Лингвистическое и функциональное тестирование
Готовый файл ресурсов после встраивания в продукт проходит тестирование:
- Лингвистический QA: тестировщик проходит локализованную сборку в реальной среде (Windows, macOS, браузер) и проверяет обрезанный текст, попавшую в неверный контекст строку, непереведённые элементы, проблемы кодировки.
- Функциональный QA: поведение локализованной версии не отличается от оригинала: горячие клавиши работают, форматы совпадают с системной локалью, сортировка идёт по грузинскому алфавиту, поля принимают грузинские символы.
- Регрессия при обновлении: в каждой новой версии проверяются только изменённые и новые строки, что делает процесс быстрым.
Каждая проблема фиксируется идентификатором строки, скриншотом и предложенным исправлением, чтобы разработчику не потребовался дополнительный поиск.
Непрерывная локализация в agile-командах
Современные продукты выходят двухнедельными спринтами или ещё чаще. Локализация должна следовать этому ритму, а не тормозить его. В модели непрерывной локализации (continuous localization) новые строки автоматически уходят из репозитория на платформу локализации, наша команда обрабатывает их за 1-2 рабочих дня, а перевод возвращается в виде pull request. В результате каждый выпуск происходит на всех языках одновременно, а практика «сначала выпустим на английском, грузинский потом», которая заставляет местного пользователя чувствовать себя второсортным, больше не нужна.
Часто задаваемые вопросы
В чём разница между интернационализацией и локализацией?
Интернационализация (i18n) - подготовка кода к многоязычной работе, задача разработчика. Локализация (L10n) - адаптация файлов ресурсов для конкретного языка и рынка. В начале проекта мы проверяем, насколько код готов к локализации, и даём нужные рекомендации.
Можете ли вы работать напрямую с нашим репозиторием?
Да. Мы работаем через Git-интеграцию с платформами локализации (Crowdin, Lokalise, Phrase, Weblate) или напрямую pull request-ами, что объединяет локализацию с вашим процессом CI/CD.
Как вы обеспечиваете, чтобы переменные и код не повредились?
CAT-инструменты воспринимают переменные и теги как защищённые элементы, а автоматический QA проверяет каждую строку на потерю или искажение переменной. Дополнительно локализованная сборка проходит функциональное тестирование.
Локализуете ли вы техническую документацию и центр помощи?
Да. Руководство пользователя, база знаний, документация API и release notes локализуются с той же терминологической базой, что и интерфейс, так что пользователь видит в статье помощи ровно те термины, что и на экране.
За сколько времени локализуется новый выпуск?
В модели непрерывной локализации строки типичного спринта (несколько сотен слов) готовятся за 1-2 рабочих дня, включая тестирование. Крупная первичная локализация планируется поэтапно, и срок мы называем после технического аудита.