Pin a Provider Code
A provider wants something the fallback ladder does not produce. Fix it in one edit.
Goal: Baidu wants cht for traditional Chinese. With nothing configured, zh-TW falls back to zh — which is what production sends today, and it is wrong.
Confirm the current answer
curl ".../v1/resolve?provider=baidu_translate&language=zh-TW"
{ "language": "zh-TW", "code": "zh", "match": "base_language", "via_language": "zh" }
match: base_language is the tell — nobody configured this; the ladder guessed.
Pin it
Admin → Providers → baidu_translate → Matrix, search chinese, find Chinese (Traditional), type cht in its cell, click away.
The cell border turns green, the source chip changes to exact, and ↺ Unpin appears.
Verify
curl ".../v1/resolve?provider=baidu_translate&language=zh-TW"
{ "language": "zh-TW", "code": "cht", "match": "exact" }
No restart, no cache wait — the catalog is invalidated on write.
Marking a pair unsupported
Sometimes the answer is that there is no answer. ✕ Unsupported on the row records it:
{ "language": "ceb", "code": null, "supported": false, "match": null }
Callers then know to skip the provider rather than send a request that will fail.
Only mark what you verified
supported: false is a factual claim that a caller will act on. If you have not tested the pair, leave it derived — a wrong false silently removes a provider from selection for that language.
Unpinning
Clear the cell. The explicit row is deleted and the pair returns to the fallback ladder. Useful when a provider adds support for a code you had pinned to something else.
Finding what to pin
Matrix → Show → Derived only lists every pair nobody has checked for that provider. Combine with Kind → Regional — base languages are almost never worth pinning.
Work through the languages you actually sell first; the tail of the list is rarely worth the time.
Next
- Editing the Matrix — the full screen
- Fallback Policies — what "derived" did