Localization Fallbacks and Delivery in a Headless CMS

Your product ships in English and Dutch. Your marketing team translates 80% of content but occasionally misses a blog post. Without fallback rules, Dutch readers see a broken page or an empty field. With a proper localization setup, they see the English version of the missing field while the rest of the page renders in Dutch. That fallback behaviour is something you configure in your CMS, not patch in your frontend.

How Locales Work in ContentGrid

ContentGrid supports multiple locales per space. Each locale has a language code (en, nl, de) and a fallback chain — an ordered list of locales to use when a field has no translation. You define the fallback chain in your space settings, not in your frontend code. When the API returns a field value, it applies the fallback automatically based on your configuration.

Fields can be marked as localised or shared. A post title is localised — it's different in every language. A post's author reference is shared — the same Author entry applies to all locales. You control this per field in your content type definition.

API Queries with Locale Context

Every REST and GraphQL request to ContentGrid can include a locale parameter. Pass ?locale=nl to get Dutch content with fallbacks applied. Your Next.js app reads the locale from the URL — /nl/blog/my-post — and passes it to the ContentGrid TypeScript SDK:

• The SDK sends the locale in every API request
• ContentGrid returns field values in the requested locale, with fallbacks applied
• Your frontend receives a consistent response shape regardless of which locale is active
• You don't need locale-specific conditionals in your rendering components

Fallback Rules in Practice

A fallback chain of nl → en means: return the Dutch value if it exists; if not, return the English value. Fallbacks apply field by field, not entry by entry. A post can have a Dutch title and an English body — the API returns each field in the best available locale independently. That granularity means partial translations don't produce fully broken pages.

Locale-Aware Caching

CDN caching for multi-locale content requires locale in the cache key. Your Vercel or Netlify deployment generates separate cached responses per locale per page: /en/blog/my-post and /nl/blog/my-post are independent cache entries. When a Dutch translation is published, ContentGrid's webhook triggers revalidation of /nl/blog/my-post only — the English cache is untouched. Locale-specific invalidation keeps cache hit rates high even in multi-language setups.