The translation is correct. The file will not import. Fix the CAT-to-LQA handoff.
Readable source and target text do not prove a safe file round trip. Test tags, locked segments, source updates and reimport before another delivery becomes a manual repair job.
On this page
- Correct words can still arrive in an unusable file
- Decide what belongs in review before importing it
- Preserve identity, context and the original file
- Test an unchanged round trip before editing a word
- Build a small fixture that exposes the expensive failures
- Automate one proven format before widening support
- Questions we hear
The short version
- Successful parsing proves that a file can be read, not that it can return safely to its originating tool.
- Agree eligible segments and word counts before assigning review. Lock and approval metadata need explicit handling.
- Preserve stable segment identity and file version so decisions survive sorting without following an obsolete source.
- Test an unchanged round trip and failure cases before automating the most expensive handoff.
Correct words can still arrive in an unusable file
The linguist completes the review. The corrected export opens in your tool, but the client's CAT environment rejects it. Or it imports successfully while locks, inline codes or segment associations have changed. The PM now has to distinguish a linguistic delivery from a file-engineering failure.
Those problems are easy to miss when an integration test checks only whether source and target text appear. The workflow also carries identity, scope and structure. Losing any of them can create review work or damage a delivery that looked finished.
A discussion of localization process failures includes practitioner reports of duplicated QA handling and locked-segment scope problems. A separate CAT interoperability discussion raises differences among XLIFF variants. These discussions identify areas to test; they do not establish a defect in every product or configuration.
Give the handoff its own acceptance criteria. The correct outcome is a reviewable import and a usable return file, with the agreed content and decisions preserved.
Decide what belongs in review before importing it
Record the format, declared version, originating application, source and target languages, and source revision. For spreadsheets, specify the worksheet and the source, target and ID columns. Define how hidden rows, blank cells and merged cells affect the scope.
For bilingual files, agree how approved or locked segments, repetitions and translation-memory matches should behave. Their presence is metadata, not a complete commercial or linguistic policy. A client can explicitly require review of otherwise locked material; the workflow needs to support the agreed rule.
- Inspect the package
Identify format, version, languages, originating tool and required return path.
- Apply the scope policy
Classify eligible content, locked context, repetitions and excluded units.
- Reconcile the totals
Compare segment IDs and word counts with the approved analysis.
- Approve the import
Assign work only after the owner resolves unexplained differences.
Keep excluded material available as context when permitted and useful, while preventing unintended edits. If two tools calculate different word counts, document the counting basis. Do not quietly change the billed or evaluated scope to match whichever count the importer produces.
Preserve identity, context and the original file
A row number is a display position. It changes when someone sorts a sheet or filters the view. Store the originating document and file identity, enclosing unit ID, segment ID where present, language and revision separately from display order. In XLIFF 2.1, the same local segment ID can occur in different units. Preserve the complete identity path so those segments cannot collide.
Repeated sentences can have different contexts. Preserve every occurrence even if the interface groups similar findings. A correction suitable for a button may be wrong in a longer instruction that contains the same words.
Keep the original input and a record of permitted transformations. Do not rebuild a bilingual package from only the displayed source and target strings when the format carries additional structure required downstream.
When the source changes, compare identity and content before carrying decisions forward. If the mapping is uncertain, request a fresh review or explicit reconciliation. A retained segment ID does not guarantee that its meaning remained unchanged.
Test an unchanged round trip before editing a word
- Export a fixture
Create a small synthetic package in the actual originating tool.
- Import without edits
Read it under the intended scope rules and preserve required metadata.
- Export and reimport
Return the unchanged package to the original test environment.
- Compare and inspect
Check structure, identities, inline codes, locks and the tool's visible result.
Use a semantic comparison rather than demanding byte-identical XML. Serializers can change whitespace or attribute order without changing the document. Conversely, well-formed XML can still violate the application-specific expectations of the tool receiving it.
The OASIS XLIFF 2.1 specification describes a vocabulary for carrying localizable data among tools. Apply the specification matching the input version. Test vendor-specific extensions separately wherever the return workflow depends on them.
Then permit one targeted edit and verify that it reaches the intended segment while unrelated content and structure remain intact. Repeat with an edit next to an inline tag and a placeholder. Successful reimport should include a human inspection of the resulting asset, not only an exit code.
Build a small fixture that exposes the expensive failures
- An editable segment and a locked segment under the agreed policy.
- Repeated wording with different context, plus identical local segment IDs in different units.
- Paired inline codes, placeholders, entities and non-Latin text.
- An empty target, a missing identifier and an unsupported format.
- A corrupt package and a failure partway through export.
- A source revision with changed text, reordered units and altered IDs.
Write expected behavior for every fixture. Unsupported or corrupt input should produce a clear error before operational review work starts. A failed export should preserve the original and recoverable decisions. A source revision should not silently inherit obsolete approval.
Classify failures by scope, identity, structure or destination behavior. This prevents a tag issue from being reported as translator underperformance and prevents an import failure from becoming an unexplained job-status problem.
For the review itself, retain original findings, human decisions, rationale and final target separately. Use one definition of actionable work for the progress count, review queue and export. A completed-looking job with unresolved findings is not an acceptable handoff.
Automate one proven format before widening support
- Record actual format, version and originating environment.
- Agree eligible content, locks and repetition policy.
- Preserve the complete file/unit/segment identity, source revision and context.
- Reconcile review scope and counting basis.
- Pass an unchanged round trip in the original tool.
- Verify one targeted edit and protected inline structure.
- Exercise corrupt input, partial export and source changes.
- Retain original input and recoverable decisions.
- Rerun fixtures after either connected tool changes.
Start with the format and client workflow causing the most measured preparation or repair time. Keep the fixture and expected results with the adapter. Broaden support when another format has a clear requirement and its own acceptance evidence.
If a handoff repeatedly needs manual repair, bring the file specification and a synthetic reproduction to a discovery call. A focused assessment can establish whether configuration, a format-specific adapter or a workflow change is the smallest useful fix. Client files are not needed to start that conversation.
Questions we hear
Why does a valid XLIFF file fail to import into another tool?
Well-formed XML and general format support do not establish application compatibility. Versions, extensions, inline structure and required metadata can differ. Reproduce the failure in the actual originating and receiving environments, then define a round-trip fixture for the specific workflow.
Should locked segments always be excluded from LQA?
Follow the agreed review policy. A lock may describe editing status rather than the complete quality or commercial scope. Preserve the metadata, make eligible content explicit and reconcile totals before assignment. Do not infer a universal rule from one application's lock field.
Can we convert every bilingual file into a simple spreadsheet?
A spreadsheet may be useful as a review interface, but flattening can lose inline structure, context or identity. If the return format needs that information, preserve it separately and test reconstruction and reimport. The visible source and target columns are not the entire file contract.