Вынесите строки из кода до того, как начнёте локализацию
Если текст интерфейса зашит прямо в код — hardcoded string в JSX или Kotlin-файле, — локализовать продукт нельзя в принципе, сначала строки нужно вынести во внешние файлы ресурсов: JSON, YAML, .strings, ARB, gettext PO. Это разовая, но обязательная инженерная работа (string externalization), и чем раньше её сделать, тем дешевле каждая следующая локализация — переводчик работает с файлом ресурсов, а не с исходным кодом.
Плюрализация — не «добавить окончание»
В английском обычно два варианта числа — единственное и множественное («1 file» / «5 files»), но в русском их три: «1 файл», «2 файла», «5 файлов» — и правило выбора формы нелинейно зависит от последней цифры числа. Если строка жёстко зашита как `{count} file(s)`, на русский её невозможно локализовать корректно вообще — нужна поддержка множественных форм на уровне формата строки: ICU MessageFormat в вебе и мобильных SDK или gettext-плюралы в других экосистемах. Закладывайте поддержку плюрализации в формат строк с самого начала, а не когда придёт первая жалоба от русскоязычного пользователя.
Плейсхолдеры и переменные — под защитой
Каждая строка с плейсхолдером вроде `{userName}`, `%s` или `{{count}}` — потенциальная точка отказа: переводчик может случайно изменить регистр переменной, разбить её пробелом или потерять при перестановке порядка слов, естественной для русского языка. Хорошая практика — валидировать после перевода, что все плейсхолдеры исходной строки присутствуют в переводе в неизменном виде автоматически, а не полагаться на внимательность переводчика.
Учитывайте длину текста и, при необходимости, RTL
Русский текст в среднем длиннее английского на 15–20%, и то, что аккуратно помещалось в кнопку на 80 пикселей на английском, может не поместиться на русском — заранее закладывайте резерв по ширине для интерфейсных элементов с фиксированным размером или используйте адаптивную вёрстку вместо жёстких лимитов. Если продукт планируется на языки с направлением письма справа налево (арабский, иврит), это отдельный слой работы — зеркалирование интерфейса и логические, а не физические, отступы — и его дешевле спроектировать с самого начала, чем добавлять поверх готового интерфейса.
QA-проход перед релизом
Перед тем как выкатить локализованный интерфейс, стоит пройтись по нему вживую, а не только проверить файлы: реальный интерфейс с реальными данными вскрывает проблемы, которые не видны в таблице строк — обрезанный текст в кнопке, наехавшую друг на друга надпись и иконку, забытую непереведённую строку из стороннего SDK. Полезно завести отдельный чек-лист скриншотов ключевых экранов на каждом языке и сверять его при каждом крупном релизе.
Если процесс перевода строк хотите делегировать целиком — вместе с валидацией плейсхолдеров, плюрализацией и возвратом файлов в исходном формате прямо из CI — этим занимается наша услуга локализации ПО.