Short answer: AI translation turns multilingual work from a specialist subcontract into something a small Umbraco team can deliver in-house. The work that remains is mostly setup, review and maintenance — not translating text. Agencies that succeed with it scope the review effort honestly, make the client's role explicit, and treat the ongoing upkeep as a retainer rather than a one-off project.
Why multilingual work is worth offering now
Multilingual Umbraco projects used to mean coordinating external translators, exporting and re-importing content, and absorbing weeks of turnaround. That put the work out of reach for smaller agencies, or made it a loss-leader.
AI translation changes the shape of the job rather than eliminating it. Producing a first draft in another language is now fast and inexpensive — see estimating AI translation costs. What has not changed is everything around it: deciding what to translate, getting the site's language architecture right, reviewing output, and keeping languages current as the site evolves. That surrounding work is the service.
Questions to ask before quoting
Multilingual projects go wrong at discovery, not delivery. These questions surface almost every hidden cost.
| Question | Why it changes the quote |
|---|---|
| Which languages, and are any right-to-left or non-Latin script? | RTL and CJK affect templates, fonts and layout, not just content |
| Every page, or a defined subset? | Most sites need only a fraction translated; this is the single biggest lever on cost |
| Who reviews each language, and are they available? | No reviewer means either no launch or an unmanaged quality risk |
| Is the site already using language variants? | Retrofitting variants onto an established site is a development task in itself |
| How much content lives in Dictionary items versus page fields? | Interface strings are cheap to translate but often missed entirely in scoping |
| Are there custom or third-party property editors? | Unsupported editors need configuration or code, or must be excluded explicitly |
| Who owns the AI provider account? | Decides who carries usage billing and who holds the API credentials |
| Is any content legally sensitive? | Regulated copy needs professional human translation, not AI review |
What the work actually consists of
Breaking the project into phases makes it far easier to quote accurately and to show a client what they are paying for.
1. Language architecture
Adding languages, enabling variants on the right document types, configuring culture-specific URLs or domains, and setting fallback behaviour. On an existing single-language site this is development work, not configuration. See building a multilingual Umbraco site.
2. Template and front-end readiness
Language switchers, hreflang tags, translated metadata, date and number formatting, and — for Arabic, Hebrew or CJK — direction and typography. This is routinely underestimated because it is invisible until a second language exists. Multilingual SEO covers the search-visibility half.
3. Translation setup
Connecting a provider, creating governed profiles, agreeing which model tier suits which content, and building a glossary of brand terms, product names and phrases that must never be translated. The glossary is worth real time: it is what stops the client's product name being helpfully translated into forty languages.
4. Pilot on real content
Translate a representative sample — a landing page, a complex block-based page, a form-heavy page — and review it with the client's reviewer before committing to the full run. A pilot converts an argument about quality into a shared observation, and it is the cheapest possible way to discover an unsupported editor.
5. Bulk translation and review
The fast part. Run the jobs, then hand the drafts to reviewers. Plan for review to take substantially longer than translation, and make sure the reviewer knows they are editing a draft rather than approving a finished page.
6. Handover and maintenance
Train the client's editors on the translation workflow, and agree what happens when English content changes. This phase is where most of the recurring revenue lives — see maintaining translations after launch.
Where the risk sits
| Risk | How to protect the project |
|---|---|
| Client has no fluent reviewer | Establish this at discovery; either they resource it, you subcontract it, or the quality caveat is written into the contract |
| Scope creep from "just add another language" | Price per language explicitly, including its review and template implications |
| Client expects publish-ready output | Demonstrate the draft-only workflow during the pilot so expectations are set by observation, not by a clause |
| Unsupported editors discovered late | Audit property editors before quoting, not during delivery |
| Translations drift after launch | Propose maintenance up front; a stale multilingual site reflects on you, not the tool |
| Ambiguity over who pays for AI usage | State it in the proposal — even small sums cause friction when unexpected |
Setting expectations with the client
The single most useful thing you can do is be direct about what AI translation is. It can reduce the work of creating a first draft, but quality and review effort vary by content and language. It does not replace a professional translator for copy where nuance, persuasion or legal precision matter.
Agree the review responsibilities before starting, and demonstrate the output on a representative sample. Framing the service as"fast, reviewable drafts plus the tooling to keep them current" is both accurate and easier to deliver against.
It also opens a legitimate hybrid: AI for the long tail of informational pages, professional human translation for the handful of pages that carry real commercial or legal weight. Most sites do not need every page treated identically.
Common questions
Do we need to speak the target languages?
No, but somebody involved should. You can own the setup, tooling and workflow without speaking a word of the target language — provided a fluent reviewer signs off the content before it publishes. Be explicit about which side that resource comes from.
Should this be a project or a retainer?
Realistically both. The initial rollout is a project; keeping languages current as the site changes is ongoing. Presenting maintenance as an afterthought tends to mean it never gets bought, and the site quietly falls out of sync.
How do we handle a client who wants twenty languages?
Start with two or three and prove the workflow end to end. Language count multiplies review effort, not just translation cost — and review is the constrained resource. A successful three-language launch is a far better foundation than twenty half-reviewed ones.
Try to avoid overcommitting to too many languages or duplicating languages that are very similar (e.g. British English and US English).
What if the client's content is constantly changing?
That is an argument for change-tracking tooling rather than against translation. What matters is being able to identify precisely which pages have moved since they were translated, so retranslation stays proportional to the change.
Is AI translation appropriate for every client?
No. Regulated, medical, legal and safety-critical content should go to professional translators. Saying so plainly builds more trust than promising AI can handle everything, and it protects you when accuracy is challenged later.
Evaluate the tooling for your portfolio
If you are assessing packages to standardise on, the practical checks — structured content integrity, draft-only output, permissions, change detection — are set out in comparing Umbraco translation options.