Technology Integration
Connecting translation to your CMS, applications and workflows so multilingual content ships with your release cycle instead of after it.
Get a quoteThe hardest part of a multilingual website isn't translating it. It's the twelfth time you translate it, when content has changed across 40 pages and nobody can say which ones.
That's a workflow problem wearing a translation problem's clothes, and it's why organisations quietly abandon in-language sites two years after launching them. The content goes stale, the stale content becomes a liability, and the pages come down.
What integration changes
Translation stops being a project that runs beside publishing and becomes part of it. Changed content is detected, sent, translated and returned into the same fields. Nobody exports a spreadsheet. Nobody re-keys anything. The in-language version is current because staying current no longer requires anyone to remember.
- API connectivity to CMS platforms, applications and custom systems.
- Continuous localisation, where content moves to translation as it changes rather than in periodic batches.
- Translation proxy, serving in-language versions of an existing site without touching the underlying build. Usually the fastest route when development capacity is the constraint.
- Translation memory and terminology applied automatically, so cost falls as the memory grows.
- Real-time visibility through CORE+: what is in progress, what is in revision, what is late and who has it.
Multilingual SEO, which is where the value usually leaks
In-language pages need correct hreflang annotations, self-referencing canonical tags and localised metadata. Without them, search engines treat in-language pages as duplicates and keep serving the English version to everyone, including the people the pages were built for.
We also localise metadata and structured data rather than translating it literally, because search behaviour in Vietnamese or Arabic doesn't mirror the English query. The phrase someone searches for is frequently not the phrase your English page ranks on, translated.
At enterprise scale
For Uniting we've run an enterprise translation partnership for over a decade, across 550 services in New South Wales and the ACT. What integration buys at that scale isn't speed on any one job. It's that a translation from 2016 and one from this month use the same terms, that nothing is paid for twice, and that anyone can see the state of every job without asking. How it runs.
Common questions
Speak to our teamWhich platforms do you integrate with?
The common content platforms by API, plus custom systems and internal applications. Where a direct integration isn't practical or the development effort isn't justified, a translation proxy delivers in-language versions of your site without changing the build. Tell us what you run and we'll tell you which of the two makes sense, including when the answer is neither.
How long does an integration take to stand up?
A proxy-based multilingual site can be live in weeks. A full CMS integration typically runs four to eight weeks, most of which is mapping content types and agreeing the workflow rather than writing code. The step that decides success is the workflow design: who approves in-language content, and what happens when the English source changes after translation has started.
Who owns the translation memory?
You do. It's your linguistic asset, built from content you paid to translate, and you can export it at any time and take it with you. Any arrangement where the memory stays with the provider makes changing providers artificially expensive, which is the point of the arrangement.
Does this replace human translators?
No. It removes the file handling, the version chasing and the retranslation of content already translated, so the human effort goes into the translation itself. Every workflow still ends in the ISO 17100 process for anything published: a qualified translator, then an independent reviser.