Реализация локализации мобильного приложения на английский язык

Локализация мобильного приложения: где ломается английская версия

Локализация мобильного приложения чаще всего ломается не на переводе строк, а на assumptions, зашитых в код. Разработчик верстает экран под русский текст, где «Оформить заказ» занимает 15 символов, а английское «Proceed to checkout» — 19. При фиксированной ширине кнопки или высоте строки текст обрезается, кнопка уезжает за границу контейнера, а на маленьких экранах ломается вся сетка. То же с форматами дат: dd.MM.yyyy в английской версии читается как MM/dd/yyyy, и «03.04» превращается из третьего апреля в четвёртое марта — в отчётах, бронированиях и напоминаниях это критичная ошибка.

Отдельный класс проблем локализации — склонения и множественные числа. В русском «1 товар, 2 товара, 5 товаров» — три формы, в английском — две (1 item, 2 items). Если в коде зашита логика if (count === 1), английская версия либо покажет «1 items», либо сломает счётчик на нуле. Аналогично с падежами в шаблонах писем и пуш-уведомлений: подстановка имени в русское предложение работает, в английское — даёт «Hello, Ivan Ivanov!» вместо «Hi, Ivan».

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

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

Что даёт корректная локализация на английский

Конверсия на входе падает меньше

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

Отток после первого запуска снижается

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

Повторные правки интерфейса больше не нужны

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

Англоязычный рынок становится управляемым

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

Подходы к локализации: ручной, автоматизированный, гибридный

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

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

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

Как мы проводим локализацию: от аудита до передачи

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

1. Аудит строк. Собираем все текстовые ресурсы из кода и разметки, включая зашитые в логику подписи, форматы дат и чисел, тексты ошибок и push-уведомлений. На выходе — реестр строк с пометками, что переводится, что остаётся константой, а что требует переработки: склейка фраз через конкатенацию и жёстко заданные падежи при локализации ломаются первыми.
2. Проектирование словаря. Формируем глоссарий терминов и единый стиль для английской версии, чтобы один и тот же термин не переводился тремя способами в разных экранах. Заодно закладываем запас по длине строк: английские подписи в среднем на четверть длиннее исходных, и это напрямую влияет на вёрстку кнопок и табов.
3. Настройка пайплайна локализации. Подключаем файлы переводов к системе управления переводами и к сборке так, чтобы обновление строк не требовало ручной правки кода. Дальше новые строки попадают в словарь автоматически, а сборка подхватывает актуальную версию — расхождений между ветками не возникает.
4. Проверка вёрстки. Прогоняем экраны с английскими строками и смотрим, где текст обрезается, переносится некрасиво или наезжает на элементы. Правки вносим в разметку, а не подгонкой перевода под исходную длину.
5. Тестирование на устройствах. Проверяем сценарии на реальных аппаратах: смена языка на лету, форматы дат и чисел, сортировка списков, поиск, уведомления. Отдельно смотрим крайние случаи — длинные имена, отсутствующие строки, поведение при переключении языка во время работы приложения.
6. Передача. Отдаём словарь, настроенный пайплайн и инструкцию, как добавлять новые языки без пересборки логики. Дальше команда заказчика расширяет локализацию самостоятельно.

Такой порядок убирает главную причину срывов — правки в перевод, когда проблема на самом деле в разметке или в логике экрана.

Что заказчик получает после локализации приложения

Локализация — это не только переведённые строки. После релиза английской версии у команды остаётся набор артефактов, по которым продукт развивается дальше без повторного «переводческого спринта» на каждом обновлении.

• Файлы локализации — структурированные ресурсы по языкам (строки, форматы дат, чисел, валют, единиц измерения). Разделены по экранам и модулям, чтобы правка одной фразы не задевала остальные.
• Глоссарий терминов — согласованный словарь продуктовых и доменных понятий с переводом и пометкой «не переводить». Убирает разнобой, когда один и тот же термин на разных экранах звучит по-разному.
• Схемы экранов с привязкой строк — карта, где видно, какой ключ отвечает за какой элемент интерфейса. Новая строка добавляется в нужное место, а не «куда-нибудь».
• Регламент обновления — порядок действий при добавлении текста: кто вносит строку, как она попадает в файлы локализации, какие проверки проходит до релиза.
• Инструкция для команды — короткий документ для разработчиков и контент-менеджеров: как работать с ключами, что делать с длинными фразами, как проверять вёрстку после правок.
• Чек-лист приёмки — набор проверок перед выпуском: полнота перевода, отсутствие обрезанных надписей, корректные форматы и раскладка на реальных устройствах.
• Отчёт по покрытию — доля переведённых и проверенных строк по экранам. Видно, что осталось, и не приходится искать пропуски вручную.

Эти артефакты передаются команде заказчика вместе с приложением. Дальше английская версия обновляется штатным порядком: правки идут через глоссарий и регламент, а не через разовый перевод «с нуля».

Кейс: как английская версия перестала ломать вёрстку

К нам пришло приложение сервиса доставки: русская версия работала стабильно, а английская после запуска дала волну жалоб. На 40% экранов текст обрезался или наезжал на соседние элементы — кнопки уезжали за границу карточки, заголовки в две строки перекрывали иконки, а на экране оформления заказа сумма и подпись поля слипались в одну строку. Пользователи не понимали, что нажать, и бросали корзину на последнем шаге.

Причина оказалась не в переводе, а в вёрстке. Макеты собирались под русские строки: фиксированная ширина контейнеров, жёсткие высоты кнопок, переносы, зашитые в разметку. Английские формулировки в среднем на 30-40% длиннее, и там, где русский текст помещался, английский уже нет. Отдельно добавили проблему форматы: даты, суммы и разделители разрядов выводились по одной схеме для всех языков.

Мы начали с инвентаризации: прошли по всем экранам и собрали список мест с фиксированными размерами. Дальше перевели интерфейс на самоподстраивающиеся контейнеры — высота по содержимому, перенос строк вместо обрезки, ограничение по числу строк только там, где это осознанное решение. Форматы дат и чисел вынесли в отдельный слой, который подставляет правила под выбранный язык, а не под регион сборки.

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

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

Duolingo

Чем отличается локализация от интернационализации?

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

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

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

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

Частые технические сомнения при локализации на английский

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

Нужно ли подключать отдельный шрифт под латиницу?

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

Почему нельзя просто отдать строки переводчику и вставить обратно?

Потому что часть строк — не текст, а логика: склонения, порядок слов в предложении, форматы чисел и дат. Английский требует другого порядка и разделителей — «1,234.56» вместо «1 234,56», месяц перед днём в датах. Мы выносим такие значения в параметры локали, чтобы формат подставлялся системой, а не хардкодился в строке.

Как вы работаете с правками от носителей языка?

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

Обсудим вашу задачу по локализации мобильного приложения

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

Что стоит подготовить к разговору

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

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