Локализация мобильных приложений
Я уже раза два рассказывал на канале про локализацию мобильных приложений и как я это делаю. Но мой подход значительно прокачался с тех пор, а я об этом вам еще не рассказал.
Первичный подход был такой: был скрипт, который брал пачку строк из файла локализации, был промпт с описанием правил перевода, и всё это отправлялось в OpenAI API. Причем следующая пачка строк брала часть предыдущего хвоста, чтобы было хоть какое-то согласование стилей в переводах, к примеру согласованность ты/вы и прочие языковые нюансы.
Второй заход был такой: весь флоу переложил на Claude Code (здесь был
пост), от первого захода переняли правила, только CC теперь сам читает все строки, может заглянуть в код проекта и понять, как используется строка и в каком контексте, агент видит всю картину масштабнее. И мне казалось, что вот оно, более качественный подход: находилось множество проблем в переводах от первичного захода, и всё было прекрасно.
Но! Несколько недель назад в голову пришла мысль: а что, если перевод так себе? А пришел я к такой мысли не просто так. Потребовалось расширить кол-во языков в одном приложении, и когда агент начал переводить приложение на 2 китайских языка (традиционный и упрощенный), он сам решил запустить на iOS-симуляторе некоторые экраны и проверить визуально отображение строк на китайском. И появились нюансы, которые не были понятны при чтении строк и даже при просмотре кода. И тут я понял, что суперважно, чтобы агент верифицировал переводы визуально на всех экранах и состояниях.
Через CC проработали демо-сценарии генерации скриншотов всех экранов в разных состояниях. Там, где контент экрана длинный и нужно скроллить, скриншотов такого экрана делается несколько в нужных положениях скролла.
Скриншоты генерируются через fastlane, для одного языка это занимает минут 20-25, и получается до 150 скриншотов. Я делал уже 3 захода на оптимизацию скорости съемки, но пока это какой-то предел, так как учитываются еще анимации переходов, и fastlane дожидается чистого отображения контента после анимации, чтобы заснять нужный кадр, сделать скролл, если он есть, и еще раз снять кадр.
И так получается порядка 150 скринов, которые агент дальше по одному изучает.
Получается так: агент имеет правила локализации, под каждый язык дописывает нюансы, читает все строки, находит проблемные места в переводах, если это верификация существующего перевода. А если новый язык, то сначала переводит все строки, равняясь на переводы пары языков рус/англ, чтобы понимать контекст, некоторую связанность и правильно улавливать смыслы.
Затем выделяет места, которые точно нужно перепроверить на визуальной стадии, запускается фоновый процесс съемки всех скриншотов, и агент уходит в ожидание. Проходит 20+ минут, агент приступает к визуальному осмотру каждого скриншота, находит проблемы, вносит правки. Если нужно, правит в коде формирование строки, меняет форматтеры и прочие нюансы.
После этого снова запускает прогон съемки экранов, но уже не весь, а только там, где нужно проверить исправления. И только после этого заканчивается цикл перевода или верификации перевода.
Последний подход выявил массу проблем в коде как для языков, где используется RTL (справа налево), так и для других языков. В коде составные строки формировались простейшей конкатенацией, не всегда учитывались форматы локалей и было много хардкода при формировании составных строк.
И если честно, уверен, мало какой разработчик, даже senior пупер-дюпер уровня, знает все нюансы форматтеров, особенностей некоторых символов в разных языках, неразрывных пробелов, BiDi и прочего-прочего.
Простейшие примеры: $10 и 10 €, 1.5 и 1,5, 08/09/2026 с разным порядком дня и месяца, турецкие i/İ/ı/I, арабский RTL вперемешку с email или цифрами, французские неразрывные пробелы перед некоторыми знаками. А есть еще plural forms, разные виды кавычек, Unicode normalization, ZWJ, переносы в китайском/японском/тайском и куча других мелочей, которые легко вообще не заметить, пока не увидишь реальный экран.