There’s a question we hear often when talking to a new client:

“So, when can you start translating?”

Our answer is always the same: not yet.

We know that’s not what most people want to hear. There’s usually a deadline. There’s a product launch. There’s pressure from stakeholders across the organization. Everyone wants to see translated files moving through the pipeline.

But here’s what we’ve learned after years of working across industries and content types: the fastest way to delay a localization project is to start translating too early.

The problem nobody talks about

In any multilingual program, terminology management is not a stylistic preference. It’s a quality and consistency requirement.

If a feature is named one way in a product interface and a different way in the user guide, that’s not a “minor inconsistency.” It’s a source of confusion for end users. It’s a support cost waiting to happen. In regulated industries, it can even become a compliance issue that triggers costly re-submissions.

And yet — most localization projects start with translation.

Files are handed over, the CAT tool is set up, linguists are assigned, and everyone hopes the translation glossary will sort itself out along the way.

It never does.

What actually happens is predictable: each target language starts developing its own variants of the same terms. One linguist translates a product name one way. Another linguist, working on a different document for the same product, translates it differently. Multiply that by fifteen languages and three product lines, and you’re sitting on a terminology debt that grows with every project.

What we do instead

We start with terminology management. Always.

Before a single word is translated, we build a validated, client-approved glossary. Not as an optional add-on. Not as a “nice to have” if the budget allows. As a prerequisite for everything that follows.

Here’s how our process works.

Step 1: NLP extraction. Our natural language processing pipeline scans the client’s existing content — documentation, software strings, legacy translation memories — and extracts candidate terms at scale. For a recent project, this meant processing over 1.15 million words of legacy content across three languages.

Step 2: Source-language review. A native linguist in the source language filters and validates each term. Not every term the NLP extracts is a real term. This is where human judgement separates signal from noise.

Step 3: Client validation. The client reviews and approves every source entry. This step is non-negotiable. They know their products, their naming conventions, their brand voice. We don’t make assumptions about what a product component should be called.

Step 4: Target-language terminology. A native linguist in each target language sources equivalents from existing translation memories and aligned documents — or translates from scratch where no resource exists.

Step 5: Deployment. The glossary is loaded into the CAT environment and enforced across every project, every linguist, every language.

Two things matter here that are easy to miss. First, steps 2 and 4 are handled by two different specialists — a source-language expert and a target-language expert. We don’t ask one person to do both. Second, the client validates the source glossary before the target terminology is created. This prevents the single most expensive mistake in terminology management: building a multilingual glossary on top of source terms that the client doesn’t recognise or agree with.

What this looks like in practice

For that 1.15-million-word project we mentioned: we delivered 300 validated glossary entries across three languages in one week. The manual approach would have taken over 750 hours. The cost saving was roughly 70%.

But the real value wasn’t in the speed or the cost reduction. It was in what came after.

Every translation project that followed had a foundation. Linguists knew exactly what each term should be. Reviewers could check terminology compliance automatically. New products could inherit the shared glossary from day one.

That’s the part most organizations underestimate about terminology governance: it’s not a project cost. It’s an investment that compounds on every subsequent project — reducing rework, lowering risk, and accelerating turnaround.

Why this matters more than you think

Terminology errors discovered late in the localization cycle require cascading fixes across all documents, all languages, and all versions. We’ve seen organizations spend more on fixing terminology downstream than they would have spent building the glossary in the first place.

Without a governed source glossary, each target language develops its own variants. Those variants compound into inconsistencies that become harder and more expensive to fix with every release.

The question isn’t when to start translating. The question is: what needs to be true before translation can begin?

Creative Words helps organizations build validated multilingual glossaries before any translation begins — so every project starts on a solid foundation. Get in touch to see how terminology governance could work for your content!