Nobody knows what a change touches
Engineering updates a value in the source document. Nobody holds a list of the pages, PDFs and decks in other languages that repeat it.
Keep market content aligned when the source changes.
You may recognise some of this.
Not every team has every one of these. They are the situations that usually prompt the conversation.
Translation without the reason
Translators receive changed sentences without knowing why they changed, and terminology drifts from one market to the next.
Local versions that quietly diverge
A market adapted its page for a good reason two years ago. Nobody wrote the reason down, so the next update either overwrites it or skips that market.
From trigger to accepted result.
We follow one approved source change from release to verified publication in each market.
Step 1: Approved source change
- Product or technical owner
- The change record
- The change is described once, with its reason.
Step 2: Affected assets
- Content operations
- A dependency map across languages and channels
- Every affected asset listed, each with an owner.
Step 3: Translation and adaptation
- Translators or your language service provider
- Terminology guidance and the reason for the change
- Translated with context, not as isolated sentences.
Step 4: Market review
- Local market owner
- Updated asset and documented local exceptions
- Approved, or held with a stated reason.
Step 5: Publication and verification
- Web and channel owners
- The release verification record
- Each version confirmed live, or explicitly held.
What this looks like in practice.
An anonymised scenario drawn from patterns across our past work, showing how this kind of problem gets solved. Named projects follow further down the page.
One real update across two languages
We take one planned or recent source change and follow it across two languages and the channels you agree, building the process as we go.
What you supply
- One planned or recent source change
- The current assets in two languages: web pages, PDFs and sales material
- Any existing terminology lists or translation memories
- A reviewer in each market
What you receive
- A dependency map from the source to every in-scope asset
- Terminology guidance for the content involved
- Ownership and approval steps for each market
- A release verification record
What stays with you
- Market owners approve their local versions
- You decide which channels and languages are in scope
- Your translation supplier, if you have one, remains your supplier
When it is complete
- Every in-scope version is verified live, or held with a reason and an owner
- Documented local exceptions survived the update
- The process is written down, so the next change follows it
Scope, fee, timing and how much of your team's time it needs are agreed in writing before any work starts.
Measured against your own starting point.
During scoping we agree a baseline for each measure from your own records, then compare at the end. We do not promise a percentage before we have seen the work.
From approved change to live in each market.
Assets corrected after publication.
In-scope assets past their agreed date.
Share of affected assets verified or explicitly held.
Similar work, and why it is relevant.
Work by the people behind ECM.DEV, chosen because the workflow is similar, not because the sector is identical. Each case study says how it was delivered, and client names do not imply endorsement.
Multilingual Content Operations for a National Seafood Trade Body
Original English content moved into more than a dozen languages and published in the CMS, including time-critical material where every market had to say the same thing.
Read the case studyContent Operations Transformation
Multilingual publishing across 14 languages with editorial governance, for a national tourism platform over several years.
Read the case study
Founder · Fractional content operations lead
Senior ownership for the work between expertise, content and sales.
I help your team turn specialist knowledge into clear, approved material and repeatable workflows. That means connecting the people, information and systems needed to keep content useful across buying journeys and markets.
Start with one defined project. If you need continued support, I can lead agreed priorities, coordinate contributors and keep approvals and improvements moving, with a scope and rhythm that fit your team.
Start with one conversation.
A scoping conversation is about the work in front of you: which workflow, which material, who needs to be involved. If a first project makes sense, you receive a written scope and fee. If it does not, we say so.
- Understand the problem
- Agree one project
- Deliver and review
- Decide whether more is useful
A completed project with nothing further is a good outcome. Ongoing support is there if you want it, not a condition of starting.