---
title: "Использование локализаций и кодов языков в iOS SDK"
description: "Управляйте локализациями приложения и кодами языков для работы с глобальной аудиторией в вашем iOS-приложении."
---

## Почему это важно \{#why-this-is-important\}

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

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

## Стандарт кодов языков в Adapty \{#locale-code-standard-at-adapty\}

Для кодов языков Adapty использует слегка модифицированный стандарт [BCP 47](https://en.wikipedia.org/wiki/IETF_language_tag): каждый код состоит из подтегов в нижнем регистре, разделённых дефисами. Примеры: `en` (английский), `pt-br` (португальский (Бразилия)), `zh` (упрощённый китайский), `zh-hant` (традиционный китайский).

## Сопоставление кодов языков \{#locale-code-matching\}

Когда Adapty получает запрос от клиентского SDK с кодом языка и начинает поиск соответствующей локализации пейвола, происходит следующее:

1. Входящая строка с кодом языка приводится к нижнему регистру, а все подчёркивания (`_`) заменяются дефисами (`-`)
2. Выполняется поиск локализации с полностью совпадающим кодом языка
3. Если совпадение не найдено, берётся подстрока до первого дефиса (`pt` для `pt-br`) и выполняется поиск по ней
4. Если совпадение снова не найдено, возвращается локализация по умолчанию — `en`

Таким образом устройство iOS, отправившее `'pt_BR'`, устройство Android, отправившее `pt-BR`, и другое устройство, отправившее `pt-br`, получат одинаковый результат.

## Реализация локализаций: рекомендуемый способ \{#implementing-localizations-recommended-way\}

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

```swift showLineNumbers
// 1. Modify your Localizable.strings files

/*
Localizable.strings - Spanish
*/
adapty_paywalls_locale = "es";
/*
Localizable.strings - Portuguese (Brazil)
*/
adapty_paywalls_locale = "pt-br";
// 2. Extract and use the locale code
let locale = NSLocalizedString("adapty_paywalls_locale", comment: "")
// pass locale code to AdaptyUI.getViewConfiguration or Adapty.getPaywall method
```

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

## Реализация локализаций: альтернативный способ \{#implementing-localizations-the-other-way\}

Похожего (но не идентичного) результата можно добиться, не задавая явно коды языков для каждой локализации. Для этого нужно извлекать код языка из других объектов, предоставляемых платформой:

```swift showLineNumbers
let locale = Locale.current.identifier
// pass locale code to AdaptyUI.getViewConfiguration or Adapty.getPaywall method
```

Мы не рекомендуем этот подход по ряду причин:

1. На iOS предпочитаемые языки и текущая локаль — не одно и то же. Чтобы локализация выбиралась корректно, придётся либо полагаться на логику Apple (которая работает автоматически при использовании рекомендованного подхода с файлами локализованных строк), либо воссоздавать её самостоятельно.
2. Сложно предсказать, что именно получит сервер Adapty. Например, на iOS устройство может вернуть локаль вида `ar_OM@numbers='latn'`, и в ответ вы получите не локализацию `ar-om`, которую ожидали, а `ar` — что, скорее всего, окажется неожиданным.

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