Как локализовать мобильное приложение

TABLE OF CONTENTS

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

В этом и заключается ключевое различие: локализация мобильного приложения — это не просто перевод текста. Это адаптация приложения, страницы продукта и процесса QA для каждого целевого рынка. Apple сообщает, что App Store доступен в 175 регионах и на 40 языках, а в Android 13 появились системные настройки языка для каждого приложения. Иными словами, обе основные платформы теперь рассматривают выбор языка как ключевой элемент пользовательского опыта, а не как второстепенную задачу.

Это руководство описывает практические шаги для команд iOS и Android.

Краткий обзор:

Разделяйте локализацию внутри приложения и локализацию для App Store и Google Play.
Выносите строки наружу до начала перевода.
Обрабатывайте формы множественного числа, переменные, даты, валюту и RTL заблаговременно.
Тестируйте с псевдоязыками до отправки реальных переводов.
Локализуйте скриншоты и ресурсы магазина, а не только описания.

Что на самом деле включает локализация мобильного приложения

Работа по локализации обычно делится на два направления.

1. Локализация внутри приложения

Это сам продукт:

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

Apple прямо рекомендует использовать Xcode, API Foundation, Auto Layout, поддержку Unicode, каталоги локализованных ресурсов и символы, учитывающие направление, для подготовки приложений к международным рынкам. Android аналогично рекомендует использовать ресурсы с учётом локали, поддержку языка приложения и RTL-адаптированные макеты вместо жёстко заданного текста и позиционирования.

2. Локализация листинга магазина

Это то, как пользователи находят ваше приложение:

название приложения
подзаголовок или краткое описание
полное описание
ключевые слова
скриншоты
превью приложения или промо-видео

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

Начинайте с интернационализации, а не с перевода

Перевод — это последний этап в цепочке, которая начинается со структуры.

Выносите строки наружу и поддерживайте полную резервную локаль

На Android Google предупреждает, что ваш файл res/values/strings.xml по умолчанию должен содержать все строки, необходимые приложению. Если файл по умолчанию неполон, а устройство работает на неподдерживаемой локали, приложение может не загрузиться и показать ошибку с кнопкой принудительного закрытия. Именно поэтому локализация начинается с порядка в ресурсах, а не с выбора языков.

Для iOS Apple рекомендует отделять видимый пользователю текст и изображения от исполняемого кода, чтобы их можно было локализовать как файлы ресурсов. В современных рабочих процессах Apple каталоги строк — рекомендуемый подход в Xcode 15 и новее для строк, содержащих формы множественного числа.

Практическое правило:

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

Небольшой пример поможет визуализировать идею.

На Android обычно начинают с файла strings.xml по умолчанию:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

Затем ваш интерфейс читает ресурс вместо жёстко заданного текста на английском:

Text(text = stringResource(R.string.checkout_cta))

На платформах Apple в Xcode 15+ та же идея часто реализуется в каталоге строк. Упрощённый фрагмент Localizable.xcstrings может выглядеть так:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

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

Если ваше приложение также использует структурированные языковые файлы, наше руководство Best JSON Translators in 2026 поможет продумать автоматизацию и сохранение формата.

Если вам нужен конкретный инструмент для ресурсных файлов приложения, стоит обратить внимание на OpenL JSON Translator. Он предназначен для перевода файлов .json без нарушения ключей и структуры — именно то, что нужно, когда строки приложения хранятся в машиночитаемых файлах локализации. Рабочий процесс прост: загрузите JSON, экспортированный из приложения, CMS или конвейера локализации, выберите целевой язык и скачайте переведённый JSON-файл с той же структурой. Согласно странице продукта, инструмент поддерживает более 100 языков и файлы до 50 МБ, что делает его практичным инструментом первого прохода для команд локализации приложений, работающих со структурированным контентом.

Поддержка выбора языка на уровне приложения

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

На платформах Apple пользователи могут выбрать предпочитаемый язык для приложения независимо от языка устройства. На Android в Android 13 добавлена централизованная настройка языка приложения, и Google рекомендует включить автоматическую поддержку языка для каждого приложения или подключить ваш переключатель к официальным API.

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

Используйте платформенный стек локализации

Сопротивляйтесь желанию создать параллельную систему локализации, если в ней нет реальной необходимости.

Для большинства команд стандартного платформенного стека достаточно:

iOS: каталоги строк, Localizable.strings, .stringsdict, форматировщики Foundation, Auto Layout
Android: res/values/, папки ресурсов для конкретных локалей, LocaleConfig, setApplicationLocales(), supportsRtl

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

Локализуйте то, что большинство команд упускает

Команды часто переводят видимые предложения и упускают продуктовую механику вокруг них.

Множественное число, переменные и грамматика

Правила множественного числа не универсальны. Правила множественного числа Unicode CLDR определяют такие категории, как zero, one, two, few, many и other, и разные языки используют разные подмножества. Apple отмечает, что в старых рабочих процессах .stringsdict единственная обязательная категория — other, но пропуск языковых категорий всё равно может приводить к грамматически неверному результату. И Android, и iOS неспроста полагаются на обработку множественного числа с учётом локали.

Именно здесь наивный машинный перевод даёт сбой:

1 file и 2 files — просто в английском
В славянских языках часто требуется более двух форм множественного числа
В некоторых языках меняются существительные, глаголы или окружающие слова одновременно

Никогда не создавайте UI с множественным числом путём конкатенации фрагментов вроде "You have " + count + " messages". Используйте вместо этого платформенные ресурсы множественного числа.

Вот минимальная структура для каждой платформы.

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>

Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

Пример устаревшего формата .stringsdict для iOS:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

В Xcode 15 и новее Apple рекомендует обрабатывать множественное число в каталогах строк, но принцип остаётся тем же: передайте платформе один шаблон сообщения и позвольте ей выбрать правильную языковую форму.

Более подробно о гарантиях рабочего процесса для плейсхолдеров и структурированных строк читайте в How to Translate Technical Docs Without Breaking Code.

Даты, числа, валюта и единицы измерения

Apple прямо рекомендует использовать API Foundation для форматирования дат, длин, весов, цен и символов валют в разных локалях. Тот же принцип применим и на Android: форматируйте данные с помощью API, учитывающих локаль, вместо жёсткого задания пунктуации, десятичных разделителей или порядка единиц.

Типичные ошибки:

03/04/2026 означает разное в разных регионах
жёстко заданные символы доллара для рынков, не использующих USD
1,234.56 отображается неправильно в локалях, где запятая используется как десятичный разделитель
единицы измерения показываются в неправильной системе

Если ваше приложение содержит расписание, биллинг, окна доставки или аналитику — это часть локализации, а не косметическая доработка.

Расширение макета и поддержка письма справа налево

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

Apple рекомендует тестировать с псевдоязыками, включая псевдоязык с письмом справа налево и псевдоязык с удвоенной длиной, ещё до импорта реальных переводов. Android рекомендует использовать start и end вместо left и right, включать android:supportsRtl="true" и тестировать RTL-макеты на устройстве с помощью Force RTL.

Ваш чек-лист здесь прост:

позвольте кнопкам и меткам расширяться
избегайте контейнеров фиксированной ширины для важных элементов UI
зеркалируйте направленные элементы интерфейса там, где это уместно
проверяйте иконки, шевроны, последовательности шагов и карусели в RTL
тестируйте смешанное направление текста, например арабский интерфейс с латинскими названиями продуктов или промо-кодами

Изображения, иконки, скриншоты и видео

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

Это особенно важно для экранов онбординга, карточек-туториалов и ресурсов App Store. Пользователи не разделяют мысленно «маркетинговые визуалы» и «язык продукта». Они оценивают весь опыт целиком.

Локализуйте страницы в App Store и Google Play отдельно

Именно здесь многие команды теряют установки, даже выполнив локализацию внутри приложения качественно.

Требования App Store, которые нужно учитывать

Apple рекомендует локализовать метаданные в App Store Connect, включая описание приложения, ключевые слова, превью и скриншоты. Apple также сообщает, что на странице продукта можно разместить до 10 скриншотов и до 3 превью приложения для каждого поддерживаемого размера устройства и языка. Превью могут длиться до 30 секунд, а скриншоты имеют ещё большее значение при отсутствии превью, поскольку первые один-три скриншота могут отображаться в результатах поиска.

Из этого следует два вывода:

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

Требования Google Play, которые нужно учитывать

Google Play также рассматривает локализацию листинга как отдельный рабочий процесс. Play Console позволяет добавлять локализованный текст, скриншоты на нужном языке и локализованные графические ресурсы. Если вы добавите текстовые переводы без локализованных графических ресурсов, Google сообщает, что будут показываться визуалы на языке по умолчанию.

Google также отмечает, что если вы не добавите собственные переводы листинга магазина, пользователи могут увидеть автоматический перевод с пометкой о том, что он был сгенерирован автоматически. Это полезно как запасной вариант, но не является сильной стратегией выхода на рынок.

Одна особенно актуальная функция: Play Console заявляет, что может непрерывно переводить строки приложения с помощью моделей Gemini бесплатно. Более конкретно, Google уточняет, что это относится к строкам приложения из strings.xml в пакетах приложений, загруженных в черновые релизы, и что вы можете предварительно просмотреть сгенерированные переводы во встроенном эмуляторе перед публикацией. Это отличный способ ускорить первоначальное покрытие, но за ним всё равно должна следовать проверка человеком для критических сценариев.

Постройте процесс релиза и QA

Хороший процесс локализации — это не столько про ускорение перевода, сколько про сокращение неожиданностей при выпуске.

Шаг 1. Осознанно выбирайте целевые локали

Не начинайте с «переведём всё на 20 языков».

Начните с:

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

Доведение одного рынка до конца обычно лучше, чем половинчатая локализация пяти рынков.

Шаг 2. Подготовьте ресурсы, готовые к локализации

Перед началом перевода зафиксируйте и подготовьте:

исходные строки с контекстом
список скриншотов по локалям
глоссарий и правила использования названий продуктов
правила для плейсхолдеров
рекомендации по ограничению символов для текстов магазина
ответственных за проверку по каждой локали

Если приложение использует несколько репозиториев или форматов файлов, стандартизируйте именование и извлечение заранее.

Шаг 3. Сначала протестируйте с псевдолокализацией

На платформах Apple используйте псевдоязыки с удвоенной длиной и письмом справа налево. На Android тестируйте неподдерживаемые локали, Force RTL и настройки языка приложения. Это выявит:

обрезанные кнопки
обрезанные заголовки
скрытый текст
неправильное выравнивание
нелокализованные строки
жёстко заданные предположения о направлении left/right

Это один из самых дешёвых проходов QA, которые вы можете выполнить.

Шаг 4. Проведите лингвистическое QA на реальных устройствах

После получения переводов:

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

Если баг затрагивает онбординг, оформление заказа, верификацию личности или уведомления, считайте его блокирующим для релиза.

Чек-лист для первого спринта локализации

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

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

Примеры из реальной практики

Описанные выше идеи не являются теоретическими.

DoorDash выстроил перевод как платформенную задачу

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

В записи блога DoorDash от 2 февраля 2026 года компания сообщила, что её перестроенная платформа онбординга теперь обеспечивает регистрацию на всех рынках DoorDash и поддерживает быстрые международные запуски с бесшовной локализацией. Это именно то, как выглядит зрелая локализация: переиспользуемые рабочие процессы, региональная гибкость и меньше одноразовых решений.

Meta подошла к локализации и как к языковой, и как к проблеме размера приложения

Meta сообщает, что около 57% пользователей Facebook для Android и 49% пользователей Facebook для iOS используют приложение на языке, отличном от английского. В том же материале Meta говорит, что удаление встроенных файлов перевода сэкономило до 16,6 МБ в iOS-приложении и позволило Android добавить почти дюжину новых языков без увеличения размера приложения.

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

Финальный чек-лист перед релизом

Используйте это как последнюю проверку:

Все видимые пользователю строки вынесены наружу.
Ресурсы резервной локали по умолчанию полны.
Множественное число и плейсхолдеры используют нативную платформенную поддержку локализации.
Даты, время, числа, валюты и единицы измерения учитывают локаль.
RTL-макеты и смешанное направление текста протестированы.
Текст листинга магазина локализован для целевых рынков.
Скриншоты и превью локализованы для приоритетных языков.
Выбор языка в приложении работает корректно на iOS и Android.
Лингвистическое QA охватило наиболее важные пользовательские сценарии.

Заключение

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

Если вы делаете это впервые, не стремитесь к идеальному глобальному покрытию в первый день. Выберите одну-две стратегические локали, локализуйте приложение и страницу магазина вместе, проведите серьёзный проход QA и учитесь на реальном использовании. Если вы уже управляете ресурсными файлами и контентом для разработчиков, дополните этот рабочий процесс руководствами How to Translate Technical Docs Without Breaking Code и Best JSON Translators in 2026.

Если вы можете сделать только одно действие на этой неделе, сделайте это: выберите 1 локаль, выполните 1 проход псевдолокализации и локализуйте 1 соответствующий листинг в App Store или Google Play. Этот трёхэтапный тест расскажет о вашей готовности больше, чем перевод двадцати локалей параллельно.

Если вам нужен быстрый первый проход для текстов приложения, скриншотов или структурированных языковых файлов, используйте автоматизацию для ускорения черновика, а затем сохраните этап проверки человеком перед релизом. Именно это защищает доверие пользователей и предотвращает запуск в стиле «переведено, но не по-настоящему локализовано».

Ссылки

Apple Developer. Localization. https://developer.apple.com/localization/
Apple Developer. Creating Your Product Page. https://developer.apple.com/app-store/product-page/
Apple Developer. Upload app previews and screenshots. https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots
Apple Developer. Localizing strings that contain plurals. https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals
Apple Developer. Testing Your Internationalized App. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/TestingYourInternationalApp/TestingYourInternationalApp.html
Apple Developer. Get it right (to left). https://developer.apple.com/videos/play/wwdc2022/10107/
Android Developers. Localize your app. https://developer.android.com/guide/topics/resources/localization
Android Developers. Per-app language preferences. https://developer.android.com/guide/topics/resources/app-languages
Android Developers. Support different languages and cultures. https://developer.android.com/training/basics/supporting-devices/languages
Google Play Console Help. Translate and localize your app. https://support.google.com/googleplay/android-developer/answer/9844778?hl=en
Google Play Console Help. Create and set up your app. https://support.google.com/googleplay/android-developer/answer/9859152?hl=en
Unicode CLDR. Plural Rules. https://cldr.unicode.org/index/cldr-spec/plural-rules
DoorDash Engineering. Building a Platform to Translate DoorDash into Multiple Languages. https://careersatdoordash.com/blog/building-a-platform-to-translate-doordash-into-multiple-languages/
DoorDash Engineering. Unified Dasher Onboarding: A modular platform to scale globally. https://careersatdoordash.com/blog/doordash-unified-dasher-onboarding-a-modular-platform-to-scale-globally/
Engineering at Meta. Language packs: Meta’s mobile localization solution. https://engineering.fb.com/2022/05/09/android/language-packs/