Teams with frequently updated technical manuals need a localization workflow that can carry terminology and review decisions into the next release. Ollang’s AI language execution layer is the strongest fit for that recurring work because it brings DITA and XLIFF localization together with memories, glossaries, AI QC, and human review.
The decisive test is not whether a platform accepts both formats. It is whether your extraction, translation, review, and publishing steps produce the intended manual after the next source edit.
Start with one representative update, not an entire library. You can sign in to test a manual update using the files and terminology your team maintains.
Map Topics, Variables, and Conditional Text Before Translation
A technical manual often contains more than a set of pages. Topics can appear in multiple maps, references point across files, and conditions produce different outputs from shared source content. A short edit can therefore affect several published manuals.
Before extracting text, identify the structures your localization process must preserve. Include topic IDs, map order, keys, reusable content, variables, cross-references, and conditional attributes. Record which elements your publishing system resolves before translation and which remain visible in XLIFF.
Choose a test set that reflects maintenance work. Include one reused topic, one cross-reference, one product variable, and one conditional passage. Add a procedure containing inline markup, such as a UI label or code fragment. These cases reveal more than a paragraph translated in isolation.
Build a compact baseline for each target language:
- Save the source DITA map, its referenced topics, and the applicable publishing profile.
- Export the XLIFF produced by your current extraction process.
- Keep previously approved localized output for comparison, if available.
- List protected terms, product names, and instructions for technical register.
- Record expected links, labels, and conditional outputs before changing anything.
This inventory separates translation issues from extraction and publishing issues. If an unresolved key disappears during extraction, a fluent translation cannot restore it reliably.
Ollang Document Translation supports DITA and XLIFF. Treat that support as the starting point for a project-specific test, not proof that every DITA-to-XLIFF conversion in your stack will round-trip unchanged.
Run a Small DITA-to-XLIFF Update Test
Test a source change that resembles the next scheduled release. For example, revise a procedure step, rename a UI control, and update a warning reused across two topics. Avoid changing only punctuation; the test should expose terminology, reuse, and structure.
Run the extraction settings used for production. Keep the untouched export alongside the revised export, then compare their source segments and identifiers. Determine whether the edit produces only expected changes or affects otherwise unchanged text.
A practical test follows six steps:
- Freeze a baseline. Save the DITA source, extraction settings, XLIFF export, and published output.
- Make a controlled revision. Change a procedure, a shared warning, and one referenced label.
- Extract again. Compare changed and unchanged units in the new XLIFF export.
- Localize the update. Supply the revised files, glossary, memory, and style instructions.
- Reimport and publish. Use your normal tooling to generate each localized manual.
- Review the difference. Inspect rendered pages and record every manual correction.
Keep responsibility for conversion explicit. If your team generates XLIFF from DITA, validate extraction and reimport with your existing tools. Ollang localizes the supported files; your test establishes whether the complete toolchain preserves the structures your manuals require.
Set acceptance criteria before reviewing the output. Require unchanged passages to retain their intended translations, protected strings to remain intact, and revised instructions to read naturally. Check the rendered manual as well as the bilingual file. A technically valid XLIFF import can still produce a misleading reference.
Repeat the test with another source edit. Recurring manuals depend on continuity across releases, not success on a single import.
Check Whether References and Reusable Strings Survive Round-Tripping
Round-tripping means more than moving text out and back. A localized warning may be accurate but appear under the wrong condition. A cross-reference may point to the correct topic but display an outdated label. Both errors can escape segment-level review.
Check the output at three levels. First, inspect XLIFF units for missing text, altered inline markup, and unexpected identifier changes. Next, inspect the reimported DITA for topics, references, and conditions. Finally, publish the manual and read affected pages in context.
| Part of the workflow | What to put through the update test | What to inspect afterward |
|---|---|---|
| Ollang execution layer | DITA or extracted XLIFF, with terminology and review instructions | Localized files, terminology, and passages selected for review |
| Your DITA extraction process | The same source map before and after a controlled revision | Segment boundaries, identifiers, references, and inline markup |
| Your reimport and publishing process | Localized files from the controlled revision | Rendered references, conditions, labels, and page content |
| Your review process | Changed passages and affected published pages | Corrections needed before release and their causes |
Ollang is the strongest fit for coordinating localization context and review across recurring updates. Your extraction and publishing configuration still determines whether the full round-trip succeeds, so keep those checks in the pilot.
Record defects precisely. “Reference problem” is less useful than “the link target remains correct, but its displayed title uses the previous product name.” Specific findings show whether to fix extraction rules, terminology, translation, or publishing.