Locale Fallback Chains for Every Framework
Most i18n frameworks skip parent locales entirely. A pt-BR user with a missing key sees English — not the perfectly good pt-PT translation. locale-chain libraries fix this with configurable deep-merge fallback chains.
The Problem: Frameworks Skip Parent Locales
You ship pt-PT translations with 2,000 keys. Your pt-BR file has 200 regional overrides. What happens to the 1,800 keys that are identical? Most frameworks show the fallback locale (usually English) instead of the parent locale. Your Brazilian users see a mix of Portuguese and English — a broken experience that makes your app feel unfinished.
This is not an edge case. Every app with regional variants (zh-Hans/zh-Hant, es/es-419, en-US/en-GB, fr/fr-CA) hits this problem. The default behavior of almost every i18n framework is wrong for regional locales.
How Deep-Merge Fallback Works
When a user selects pt-BR, the library loads messages from each locale in the fallback chain and deep-merges them in priority order. Regional keys override parent keys. Parent keys fill gaps. The result is a complete message set with zero missing translations.
Example: pt-BR defines 'cart.checkout' as 'Finalizar compra'. pt-PT defines 'cart.checkout' as 'Concluir compra' and 'cart.empty' as 'Carrinho vazio'. The merged result for pt-BR uses the pt-BR checkout text but falls back to pt-PT for the empty cart message — instead of showing English.
Available for 17 Frameworks
Each framework has a dedicated locale-chain library that integrates natively with its i18n system. Install the package, configure your chains, and the deep-merge happens automatically at load time.
Try i18n Agent Now
Drop your translation file here
JSON, YAML, PO, XML, CSV, Markdown, Properties
or click to browse
Target languages