05 / Localize
Translate at field level with built-in inheritance. Keep every market connected to the same structure, so a second language is a setting, not a second project.
All locales included. No per-language tier.
What this replaces
Most headless tools treat localization as a premium feature. Some price it into a five-figure plan, some cap the number of languages by tier, some make you keep a separate content tree per market. All three answers cost you the same thing: your structure drifts apart.
How it works
Locales sit inside the content model instead of beside it. You decide field by field what travels and what gets translated.
A new locale inherits everything from its fallback language. Translate a field and it becomes local. Leave it and it stays in step with the base.
Mark a field translatable or global. A SKU, a price, a toggle stays the same everywhere. A headline, a description, a call to action speaks per market.
Translators read the source next to the field they are filling in. Context stays on screen, so nobody translates a headline blind.
Editing the English value touches English only. The Spanish draft and the Japanese review keep going. Same structure, separate work.
Send untranslated values out as structured data for a translator or a TMS, then import the result straight back into the right fields. Built-in AI gives you a first draft when you want one.
Localized slugs, per-locale meta, hreflang signals and a sitemap for every enabled language. Search engines get the version you meant them to see.
What you actually get
Ask for a language and the API answers in that language, with inherited values already resolved. Your frontend reads one shape, no matter how many markets you serve.
Reach further
Add the locales you need from your very first day. Same structure, same editors, no extra invoice.