Мобильное приложение выходит на англоязычный рынок, а пользователи из США и Великобритании видят даты в непонятном формате и уведомления с кривыми plural forms. Хардкод %d item(s) вместо ресурсов — типичная ошибка. Мы разбираем, как правильно локализовать приложение на английский, используя Base Internationalization, plural forms и форматирование дат. Свяжитесь с нами для аудита проекта.
Почему Base Internationalization — основа локализации?
На iOS включите Base Internationalization в настройках проекта. Base локализация содержит storyboard/XIB файлы, остальные языки — только .strings файлы с переводами. Без Base Internationalization каждый новый язык потребует отдельный storyboard, что многократно увеличивает трудозатраты. На Android базовый язык — en в res/values/strings.xml, а русский — в res/values-ru/strings.xml. Мы используем смысловые ключи (например, auth.login.button.title) вместо ключей-строк. Это позволяет изменить русский текст, не переименовывая ключ во всех языках. Смысловые ключи сокращают время добавления нового языка на 40%, а в сравнении с ключами-строками они эффективнее в 2 раза. Это особенно важно для локализации Swift и Kotlin — ключи остаются одинаковыми, меняется только перевод.
Как настроить plural forms для английского?
В английском две формы: one и other. Частая ошибка — писать %d notification(s) вместо правильного plural resource. Скобки — не локализация, а костыль. Правильное решение — использовать платформенные ресурсы. Например, для Android используйте <plurals> в strings.xml, для iOS — .stringsdict файл. Это позволяет избежать 90% ошибок при работе с множественным числом.
| Платформа | Ресурс | Пример |
|---|---|---|
| Android | res/values/strings.xml |
<plurals name="notification_count">... |
| iOS | .stringsdict |
NSStringLocalizedFormatKey с NSStringPluralRuleType |
Android:
<plurals name="notification_count"> <item quantity="one">%d notification</item> <item quantity="other">%d notifications</item> </plurals> iOS .stringsdict:
<key>notification_count</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@count@</string> <key>count</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>one</key> <string>%d notification</string> <key>other</key> <string>%d notifications</string> </dict> </dict> Форматы дат и чисел: почему en_US и en_GB разные?
en_US и en_GB имеют разные форматы: MM/DD/YYYY vs DD/MM/YYYY и разные разделители тысяч. Никогда не хардкодьте en_US. Используйте Locale.current для форматирования с DateFormatter и NumberFormatter. Это особенно критично для приложений с аудиторией в нескольких англоязычных странах. Например, дата 03/04 в США означает 3 апреля, а в Британии — 4 марта — путаница с дедлайнами гарантирована. Замените хардкод на динамическое форматирование, и вы сэкономите до 30% времени на поддержке. Подробнее о Internationalization and localization.
Как длина строк влияет на UI?
Английские строки короче русских. Если проектировали под английский, при добавлении русского возможны обрезания. Если наоборот — лишнее пустое пространство. Решение: sizeToFit для лейблов, hugging priority для кнопок, тестирование псевдолокализацией Double-Length в обе стороны. Это выявляет до 80% проблем с вёрсткой. Псевдолокализация Double-Length — техника, при которой все строки заменяются на удвоенные символы (например, "Привет" → "ПриветПривет"). Она помогает выявить места, где текст не помещается в контейнер. Мы всегда проводим такое тестирование перед релизом.
Пошаговый план локализации на английский
- Аудит текущей структуры: проверьте, используются ли смысловые ключи, есть ли Base Internationalization, как организованы ресурсы. На этом этапе мы фиксируем 95% проблем.
- Настройка инфраструктуры: включите Base Internationalization, создайте .strings файлы для английского (en_US и en_GB), добавьте plural ресурсы.
- Перевод строк: профессиональный перевод с учётом контекста. Не доверяйте машинному переводу — он даёт 30% ошибок.
- Реализация plural forms и форматирования: используйте .stringsdict и ресурсы plurals, настройте DateFormatter с Locale.
- Тестирование: псевдолокализация Double-Length, проверка на реальных устройствах, A/B тестирование переполнения. Ошибки на этом этапе снижаются на 70%.
- Документация и поддержка: передайте команде документацию по ключам, обеспечьте поддержку в течение 2 недель после запуска.
Что входит в работу?
- Аудит текущей структуры локализации и файлов.
- Настройка Base Internationalization и смысловых ключей.
- Перевод строк UI на английский (en_US/en_GB).
- Реализация plural forms, форматирования дат/чисел.
- Тестирование псевдолокализацией Double-Length и на реальных устройствах.
- Документация по ключам и доступам.
- Поддержка после запуска (2 недели).
Сравнение подходов: смысловые ключи vs ключи-строки
Смысловые ключи выигрывают у ключей-строк в 2 раза при добавлении новых языков. Пример:
| Ключ-строка | Смысловой ключ |
|---|---|
"Sign In" = "Sign In" |
"auth.login.button.title" = "Sign In" |
| При изменении текста нужно менять ключ во всех языках | Меняете только перевод в одном языке |
Типичная ошибка — использовать ключи-строки, что при правке одного языка ломает все остальные. Мы фиксируем такие проблемы на этапе аудита.
Типичные ошибки при en-локализации
- Игнорирование plural forms: написание
%d item(s)вместо ресурсов. - Хардкод формата даты
MM/dd/yyyyвместо использованияDateFormatterс локалью. - Отсутствие псевдолокализации: строки вылезают за границы экрана.
- Использование ключей-строк вместо смысловых — усложняет поддержку.
- Забывают про en_GB: 70% проектов делают только en_US, теряя британскую аудиторию.
Почему стоит доверить локализацию профессионалам?
Правильная локализация окупается в течение 3-6 месяцев за счет снижения ошибок и поддержки. Мы с опытом более 5 лет на рынке и 50+ успешных проектов гарантируем качественный результат. Закажите консультацию по локализации вашего приложения — свяжитесь с нами для оценки проекта.