Головна/Провайдери/Політики фолбеку 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 називає мову, проти якої відмову записано. Політика для таких пар не запускається взагалі: вона вирішує, що робити, коли не відомо нічого, а тут відомо.

Далі