{"id":13864,"date":"2026-04-16T11:50:28","date_gmt":"2026-04-16T11:50:28","guid":{"rendered":"https:\/\/www.1stopasia.com\/blog\/?p=13864"},"modified":"2026-04-16T10:20:30","modified_gmt":"2026-04-16T10:20:30","slug":"terminology-in-translation-rework-costs","status":"publish","type":"post","link":"https:\/\/www.1stopasia.com\/blog\/terminology-in-translation-rework-costs\/","title":{"rendered":"The terminology decision that costs LSPs three years of rework"},"content":{"rendered":"

AI Overview<\/h2>\n
\n\n\n\n\n\n\n\n\n
Category<\/strong><\/td>\nSummary<\/strong><\/td>\n<\/tr>\n
Topic<\/strong><\/td>\nThe critical necessity and compounding cost of deferred terminology governance in LSP account management.<\/td>\n<\/tr>\n
Purpose<\/strong><\/td>\nTo demonstrate that establishing terminology governance early in a project is a critical foundation for consistency, quality, and long-term client retention, preventing years of expensive rework.<\/td>\n<\/tr>\n
Key Insight<\/strong><\/td>\nTerminology failure is often an accumulating inconsistency (an ‘undecided’ term) that passes project-level QA until it causes systemic quality issues and forces manual clean-up at scale.<\/td>\n<\/tr>\n
Best Use Case<\/strong><\/td>\nApplicable for Language Service Providers (LSPs), Project Managers (PMs), and clients onboarding new, long-term translation accounts where consistency is vital.<\/td>\n<\/tr>\n
Risk Warning<\/strong><\/td>\nDeferring terminology ownership leads to years of expensive manual rework, destroyed project profit margins, and a gradual erosion of client confidence that severely jeopardizes account retention.<\/td>\n<\/tr>\n
Pro Tip<\/strong><\/td>\nInvest two weeks at the start of a new account to explicitly assign terminology ownership, build a validated candidate glossary, implement version control, and treat new terms as a mandatory deliverable.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
\n
Download Article<\/a><\/div>\n
<\/div>\n<\/div>\n

There was a project manager somewhere in an LSP’s account team who spent the better part of a quarter managing a problem she couldn’t name. The client’s feedback wasn’t wrong, exactly. It wasn’t pointing to a specific error. It was something harder to address: the quality feels clunky and unprofessional<\/i>. The scores were borderline. The review cycles were stretching. And every time she looked at the individual deliverables, they passed QA.<\/p>\n

The root cause surfaced on project seven. Back in week two, a production team had made a reasonable terminology call. They had no glossary, they had a deadline, and they made a judgment. That judgment went into the TM. Three linguists and six projects later, it had quietly become the standard, carried forward by momentum rather than any conscious decision.<\/p>\n

That is a terminology problem. It doesn’t look like one until it’s already cost you.<\/p>\n

Terminology alignment is a relationship foundation. The LSPs who treat it as a project task spend years paying the cost of a decision that takes two weeks to get right at the start.<\/p>\n

When the problem surfaces, it doesn’t announce itself<\/h2>\n

Here is what makes terminology failure so damaging: the evidence that something is wrong arrives long before anyone can name the cause.<\/p>\n

From the PM’s side, the symptoms follow a recognizable pattern. Quality scores are inconsistent, but no single project fails outright. Review cycles run longer than the account’s history would predict. Client feedback is frustrated but imprecise. Not “this term is wrong,” but something vaguer and harder to act on: it doesn’t sound like us, it feels off, I keep having to explain the same thing to my reviewers.<\/i><\/p>\n

The reason it’s so hard to diagnose is that every one of those symptoms passes QA. Take a Vietnamese educational software project we ran for a major EdTech client. The standalone term “Attendance” was translated as S\u1ef1 tham d\u1ef1<\/i> – general presence, linguistically valid, and not a mistake any automated tool would flag. The actual UI context required \u0110i\u1ec3m danh – the specific act of taking roll call. The client felt the result was clunky and unprofessional. The individual project passed QA. The problem was that nobody had defined what “Attendance” meant in this product, in this context, before the first string was touched.<\/p>\n

When a wrong term makes it into the TM, the damage is rarely visible at the project level. Individual deliverables pass. Scores hold. The error only becomes apparent when someone steps back and looks across the account, and by that point, the wrong term has been accumulating in the TM for months. In the EdTech case, fixing it meant a manual Replace All across 745 segments, followed by days of unplanned work to walk the client through every change and why it was necessary.<\/p>\n

Terminology problems rarely announce themselves. They accumulate until they can no longer be ignored.<\/p>\n

The decision that nobody marks as a decision<\/h2>\n

Deferral is rarely negligence. It is the rational response to a job with no instructions and a deadline.<\/p>\n

When a new account arrives with no glossary, no style guide, and no terminology reference, which happens more often than anyone in the industry likes to admit, the production team builds the foundation implicitly. The first translator makes the first call. It gets recorded in the TM. The next translator uses the TM. The call becomes the default.<\/p>\n

This plays out in practice. In a large-scale documentation project for a technology client, the source English strings and target translations became misaligned in the working file. The rows were no longer parallel. Without a locked terminology grid, terms were being matched to the wrong source strings. A linguist editing the target for “Newsfeed” was reading the source for “Save and add to post.” The linguist wasn’t careless. They were working inside a setup that assumed a terminology foundation that didn’t exist.<\/p>\n

The result was a cascade of errors that forced the PM to stop production and manually re-verify the entire file against a reference PDF. The project’s profit margin was gone, consumed by manual labor on work that should never have existed. The root cause wasn’t the file misalignment. It was the absence of a locked, governed terminology structure from the beginning of the account.<\/p>\n

By project three, an implicit default has been applied by multiple linguists across potentially thousands of segments. By project five, it is indistinguishable from a decision that was made deliberately. The PM who onboarded the account may not even be managing it anymore. The context that might have flagged the original call as provisional doesn’t travel with the TM entry. What travels is the term.<\/p>\n

The decision point nobody marks as a decision is the moment a new account is onboarded and terminology ownership is either resolved or deferred. Deferred looks like normal operations. It is not.<\/p>\n

What three years of rework actually costs<\/h2>\n

The cost is never contained to the project where it surfaces.<\/p>\n

On a cryptocurrency platform project covering Hong Kong and China markets, high-frequency trading terms like Take profit, Stop loss<\/i>, and Limit<\/i> were marked as Approved in the TM but remained in English. There had been no initial decision on whether to transliterate or localize. The first linguist left them in English as a placeholder. The system saved that as the Approved default for every linguist who followed on the account.<\/p>\n

The problem wasn’t discovered until the end of the project lifecycle, when the internal production team had to reopen locked segments, trigger a late-stage investigation into the project settings, and perform a retroactive cleanup of the entire TM. The client didn’t ask us to fix a specific translation error. They asked us to explain why a decision that should have been made on day one was still unresolved at final delivery.<\/p>\n

The shape of the cost is always the same. It has three layers.<\/p>\n

The direct rework cost<\/h3>\n

TM cleanup across the affected account. Re-translation of segments where the wrong term was applied at scale. Retroactive glossary work, which often means building the glossary backwards from the TM, formalizing the wrong term rather than correcting it. Every hour of this is time that should not exist.<\/p>\n

The PM cost<\/h3>\n

A client who feels inconsistency but can’t point to a specific error is one of the hardest positions a PM can be in. The feedback is real, the frustration is real, and the explanation isn\u2019t clean. The time a PM spends in review cycles, clarification calls, and remediation conversations on a terminology problem compounds across every project that\u2019s affected.<\/p>\n

The relationship cost<\/h3>\n

This one doesn’t appear in a project budget, but it shows up in account retention. A client who loses confidence in consistency rarely raises a formal complaint. They start reviewing more carefully, which causes longer approval times. They bring the relationship up for evaluation at the next vendor review<\/a>. The erosion is gradual and reads as general dissatisfaction rather than a specific failure, which makes it nearly impossible to address directly.<\/p>\n

The asymmetry is worth stating plainly. Getting terminology governance right at the start of a new account requires two weeks of structured work. Fixing it pulls in TM cleanup, retroactive glossary development, re-translation, PM time, and relationship repair. That work takes years. I have watched this play out across too many accounts for years to call it bad luck.<\/p>\n

What two weeks at the start prevents<\/h2>\n

This is what terminology governance looks like when it is done right. Hold any production partner accountable to this standard, including us.<\/p>\n

The clearest illustration of what happens when it fails comes from an aerospace cleanup project requiring strict adherence to a Master Glossary for environmental and legal terms. Different linguists were working from different versions of that glossary, saved locally, with no live master file and no version control. The PM had to issue an Urgent QC Resolution to fix missing legal terms across all files, and then implement a mandatory timestamped naming convention for every subsequent glossary update to ensure the client and the production team were finally working from the same document. That timestamping protocol existed because assuming everyone had the current version had already failed.<\/p>\n

The protocol that prevents this is straightforward. The execution requires discipline from both sides.<\/p>\n

Before the first project starts, terminology ownership is assigned explicitly on both sides. The client names who makes the final call on new terms, whether that is a subject matter expert, a review lead, or a product manager. On the production side, a named person is accountable for consistency across the account. This is a specific, assigned terminology function, not a general QA responsibility.<\/p>\n

If the client cannot provide a glossary, which is common on new accounts, the first step is to build a candidate glossary from available source material: previous translations, product documentation, or any client-side reference material. That candidate glossary goes back to the client for validation before the first project starts. It may be short. It may be incomplete. What matters is that the first TM entries are made against a validated, version-controlled foundation. Every glossary file gets a timestamp. One master and no local copies.<\/p>\n

On project one, terminology is treated as a deliverable alongside translation. New terms encountered in the source that don’t appear in the glossary are flagged, not decided unilaterally. The decision gets made with the client and recorded. The glossary is a living document from day one, not a reference that gets built retroactively when a problem surfaces.<\/p>\n

At the 30-day mark, a terminology review covers what was established, what decisions were made on new terms during project one, and whether the client’s internal reviewers are aligned with the terminology choices in the TM. Misalignments at this stage are cheap to fix. Misalignments discovered at project six are not.<\/p>\n

This is the difference between a production partner and a vendor. A vendor completes the project. A production partner builds the foundation.<\/p>\n

The foundation the client never notices, because it works<\/h2>\n

\"TheThe PM in that account I described at the start eventually found the cause. It took her most of a quarter and a lot of conversations that should not have been necessary. When she traced it back to week two, the original terminology call wasn’t wrong. It was just undecided. Nobody told the production team what the right term was, so they chose. Reasonably. And then it compounded.<\/p>\n

What would have prevented it was two weeks of structured work before project one started:<\/p>\n