Build 01 / Governed Marketing Localisation
Translation AI
A governed localisation workflow for serious marketing teams. Translation AI turns approved campaign assets into language-specific working assets with orchestration, protected terminology, QA gates, GitHub versioning, and human approval built in.
Greg's take
Translation is the simplest-sounding workflow problem in enterprise marketing. Translate the asset. Send it to the market. Done.
Except: who checks whether the product name was protected? Who ensures the pricing disclaimer was not paraphrased? Who tracks what the model touched and whether a human approved it before the file went into the campaign?
That is the workflow behind the translation - and it is the part most teams manage by email, spreadsheet, and collective memory of past mistakes. This build is an attempt to make it legible.
The problem
Translation tools do not automatically create usable marketing assets.
Protected terms get changed
Product names, claims, merge fields, URLs, disclaimers, and campaign structure can be changed by a model unless the workflow protects them before translation.
Review happens without evidence
Teams often see the translated output, but not the rules used, terms protected, QA result, or model behaviour that produced it.
Assets break during rebuild
Copy and paste workflows are fragile. The translation may be good, but the working asset can still be broken when it returns to the campaign platform.
Decisions are lost
Approved phrases, rejected wording, QA notes, and reviewer decisions often disappear into email threads instead of becoming reusable memory.
What it is
A controlled operating layer for AI-assisted localisation.
Translation AI is not a prompt wrapper. The core idea is to wrap the model in operations: structured payloads, protected fields, language-specific translator agents, QA gates, human approval, and a recoverable version trail.
Structured payloads
The model receives segments, protected terms, formatting rules, glossary matches, prompt version, rules version, and output requirements as controlled input.
Language-specific agents
Each target language can have its own rules, approved phrasing, terminology behaviour, and quality controls under one orchestration layer.
Protected terminology
Names, links, placeholders, claims, tracking fields, and structural markers are isolated before translation so the model cannot freely rewrite them.
QA gates
Output is checked for protected term preservation, links, placeholders, structure, language target, and confidence before review.
Human approval
Generated output is held before use. The system records review status instead of pretending machine output is automatically approved.
Versioned evidence
Source file, generated output, approved output, QA report, prompt version, and rules version can be stored for traceability and rollback.
Workflow evidence
The build is designed as an operating system for localisation, not a one-off translation step.
A marketing asset moves through a controlled spine from approved source, to orchestration, to language-specific translation, to QA, to reviewed output, to versioned archive.
Click to enlarge
Illustrative workflow panel for the governed Translation AI build.
Operational value
The value is not only faster translation.
The value is fewer broken assets, fewer lost decisions, better evidence, and a localisation workflow that can be trusted by marketing operations.
Less manual rebuild risk
Extracts translatable content, routes it through a controlled structure, and rebuilds usable assets without repeated copy and paste work.
Controlled terminology
Product names, trademarks, merge fields, URLs, approved phrases, and restricted claims are protected before the translator agent receives the payload.
Traceable decisions
Source asset, generated output, QA result, approval status, prompt version, and rules version can be stored against a version-controlled record.
Architecture
A controlled spine from approved source asset to platform-ready working asset.
01
Controlled input
Approved source assets enter through a controlled route first, with future support for terminal, GitHub, and repository-triggered workflows.
02
Orchestration
A server-side route controls validation, payload construction, rules injection, language-agent routing, QA coordination, and archive writes.
03
Translation and reconstruction
Language-specific translator agents return structured segments. The builder layer reconstructs the asset without breaking layout or protected fields.
04
Storage and retrieval
GitHub stores source, output, QA reports, prompts, and rules so approved phrases and language preferences can be reused later.
Pipeline flow
Structured translation requests replace copy and paste prompting.
Source asset registered
The system receives a structured marketing asset, validates the request, and identifies the asset type, source language, target language, and metadata.
Structured payload created
The model receives segments, protected terms, formatting rules, glossary matches, prompt version, rules version, and output requirements.
Language-specific translator runs
The language router assigns the job to the right translator agent. The agent returns translated segments while preserving structure and controlled terms.
QA gate and human approval
Automated checks validate protected terms, links, placeholders, structure, language target, and confidence score before human approval.
Archive, evidence, and rollback
Source, generated output, approved output, QA report, prompt version, and rules version are stored so every job can be traced and recovered.
Language-specific translation layer
Language-specific agents, not one generic language switch.
Each target language can have its own translator agent, rules, approved phrasing, terminology behaviour, and quality controls. The orchestrator supervises every agent so no language workflow operates outside the governed process.
Governance controls
Designed to stop unsafe output before it becomes real marketing work.
Boundaries the AI cannot cross
> Cannot auto-approve translated assets
> Cannot bypass QA or human approval
> Cannot rewrite protected product claims
> Cannot store secrets in frontend code
Evidence the system records
> Source file and source commit
> Prompt version and rules version
> QA result and confidence score
> Approved asset and rollback reference
Technical build stack
Lightweight interface. Serious orchestration spine.
Frontend
The interface remains replaceable. The durable value sits in the orchestration, payload, governance, QA, memory, and archive model.
Orchestration
Server-side orchestration keeps secrets out of the browser and gives the workflow a clean control point.
Model layer
The model is a replaceable service. The durable value is the governed workflow wrapped around it.
Current build stage
Built to prove the workflow first, then deepen the automation.
Status
Prototype spine active
The important product decision is already clear: the workflow must be governed from source to output. The next build steps are about connecting more triggers, memory, and platform handoff without weakening the control layer.
Now
Controlled source asset, structured payload, language routing, QA concept, GitHub archive model, and review-first output flow.
Next
Approved phrase memory, repository-triggered runs, stronger QA reporting, and working-folder output for human review.
Demo story
Take one approved campaign asset, route it through the orchestrator, generate target-language working assets, show QA evidence, then prove rollback through GitHub.
Product app
Open the Translation AI app experience
The build page remains top-level. The product/app experience lives in the Translation AI app route and should only be used when the CTA means opening the actual product experience.
Demo and speaking angle
A live AI build story people can understand in five minutes.
Before
Manual localisation drag
Teams lose time copying, pasting, checking links, protecting merge fields, chasing versions, and rebuilding the same campaign in several languages.
During
Orchestrated AI run
The orchestrator prepares the job, language agents translate the controlled segments, and QA checks the parts that marketing operations cannot afford to break.
After
Review-ready output
The team receives working translated assets, QA evidence, and a versioned trail that makes review, approval, rollback, and reuse easier.
Roadmap
A phased roadmap that grows without losing governance.
Controlled manual upload workflow
Upload source asset, build structured payload, translate through the orchestrator, rebuild output, run QA, download result, and archive evidence.
Approved phrase memory and retrieval
Store approved phrase pairs, protected terms, rejected phrases, glossary rules, and language preferences for reuse before each translation run.
Terminal and repository trigger
A Git push from VS Code triggers the orchestrator through GitHub, then commits translated outputs and QA evidence back to the repository.
Controlled working-folder deployment
Approved translated assets can be pushed into a controlled marketing platform work folder for human review before final placement.
End-to-end localisation operating model
End-to-end translation, approval, deployment, rollback, reporting, and audit evidence through one governed workflow.
Greg's take
A translation platform is not automatically the answer. Sometimes it is the right answer. Sometimes it is a large system bought to fix a smaller workflow problem.
The risk is paying for a full translation operating model when the actual pain is simpler: files move slowly, terms get changed, reviewers lack evidence, and campaigns wait.
This build is about proving the smaller controlled layer first. If the company still needs the full platform later, fine. But then the decision is made with evidence, not panic.
Smartcat option and ROI case
Platform versus controlled internal layer.
Smartcat is a serious enterprise translation platform. It offers AI translation, localisation workflows, human review options, file handling, vendor support, and broader translation management capability. That makes it a valid benchmark. It also means the buying decision is bigger than the immediate problem many marketing teams are trying to solve.
Translation AI is aimed at a narrower but valuable gap: recurring marketing assets that need fast translation, protected terminology, evidence, and human review control. The question is not "can we build Smartcat?" The question is "can we remove enough manual cost, delay, review effort, and platform dependency from the marketing translation workflow to justify a controlled internal AI layer?"
| Decision area | Smartcat-style platform | Translation AI internal workflow |
|---|---|---|
| Best fit | Large-scale or multi-domain localisation across products, markets, and vendor networks | Recurring marketing asset translation with fast turnaround, protected terms, and internal review control |
| Cost profile | Platform subscription plus per-word or per-project vendor costs. Can scale to $25,000-$120,000+ annually at enterprise tier | Infrastructure cost only through Cloudflare Workers and AI API calls. No per-word or platform licence cost. Build cost is a one-time investment |
| Marketing asset control | Good, but configured within platform constraints. File types, review states, and workflows depend on platform support | Fully customizable. Asset structure, protected terms, QA criteria, and review states are defined by the team |
| Protected terms | Glossary and termbase features available. Quality depends on how well configured and maintained | Protected terms enforced in the payload before the model call. Violations surface at QA gate, not after the fact |
| Evidence and audit trail | Project-level reporting and audit features available at higher tiers | Evidence is built into the output. Every translation carries provider, QA result, review status, and rollback path |
ROI model
The assumptions below are illustrative. Replace with actual figures to size the business case.
Platform benchmark
Annual Smartcat-style platform cost, if purchased
Actual cost depends on tier, seats, volume, and vendor marketplace usage. These are reference figures, not quotations.
Manual workflow savings
Time saved per translated marketing asset
Time saved covers file preparation, vendor handoff, review coordination, protected term corrections, upload, and rework.
Conservative case
Translation AI pays for itself if it saves enough manual handling and review time to avoid or reduce platform spend and remove recurring translation bottlenecks.
Stronger case
Translation AI becomes valuable when it shortens campaign turnaround, reduces rework, protects brand and legal terminology, and gives reviewers enough evidence to approve faster.
Enterprise case
If the company would otherwise buy or expand a full TMS mainly for recurring marketing assets, a controlled internal layer could save tens of thousands annually while preserving the option to use a TMS for complex localisation needs.
Greg's take
A translated asset is not automatically a usable asset. Somebody still has to know what changed, what terms were protected, what the model touched, and whether a human needs to review it before it goes near a campaign.
That is the part most translation workflows hide. They show the output and skip the evidence. The model translated it, so it must be fine. Nobody checks whether a product name was protected. Nobody checks whether the confidence was high enough. Nobody checks what the QA gate actually said.
This build puts the evidence back in. Protected terms are enforced before the model call, not reviewed after. The QA gate is explicit. The review state is recorded. A human can see exactly what happened before the asset gets used.
A model that translates well is not the same as a translation system. The difference is the layer around the model call: structured payloads, protected terminology, review states, and a clear record of what happened and who approved it.
Want to discuss the Translation AI build?
For demos, architecture conversations, speaking opportunities, or collaboration around governed AI localisation workflows.