Segments and context can work together, so the conflict isn't technical. It's trust. A localization manager can predict, price, and measure one segment at a time, and moving the memory from matching characters to matching meaning breaks the one to one their work is built on. Rodrigo argues for making the move anyway, starting from that trust.
What is the myth?That more context is the big change. The bigger change is finding approved work by meaning, not by characters.
Where do I start?Take last quarter's segments that had no match and count how many your team already approved in other words.
A debate on LinkedIn this week asked how a myth got started. The myth is that segments and context are in conflict. A segment is a sentence or a short passage, the unit a translator works on. Context is everything else an AI model could read to translate that sentence well.
The answer in the thread was that you can have both. Pass the important context to the model, and still reuse the segments your reviewers already approved.
I agree there is no technical conflict. The conflict I see is about trust. I see two reasons a localization manager could have a hard time making this move.
- One segment at a time is easy to run. It's easy to predict, pay for, and measure. Open context is not, at least not yet.
- Moving the memory to meaning breaks what they built on. A translation memory finds past work by matching characters, not meaning. Moving to meaning is the real change, and it breaks the one to one that review, reuse, and pricing all depend on.
A disclosure before I start. When I put myself in the localization manager's shoes, I'm not supporting that view. I'm forcing myself to think from their side, because they are the ones who have to trust the change. I don't support staying with segments. I support that we have to migrate to this new world.
1. Why a localization manager holds on to one segment at a time
Segments, edit distance, MQM, and the rest of the localization framework were a response. Edit distance measures how much a reviewer changes a suggestion. MQM is a shared way to count and grade translation errors. Together they helped the industry raise productivity and reduce cost and risk at scale.
They also gave the localization manager a problem they can solve one segment at a time. It fits a workflow anyone can follow. It gets translated, reviewed, approved, and stored. You can count it, price it, and report on it. When a stakeholder asks what happened to a sentence, you can show them. That is how quality management works on most teams today, and it works.
Take a 30-page document your team translated last year. Three segments changed. One segment at a time, you know what happens. Three get translated and three get reviewed. You pay for three, and the risk is three segments. It's predictable.
With open context, the same three segments open a whole other world. What context do I put in to fix them? All 30 pages, the style guide, last year's version? Will the segments we already approved stay exactly as they were? What will it cost? And how do I measure that all of it makes the translation better, and not just different?
The job itself changes. I was someone dealing with workflows, managing assets, and delivering assets. Now I'm working on taxonomy, content hierarchy, and many topics connected to language and content.
Some people call this orchestration. I think it goes deeper. In orchestration, your musicians are all still playing. Here you remove the musicians and replace the entire place.
That is much harder to sell to a localization manager, and much harder to trust. It raises an honest question, too. If everything moves to context, why keep any localization technology at all? Why not send the content to the newest model and let it do the thing?
I see it as a range. On one side, translation that is fully automated, with none of the tools teams use today. On the other, translation done fully by people. Each step toward the automated side removes something our industry was built on. So the manager has to trust that the new way works, that it keeps their job alive, and that it won't break the workflows they run right now.
2. Why moving the memory to meaning is hard for a localization manager
My second point matters more to me. A translation memory, your library of approved past translations, finds matches by comparing characters, not meaning. The comparison is called a fuzzy match, a percentage of how much of the old sentence lines up with the new one.
So an approved translation can sit in your memory and never come up, only because it was written differently. If a sentence changed 50%, in many cases the fuzzy match won't even offer it.
Take "Talk to our sales team." and "Speak with someone in sales." They mean the same thing. About a quarter of their characters line up, far too few for a fuzzy match to show. A reviewer approved that idea last year, and this year the translator starts from zero.
Search by meaning works differently. Each sentence is stored as a list of numbers that stands for what it means, a method researchers call vector semantics. Sentences that mean the same thing land close together, whatever words they use. So a new sentence finds your approved work by what it says.
Gabriel's deck on vectors shows the difference with two sentences that say the same thing.
| Stored as text | Stored by meaning | |
|---|---|---|
| John has gone to the store. | The words, letter by letter | [0.12, -0.94, 0.43, 0.01, 0.63] |
| John went to the supermarket. | The words, letter by letter | [0.12, -0.93, 0.42, 0.01, 0.63] |
| What a search sees | Two different sentences | The same idea |
The numbers are a simplified example from the deck. Real vectors are much longer, and sentences with close meanings still get close numbers.
Here is the hard part, from the same seat. A translation memory is built on pairs, one source sentence for one target sentence. Translate by meaning, and that one to one breaks. "Our new store is open. Come in this weekend." can become one Portuguese sentence, "Nossa loja nova abriu, venha conhecer neste fim de semana." So what goes back to the memory? What does the reviewer compare? How do you count it and pay for it?
“Segments are great… but they’re also a prison.”
Gabriel Fairman, CEO of wxrksSo the myth, in my opinion, is not about more context or less context. It's about moving from a syntactic way of storing and searching, by characters, to a semantic way, by meaning. Once meaning is at the center, you reuse far more of the content your team already approved and paid for.
Our CEO, Gabriel Fairman, made the same point in his talk on why segments hold us back. Segments, he said, are "built for syntax-driven operations, not for semantic-driven operations."
What it looks like in practice
Free-Flow is our editor built on vectors. You work on the whole document, and it reads your glossaries and past translations by meaning instead of matching words. Henrique Cabral, our CTO, presented it at the Process Innovation Challenge at LocWorld.
Free-Flow doesn't replace our segment editor. As its deck puts it, Free-Flow is an alternative for a different kind of use case and purpose.
| Segment editor | Free-Flow | |
|---|---|---|
| Best for | Software, documentation, and work that must be predictable | Transcreation, deep adaptation, repurposing, and new content |
| Memory and glossary | Found by matching characters | Found by meaning |
| Source and target | One sentence for one sentence | No one-to-one rule, you can even start from the target |
| The text | Split into segments | The whole document |
The Free Flow Editor by Gabriel Fairman
Gabriel's deck, Findings and Theories in a Push for a Fully Vectorized Translation Environment, lays out the research behind it.
Once you have vectors, you start to play with more meaningful alerts. Articulated Suggestions, the continuation of Free-Flow, is that next step. Gabriel presented it at the Process Innovation Challenge at LocWorld 54. It looks at the why behind each edit, not only the edit. A translator replaces "cutting-edge" with "advanced" to sound less bold, and it suggests "several" instead of "various" to keep the same tone.
Measuring doesn't have to change. You can still measure each segment by how much a reviewer edits it. In The Edit Distance Report, across 27 million segments, suggestions built from each team's own approved translations and glossary, what we call Context Sensitivity, needed 47% less editing than machine translation. That's a number you can take to a stakeholder.
The two worlds, side by side
Here are the topics from this article, as a localization manager sees them today and in the new world.
| TodayOne segment at a time | The new worldMeaning at the center | |
|---|---|---|
| Price | Predictable. Three segments changed, you pay for three. | Depends on how much context goes in with them. |
| Risk | You can count it, three segments. | Will the segments you already approved stay the same? |
| Context for the AI | The segment, maybe a few neighbors. | The whole document, the style guide, the glossary, past versions. |
| Finding approved work | By matching characters. 25% alike is not shown. | By meaning. The same idea is found in other words. |
| Source and target | One sentence for one sentence. | Two sentences can become one, and one can become two. |
| Review | Each pair, side by side. | A whole passage, read for meaning. |
| Measuring | Edit distance per segment, easy to report. | Still per segment, plus proof that the context helped. |
| The manager's job | Workflows, assets, and deliveries. | Taxonomy, content hierarchy, and language. |
Where to start
Pull last quarter's new segments, the ones translated with no match. Read twenty of them. Count how many say something your team already approved, in other words. That count is what search by meaning gives back.
Your translation memory still matters. It just has to be found by what it means.
See how Free-Flow finds your approved translations by meaning
Unlock the power of glocalization with our Translation Management System.
Unlock the power of
translation by meaning
with our Translation Management System.
