Как локализовать приложение и игру через нейросеть

Почему обычный переводчик здесь не подходит

Казалось бы, можно скопировать файл в любой переводчик и получить результат. На практике так делать нельзя, и причин несколько.

• Переводятся ключи. `cart.empty` превращается в «корзина.пустая» — приложение перестаёт находить строки
• Ломаются плейсхолдеры. `{count}` становится `{количество}`, и подстановка значения падает
• Теряется структура. Вложенность и типы данных не сохраняются, JSON перестаёт быть валидным
• Нет контекста. Слово «Home» переводится как «дом» вместо «главная», потому что переводчик не знает, что это пункт меню

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

Как это работает

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

Модель получает жёсткую инструкцию: переводить исключительно значения, сохранять ключи, вложенность любой глубины, а также плейсхолдеры вида `{name}`, `{{count}}`, `%s`, `%d`, `:param`, HTML-теги и переносы строк. Всё это остаётся нетронутым.

Как готовить файл

Несколько приёмов, которые заметно повышают качество результата.

Режьте по смыслу, а не по объёму

Лимит — 60 000 знаков на задачу, но дробить файл лучше по смысловым разделам: отдельно интерфейс, отдельно тексты ошибок, отдельно описания. Так модель видит однородный контекст и переводит последовательнее, а вам проще проверять результат.

Добавьте глоссарий прямо в задачу

Если в проекте есть термины с устоявшимся переводом, перечислите их в тексте задачи: «Board переводить как „доска“, Card — как „карточка“». Модели хорошо следуют таким указаниям, и терминология не разъедется между файлами.

Учтите длину строк

Немецкий текст обычно длиннее английского на треть, а китайский — вдвое короче. Если интерфейс свёрстан впритык, попросите модель держаться близко к длине оригинала. Это не гарантия, но заметно снижает число переполнений.

Какую модель брать

Для структурированных данных лучше модели посильнее: они аккуратнее следуют формату и реже ломают JSON на длинных файлах.

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

С каких языков начинать

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

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

Дальше ориентируйтесь на аналитику: посмотрите, откуда уже приходят пользователи без всякой локализации. Эти страны и есть первые кандидаты — там спрос подтверждён, а не предполагается.

Отдельно про языки с письмом справа налево — арабский, иврит. Перевод строк здесь простая часть; сложная — вёрстка интерфейса в зеркальном направлении. Если фреймворк это не поддерживает из коробки, локализация текстов не поможет.

Подводные камни

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

• Множественные числа. В русском три формы вместо двух английских — если в проекте используется плюрализация, правила нужно проверять руками
• Короткие неоднозначные строки. «Open», «Close», «Set» без контекста переводятся наугад — добавьте комментарий прямо в задачу
• Гендерные формы. «Вы удалили» и «Вы удалила» — модель не знает пол пользователя, такие строки лучше формулировать нейтрально
• Форматы дат и чисел. Их локализация — задача кода, а не перевода
• Юридические тексты. Оферты и политики конфиденциальности переводить автоматически не стоит

Как встроить это в процесс разработки

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

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

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

Сколько времени и денег это экономит

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

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

Что ещё пригодится

• Перевод текстов — для описаний в сторах, справки и рассылок, где формат свободный
• Копирайтинг — если тексты интерфейса нужно сначала написать, а не перевести
• Генерация изображений — локализованные скриншоты и промо для сторов
• Звук для игры — если локализуется игра, а не приложение