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

Локализация (часто сокращается до L10n) — это работа по адаптации приложения, его присутствия в магазине и сопутствующего маркетинга для пользователей конкретных языков, регионов и культурных контекстов. Это больше, чем перевод. Полная локализация включает переведённые UI‑тексты, переведённые метаданные магазина, переведённые подписи к скриншотам, корректное под локаль форматирование валют и дат, культурно уместные изображения, региональные способы оплаты (UPI в Индии, Pix в Бразилии, iDEAL в Нидерландах) и адаптированные юридические уведомления. Если пропустить хотя бы что‑то одно, для местных пользователей продукт читается как иностранный, сделанный наполовину.

App Store и Google Play автоматически показывают локализованные страницы пользователям на их предпочитаемом языке — если вы их предоставили. Если нет, пользователь видит англоязычную страницу по умолчанию, что значительно снижает конверсию на неанглоязычных рынках. Вопрос редко звучит как «локализовать ли»; он звучит как «какие рынки в первую очередь и насколько глубоко».

Опубликованные данные Apple и Google и независимые ASO‑исследования стабильно показывают одно и то же: локализованные скриншоты увеличивают конверсию установок намного сильнее, чем локализованные заголовки или описания. Причина — плотность информации. Скриншот за один визуальный момент сообщает продукт, языковое покрытие, лоск бренда и культурное соответствие. Локализованный заголовок сообщает только о том, что приложение существует на вашем языке.

Прирост неоднороден. Восточноазиатские рынки (Япония, Корея, Китай, Тайвань) исторически демонстрируют самый большой прирост установок от локализованных скриншотов — часто 30–60% над англоязычным дефолтом — потому что эти рынки наиболее скептичны к нелокализованным страницам. Европейские рынки обычно дают 10–25% прироста, а англоговорящие неанглоязычные рынки (Нидерланды, Швеция, Финляндия) иногда показывают всего 5–15%. Планируйте инвестиции в локализацию исходя из ожидаемого прироста, а не только из размера рынка.

Для большинства приложений первые волны локализации с самым высоким ROI: немецкий (de), французский (fr), испанский (es), итальянский (it), португальский (Бразилия) (pt-BR), японский (ja), упрощённый китайский (zh-Hans) и корейский (ko). Они покрывают рынки с наибольшим объёмом установок и наибольшим приростом от локализации. Вторая волна часто добавляет: русский (ru), польский (pl), нидерландский (nl), турецкий (tr), арабский (ar), вьетнамский (vi) и традиционный китайский (zh-Hant).

Apple и Google поддерживают значительно больше локалей (у Apple более 175 комбинаций «язык / страна»), но длинный хвост редко оправдывает усилия, если у вашего продукта нет специфического market fit. Начните с восьми, измеряйте прирост конверсии по рынкам и расширяйтесь в те, что дают самый сильный сигнал.

Три подхода: (1) Отправлять подписи в профессиональный сервис перевода (Smartling, Lokalise, Crowdin) — наивысшее качество, самый медленный сроки, дороже всего за локаль. (2) Использовать LLM (GPT-4o, Claude, Gemini) для первого прохода с последующим ревью носителями языка — быстро, дёшево, удивительно неплохо для коротких маркетинговых текстов. (3) Нанимать носителей напрямую через Upwork или Fiverr — часто лучший баланс для команд на ранней стадии.

Что бы вы ни выбрали, никогда не выпускайте машинный перевод подписи к скриншоту без человеческого ревью. Маркетинговый текст слишком много значит, чтобы доверять его непроверенному автоматическому переводу. Стоимость неуклюжей японской подписи — это сотни потерянных установок; ревью стоит 5–20 долларов за локаль.

Именно здесь чаще всего спотыкаются. Перевод «$19.99/month» в «19,99 $/Monat» в немецкой странице — ошибка; должно быть «19,99 €/Monat». Конвертация валюты по справедливому паритету покупательной способности, корректные под локаль десятичные разделители (запятая в большей части Европы, точка в США/Великобритании), системы единиц (см против дюймов), форматы дат (DD/MM/YYYY против MM/DD/YYYY против YYYY-MM-DD) и форматы времени (12h против 24h) — всё это должно отрисовываться под каждую локаль.

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

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

Для RTL‑рынков относитесь к скриншот‑шаблону как к отдельному артефакту, а не как к переводной накладке. Прирост от правильно отзеркаленного арабского скриншота по сравнению с лево‑направленным арабским — большой; прирост от улучшения уже отзеркаленного — небольшой. Сначала добейтесь правильного макета.