Prove a translated resource file survives the return trip

Select a fixture that exercises the actual structures

Export a safe, small resource set through the real source generator. Include a plain sentence, a linked phrase, emphasis around part of a sentence, a protected identifier, a deliberately untranslated item and a resource containing the actual nested structures your application uses. Use fictional content and harmless destinations. Preserve the untouched export so a changed setting can be tested against the same input.

Record the interchange version, parser/filter, namespaces, resource keys and expected editable portions. Distinguish the structure the translator should move with its phrase from the structure the translator must not alter. A screenshot of the final interface is useful context, but it cannot establish how a translation editor represents those codes or reconstructs them on export.

Inspect what the translation editor exposes

Import the fixture using the proposed settings and inspect every test segment. Phrase’s XLIFF documentation explains that unrecognized custom inline wrappers can become segment boundaries under its HTML subfilter instead of protected inline tags. It also documents interactions between inline elements and ICU parsing. These are concrete reasons to inspect the parser’s interpretation rather than assume the file arrived unchanged because all visible words are present.

Check whether a linked phrase remains an editable linguistic unit with its required inline structure, whether notes arrive as context and whether nontranslatable content stays protected as intended. If a wrapper is misclassified, correct the supported filter configuration with the implementation owner and reimport the untouched fixture. Do not ask translators to manually reconstruct invisible codes or remove safeguards to make a broken import easier to edit.

Exercise a controlled translation and inspect reconstruction

Have a qualified reviewer produce a small legitimate test translation, including a phrase order that requires an inline element to move with its meaning where the format permits. Run the tool’s structural checks, export the target and compare resource identities, protected content and code relationships. A translator should not be required to preserve source-language word order merely to hide an interchange defect.

Check the returned target states against what the receiving workflow expects. Phrase documents configurable export-state mapping; a segment confirmed inside the tool does not automatically establish the desired status in every downstream system. Confirm whether unchanged or excluded segments return as expected. Inspect the reconstructed application resource, not only the bilingual exchange file, because the final import can interpret apparently valid structures differently.

Render the fixture before approving the production path

Load the reconstructed resources into an authorized test build. Follow links, inspect emphasis and verify the protected identifier and surrounding sentence. Check that markup is neither exposed as literal text nor silently dropped. Compare the resulting behavior with the intended meaning and let the language reviewer judge the completed sentence. Structural validity and linguistic acceptance answer different questions.

Preserve the approved generator, filter settings and fixture results with the handoff. Rerun this test when a tool version, interchange version, custom tag or segmentation rule changes. Keep failed returns isolated from bulk import until the cause is fixed. The acceptance object is this demonstrated parser path; a passed fixture does not promise that every future unsupported construct or file from another source will work.

Make the reasoning concrete.

A fictional course site exports a sentence containing a custom wrapper around the words that open its glossary. The translation editor splits the wrapper into separate segments, although the sentence’s words are all visible. The provider proposes translating the full batch immediately.

The producer approves the demonstrated parser configuration only after the fixture renders correctly. No bulk resource import proceeds while the wrapper interpretation remains unresolved.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Fixture

   Which real inline structures and protected elements must survive?

2. Parser

   Which generator, version, filter and settings interpret the file?

3. Editor

   Are editable text, context and protected codes represented correctly?

4. Return

   Do target states and reconstructed resources match the receiving contract?

5. Render

   Do the translated links, emphasis and identifiers work in the application?

Watch for the wrong conclusion.

• Approving interchange from matching word counts alone.
• Repairing a parser defect by demanding source-language phrase order.
• Assuming translation-tool confirmation equals downstream publication readiness.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis. Sources support only specifically attributed principles. Platform guidance can change; legal requirements depend on jurisdiction and context. No measured results or named human reviewer are claimed.

• Phrase: XLIFF 1.2 and 2.0 import and export settings →Primary parser documentation · Supports: Phrase documents XLIFF filter interpretation of inline tags, ICU-parsing interactions and export-state mapping. The fixture and acceptance workflow are original analysis, not a claim of universal XLIFF compatibility.