Localization Data Model, Translation Memory and Terminology

1. First screen: a 100% match can still be wrong

A product has used the English label “workspace” for two years. The German translation memory contains Arbeitsbereich öffnen, and a CAT tool returns it as a 100% segment match for “Open workspace”. Last month, however, the product team renamed the feature and approved Projektbereich for the current UI. The old translation is textually exact and operationally stale.

That is the problem this lesson owns. Localization data is not just a bag of strings. A reusable translation unit needs source and target text, a locale pair, context, status, provenance, and lifecycle information. Terminology is a different governed asset: it can say which term is preferred, forbidden, product-specific, or deprecated. Reuse becomes safe only when those records can be evaluated together instead of treating a match percentage as approval.

Microsoft’s current globalization guidance describes translation memories as stores of source/target translation units, distinguishes exact/context and fuzzy matches, and explicitly warns that TMs accumulate duplicate, inconsistent, or obsolete translations and need maintenance. [S-MS-TM] Its localization overview treats translation memories and terminology lists as distinct linguistic assets and identifies TMX and TBX as interchange formats for those asset types. [S-MS-LOC] W3C’s terminology requirements likewise emphasize identifying terms with related terminology data so that information can be reused across localization steps and tools. [S-W3C-TERM]

The bounded artifact is Localization Data & Terminology Governance Record v1. It records what kind of record is being reused, source and target values, locale pair, product/context namespace, lifecycle status, provenance, terminology constraints, the reuse decision, mutation evidence, repair evidence, changed-context transfer, and one residual limitation. It does not perform linguistic QA, approve AI translations, or claim that an exact or high fuzzy score is automatically correct.

2. Route orientation: the database shape is not the learning goal

Foundation route: begin by separating two tables conceptually. A translation unit is a reusable source/target segment in a locale pair. A terminology record governs a term such as a feature name, with a preferred or forbidden target and a scope. Then add the fields that make reuse reviewable: context, source identity/version, status, review history, and the terminology version used when the translation was approved.

Repair route: start from one bad reuse decision. Mark a deprecated exact match as automatically approved, merge the termbase into the full-sentence TM, remove provenance, or allow a high fuzzy match to override the current preferred term. Predict which audit code should appear, execute the local audit, repair only the failed boundary, and rerun.

Experienced route: inspect the fixture as a data-governance contract. Ask whether a reviewer can answer: What product and surface did this translation come from? Is it active, deprecated, or review-required? Which source version was reviewed? Which terminology rule applied? Is the candidate exact, context, fuzzy, or new? Was the historical match accepted, rejected, or forced back to review? You may compress the introductory vocabulary, but not the mutation, evidence, or transfer requirements.

3. Mental model: four layers, four different responsibilities

Keep four concepts separate.

Source resource identity answers what message is being localized now. A stable key such as nav.open_workspace is useful, but it is not enough by itself; product, surface, source version, and source text can change.

Translation memory stores reusable source/target segments. A translation unit is usually more than two strings in a serious system. It needs a locale pair, context metadata, lifecycle status, and provenance so that an old record can be diagnosed instead of silently reused. Microsoft notes that 100% segment matches differ from context matches and that fuzzy matches must still be considered in the current context. [S-MS-TM]

Terminology governs terms rather than full sentence reuse. The current German preferred translation for workspace might be Projektbereich, while Arbeitsbereich is forbidden for Product Alpha but still acceptable in Product Beta. A termbase therefore needs scope and versioning. Treating the termbase as a sentence-level TM erases a meaningful governance boundary. [S-MS-LOC]

Reuse decision is an accountable decision built from evidence. Similarity can help find candidates; it is not a universal quality score. A 100% text match can be stale because terminology or product meaning changed. A 92% fuzzy match can be excellent in one context and unusable in another. The data model must preserve the ability to reject a historical match.

4. Foundation layer: model identity, context, lifecycle, and provenance

A minimal translation-unit record for this lesson includes: id, source, target, source_locale, target_locale, context, status, provenance, terminology_version, and an optional superseded_by. Context contains at least product, surface, and resource key. Provenance contains the source version, reviewer identity, and review date. Status distinguishes records such as approved, deprecated, and review_required.

These fields serve different questions. status tells you whether the record is currently eligible for reuse. source_version tells you what source revision was actually reviewed. terminology_version tells you which terminology policy was in force. superseded_by provides a trace from an obsolete translation to a current one. None of those fields alone proves current correctness, but together they make stale reuse diagnosable.

The terminology record is deliberately smaller and different: source term, target locale, preferred target, forbidden alternatives, product/context scope, status, and version. A termbase can constrain a translation unit without becoming the translation unit. W3C’s terminology requirements describe associating terms with terminology information and reusing those markers through localization workflows, which supports this separation of full-segment reuse from term governance. [S-W3C-TERM]

Do not use timestamps as a magic freshness score. A record reviewed yesterday can still be wrong for a different product namespace; a stable term reviewed months ago may still be valid. Time is provenance, not proof.

5. Deep explanation: exact, context, fuzzy, and new are candidate classes

A useful reuse pipeline starts by finding candidates and only then makes a governance decision.

An exact segment match means the source text matches. It does not prove that the product meaning, surrounding resource, terminology, or current status matches. Microsoft’s TM guidance explicitly distinguishes segment-only 100% matches from context matches. [S-MS-TM]

A context match strengthens the candidate because surrounding segments or project context align, but it still does not supersede current terminology or lifecycle status.

A fuzzy match is a retrieval hint with a similarity percentage. Microsoft describes fuzzy matches as candidates that translators must consider for the current context; some require small changes, some complete retranslation, and some are unusable. [S-MS-TM] Therefore this lesson stores a fuzzy score as candidate metadata, never as a universal acceptance threshold.

A new translation is not a failure of the TM. It is the correct state when no historical unit satisfies the current contract.

The lab expresses final decisions with bounded labels such as REJECT_STALE, REUSE_CANDIDATE_REVIEW_REQUIRED, REVIEW_REQUIRED_TERM_CONFLICT, and NAMESPACE_OR_NEW_REVIEW. None means “automatically linguistically approved.” That adjacent outcome belongs to the next lesson’s localization QA and AI-assisted review boundary.

6. Worked example: “workspace” after a product rename

Product Alpha originally translated workspace as Arbeitsbereich. Translation unit TU-001 contains “Open workspace” → “Arbeitsbereich öffnen”. It is a perfect source-text match for today’s label, but its status is deprecated, its terminology version is old, and it points to TU-002 as its successor.

Current terminology says the preferred German term for Product Alpha is Projektbereich and explicitly forbids Arbeitsbereich. TU-002 contains the updated target “Projektbereich öffnen”, carries the current context and terminology version, and has an approved lifecycle state. Even then, the lesson records it as a reuse candidate requiring current review, not an automatic linguistic approval. The data layer proposes and explains; it does not steal the QA lesson’s decision.

A second candidate, “Create a new workspace”, has a 92% fuzzy historical match containing the forbidden old term. The correct evidence is not “92 is high, therefore reuse.” The evidence is: similarity found a candidate; current termbase detects a conflict; provenance shows the unit predates the terminology change; decision becomes REVIEW_REQUIRED_TERM_CONFLICT.

The evidence matrix makes each step inspectable: record type, source, target, locale pair, context, status, provenance, terminology constraint, and reuse decision. If an output row cannot explain why a candidate was rejected or escalated, the model is too lossy for the owned outcome.

7. Failure modes that survive happy-path demos

Exact-match automation. A system sees 100% and sets approved=true. The old feature name returns to the UI even though the source string is unchanged.

TM/termbase collapse. Full sentence translations and term policies are merged into one undifferentiated table. Reviewers can no longer tell whether a row is a sentence candidate or a terminology constraint.

Missing provenance. Two targets exist for the same source, but there is no source version, reviewer, review date, or successor relation. The system can detect duplication but cannot explain which record is current.

Similarity as quality. A fuzzy score is treated as linguistic confidence. Similarity says how close candidate source text is according to the matching system; it does not encode current terminology, audience, legal meaning, or UI context.

Historical hoarding. Every old record remains active forever. The TM grows, but curation quality falls. Microsoft specifically calls out obsolete, duplicate, and terminology-inconsistent TM entries as maintenance problems. [S-MS-TM]

Interchange overclaim. A TMX or TBX file imports successfully, so the team claims semantic compatibility. Interchange preserves a portable representation, not your product’s current context, status policy, namespace semantics, or acceptance rules. [S-MS-LOC]

8. Experienced bridge: treat localization assets like governed code data

The stronger engineering analogy is not “translations are strings”; it is “localization assets have schemas, provenance, migrations, lifecycle states, and compatibility boundaries.” A rename resembles a data migration: old records may remain for history, but current read paths should not treat deprecated rows as active.

A good repository can answer why a candidate exists and why a decision was made. This suggests stable IDs, explicit status, review events, supersession links, and scoped terminology. It also suggests separating immutable historical evidence from the active view used for reuse suggestions.

Do not overfit this lesson into a production CAT architecture. You do not need to implement a search engine, vector index, vendor workflow, MT engine, or reviewer UI. Those would hide the construct. The bounded implementation is a small deterministic dataset plus an audit that proves stale/conflicting entries are detectable and that changed-context reuse is not silently generalized.

9. Alternatives and trade-offs

You can keep TM and terminology in separate services, separate tables, or one physical store with different record types. The physical layout is secondary to semantic separation. If one database table is used, a record_type and distinct validation rules must still prevent a term policy from masquerading as a sentence-level translation unit.

You can preserve historical rows in place with status flags, move them to an archive, or use temporal/versioned storage. Keeping history is useful for audit and rollback; keeping everything active is the problem. Lifecycle must be explicit.

You can use exact string matching, CAT-style fuzzy matching, token similarity, or embeddings to retrieve candidates. Retrieval technique does not own acceptance. The acceptance boundary still needs context, status, terminology, and provenance evidence.

TMX and TBX are useful when exchanging assets between tools. Microsoft’s current guidance identifies TMX for translation-memory data and TBX for terminology data. [S-MS-TM] [S-MS-LOC] The trade-off is that interchange portability can tempt teams to assume semantic portability. The lab therefore records semantic_compatibility_guaranteed=false and requires product-specific validation after import.

10. Guided and independent practice

Guided task: run the baseline audit and inspect the four reuse candidates. Before running it, predict which exact match should be rejected as stale, which current exact/context candidate still requires review, and which fuzzy match should be escalated because of current terminology.

Then run deliberate mutations. First, change the deprecated exact match decision to AUTO_APPROVE. The audit must fail with STALE_EXACT_AUTO_APPROVAL. Next, merge terminology records into the translation-unit collection; the audit must detect TM_TERMBASE_BOUNDARY. Remove provenance from the current unit; the audit must detect PROVENANCE_REQUIRED. Accept the 92% fuzzy match solely because of score; the audit must detect FUZZY_SCORE_OVERCLAIM. Finally, claim that TMX/TBX import guarantees semantic compatibility; the audit must reject INTERCHANGE_SEMANTIC_OVERCLAIM.

Independent task: Product Beta shares the English term workspace, but its audience and established terminology differ from Product Alpha. Decide what can be shared, what must be namespaced, and what needs new review. You must not copy Alpha’s target term merely because the English source token is identical.

11. Verification and evidence: observation, inference, decision

The Localization Data & Terminology Governance Record v1 separates three levels.

Observation: TU-001.status == deprecated; Product Alpha termbase forbids Arbeitsbereich; TU-001.terminology_version == 1; current terminology version is 3.

Inference: the historical exact match is stale for the current Alpha context.

Decision: reject TU-001 for current reuse and inspect its successor or create a new reviewed translation.

A second row may observe a fuzzy score of 92. The bounded inference is only that the source is similar enough to inspect. The final decision still checks terminology and context. If the current preferred term is violated, the record is escalated instead of accepted.

Mutation evidence must include predicted failure, observed issue code, diagnosis, repair, and rerun. Transfer evidence must show the method applied to Product Beta without copying Product Alpha’s answer. The residual limitation must state that this deterministic fixture does not perform linguistic QA, human approval, machine translation evaluation, or vendor-platform interoperability testing.

12. Assessment and transfer

You should be able to state the TM-versus-termbase boundary, implement the bounded model, diagnose a stale or conflicting reuse decision, defend the lifecycle/provenance fields, explain what TMX/TBX do and do not prove, and transfer the method to a second product namespace.

Blocking failures are: a deprecated exact match is automatically approved; terminology and TM units become indistinguishable; provenance is missing where lifecycle decisions depend on it; fuzzy percentage is treated as a universal quality score; interchange syntax is claimed as semantic compatibility; or the changed-context task simply copies the first product’s terminology.

AI may suggest candidate checks after you state the governing contract, but it may not fabricate evidence or make the accountable acceptance decision. This lesson ends when the data and evidence make safe reuse reviewable, not when a tool reports a high match score.

13. References and freshness boundary

S-MS-TM — Microsoft, Translation memories. Current guidance describes translation units, exact/context and fuzzy matches, TMX, and maintenance problems including duplicate, inconsistent, obsolete, and terminology-out-of-sync entries. [S-MS-TM]

S-MS-LOC — Microsoft, Localizing your product. Current guidance treats translation memories and terminology lists as distinct assets, identifies TMX and TBX interchange, and emphasizes review in actual user context. [S-MS-LOC]

S-W3C-TERM — W3C, Internationalization and Localization Markup Requirements, terminology requirements. It describes identifying terms and associating terminology data so that terminology information can be reused through localization steps and tools. [S-W3C-TERM]

The source boundary has not expanded. Microsoft pages are practice-evolving sources with review due 2026-12-31; W3C terminology requirements are used as a foundational source. Recheck earlier if official guidance changes materially. This lesson does not infer that a portable file, exact match, or fuzzy percentage proves product-specific correctness.