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

## Почему это важно \{#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:

```dart showLineNumbers
// 1. Modify your app_en.arb, app_es.arb, app_pt_br.arb files

/*
app_en.arb
*/
"adapty_paywalls_locale": "en",

/*
app_es.arb
*/
"adapty_paywalls_locale": "es",

/*
app_pt_br.arb
*/
"adapty_paywalls_locale": "pt-br",

// 2. Extract and use the locale code
final locale = AppLocalizations.of(context)!.adapty_paywalls_locale;
// pass locale code to AdaptyUI.getViewConfiguration or Adapty.getPaywall method
```

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

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

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

```dart showLineNumbers
final locale = Localizations.localeOf(context).languageCode;
// pass locale code to AdaptyUI.getViewConfiguration or Adapty.getPaywall method
```

Мы не рекомендуем этот подход по нескольким причинам:

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

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