Home/Providers/Fallback Policies ENУКРРУС API Reference (ReDoc) ↗

Fallback Policies

What a provider does with a regional language nobody configured — and why none of them ship as strict.

A provider's fallback_policy decides one thing: what to answer for a regional language with no explicit row. It never affects base languages, and it never overrides a row that exists.

The three policies

base_language

Send the base language's code. pt-BR → pt, de-CH → de, ar-EG → ar.

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

You lose the regional distinction, but you get a code the provider certainly understands. This is what every provider ships with, and what the console does today.

passthrough

Send the canonical code unchanged. pt-BR stays pt-BR.

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

For engines whose accepted set is not a standard: a customer-trained model knows exactly the tags it was trained on, and truncating to a base tag is a worse guess than not truncating.

strict

Answer supported: false, code: null. Do not guess.

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

For APIs that reject unknown tags with a 4xx, once you have curated which pairs actually work. A wrong guess there costs a failed job; failing early is cheaper.

Why nothing ships as strict

It is tempting to mark DeepL, Azure and Amazon strict — their APIs really do 400 on unknown tags, and their notes say so.

That would break production.

The console's fallback is lang_region_list.code[:2], so today an unmapped pt-BR reaches Amazon Translate as pt — and it works, because pt is not an unknown tag to Amazon. Amazon has 6 explicit console rows out of 87 active regional languages; the other 81 all resolve through that truncation right now. Seeding Amazon as strict would turn 81 working pairs into supported: false on the day this service went live.

The rule

strict is a per-provider opt-in, turned on after that provider's genuinely unsupported pairs have been recorded explicitly — not before. Marking a pair unsupported is a statement of fact; marking a whole provider strict is a statement about everything you have not checked.

The provider notes field carries the shortlist of candidates.

Marking one pair unsupported

You rarely need strict. If you know a specific pair fails, record just that pair — from the matrix, the ✕ Unsupported button, or:

POST /admin/mapping
provider=deepl_api&language=ceb&action=unsupported

That gives you supported: false for the pair you verified, and leaves every other pair alone. See Pin a provider code.

Changing a policy

Admin → Providers → pick one → Fallback policy. It takes effect on the next request; the catalog cache is invalidated on write.

Before switching a provider to strict, look at its derived count on the coverage table. That is exactly the number of pairs that will start answering supported: false.

Next