Разрешение локалей

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

Как это работает#

При вводе локали приводятся к каноническому виду, а затем сохраняются и возвращаются именно в этой форме. Регистр и разделители нормализуются, подтипы сохраняются.

Сопоставление работает в обоих направлениях через границу подтегов: сохранённая локаль применяется к запросу, если одна из них точно совпадает с другой или является её предком. Две записи одной локали тоже совпадают, даже если ни одна не является предком другой, — когда регион однозначно определяет письменность: форма только с регионом и форма с явной письменностью равнозначны (zh-CN ≡ zh-Hans-CN, zh-TW ≡ zh-Hant-TW).

Разрешение нескольких совпадений#

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

• Сначала точное совпадение или язык по умолчанию. Для запроса de предпочтение отдаётся de-DE (региону по умолчанию из CLDR для немецкого), а затем базовому de.
• Затем — наиболее специфичный вариант как правило для разрешения ничьей.
• Любой другой подходящий регион остаётся как fallback — если у клиента единственная запись de-CH, она всё равно будет использоваться для запроса de, когда ничего лучше не найдено, поэтому конфигурация никогда не остаётся невостребованной.

Ранжирование и выбор#

Ранжирование выше определяет порядок для поверхностей, которые объединяют записи, и победителя для тех, кто выбирает одну:

Безопасность письменности#

Одно дополнительное правило действует только для элементов глоссария custom_translation, текст которых привязан к конкретной орфографии. Базовый язык с неоднозначной письменностью — sr (кириллица или латиница), zh (упрощённое или традиционное письмо) — должен явно указывать письменность при записи: либо как явный скрипт (zh-Hans, sr-Cyrl), либо как регион, который его определяет (zh-CN → упрощённое, sr-RS → кириллица, согласно CLDR). Отклоняется только по-настоящему «голый» код — без скрипта и без региона. При чтении эти формы равнозначны: термин, сохранённый как zh-Hans-CN, применяется к запросу zh-CN и наоборот. Но «голый» запрос zh, у которого письменность неизвестна, не подхватит строку с явно указанным скриптом. Поэтому для предсказуемых результатов указывайте скрипт или регион явно. Языки с единственной письменностью, например de, скрипт не требуют и разрешают de до de-DE в обычном порядке. Элементы non_translatable проходят без учёта письменности.

Пример#

Движок, настроенный на региональные коды (en-US в fr-FR, de-DE, nb-NO), получает запросы с базовыми кодами (fr, de, no):

• Цель fr подхватывает термины глоссария fr-FR, текст тональности бренда и правила — они ранжируются как вариант по умолчанию для fr, а не как последний резерв, — потому что fr-FR является регионом по умолчанию для французского языка согласно CLDR.
• Исходная локаль en совпадает с записями en-US — сопоставление двустороннее.
• Целевая локаль no не подтягивает nb-NO. no и nb — это разные языковые подтипы, а не пара регионов; в качестве целевой локали используйте nb.

Как использовать разрешение локалей в API#

Разрешение происходит автоматически при вызове endpoint локализации. Движок сопоставляет sourceLocale и targetLocale запроса с подходящими терминами глоссария, текстами тональности бренда, правилами и конфигурациями моделей — никаких дополнительных параметров не нужно.

Что дальше#