Запустил приложение, получил первые отзывы из Польши и Германии - “Translation is broken”, “Дата отображается неправильно”, “Кнопка обрезана”. А ты думал, что просто перевёл текст через DeepL - и всё готово. Разберёмся, почему этот подход не работает и как сделать локализацию правильно: от strings в коде до описаний в App Store.
Локализация - это не то же самое что перевод¶
Локализация (l10n) - адаптация приложения для конкретного рынка. Не только текст, а весь пользовательский опыт: форматы дат и чисел, валюта, направление чтения (RTL для арабского и иврита), культурно уместные изображения, местные требования к конфиденциальности.
Просто перевод текста - это только половина работы. Вот почему:
- Дата 03/15/2026 в США - это 15 марта. В России или Украине та же запись выглядит как ошибка формата или 3 декабря
- Цена “$29.99” для американского рынка становится “27,49 €” для Германии - с запятой вместо точки и символом после числа
- Жест “thumbs up” - позитив в Европе, оскорбление в части Ближнего Востока
По данным исследования Centus, 87% потребителей не покупают на сайтах только на английском. Рынок локализационных услуг достиг $71.7 млрд в 2024 году и растёт на 7% ежегодно. Для мобильных игр качественная локализация даёт рост загрузок на 200-300% в новых рынках, для e-commerce - конверсия в покупку растёт на 150%.
Всего 8 языков - английский, китайский, испанский, французский, немецкий, японский, португальский, арабский - покрывают 80% онлайн-покупательской способности планеты. Не нужно локализовать под 40 языков сразу, но первые 3-5 уже существенно расширяют аудиторию.
Strings - техническая основа локализации¶
Всё начинается со strings - строк перевода, которые хранятся отдельно от кода. Это первый и главный принцип: никакого хардкода текста прямо в коде.
iOS: .strings, .stringsdict и .xcstrings¶
На iOS есть три формата, которые эволюционировали со временем:
.strings (классический формат)
Простые пары ключ-значение, хранятся в папках *.lproj:
/* Кнопка подтверждения */
"confirm_button" = "Подтвердить";
"welcome_message" = "Привет, %@!";
Каждый язык - отдельная папка: en.lproj/Localizable.strings, de.lproj/Localizable.strings, ru.lproj/Localizable.strings. Простой формат, но не поддерживает множественное число и метаданные.
.stringsdict (для множественного числа)
XML-формат для строк с числами, где форма слова зависит от количества. Необходим когда нужно “1 сообщение / 2 сообщения / 5 сообщений” - и это ещё сравнительно просто.
.xcstrings (Xcode 15+, современный стандарт)
Введён в Xcode 15, JSON-формат объединяет преимущества .strings и .stringsdict в одном файле. Поддерживает множественное число, варианты для разных устройств, комментарии переводчикам, состояние перевода (new / translated / reviewed / stale). Миграция через Editor → Convert to String Catalog в Xcode 15 занимает несколько минут. Именно на него стоит переходить для новых проектов.
Android: strings.xml¶
На Android все строки хранятся в res/values/strings.xml:
<resources>
<string name="confirm_button">Подтвердить</string>
<string name="welcome_message">Привет, %s!</string>
<plurals name="messages_count">
<item quantity="one">%d сообщение</item>
<item quantity="few">%d сообщения</item>
<item quantity="many">%d сообщений</item>
</plurals>
</resources>
Переводы кладутся в res/values-de/strings.xml, res/values-ru/strings.xml и т.д. Система автоматически подбирает нужный файл в зависимости от локали устройства.
Проблема множественного числа: сложнее, чем кажется¶
В английском языке два варианта: “1 message” и “2 messages”. Но:
- Русский и украинский: 4 формы (1, 2-4, 5+, плюс специальная для 11-14)
- Арабский: 6 форм
- Японский и китайский: 1 форма (нет грамматического множественного числа)
Как пишет SimpleLocalize:
Pluralization isn’t just about singular vs plural - it’s a complex linguistic feature that varies significantly across languages. Arabic has 6 plural forms, while Japanese has only 1. Your localization framework needs to handle all of these cases correctly.
Поэтому “У вас ” + count + ” сообщений” (конкатенация строк) - провальный подход. Порядок слов в предложении разный для разных языков, и разбитую строку невозможно перевести грамматически правильно. Правильно: один ключ с ICU-форматом или plurals, и переводчик сам вписывает все нужные формы.
Store descriptions: App Store и Google Play - два разных подхода¶
После того как приложение технически готово к локализации, нужно позаботиться о “витрине”.
Apple App Store¶
App Store поддерживает 40 локалей и требует ручной загрузки всех метаданных для каждого языка - автоматического перевода нет.
Что локализуется в App Store:
| Поле | Ограничение | Важность |
|---|---|---|
| App Name | 30 символов | Критическая - влияет на ASO |
| Subtitle | 30 символов | Высокая - видно сразу |
| Promotional Text | 170 символов | Можно менять без нового релиза |
| Description | 4000 символов | Высокая - SEO и конверсия |
| Keywords | 100 символов | Критическая - ASO ранжирование |
| Screenshots | 3-10 штук | Критическая - первая точка контакта |
Ключевая ошибка: переводить keywords дословно. Как пишут в AppLaunchpad, нужно rebuild your keyword list from scratch for each country - чтобы отражать как пользователи реально ищут на том языке. Дословный перевод ключевых слов - это унаследовать чужие SEO-ошибки вместо того чтобы занять свои позиции.
Скриншоты - самый важный элемент конверсии. Большинство пользователей не читают описание, но листают скриншоты. Локализованные скриншоты с текстом и культурно релевантными изображениями дают значительно более высокий CTR.
Google Play¶
Google Play поддерживает 70+ языков и имеет ряд отличий:
| Поле | Ограничение |
|---|---|
| App Name | 30 символов |
| Short Description | 80 символов |
| Full Description | 4000 символов |
| Screenshots | до 8 штук |
Google Play позволяет автоматический перевод описаний - но это отправная точка, не финальный результат. Автоматические переводы буквальны и теряются нюансы, важные для конверсии.
Важная деталь: App Store и Google Play определяют локализацию приложения не из текста описания, а из того, какие локали и переводы ты загрузил через App Store Connect и Play Console. Писать в описании “available in 10 languages” - пустая трата символов.
Минимальная и полная локализация store¶
Minimum Viable Localization (MVL) - 1-2 недели: только store metadata (название, описание, keywords, скриншоты). Цель - запустить на новом рынке и собрать первый фидбек.
Полная локализация - 4-8 недель: metadata + все строки интерфейса + QA тестирование на реальных устройствах.
In-app content: что ещё нужно локализовать¶
Strings и store descriptions - только часть работы. В реальном приложении есть ещё несколько слоёв.
Onboarding¶
Первые экраны после установки - критический момент для удержания. Если onboarding выглядит как машинный перевод или непонятен - 60-70% новых пользователей уходят уже на первой неделе.
Но даже качественный перевод onboarding’а недостаточен. Value proposition, которая резонирует в США (“Save time, save money”), может совершенно не цеплять в Японии, где ценится надёжность и безопасность. Это уже культурная адаптация, а не просто перевод.
Push-уведомления¶
Push-уведомления локализуются двумя способами:
- Локализованные ключи (рекомендуется для iOS): в payload указывается
loc-key, и iOS сам подставляет перевод из.stringsна устройстве - Серверная локализация: бэкенд отправляет готовый текст в зависимости от языковых настроек пользователя
Кроме текста важна культурная адаптация: время отправки (то что хорошо в 9 вечера в США - неприемлемо в 3 ночи по местному времени), тон (в Японии избегают прямых призывов), контент (промо “Black Friday” - только там где этот день есть).
In-app purchases и подписки¶
Apple позволяет локализовать название и описание каждого in-app purchase через App Store Connect API. “Premium Plan” по-английски звучит нейтрально, но локализованное название повышает конверсию в платёж.
Цены тоже нужно адаптировать - и это не просто конвертация курса. Apple и Google имеют tier-системы для разных рынков. Цена $4.99 в США соответствует ¥680 в Японии не по курсу, а по purchasing power parity.
Системные сообщения и ошибки¶
“Error 404”, “Network error” - это тоже контент, который видит пользователь. Английские ошибки в локализованном приложении сразу создают ощущение незавершённости. Локализуй все user-facing сообщения - ошибки, подсказки, tooltip-ы, пустые состояния (“No results found”).
Типичные ошибки при локализации¶
Хардкод строк в коде¶
// Неправильно
label.text = "Загрузка..."
// Правильно
label.text = NSLocalizedString("loading_label", comment: "Loading indicator text")
Хардкодный текст переводчик просто не найдёт. Это самая распространённая ошибка в проектах, где локализацию “добавили позже”.
Конкатенация строк¶
// Неправильно - нельзя перевести
label.text = "У вас " + String(count) + " сообщений"
// Правильно
label.text = String(format: NSLocalizedString("messages_count", comment: ""), count)
Порядок слов в предложении разный для разных языков. Если разбить строку на части и склеить - перевод будет грамматически неправильным независимо от качества переводчика.
Отсутствие контекста для переводчиков¶
Строка "OK" может быть кнопкой подтверждения удаления, подтверждения покупки или закрытия модального окна - и в каждом случае перевод может отличаться. Без скриншота или комментария переводчик гадает.
Непредусмотренное расширение текста¶
Разные языки занимают разное количество места по сравнению с английским:
| Язык | Среднее расширение |
|---|---|
| Немецкий | +30-40% |
| Французский | +15-20% |
| Испанский | +15-25% |
| Японский | -40% (компактнее) |
| Китайский | -30% |
Кнопка “Save” (4 символа) становится “Speichern” (9 символов). Если UI не адаптирован под расширение - текст обрезается или кнопка деформируется.
RTL без поддержки¶
Для арабского, иврита и персидского языка не только текст идёт справа налево - весь layout должен зеркально отразиться. Кнопка “Назад” переходит в правый угол, иконки меняются местами. iOS и Android предоставляют API для этого, но разработчики часто забывают проверить RTL-режим.
Как пишет Phrase в своём блоге:
RTL support isn’t just about flipping text direction - it’s about mirroring the entire UI, including icons, progress bars, and animations. When targeting Arabic or Hebrew speakers, test your app in RTL mode before release.
Инструменты для локализации мобильных приложений¶
Ручное ведение файлов перевода - рабочий подход для 1-2 языков. Для 5+ языков и CI/CD нужен TMS (Translation Management System).
| Инструмент | Цена | Сильные стороны |
|---|---|---|
| Lokalise | от ~$120/мес | Мобильные SDK, over-the-air обновления |
| Crowdin | от $25/мес, бесплатно для open-source | 700+ интеграций, GitHub/GitLab sync |
| Phrase | от ~$100/мес | TM, глоссарии, QA-чекеры |
| SimpleLocalize | есть бесплатный tier | Простота, CLI, CI/CD |
Ключевые фичи при выборе:
- Over-the-air updates: обновить переводы без публикации нового релиза в App Store/Google Play
- GitHub/GitLab integration: автоматический sync файлов при каждом коммите
- Context: скриншоты или live preview для каждого ключа - переводчик понимает где и как будет отображаться строка
- Plural editor: удобный редактор форм множественного числа для каждого языка
По данным теста Crowdin vs Lokalise, Crowdin имеет преимущество для open-source и проектов с большим количеством GitHub-интеграций, Lokalise - для продуктовых команд где важна мобильная SDK и over-the-air.
Как организовать процесс: continuous localization¶
Локализацию не нужно “добавлять после того как приложение готово” - это антипаттерн. Правильный подход - continuous localization, параллельно с разработкой.
Рекомендованный workflow¶
- i18n с первого дня: вынес все строки в resource файлы, настроил форматирование дат/чисел через ICU/NSDateFormatter, проверил RTL layout с самого начала
- Подключил TMS: настроил sync с репозиторием через GitHub Action или webhook - новые ключи автоматически попадают к переводчикам
- Подготовил контекст: для каждого ключа добавил скриншот или описание где эта строка появляется
- Заказал перевод: machine translation как черновик + человеческий post-editing для публичных текстов (store description, onboarding)
- QA на реальных устройствах: проверил все языки, RTL, truncation, даты/числа, in-app purchases
- Запуск и мониторинг: смотришь на отзывы и ratings в новых локалях - они покажут где что-то пропущено
Важно: machine translation для технических strings (системные сообщения, сообщения об ошибках) - нормально. Но onboarding, store description и маркетинговые тексты требуют человека-переводчика или хотя бы качественного post-editing - именно здесь конверсия.
FAQ¶
В чём разница между i18n и l10n?¶
i18n (internationalization) - техническая подготовка кода: вынес строки в resource файлы, настроил форматирование, поддержка RTL. Это делается раз и навсегда разработчиком.
l10n (localization) - адаптация для конкретного рынка: перевод строк, адаптация скриншотов, локальные цены, культурная адаптация. Это постоянный процесс для каждого нового языка.
С каких языков начинать локализацию?¶
Ориентируйся на данные своего продукта и рынка. Для English-продукта обычно первый шаг - Spanish, French или German: большие рынки, близкая культура, хорошие переводчики. Для постсоветских продуктов если уже есть Russian или Ukrainian - дальше обычно English, потом Polish или German.
8 языков покрывают 80% покупательской способности - не нужно локализовать под 40 сразу.
Можно ли использовать только машинный перевод?¶
Для технических strings и системных сообщений - да, качества DeepL или GPT-4 достаточно. Но для store description, onboarding и маркетинговых текстов нужен человек-переводчик или post-editing. Машинный перевод в критических точках конверсии снижает доверие и CTR.
Сколько стоит локализация мобильного приложения?¶
Зависит от объёма и количества языков. Ориентировочно для одного языка:
- Только store metadata: $150-400
- MVL (metadata + критические strings): $300-800
- Полная локализация среднего приложения: $800-3000+
TMS-инструменты: Crowdin от $25/мес, Lokalise от $120/мес.
Нужно ли локализовать push-уведомления?¶
Да, и не только текст. Push в неправильное время (из-за разницы часовых поясов), с агрессивным тоном для рынков где это неприемлемо, или с нерелевантным контентом - прямая дорога к unsubscribe и uninstall. Особенно критично для Японии и Кореи, где тон коммуникации сильно отличается от американского.
Что делать если в App Store отклонили скриншоты для локализованной версии?¶
Проверь App Store Review Guidelines для конкретной страны и адаптируй скриншоты соответственно. Для некоторых рынков (Китай, Саудовская Аравия) требования к контенту существенно отличаются от общих правил.