Localization has a terminology problem. The same concept gets called something different depending on whether you sit at an LSP, a TMS vendor, or a buyer organization. Some definitions are wrong. Others are contested. This glossary names them plainly and invites you to push back.
Your responses help build a shared picture of how localization actually works. We publish the results here as percentages, so everyone can see where the industry stands.
20 terms
The structural condition that pervades LSP organizations at multiple levels. A person (senior PM, i18n engineer, graphic designer) is held responsible for an outcome they cannot control, because the decisions that shape that outcome are made above them with no input from them. Not a personal failure. A systemic arrangement.
A failure pattern in localization programs where a technical problem is relabeled at each handoff until it reaches the program director with the wrong diagnosis. A broken array becomes "a translation quality issue." A missing API endpoint becomes "the LSP is slow." A stopped script becomes "the team isn't communicating." The root cause is never named because no one in the chain had the full picture.
A translation memory segment that partially matches a new source string, typically expressed as a percentage. Contested because different TMS tools calculate fuzziness differently, and discount tiers tied to match percentages vary widely across LSP contracts, often to the buyer's disadvantage.
The observation that quality failures in localization programs almost never originate in the translation itself. They originate at the boundaries between systems. Content updated after translation begins. Approved copy sitting in staging. Files reaching the LSP without a spec. The handoff, not the translation, is where programs break.
Review of translated content by native speakers based in the target market, typically employees rather than linguists. Contested because reviewers apply personal preference over approved style guides, their feedback is difficult to govern at scale, and the process often delays delivery without improving measurable quality.
The foundational resources that make consistent, scalable translation possible: a glossary or termbase, a style guide (per locale), and translation memory. Without these, every project starts from zero and every vendor invents their own terminology. These are the client's responsibility to own and provide. The LSP can contribute to and maintain them, but cannot build them unilaterally.
The properly scoped function of a language service provider in a mature program: not simply delivering translations, but acting as the guardian of linguistic quality: assigning work only to the most qualified linguists for each language pair and content type, enforcing the style guide, and ensuring translation memory and glossary are applied consistently. This role is difficult to fulfill without a shared operating environment (TMS + language assets).
A workflow condition where a person must step in and take a deliberate action to keep the translation cycle moving. Often surfaces as an error at the delivery stage rather than being anticipated in planning. The risk is normalization: once a manual step resolves a problem, it tends to get absorbed into the standing workflow and repeated on every subsequent project, whether or not the original trigger still exists. What began as a workaround becomes a permanent drag on efficiency, invisible in retrospect because it was never formally added to the process.
Machine Translation Post-Editing. Using a human editor to correct machine translation output. Contested because "light post-editing" and "full post-editing" mean different things to every buyer and every LSP, and the line between them is rarely enforced in contracts.
A diagnostic pattern that distinguishes a practitioner's read from a generic AI response. When intake answers match a practitioner signal, the brief names the underlying issue explicitly rather than describing its symptoms in general terms. Examples: terminology drift from multiple simultaneous vendors; bilingual employee used as a structural substitute for a professional reviewer; AI translation without a defined post-editing step.
The plain-language output of the LocNavigator diagnostic: a structured assessment of a localization program's maturity level, key gaps, practical suggestions, and strategic recommendations. Distinct from a "diagnostic brief" (avoids AI-generated framing) and from a consulting report (shorter, immediately actionable).
Approved translations that have accumulated in disconnected locations: email threads, vendor portals, shared drives, individual TMS instances. No single source of truth. The result of project-by-project management without a shared translation memory or centralized TMS. Every new project starts from scratch because no one can find or trust what was approved before.
The point at which source content is locked and formally handed off for translation. Contested in software localization because it is frequently violated or extended without notifying the localization team, making downstream translation invalid.
A program condition where the root cause has been correctly identified but resolution requires coordinated action across organizational boundaries that no single person controls. Distinct from a chain of misattribution, where the problem is misdiagnosed at each handoff. In structural deadlock, the diagnosis is accurate, but the authority, budget, and will to act are held by different people who have not yet been brought into alignment.
Translation, Editing, Proofreading. The traditional three-stage workflow model for professional translation. Contested in practice: the editing and proofreading steps are frequently collapsed, assigned to the same linguist, or dropped under cost and time pressure, often without the buyer knowing.
The structural gap in the localization tooling market between (1) a script written by an SE that lives on one engineer's laptop and (2) a formal enterprise TMS platform built for the widest use case at significant cost. Almost nothing exists in the middle that is lightweight, domain-specific, and deployable without an engineering team. This is the gap LocNavigator and future Vertical SaaS tools are built to fill.
A localization program situation that exceeds what any automated diagnostic can resolve. The readiness brief correctly identifies the pattern (stranded assets, a broken handoff, a vendor relationship in decline, a budget that doesn't match the program's stated goals) but the path forward requires something a form cannot provide: judgment about organizational trade-offs, credibility with stakeholders, knowledge of how similar programs have navigated the same friction, and the ability to name the real problem in a room where it hasn't been named yet. The ceiling is not a limitation of the tool. It is a signal that the situation requires a practitioner.
The percentage of a project's content that matches existing approved translations in translation memory. Contested because matching algorithms vary by TMS, fuzzy thresholds differ across tools, and "leverage" does not always translate into equivalent time or cost savings for the buyer.
Creative adaptation of content that prioritizes intended effect over literal accuracy. Contested because there is no standard definition of where translation ends and transcreation begins, no standard deliverable, and no standard pricing model for it.
Software built for a specific industry by a practitioner who understands it from the inside, not a generalist developer. Occupies the gap between a script (no UI, no persistence, no user) and an enterprise platform (too heavy, too expensive, too slow to implement). Purpose-built, opinionated, and owned by someone with domain knowledge that cannot be replicated by a developer alone. LocNavigator is an example.