How People Translate Quickly | TMX Import Validation: Check Language Pairs, Locales, TUs and Tags Before a Translation Memory Goes Live

People searching TMX import, TMX translation memory, TMX validator, translation memory import, TMX language pair, TMX locale matching, TMX 1.4b, or how to check a TMX file before importing it are usually not trying to learn the entire theory of translation memory. They are trying to answer a narrower operational question: can this TMX file be trusted enough to enter a live translation memory without misrouting languages, flattening locales, importing broken tags, or seeding thousands of low-trust translation units into future work?

Current TMS documentation uses practical terms such as TMX 1.4/1.4b, source language, target language, strict locale matching, translation units, language variants, tags, creation metadata, and processed translation units before deduplication. These terms point to the dominant reader job. A TMX import should be treated like a data migration: verify the header, language direction, locales, units, inline markup, metadata, duplicates, and sample retrieval behavior before the file becomes part of an authoritative memory.

This article has one dominant job: validate a TMX file before importing it into a working or master translation memory. It does not replace translation-memory cleanup, which repairs the quality of entries already inside a memory. It does not replace legacy-translation auditing, which asks whether old translations are linguistically and commercially safe to reuse. TMX import validation is the gate in between: confirm that the interchange file is structurally coherent and mapped to the correct languages before its contents become searchable, pre-translatable, and potentially authoritative.

Quick answer

A reliable TMX import-validation workflow is:

identify the TMX version and producing system;
preserve the original TMX before editing or conversion;
inspect the TMX header for source language and metadata assumptions;
inventory all language codes present in translation-unit variants;
compare those codes against the destination TM’s source and target locales;
enable strict locale matching when regional distinctions must remain separate;
count translation units before and after import and compare deduplication behavior;
inspect inline tags and protected markup in a representative sample;
review creation/change metadata and custom properties that may affect trust;
import into a sandbox TM first;
search for known segments, wrong-language entries, and suspicious target variants;
only then import the file into the production working or master TM.

The central rule is:

a TMX file is reusable translation data only after its language identity, structural integrity, and import behavior have been verified.

What TMX is actually carrying

TMX stands for Translation Memory eXchange.

A TMX file normally contains many translation units. A simplified conceptual unit looks like this:

<tu>
  <tuv xml:lang="en-US">
    <seg>Save your changes.</seg>
  </tuv>
  <tuv xml:lang="de-DE">
    <seg>Speichern Sie Ihre Änderungen.</seg>
  </tuv>
</tu>

The tu represents a translation unit. The tuv elements represent language variants of that unit. The seg elements contain the source and target text.

Real TMX files can also carry creation date, creator, change date, changer, client, domain, project, context, custom properties, and inline tags. That means a TMX file is not only a bilingual sentence list. It is a reusable data package with identity and provenance.

Why a TMX import can create silent damage

A bad DOCX usually fails visibly. A bad TMX can import successfully and still cause damage later.

Examples include:

en-US content imported into a TM expected to use generic EN;
French-Canada targets mixed with French-France;
source and target language direction reversed;
old vendor memory outranking current client memory;
tags converted incorrectly;
duplicate units creating conflicting suggestions;
metadata stripped so reviewers cannot judge provenance.

The import button can succeed. The project can still become worse. That is why import validation matters.

TMX validation has three layers

Layer 1: structural

Can the file be parsed as valid TMX/XML?

Layer 2: mapping

Do the languages, locales, and metadata map correctly into the destination TM?

Layer 3: reuse behavior

After import, do the expected translations appear in search and pre-translation without unexpected alternatives or broken tags?

All three should pass.

Step 1: identify the TMX version

Many modern tools support TMX 1.4 and 1.4b. Do not assume every TMX-like file follows the same conventions.

Record:

TMX version;
producing CAT/TMS;
export date;
source memory name;
expected source locale;
expected target locales.

This information belongs in the import log.

Why the producing system matters

Different systems export different metadata. One system may preserve creation user, changed user, project field, and context path. Another may omit them. A destination TMS may rename fields during import.

That is normal if documented. The important question is:

What information survives, and what information disappears?

Step 2: preserve the original

Before normalizing language codes, deleting tags, editing XML, deduplicating, or converting encodings, save the original.

Use a clear name:

ClientAMasterTM2026-09-19_original.tmx

Then create:

ClientAMasterTM2026-09-19_validated-copy.tmx

A TMX repair should be reversible.

Step 3: inspect the header

The TMX header can carry information such as creation tool, creation-tool version, segmentation type, original format, admin language, and source language.

The source-language field is especially important. If the file’s source language is not the destination TM’s source language, stop and investigate.

Source language is not just a label

Suppose a TM expects English → German. The TMX header suggests German as source. The file may still contain both languages, but source-target direction affects search, pre-translation, penalty, and editing assumptions.

Do not import and “see what happens” in production. Use a sandbox.

Step 4: inventory every language code

Do not inspect only the header. Count every language code used in tuv elements.

You may find:

en;
en-US;
en-GB;
de;
de-DE;
fr-FR;
fr-CA.

The file may be multilingual even if the exporter’s UI described it as bilingual.

Create a language inventory.

Language code	TUV count	Expected?
en-US	42,180	yes
de-DE	42,110	yes
en	70	investigate
fr-FR	12	wrong file?

Twelve unexpected French entries can contaminate German TM search. They deserve investigation.

Step 5: decide strict locale matching

The underlying decision is simple: should a generic language code be treated as equivalent to a specific regional locale?

Should en be treated as equivalent to en-US? Should pt-BR be allowed into pt-PT? Should fr-FR be allowed into fr-CA?

There is no universal answer.

When strict locale matching is valuable

Use strict matching when regional distinctions matter strongly:

legal language;
medical terminology;
product names;
spelling;
units;
date conventions;
regulated text.

It prevents a “close enough” language code from silently entering the wrong resource.

When looser mapping can be acceptable

A general internal memory may intentionally accept en and en-US as the same source variety. Or a legacy memory may use generic codes because the old system did not preserve locales.

If you relax matching, document the decision, inspect samples, and consider adding a TM penalty or lower priority. Loose mapping should be deliberate.

Worked example 1: English locale mismatch

Destination TM:

en-US → de-DE.

Incoming TMX:

en → de-DE.

Possible choices:

Strict

Reject or skip generic EN.

Mapped

Treat en as en-US.

The right choice depends on the memory. If the source is product documentation written consistently in US English, mapping may be safe. If source comes from mixed British and American content, the generic code hides a real distinction.

Worked example 2: French regional target

Destination:

en-US → fr-CA.

Incoming:

en-US → fr-FR.

A translator may understand both. The product may not accept both. Differences can include terminology, institutional language, legal references, and UI convention.

Do not merge regional target locales merely because readers can understand them.

Step 6: check source-target inversion

One of the most damaging import mistakes is reversed direction.

Expected:

English source, German target.

But the TMX is effectively German → English.

Symptoms after import include source searches returning nothing, German appearing in the source column, or pre-translation suggestions looking reversed.

Test before production. Search a known English sentence. Confirm it appears as source and the German variant appears as target.

Bidirectional TMs require explicit policy

Some systems can leverage a TM in both directions. That can be useful. It can also hide source-direction confusion.

If bidirectional lookup is enabled, still record the canonical direction. A resource should have a clear intended role.

Step 7: inspect translation-unit counts

Before import, count:

tu units;
language variants;
empty segments;
units with more than two languages.

After import, compare processed units, stored units, duplicates removed, and variants per language.

Deduplication can make stored counts lower than incoming counts. That can be healthy. The important question is whether the difference is explainable.

Deduplication can be healthy

Incoming TMX:

100,000 translation units.

Destination stores:

82,000.

Possible reason:

18,000 duplicates collapsed.

That may be fine. But if the destination stores only 12,000, something is wrong. Possibilities include wrong language mapping, invalid structure, import filtering, excessive deduplication, or empty targets.

Counts are diagnostic.

Step 8: inspect duplicates before import

A TMX can contain the same source with the same target, several stylistic variants, contradictory targets, or valid regional variants. These cases are different.

Same source + same target

Probably harmless duplicate.

Same source + stylistic variants

Potential review noise.

Same source + contradictory meaning

High risk.

Same source + different locale

May be legitimate.

Do not deduplicate blindly before understanding why the variants exist.

Step 9: inspect target multiplicity

One source unit can have multiple target-language variants. That may be intended. A multilingual TMX can carry German, French, Japanese, and other targets under the same source unit.

If you are importing into a bilingual TM, the destination may import only the target languages configured in that TM. Know the behavior. Do not assume every target variant will survive.

Step 10: inspect inline markup

TMX segments can contain inline markup. Examples include paired tags, placeholders, and formatting markers.

A destination system may preserve them, normalize them, or remove them if an import option says “remove tags.” Tag behavior affects reuse.

“Remove tags” can help and hurt

Removing tags can reduce tag noise from legacy systems. It can also destroy useful structural information.

Consider:

Source:

Click <b>Save</b>.

A TM with tags can preserve emphasis. A tag-stripped TM stores:

Click Save.

Depending on the project, that may be acceptable or may reduce exact matching. Test rather than assuming.

Step 11: inspect proprietary inline tags

Some TMX exporters encode tags in tool-specific ways. A receiving tool may not understand them.

Symptoms include:

raw tags visible in matches;
strange {1} markers;
broken formatting;
lower match percentages.

Use a sample import. Do not clean thousands of tags manually without first understanding the exporter.

Step 12: inspect Unicode and encoding

TMX files are XML and commonly UTF-8. Check the encoding declaration and inspect accented characters, non-Latin scripts, combining marks, and replacement characters.

A file can parse and still contain corrupted text from an earlier export.

Look for:

�;
mojibake;
doubled escapes;
lost diacritics;
suspicious question marks.

Encoding damage should be repaired before import, not after the corrupt segments become reusable history.

Step 13: inspect source and target empties

A translation unit may contain source with empty target, target with empty source, or whitespace-only content.

Decide whether such units should enter the TM. Usually a translation memory should not store meaningless empty pairs.

Filter or quarantine them.

Step 14: inspect same-as-source pairs

Some same-as-source units are legitimate:

brand;
code;
product name;
standard;
URL.

Others are untranslated contamination.

Sample them. If 20% of a foreign-language TM consists of identical full sentences, the memory may contain copied source. Do not import blindly.

Step 15: inspect language contamination

Search target variants for words or scripts from the wrong language.

Examples:

German TM contains French sentences, English untranslated paragraphs, or Italian fragments.

This can happen after vendor merges, wrong-locale exports, or manual spreadsheet conversions.

Target-language and script checks can help before import.

Step 16: inspect metadata fields

TMX may carry properties such as:

client;
project;
subject or domain;
creator;
creation date;
changer;
change date.

These fields can support TM penalties, filtering, and provenance.

If the destination strips them, the TM may become less trustworthy because old and new content look identical to the retrieval engine.

Know which fields survive.

Step 17: decide what metadata is authoritative

A field saying:

client=Acme

does not prove the translation belongs to Acme. Legacy migrations can contain stale labels.

Use metadata as evidence, not absolute truth.

When metadata is weak, lower trust rather than inventing confidence.

Step 18: inspect creation and change dates

Very old segments may use obsolete product names, old grammar conventions, superseded legal terms, or retired style rules.

Dates can support a trust policy.

Example:

reviewed after 2024 → normal priority;
before 2018 → lower priority or penalty.

Do not delete old units solely because they are old. Use age together with domain knowledge.

Step 19: inspect creator fields cautiously

Creator IDs can be useful for provenance. But user IDs may not map into the destination system. Unmatched usernames may import as empty or generic values.

Do not build a critical trust policy around fields that disappear during migration.

Step 20: inspect context metadata

TMX can carry context information. Different exporters encode it differently.

Some context can only be approximated after migration. This matters for:

101% matches;
previous/next context;
file paths;
UI keys.

If context cannot be preserved, imported units may still be useful as 100% or fuzzy matches, but confidence should reflect the loss.

Step 21: inspect segmentation history

A TMX can carry units created under a different segmentation profile.

Example old TM:

See Fig.

4 for details.

Current project:

See Fig. 4 for details.

The TM is not necessarily wrong. The historical segmentation differs.

This can reduce leverage. Alignment or cleanup may help, but do not mechanically merge every fragment without understanding context.

Step 22: inspect source normalization

Legacy TMs can contain source variants differing only by whitespace, punctuation, Unicode normalization, or tag representation.

Deduplication may treat them separately.

A cleanup pass can normalize selected properties, but do not normalize meaning-bearing distinctions.

For example, changing hyphens, minus signs, decimal punctuation, or code case can change technical meaning.

Step 23: import into a sandbox TM

Create a non-production memory.

Import the TMX.

Record:

processed units;
stored units;
warnings;
language variants;
skipped rows;
import duration.

Do not attach it to a live project yet.

Step 24: run known-sentence searches

Choose 20 source examples from the TMX:

short;
long;
tagged;
number-heavy;
regional term;
old term.

Search the sandbox.

Verify the correct target, metadata, tags, and match score.

This is functional validation.

Step 25: test pre-translation behavior

Attach the sandbox TM to a small sample project.

Run analysis or pre-translation.

Check:

exact matches;
fuzzy matches;
wrong-language suggestions;
stale terms;
tags;
context behavior.

A TM that looks clean in a list can behave badly in real retrieval.

Step 26: compare against the existing production TM

If the TMX will be merged into an existing memory, search overlapping sources.

Possible outcomes:

new TM agrees;
new TM conflicts;
new TM has newer preferred term;
new TM has older style.

Do not merge conflict blindly. Choose precedence.

Step 27: use a temporary lower priority

When trust is uncertain, attach the imported TM read-only, give it lower priority or a penalty, and let linguists inspect results.

After confidence grows, promote.

You do not have to make a new TM authoritative on day one.

Step 28: decide import destination

Possible destinations include:

Working TM

Good for pilot or uncertain imports.

Client TM

Good when provenance is strong.

Master TM

Only when quality and ownership are trusted.

Do not import an unknown vendor dump straight into the master resource.

Step 29: record the import log

A useful log might say:

File: VendorA_2026Q3.tmx Version: TMX 1.4b Languages: en-US → de-DE Incoming TUs: 84,210 Stored: 78,922 Strict locale: yes Tags: preserved Sandbox sample: 50/50 correct mapping Issues: 43 wrong-language targets removed Destination: working TM

This makes future troubleshooting possible.

Step 30: quarantine suspicious subsets

If 95% of the TMX is trustworthy and 5% is questionable, do not necessarily reject everything.

Split:

trusted;
quarantine.

Possible quarantine dimensions:

one locale;
one old project;
one vendor;
one date range;
one domain.

Then audit separately.

Step 31: inspect multi-domain TMX files

A vendor export may contain legal, marketing, technical, and support content.

Mixing them into one high-priority TM can reduce match relevance.

Use metadata to split by domain if practical. Or import into a lower-priority general TM.

Step 32: test glossary-critical terms

Pick 20 approved terms.

Search TM targets.

If the TM repeatedly uses forbidden legacy terminology, decide whether to clean before import, apply a penalty, quarantine, or reject.

Terminology drift is one of the most common forms of historical TM debt.

Step 33: test number integrity

Sample units containing dates, percentages, measurements, prices, and version numbers.

Legacy TM errors can be fluent and numerically wrong. A memory is reusable history. It is not guaranteed truth.

Number verification is especially important when the TM will feed automated pre-translation.

Step 34: test short ambiguous strings

Search:

Open
Close
Save
Current
Charge
Home

If the TM contains many targets without context metadata, these may produce dangerous exact matches.

A lower priority, context requirement, or dedicated UI TM can reduce risk.

Step 35: test same-source multiple-target behavior

A TM may store:

Source:

Save

Targets:

If the destination surfaces all three without useful context, translators face decision noise.

Clean or enrich metadata.

A translation memory should reduce decisions, not multiply them.

Step 36: distinguish duplicates from variants

Suppose the TMX contains the same source and two target strings that differ only in punctuation.

Possible explanations:

legitimate UI versus prose convention;
historical style change;
accidental variation;
different product context.

Do not call both “duplicates” merely because the source matches.

A duplicate is a data relationship. A variant is a linguistic relationship. You need both views.

Step 37: test domain fit

A perfect translation in the wrong domain can still be a bad match.

Source:

port

Target in logistics TM: harbor-related term.

Current software project: network port.

The language pair is correct. The TMX can be structurally perfect. Domain mismatch still creates bad reuse.

Import destination and priority should reflect domain fit.

Step 38: test product-version fit

A TMX from Product 4 may contain obsolete names that Product 7 no longer uses.

Check:

product names;
menu labels;
legal names;
feature terminology.

If the memory is still useful, preserve it with:

lower priority;
version field;
term penalties.

Do not erase history merely because the product evolved.

Step 39: inspect approval provenance

Was the TMX built from:

translator-confirmed segments;
reviewer-approved segments;
MT output;
bilingual imports;
unknown sources?

This matters.

Two TMX files with identical structure can deserve very different trust.

Ask the sender for provenance when possible.

Step 40: do not infer “human” from fluent language

Modern MT and LLM output can be extremely fluent.

A TMX that reads naturally may still contain unreviewed machine output.

Use:

metadata;
project records;
provider documentation;
sample LQA.

Fluency is not provenance.

Step 41: create a sampling plan by risk

Do not sample 100 random sentences and assume the TM is safe.

Include:

safety content;
legal content;
product terminology;
numbers;
short UI strings;
long technical sentences;
old segments;
newest segments.

A risk-stratified sample reveals more than pure randomness when the goal is operational reuse.

Step 42: calculate a wrong-language rate

For a sample of 1,000 target variants, count how many are clearly in the wrong language.

Example:

1,000 sampled;
7 wrong-language.

That is 0.7%.

Is 0.7% acceptable?

For a master TM feeding automatic confirmation, probably not.

For a low-priority research TM, maybe manageable.

The acceptable rate depends on authority.

Step 43: calculate a terminology violation rate

Sample units containing known controlled terms.

Count:

approved;
outdated;
forbidden;
ambiguous.

If 30% of product terms are stale, the TM may need cleanup before high-priority use.

Step 44: compare edit burden

Pilot translators can use the sandbox TM for a small job.

Track:

how often matches are accepted;
how often they need edits;
how often they mislead.

A TM with many high matches but heavy correction can be less useful than a smaller precise TM.

Import value should be measured by work saved, not units stored.

Step 45: decide whether to split the TMX

One large TMX may be easier to move.

Several smaller TMs may be better operationally.

Possible split dimensions:

client;
product;
domain;
year;
approval state;
locale.

Split only when it improves retrieval or governance.

Too many tiny TMs create management overhead.

Step 46: map metadata into the destination schema

Source TMX property:

x-client=Acme

Destination field:

Client

Source:

x-domain=Legal

Destination:

Domain

If field names differ, define a mapping.

Do not let important provenance disappear merely because one system used a different property name.

Step 47: document lost metadata

Some fields cannot be preserved.

Write it down.

Example:

previous/next context lost;
creator mapped to blank;
custom project path not supported.

Then set TM priority accordingly.

A known limitation is manageable.

An unknown limitation creates false confidence.

Step 48: test inline tag normalization across tools

A source system may use one tag representation.

The destination may normalize it.

A normalized tag is not necessarily a defect.

The real test is:

can the match be inserted cleanly?
can the target export?
does formatting survive?

Evaluate function, not XML appearance alone.

Step 49: use import warnings as data

Do not dismiss a warning merely because 99% of the file imported.

Warnings can reveal:

invalid unit;
unsupported locale;
malformed tag;
empty segment.

Count them.

If there are five warnings in 100,000 units, inspect all five.

If there are 20,000, stop and investigate the producer.

Step 50: feed exporter defects upstream

If every TMX from Vendor A contains malformed tag IDs, do not build a permanent cleanup ritual.

Tell Vendor A.

If the source TMS exports generic language codes that damage locale mapping, change the export configuration if possible.

Validation should eliminate recurring defects at source.

A trust ladder for imported TMX data

Level 1: quarantine

Unknown provenance. Search manually only.

Level 2: low-priority read-only

Useful historical content, but requires judgment.

Level 3: working TM

Trusted enough for normal translator reuse.

Level 4: client-authoritative

Reviewed, domain-correct, current.

Level 5: master promotion

Governed and suitable for future high-confidence reuse.

A TMX import does not have to jump from zero to Level 5.

Failure mode 1: import directly into master TM

Result: bad entries become authoritative immediately.

Repair: sandbox first.

Failure mode 2: trust the header only

Result: wrong locale variants remain hidden inside TUVs.

Repair: language inventory.

Failure mode 3: generic EN mapped to every English locale

Result: regional contamination.

Repair: strict locale policy.

Failure mode 4: remove tags blindly

Result: useful structure lost.

Repair: sample tag behavior.

Failure mode 5: deduplicate by source only

Result: legitimate target variants erased.

Repair: context-aware deduplication.

Failure mode 6: ignore metadata loss

Result: old and low-trust entries look equal to current approved entries.

Repair: preserve or compensate with priority.

Failure mode 7: count import success as quality proof

Result: linguistic contamination survives.

Repair: functional search sample.

Failure mode 8: source-target direction reversed

Result: search and pretranslation fail.

Repair: known-sentence test.

Failure mode 9: wrong-language target contamination

Result: future matches inject another language.

Repair: