Describe the solution you'd like
I’d like templates to support localization as a first-class feature instead of treating each localized version as a completely separate template. A single template should act as the canonical record, with its localized variants nested beneath it and each variant carrying an explicit locale attribute, similar to how Strapi handles localized content.
In practice, this would mean I could manage 50 templates with 4 locale variants each, instead of manually maintaining 200 separately named templates. In the editor, I’d like a locale dropdown or locale switcher so I can move between translations of the same template without leaving the current template context.
Ideal behavior would include:
- One parent template entity with linked localized versions.
- A required locale field on each localization, ideally using full locale codes rather than only language names.
- A locale selector in the editor to switch between versions of the same template.
- A clear default locale / source locale designation.
- Optional fallback behavior when a translation does not yet exist.
- API and UI support that make localized templates feel structurally related, not just conventionally grouped by name.
This would make localization workflows much cleaner and less error-prone, especially for teams managing large numbers of translated templates. It would also better match how modern CMS tools model multilingual content.
Alternatives or workarounds
Right now, the main workaround is to create a separate template per locale and encode the locale in the template name. That works, but it scales poorly and turns localization into a naming convention rather than a real content relationship.
Another workaround is to rely on external localization systems or translation-file style workflows, but those are a weaker fit when the actual editing experience is template-centric and users expect to switch locales inside the same editor context. Localization platforms do preserve metadata well, but they don’t replace a native localized-template UX in the app itself.
Additional context
My current setup is effectively 200 separate localized templates across 4 locales, where the underlying logical structure is really just 50 templates with translations. That creates unnecessary clutter in the template list, makes editing more tedious, and increases the chance of inconsistent updates between locales.
What I’m hoping for is a workflow closer to Mautic/Strapi-style localization: one template, multiple locale variants, and a simple locale dropdown in the editor. Managing locales by template name alone feels like a workaround rather than a proper localization model.
Describe the solution you'd like
I’d like templates to support localization as a first-class feature instead of treating each localized version as a completely separate template. A single template should act as the canonical record, with its localized variants nested beneath it and each variant carrying an explicit
localeattribute, similar to how Strapi handles localized content.In practice, this would mean I could manage 50 templates with 4 locale variants each, instead of manually maintaining 200 separately named templates. In the editor, I’d like a locale dropdown or locale switcher so I can move between translations of the same template without leaving the current template context.
Ideal behavior would include:
This would make localization workflows much cleaner and less error-prone, especially for teams managing large numbers of translated templates. It would also better match how modern CMS tools model multilingual content.
Alternatives or workarounds
Right now, the main workaround is to create a separate template per locale and encode the locale in the template name. That works, but it scales poorly and turns localization into a naming convention rather than a real content relationship.
Another workaround is to rely on external localization systems or translation-file style workflows, but those are a weaker fit when the actual editing experience is template-centric and users expect to switch locales inside the same editor context. Localization platforms do preserve metadata well, but they don’t replace a native localized-template UX in the app itself.
Additional context
My current setup is effectively 200 separate localized templates across 4 locales, where the underlying logical structure is really just 50 templates with translations. That creates unnecessary clutter in the template list, makes editing more tedious, and increases the chance of inconsistent updates between locales.
What I’m hoping for is a workflow closer to Mautic/Strapi-style localization: one template, multiple locale variants, and a simple locale dropdown in the editor. Managing locales by template name alone feels like a workaround rather than a proper localization model.