Главная/Провайдеры/Политики фолбэка ENУКРРУС API-справочник (ReDoc) ↗

Политики фолбэка

Что делает провайдер с ненастроенным региональным языком — и почему ни один не едет на strict.

fallback_policy провайдера решает одно: что ответить для регионального языка без явной строки. Она никогда не влияет на базовые языки и никогда не перекрывает существующую строку.

Политика видна на провайдере: GET /v1/providers/{code} возвращает её в поле fallback_policy, так что вызывающий заранее знает, как будет отвечена ненастроенная пара.

Три политики

base_language

Отправить код базового языка. pt-BR → pt, de-CH → de, ar-EG → ar.

{ "language": "pt-BR", "code": "pt", "match": "base_language", "via_language": "pt" }

Вы теряете региональное различие, но получаете код, который провайдер наверняка понимает. Именно на этом едут сейчас все провайдеры.

passthrough

Отправить канонический код без изменений. pt-BR остаётся pt-BR.

{ "language": "pt-BR", "code": "pt-BR", "match": "passthrough" }

Для движков, чей набор принимаемых кодов не является стандартом: клиентская дообученная модель знает ровно те теги, на которых её учили, и обрезание до базового тега — худшая догадка, чем не обрезать.

strict

Ответить supported: false, code: null. Не гадать.

{ "language": "pt-BR", "code": null, "supported": false, "match": null }

Для API, отклоняющих неизвестные теги с 4xx, — после того, как стало известно, какие пары действительно работают. Ошибочная догадка там стоит упавшей задачи; упасть раньше дешевле.

Почему ни один провайдер сейчас не strict

Некоторые вендоры — среди них DeepL, Azure и Amazon — действительно отдают 400 на тег, которого не знают, и их поле notes это говорит. Они всё равно на base_language, и это осознанно.

Обрезание до базового языка значительно чаще правильно, чем нет: незамапленный pt-BR доходит до такого API как pt, а этот тег принимают все они. Явную строку для конкретного провайдера имеет лишь меньшинство региональных языков, поэтому перевод провайдера на strict превратил бы все остальные пары — включая те многие, что работают сегодня, — в supported: false одновременно.

Правило

strict — это опт-ин по провайдеру, включается после того, как действительно неподдерживаемые пары этого провайдера зафиксированы явно, а не до. Пометить пару неподдерживаемой — утверждение о факте; пометить провайдера strict — утверждение обо всём, чего никто не проверял.

Поле notes провайдера несёт шортлист кандидатов, так что вызывающий видит, какие провайдеры по характеру strict, даже пока они отвечают снисходительно.

Что это значит для вызывающего

Если пара для вас важна — читайте match:

  • exact — настроено осознанно именно для этой пары.
  • base_language / passthrough — выведено политикой. Корректно и пригодно, но именно эту пару против того API никто не проверял.

Пара, о которой известно, что она не работает, отвечает supported: false с code: null — при любой политике. Это зафиксированный факт о паре, а не фолбэк: запрос делать не нужно.

Отказ, записанный против базового языка, покрывает и его региональные варианты. Провайдер, который не переводит немецкий, не переведёт и de-AT, поэтому обе пары отвечают supported: false, а via_language называет язык, против которого отказ записан. Политика для таких пар не запускается вовсе: она решает, что делать, когда не известно ничего, а здесь известно.

Далее