Yes. Modern headless CMS platforms integrate with machine-translation engines — DeepL, Google Cloud Translation, and AI-powered translation APIs — to automatically generate language variants when content is published or updated. dotCMS supports auto-translation through external translation engine integration: content items trigger translation requests on publish, translated variants are returned and stored in the CMS, and configurable workflows approve translated content before it goes live.
Auto-translation in a CMS is not a single feature. It is an integration architecture connecting structured content, machine-translation APIs, translation workflow approvals, and locale-aware delivery.
At a Glance
DeepL’s API now supports translation between more than 30 source and target languages (expanded in late 2024), including European, Asian, and Middle-Eastern locales — the broadest coverage among dedicated neural MT providers.
Google Cloud Translation supports approximately 189 languages as of the current Cloud Translation API v3, covering the overwhelming majority of internet-used languages.
76% of online shoppers prefer to buy in their own language and 40% will not buy in another language at all, making machine-assisted translation a direct conversion lever (CSA Research, 2020).
Forrester’s 2024 Total Economic Impact study of DeepL reported a 345% three-year ROI for a composite organisation, with substantial reductions in translator effort and time-to-publish — a useful reference point for calibrating the business case, with the caveat that the study was commissioned by DeepL.
Section Overview
How auto-translation works inside a headless CMS.
The difference between embedded MT, TMS-mediated MT, and pure API-call MT.
Workflow patterns for review and approval of machine-translated content.
Quality considerations — and where machine translation still fails.
How dotCMS orchestrates auto-translation in compliance-led contexts.
How Auto-Translation Works in a Headless CMS
Auto-translation has four moving parts: a trigger (usually a publish event), a machine-translation engine call, storage of the returned translation as a language variant, and a workflow that either auto-publishes the variant or routes it for human review.
In dotCMS, the trigger is a workflow action. When an editor publishes an English content item, a workflow step calls DeepL, Google Translate, or a configured TMS. The translated text is written back to the CMS as a draft variant in the target language. A reviewer can then approve it, edit it, or reject it. See the dotCMS workflow documentation for workflow configuration patterns.
Three Integration Patterns
Pattern 1: Direct MT API Integration
The CMS calls a machine-translation API (DeepL, Google Cloud Translation, Azure Translator) directly. Simplest to set up; best for organisations that can manage glossaries and review entirely inside the CMS.
Pattern 2: TMS-Mediated Translation
The CMS sends content to a Translation Management System (Lokalise, Smartling, Phrase). The TMS applies MT plus human post-editing, glossary enforcement, and translation-memory reuse, then returns the final translation. Best for organisations with professional linguists in the loop.
Pattern 3: Hybrid AI-Human Workflow
Machine translation produces a draft. Human translators post-edit it. A compliance or brand reviewer approves it. Each step is a workflow state in the CMS. Best for compliance-led content — pharmaceutical, financial, legal — where the cost of a mistranslation exceeds the cost of human review.
Where Machine Translation Still Fails
Brand voice: MT engines produce grammatically correct but often flat output. Tagline, hero copy, and campaign language still benefit from a human writer.
Domain-specific terminology: medical, legal, and technical terms can be mistranslated unless a glossary is enforced. TMS platforms and DeepL’s glossary feature mitigate this.
Regulated claims: pharmaceutical indications, financial disclaimers, and medical device instructions must be reviewed by a qualified human. MT is a first draft, never the final word.
Cultural adaptation: MT translates words, not context. Offers, idioms, humour, and compliance nuance often need transcreation, not translation.
Quality Control Patterns That Work
Maintain a glossary per brand and per domain. Both DeepL and TMS platforms support glossary enforcement.
Use translation memory to ensure consistent phrasing across content. TMS platforms manage this automatically.
Set review gates by content type: legal and compliance content always requires human review; blog content may not.
Track translation quality with linguistic QA checks (tagging fluency, accuracy, terminology compliance).
How dotCMS Orchestrates Auto-Translation
In dotCMS, auto-translation is implemented as one or more configurable workflow actions. A “Publish and Translate” action publishes the source variant, then calls the configured MT engine (or TMS) for each enabled target language, creating draft variants. Editors see all target-language variants in a single dashboard.
For compliance-led content, dotCMS workflows can require an explicit human approval step per language variant before it goes live. Audit logs capture every translation event, every reviewer, and every publish — a standard expectation under GDPR Article 30, HIPAA 164.312(b), and similar frameworks. Implementation details are in the dotCMS integrations documentation.
Platform Comparison
Capability | dotCMS | Traditional CMS | Other Headless CMS |
|---|---|---|---|
Workflow-triggered auto-translation | Native | Rare | Varies |
DeepL / Google Translate integration | Supported | Add-on or manual | Varies |
TMS integration (Lokalise, Smartling, Phrase) | Supported | Limited | Varies |
Human-review workflow per variant | Yes | Rare | Varies |
Audit log of translation events | Yes | Rare | Varies |
Frequently Asked Questions
Which machine-translation engines does dotCMS support?
dotCMS supports integration with DeepL, Google Cloud Translation, and any TMS with a REST API — including Lokalise, Smartling, and Phrase. Integration is configured at the workflow-action level.
Will auto-translated content publish automatically?
Only if configured to. By default, auto-translation creates draft variants that require explicit human approval before publishing. This is the recommended configuration for regulated and brand-sensitive content.
How does dotCMS handle glossaries and terminology consistency?
When integrated with DeepL or a TMS, glossaries are enforced at the translation engine. dotCMS also supports content-level glossary references through custom fields and velocity macros for brand-specific terminology.
What happens when source content changes after translation?
dotCMS marks affected language variants as “out of sync.” Workflows can automatically trigger re-translation, or editors can manually schedule updates. The audit log captures every re-translation event.