Locales

What translates

Text and prose fields hold a value per locale wherever they sit: at the top of a record, inside an inline model, in a list item, or in a model placed in a prose field. Every other field type, including numbers, dates, references and media, has one value shared by all locales. Image alt text is part of the image value, so it is shared too.

Setting up locales

Locales are BCP-47 codes configured per project. One is the default, the language you author in, and each can name a fallback locale. A fallback that names a locale the project does not have, points at itself or closes a loop is refused on save.

Translations are written in the console's record editor or by an AI agent over MCP. The GraphQL API and the SDK read translations and do not write them.

The fallback chain

Pass locale on a read and each field is resolved separately, in this order: the locale you asked for, its configured fallbacks in turn, the project's closest other locales in the same written language, the project default, then the authored value. The first one with a value is served, so a partly translated record can return its title from one locale and its body from another.

The closest-match step stays within a written standard: a request for pt-PT is served pt-BR copy only if you set that fallback yourself. A locale the project has not configured still returns content, ending at the default.

Finding the gaps

Set localeStrict on a read and the response lists the fields that had no translation, and reports an unconfigured locale as an error. resolutionTrace returns the whole walk and needs a key with the targeting debug scope. Neither changes the content served.