Localization
Localization in BCMS allows you to manage and serve content in multiple languages across your entire project. Once a new language is added from the Settings, it becomes available across all entries, templates, groups, and widgets.
Adding languages
To add a new language, go to Settings → General Settings, and use the Add Language dropdown. Select the language you want to support. Once added:
The language appears in your entry editor.
You can now input localized content for every field.
Each entry in every template becomes translatable.
🧠 You don’t need to reconfigure templates or widgets. The new language applies universally.
How localization works
Each time you add a language (e.g., French), all BCMS entries gain a new language version of their fields. For example, in your code:
post.meta.en.title // English title post.meta.fr.title // French title
and content:
post.content.en.nodes // English content post.content.fr.nodes // French content
✏️ All content is scoped per language. You are responsible for translating it in the entry editor.
Required fields and languages
Field validations (like required) apply for all languages language. This means if a field is required, it must be filled out in every language variation of the entry before saving.
For example, if a blog post requires a category, both the English and French versions must include a category before the entry can be saved.
Language is for the whole entry
In BCMS, localization is handled at the entry level, not the individual field level—by design.
This means:
Each entry is fully duplicated for every language.
You manage complete, isolated versions per language.
Partial translations are not possible - every localized version must be complete before publishing.
While some systems let you localize individual fields, this often creates confusion, edge cases, and messy validation logic - especially as projects grow.
With BCMS, this clear separation keeps your content model clean, scalable, and predictable. Large projects with dozens of languages and editors won’t become a patchwork of missing or inconsistent fields. Instead, every language version of an entry is a fully-formed, reliable unit of content.
✅ Clear boundaries = fewer bugs, simpler logic, and happier editors.
Output structure example
Let’s say you added English (default) and French:
const post = await bcms.entry.get('blog', 'my-post'); console.log(post.meta.en.title); // "Welcome to our blog" console.log(post.meta.fr.title); // "Bienvenue sur notre blog" console.log(post.content.en.nodes); // [...English content...] console.log(post.content.fr.nodes); // [...French content...]
This makes rendering localized content on your frontend straightforward.