Language Service Wiki
What each translation provider calls each language — and how to ask.
This is the developer wiki for the Language Service: the single source of truth for the languages the platform can translate and the exact code string each provider's API expects for them.
The problem it solves is narrow and unglamorous. Simplified Chinese is zh-CN to Yandex, zh-Hans to DeepL and Azure, zh-Hans-CN to a couple of others. Brazilian Portuguese arrives from integrations as pt-BR, pt_BR, PT-BR or por-br. Getting one of these wrong is not a validation error you catch in testing — it is a job that fails at the provider, or worse, one that quietly comes back translated into the wrong variant.
So: send any spelling and a provider, get back the exact string to put on the wire.
GET /v1/resolve?provider=deepl_api&language=pt_BR
{ "query": "pt_BR", "provider": "deepl_api", "language": "pt-BR",
"code": "PT-BR", "supported": true, "match": "exact" }
No authentication
Everything here is open reference data — which languages exist and what they are called. There is no token to obtain and no header to set. Editing the catalog is a different matter: that lives behind a login at /admin.
Pick your path
| You are… | Start here |
|---|---|
| New — I just want one call to work | Quickstart |
| A translation runtime resolving source and target | Resolution Ladder, then Resolve a whole job |
| An integration receiving codes from outside | Aliases and Normalisation, then Normalise incoming codes |
| Migrating a caller off the console's helpers | Migrating from the Console |
| Curating the catalog | Admin Panel · Editing the Matrix |
| Running or deploying the service | Deployment · Rebuilding the Seed |
The two ideas worth reading first
One code out per pair. For any (provider, language) there is exactly one string we send. The legacy console allowed several and picked whichever row the database happened to return first — 330 pairs were ambiguous that way. See Core Concepts.
Every answer says how it got there. match distinguishes a configured mapping from a reasonable fallback, so a caller that needs precision can tell the difference. See Resolution Ladder.
API reference
Interactive ReDoc is served by the API itself. For a one-line summary of every operation with links to the page that explains it, see Endpoints Index.
Folder map
00 Getting started — Quickstart · Core Concepts · Errors and Conventions
01 Languages — Language Catalog · Aliases and Normalisation
02 Providers — Providers and Vendors · Fallback Policies
03 Resolving — Resolution Ladder
04 Admin — Admin Panel · Editing the Matrix
05 Integration — Migrating from the Console
06 Operations — Deployment · Rebuilding the Seed
07 Cookbook — Resolve a language · Resolve a whole job · Normalise incoming codes · Pin a provider code · Add a new language · Onboard a provider
08 Reference — Endpoints Index · Error Codes · Glossary