How do you translate DITA XML technical documentation without breaking topic maps, conrefs, keyrefs, procedures or links? DITA 1.3 localization is not ordinary document translation: source topics are reusable components, and a small alteration to an identifier can create failures in several published manuals at once. A successful multilingual DITA workflow preserves the document system while giving readers instructions that sound native, precise and usable.
People searching for DITA 1.3 translation, DITA topic localization, keyref and conref translation, or multilingual DITA Open Toolkit publishing usually have a practical problem: they must translate text while maintaining the assembly logic that builds a product guide. Some content is visible, some is conditionally included, and some appears only after keys resolve. Editing everything that looks like English is therefore an unsafe method.
This guide explains how to localize DITA maps, concepts, tasks, reference topics, reused content, filtering, terminology, cross-references, warnings, examples and accessible output. It separates authored prose from machine-controlled structure, shows where translation decisions become engineering decisions, and gives a verification plan that applies across software, devices, equipment, training materials and global product documentation.
The real problem: fluent translation must preserve the working document
DITA makes technical information modular. An author can write a task once, link it from several maps and publish it in different guides. That modularity improves maintenance, but changes the unit of translation. A sentence can be grammatically correct yet appear in the wrong context when its topic is reused for a second product or a different audience.
The first professional decision is to identify the authoritative source, target locale, DITA version, selected map, profiling values, transformation pipeline and release date. A translated PDF is not sufficient evidence if the source files no longer validate, the navigation fails or the browser output changes product-specific warnings.
The strongest workflow treats an ID, path, key, reference target, condition, code token and version value as a controlled interface. Human-facing wording can change. The interface survives unchanged unless a designated authoring owner approves a deliberate structural revision. This principle keeps localization separate from maintenance engineering.
This is a practical guide to DITA 1.3 XML localization for technical writers, translators, product documentation owners, software teams and multilingual publishing specialists. The document may be used to make decisions, complete work or communicate policy. A reader must not be forced to guess which labels are explanatory and which values have contractual or technical meaning. Good editing makes the distinction visible without burying the reader in specialist jargon.
The baseline matters: DITA 1.3 remains the approved OASIS Standard as of October 2026; the committee’s DITA 2.0 Beta 03 is a prerelease rather than a published OASIS Standard. The goal is not to chase every newly published standard regardless of a customer’s actual environment. It is to deliver an accurate target-language resource against the version and system that the user will actually encounter.
Start with a source-of-truth checklist
1. Establish ownership
Identify the authoritative source and record its owner, version, status and intended audience. If two files disagree, stop and resolve which one controls the release before creating parallel target-language versions.
2. Freeze protected values
List the structural elements and values that must survive unchanged: references, identifiers, link targets, configuration codes, technical numbers and any defined machine-readable tokens. Keep these apart from sentences meant for human readers.
3. Specify the language
Record the precise target locale, including writing direction where relevant, and check the terminology that the local audience already recognizes. A locale is more specific than ‘translate this to another language’.
4. Map the experience
Map the reader’s journey. Identify how people find a topic, navigate to a detail, interpret a table, act on a warning and return to the surrounding publication. This exposes failures a sentence-only review misses.
5. Choose test cases
Create a representative test corpus before full translation. Include a simple page, a complex page, a reused element, a cross-reference, an exception and one unusually long target-language passage.
6. Divide review responsibility
Separate linguistic approval from structural and technical approval. The reader-facing voice belongs to competent language reviewers; technical facts and controlled values need authority from their subject owners.
7. Test the deliverable
Rebuild the actual deliverable, not a simplified preview. Inspect the file and its rendered presentation using the software, version, language configuration and output channel that the audience will receive.
8. Document decisions
Record open ambiguities and their resolutions. When the source itself is unclear, raise an editorial correction instead of silently inventing a target-language interpretation.
Eighteen practical situations that expose translation failures
1. Understand the map before translating its topics
Consider this working situation. A support team receives forty XML topic files and a single map that assembles only fourteen of them for a starter guide. Several other topics belong to an administrator edition. The temptation is to treat the work as a sequence of strings to replace. That approach misses the relationship between the text, the surrounding system and the decisions a reader must make. The first question is what the original material is actually promising to the person who encounters it. A translator who understands that promise can choose a natural sentence without damaging the work it must perform.
The nonnegotiable boundary is specific: Keep the map’s topicref destinations, hierarchy, key definitions and resource-only relationships aligned with the intended publication. Within that boundary, the appropriate linguistic work is equally concrete: Translate reader-visible titles and navigation wording in context, including cases in which the map supplies a title different from the topic’s own title. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: A translator assumes the file list equals the publication and spends time translating unused topics while omitting a map-only navigation label. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Build the exact publication map for the target locale, compare the navigation tree and verify that every visible topic opens. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: An accurate translation inventory comes from assembled output, not only folder contents. A localization manager and information architect should jointly sign off the map inventory. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
2. Translate concept topics without losing definitions
Here is a useful example. A device manual describes the difference between standby mode and an electrical isolation state; its concept topic is reused beside several maintenance tasks. The visible sentences are only one layer of the object being translated. Some of its information exists to guide people, while other information controls assembly, traceability or downstream action. Those categories must be separated before anyone edits the file. The purpose of the translation is to let a target-language reader reach the same responsible decision as a source-language reader under equivalent conditions.
The nonnegotiable boundary is specific: Preserve the conceptual distinction, product state names, IDs and links to the associated task topics. Within that boundary, the appropriate linguistic work is equally concrete: Explain the difference in natural target-language prose, using one approved term for each state and a definition users can recall. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: A superficially fluent translation renders both states as an everyday word meaning ‘off’, hiding an important safety distinction. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Ask a reviewer to paraphrase the two states separately, then follow the linked procedures to see if the distinction survives. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: A concept topic must prepare the reader to make correct decisions later, not merely sound informative. A subject expert should approve the conceptual glossary before broad reuse. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
3. Keep task sequences executable
Imagine a normal production handoff. An installation task includes prerequisites, a numbered procedure and an expected result; readers use it beside hardware. Most errors at this point are not caused by a lack of dictionary knowledge. They arise because the translator is not shown which parts of the source are instructions, values, relationships or merely explanatory prose. That is why context and ownership matter: both help distinguish a change in expression from a change in operational meaning.
The nonnegotiable boundary is specific: Preserve step order, references, values, command literals, conditional warnings and the meaning of the final verification. Within that boundary, the appropriate linguistic work is equally concrete: Translate imperative verbs, articles, and spatial references so the sequence is immediately clear to a trained reader. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: A translator moves a verification phrase to the beginning for style, accidentally suggesting that a test happens before isolation. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Have a target-language technician execute the steps on a safe test system and record the observed state after each step. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: If a procedure reads well but cannot be performed in the stated order, it is not ready for release. Technical and language reviewers need a common record of procedural discrepancies. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
4. Treat reference topics as operational data
Consider this working situation. A table lists supported operating systems, supported product versions and exact configuration options. The temptation is to treat the work as a sequence of strings to replace. That approach misses the relationship between the text, the surrounding system and the decisions a reader must make. The first question is what the original material is actually promising to the person who encounters it. A translator who understands that promise can choose a natural sentence without damaging the work it must perform.
The nonnegotiable boundary is specific: Leave programmatic values, unit symbols, identifiers and version ranges unchanged unless an authorized source revision says otherwise. Within that boundary, the appropriate linguistic work is equally concrete: Translate column explanations, captions and notes that help users interpret what a value means. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Replacing a literal configuration value with a translated synonym makes the documented option impossible to enter. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Compare structured values with the source and a supported environment; verify that captions identify the right columns. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: Readable prose cannot compensate for a wrong reference value. Documentation and product engineering should review the data contract separately from style. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
5. Protect IDs, fragments and URIs
Here is a useful example. A paragraph links to a specific step in another topic through a topic ID and an element ID. The visible sentences are only one layer of the object being translated. Some of its information exists to guide people, while other information controls assembly, traceability or downstream action. Those categories must be separated before anyone edits the file. The purpose of the translation is to let a target-language reader reach the same responsible decision as a source-language reader under equivalent conditions.
The nonnegotiable boundary is specific: Maintain the identifier graph and legal URL syntax; translate link labels, not the machinery that resolves the link. Within that boundary, the appropriate linguistic work is equally concrete: Make surrounding links natural, particularly when a generic phrase such as ‘see here’ can become descriptive navigation. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Changing an ID to a localized phrase breaks incoming links even when the translated topic renders by itself. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Run a link and ID resolution test across all delivered maps, not just a single XML file. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: The acceptance criterion is that the reader reaches the correct target from every locale. A build engineer owns structural link failures; translators own link-label clarity. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
6. Understand conref reuse before editing wording
Imagine a normal production handoff. A warning appears through a content reference in six procedures, including two where the surrounding noun is plural. Most errors at this point are not caused by a lack of dictionary knowledge. They arise because the translator is not shown which parts of the source are instructions, values, relationships or merely explanatory prose. That is why context and ownership matter: both help distinguish a change in expression from a change in operational meaning.
The nonnegotiable boundary is specific: Keep the content reference and source element identity intact; assess the reused string in all of its destination contexts. Within that boundary, the appropriate linguistic work is equally concrete: Choose language that remains grammatically valid under multiple surrounding sentences, or flag a genuine need for separate approved variants. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Editing a conref reference as though it were locally authored duplicates an instruction and destroys the single-source maintenance advantage. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Render each dependent topic and read the warning in full context, including punctuation and grammatical agreement. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: When one target sentence cannot serve all contexts, raise a source-authoring request instead of secretly changing structural markup. The reviewer must see a reuse matrix, not only a bilingual sentence pair. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
7. Resolve keyrefs and keys in each map
Consider this working situation. The same product name is bound to a key and appears under different branding in regional editions. The temptation is to treat the work as a sequence of strings to replace. That approach misses the relationship between the text, the surrounding system and the decisions a reader must make. The first question is what the original material is actually promising to the person who encounters it. A translator who understands that promise can choose a natural sentence without damaging the work it must perform.
The nonnegotiable boundary is specific: Keep key names, keyref syntax and resolution scope stable; localize only the authorized visible key content. Within that boundary, the appropriate linguistic work is equally concrete: Translate surrounding grammar so the resolved term fits the sentence, including articles and inflection. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Blindly translating a key identifier leaves an unresolved placeholder or points a reference to the wrong map context. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Build each regional map and inspect resolved link text, product labels and destinations on actual pages. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: A key that resolves in the source-language build may still fail in a localized map. Owners of key maps and terminology must verify regional branding decisions. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
8. Handle key scopes and nested reuse
Here is a useful example. A shared troubleshooting topic is pulled into a technician map and a consumer map, each with its own scoped key definitions. The visible sentences are only one layer of the object being translated. Some of its information exists to guide people, while other information controls assembly, traceability or downstream action. Those categories must be separated before anyone edits the file. The purpose of the translation is to let a target-language reader reach the same responsible decision as a source-language reader under equivalent conditions.
The nonnegotiable boundary is specific: Preserve nested key scopes and document the contexts in which a key produces different visible wording. Within that boundary, the appropriate linguistic work is equally concrete: Adapt surrounding text for the intended audience without assuming one resolved phrase appears everywhere. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: A one-map preview gives false confidence when a second key scope changes the name of a component. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Test each supported map-and-locale combination and inspect the topic in both publication contexts. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: Translation memory should not force a shared segment when key scope creates different reader meaning. Publication owners should supply a matrix of audience, map, locale and key resolution. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
9. Apply conditional processing correctly
Imagine a normal production handoff. A product guide filters material by platform and audience. A platform-neutral sentence sits beside a warning shown only to installers. Most errors at this point are not caused by a lack of dictionary knowledge. They arise because the translator is not shown which parts of the source are instructions, values, relationships or merely explanatory prose. That is why context and ownership matter: both help distinguish a change in expression from a change in operational meaning.
The nonnegotiable boundary is specific: Preserve the conditional attribute values and the filtering configuration; they determine visibility rather than prose style. Within that boundary, the appropriate linguistic work is equally concrete: Translate each audience-specific passage only for the readers who will actually see it, keeping context around excluded passages in view. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: A translated attribute value no longer matches the publication’s filter and hides a critical instruction. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Produce representative outputs for each supported profiling configuration and compare included and excluded topics. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: An invisible warning is a localization failure even if the warning’s translated XML is flawless. Technical publications teams need to approve the configuration coverage and exclusions. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
10. Distinguish subject schemes from ordinary vocabulary
Consider this working situation. A controlled vocabulary assigns valid values to audience and platform attributes in DITA content. The temptation is to treat the work as a sequence of strings to replace. That approach misses the relationship between the text, the surrounding system and the decisions a reader must make. The first question is what the original material is actually promising to the person who encounters it. A translator who understands that promise can choose a natural sentence without damaging the work it must perform.
The nonnegotiable boundary is specific: Treat schema-bound attribute values and controlled classification tokens as data, not free text. Within that boundary, the appropriate linguistic work is equally concrete: Where labels are presented to people, use approved translations that map to the unchanged controlled value. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Replacing a classification token with a target-language word can invalidate filtering without generating a visible grammar error. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Check the allowed values and map every localized label to one canonical classification value. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: Controlled values provide predictable automation; localized labels provide reader access. Both are required. The taxonomy owner should review any term that seems ambiguous across countries. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
11. Keep executable commands and placeholders exact
Here is a useful example. A tutorial includes a shell command, a path, a UI label and a placeholder supplied by the user. The visible sentences are only one layer of the object being translated. Some of its information exists to guide people, while other information controls assembly, traceability or downstream action. Those categories must be separated before anyone edits the file. The purpose of the translation is to let a target-language reader reach the same responsible decision as a source-language reader under equivalent conditions.
The nonnegotiable boundary is specific: Preserve command names, switches, environment variables and literal paths while making the explanation readable. Within that boundary, the appropriate linguistic work is equally concrete: Translate the purpose, replaceable-value instructions and error interpretation, clearly distinguishing the parts users type. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: A well-intentioned translation changes a command option or replaces angle-bracket placeholders with natural-language words. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Copy the literal command into the supported test environment and check that the placeholder convention remains obvious. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: Readers must know what to copy verbatim and what to substitute; typography alone may not clarify that difference. Developers verify commands; language reviewers verify the instructional distinction. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
12. Preserve hazard and caution semantics
Imagine a normal production handoff. A maintenance instruction contains a warning about stored pressure and a note about convenience. Most errors at this point are not caused by a lack of dictionary knowledge. They arise because the translator is not shown which parts of the source are instructions, values, relationships or merely explanatory prose. That is why context and ownership matter: both help distinguish a change in expression from a change in operational meaning.
The nonnegotiable boundary is specific: Retain the severity, hazard cause, avoidance action and placement relative to the affected step. Within that boundary, the appropriate linguistic work is equally concrete: Translate warnings with direct language and recognized local terminology, avoiding an unnecessarily dramatic tone. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: A translator softens ‘must isolate pressure’ into ‘it is preferable to isolate pressure’, converting a required safety step into advice. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: A subject expert checks that the translated warning names the same hazard and requires the same protective action. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: Readiness depends on behavioral equivalence, not word-for-word similarity. Safety owners must review hazards; publication editors cannot approve safety changes alone. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
13. Localize user-interface references at the release version
Consider this working situation. A task tells readers to select a button whose label differs between the current and upcoming versions of an application. The temptation is to treat the work as a sequence of strings to replace. That approach misses the relationship between the text, the surrounding system and the decisions a reader must make. The first question is what the original material is actually promising to the person who encounters it. A translator who understands that promise can choose a natural sentence without damaging the work it must perform.
The nonnegotiable boundary is specific: Keep the UI action connected to the documented software release and identify each actual screen label. Within that boundary, the appropriate linguistic work is equally concrete: Translate the surrounding instruction to match the UI string that ships in the specified locale and version. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Using a preferred translation for a button that the released application does not use leaves readers unable to find it. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Review screenshots and the actual interface for each supported release and target locale. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: A translation that describes a future label as current is inaccurate even if the words sound better. The UI localization owner should supply the authoritative string catalog and release matrix. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
14. Design tables for meaning and accessibility
Here is a useful example. A troubleshooting table contains conditions in the first column, causes in the second and remedial actions in the third. The visible sentences are only one layer of the object being translated. Some of its information exists to guide people, while other information controls assembly, traceability or downstream action. Those categories must be separated before anyone edits the file. The purpose of the translation is to let a target-language reader reach the same responsible decision as a source-language reader under equivalent conditions.
The nonnegotiable boundary is specific: Maintain column relationships, header association, IDs, units and the correspondence between a symptom and its action. Within that boundary, the appropriate linguistic work is equally concrete: Translate labels and explanations concisely, accounting for expansion in narrow columns and screen-reader reading order. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Reordering cells for visual balance pairs a serious fault with the wrong remedial step. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Inspect HTML, PDF and mobile layouts; read several rows aloud with their headers to detect mismatches. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: A table is a decision tool, not decoration, and its accessible reading order must carry the same decisions. Accessibility and technical reviewers should sign off the rendered table. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
15. Preserve image callouts and textual equivalents
Imagine a normal production handoff. A figure marks three controls by numeric callout while its alt description explains their placement. Most errors at this point are not caused by a lack of dictionary knowledge. They arise because the translator is not shown which parts of the source are instructions, values, relationships or merely explanatory prose. That is why context and ownership matter: both help distinguish a change in expression from a change in operational meaning.
The nonnegotiable boundary is specific: Keep callout numbers, targets and the diagram’s relationship to the associated instruction. Within that boundary, the appropriate linguistic work is equally concrete: Translate captions, alt descriptions and explanatory legends without inventing features not visible in the image. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Renumbering callouts to match a preferred prose order sends the reader to the wrong physical control. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Compare every target-language callout against the figure and test the meaningful alternative text without the image. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: An image needs a correct textual account for readers who cannot see it and for those studying the diagram closely. A visual reviewer and accessibility specialist should jointly check high-risk figures. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
16. Support right-to-left and complex-script publishing
Consider this working situation. A guide is issued in a right-to-left language but includes left-to-right commands, model numbers and file paths. The temptation is to treat the work as a sequence of strings to replace. That approach misses the relationship between the text, the surrounding system and the decisions a reader must make. The first question is what the original material is actually promising to the person who encounters it. A translator who understands that promise can choose a natural sentence without damaging the work it must perform.
The nonnegotiable boundary is specific: Keep token order inside code and identifiers while assigning appropriate direction and language metadata to prose. Within that boundary, the appropriate linguistic work is equally concrete: Adapt sentence order, punctuation and layout so readers can scan long explanations naturally. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Applying a broad bidirectional override to a mixed command can visually reorder critical characters even when the stored bytes are unchanged. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Test rendered output with native-language readers and inspect selection, copying, search, print and assistive technology. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: A successful text build is not the same as a successful reading experience. Internationalization engineers should collaborate with the language team on bidirectional controls. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
17. Manage source changes and translation memory
Here is a useful example. An author changes one prerequisite in a reused task after most locales are complete. The visible sentences are only one layer of the object being translated. Some of its information exists to guide people, while other information controls assembly, traceability or downstream action. Those categories must be separated before anyone edits the file. The purpose of the translation is to let a target-language reader reach the same responsible decision as a source-language reader under equivalent conditions.
The nonnegotiable boundary is specific: Track the source change, affected references, translated segments and publication builds; do not treat prior approval as permanent. Within that boundary, the appropriate linguistic work is equally concrete: Reopen only the affected meaning-bearing passages while still testing every location that reuses them. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: A translation memory match returns the old prerequisite and makes a critical new condition disappear in the target edition. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Perform change-impact analysis, compare old and new requirements, then rebuild all affected maps. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: The right question is which readers now receive different instructions, not merely which files changed. Release managers need auditable review evidence for the impacted locales. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
18. Plan DITA 2.0 adoption without pretending it is finished
Imagine a normal production handoff. A documentation group considers adopting DITA 2.0 preview grammars while still delivering contractual DITA 1.3 manuals. Most errors at this point are not caused by a lack of dictionary knowledge. They arise because the translator is not shown which parts of the source are instructions, values, relationships or merely explanatory prose. That is why context and ownership matter: both help distinguish a change in expression from a change in operational meaning.
The nonnegotiable boundary is specific: Keep current approved production schemas, source branches and release policies explicit; evaluate any prerelease upgrade separately. Within that boundary, the appropriate linguistic work is equally concrete: Translate the current manuals accurately and document future migration questions without altering canonical source identifiers. This is not an argument for mechanical word-for-word correspondence. Often the best target sentence changes syntax, expands an explanation or uses a different word order. What must remain equivalent is the relation among the people, objects, conditions and outcomes described. If a word is serving as a stable system token, a translator needs confirmation before treating it as ordinary prose.
The failure to watch for is this: Treating prerelease grammar support as proof of an approved standard can lead to incompatible deliverables. Notice why that matters. The resulting document might pass a spelling check, and an inexperienced reviewer might even call its language elegant. The defect becomes visible only when someone follows the instruction, resolves the reference, searches the document or compares it with the underlying source evidence. A reliable reviewer therefore asks not just whether the wording sounds right, but what a user would now do or believe. If that behavior differs materially, correct the translation or escalate the source ambiguity.
A practical acceptance test is available: Validate against the version required by the customer and test migration candidates in a nonproduction branch. The resulting finding should be recorded beside the exact passage or component, the target locale and the release version. Do not assume one successful screenshot proves every configuration works. The broader lesson is straightforward: Standards status is a release fact, not a marketing preference; as of October 2026 DITA 2.0 Beta 03 remains prerelease. Documentation architects and customers should own the schema-adoption decision. Where uncertainty remains, state it to the responsible reviewer before distribution rather than resolving it through an undocumented stylistic choice.
For a training exercise, give two reviewers the same source and ask them independently to identify which words can change and which relationships cannot. Then provide the translated version without the original and ask a third reader to complete the intended task. Compare their interpretations, rather than simply comparing vocabulary. This small experiment separates language polish from usable comprehension. It also exposes the exact point where a missing note, unclear condition or structural mismatch creates a different result. Use that evidence to improve both the translation and the upstream writing.
A release review that separates four different kinds of quality
First, review the language as language. Read complete paragraphs aloud and ask whether a competent target-language reader can follow the argument without reconstructing the English. Check terminology, pronouns, referents, negation, conditional statements and the force of instructions. Natural phrasing is an obligation, not a luxury, but it does not authorize changing a technical fact.
Second, review structure. Compare identifiers, references, links, hierarchy, relationships, lists and any configuration that determines visibility. Verify that the release still assembles and navigates correctly after localization. A structured file is useful precisely because it carries relationships beyond the text a reader can see. Those relationships should be checked directly rather than inferred from a visually convincing preview.
Third, review the subject matter. Technical values, safety instructions, procedural decisions, dates, units and rights statements require the relevant experts. Ask them to check real scenarios and edge cases rather than merely signing a one-page approval. Their work is to establish equivalence of fact and action; a translator’s work is to establish equivalence of expression and reader understanding.
Fourth, review the delivered experience. Open the output in the actual application or viewer. Look for clipped strings, wrong reading direction, missing glyphs, broken tables, inaccessible headings, missing references and unexpected fallback-language passages. Test search, copying, navigation and printing where those functions matter. A file that saves successfully is not necessarily a file that readers can use successfully.
Common questions
Should I translate DITA element names?
No. XML element and attribute syntax is part of the document contract. Translate eligible human-language content and approved labels, and leave schema names and structural tokens intact. A practical next step is to test the specific source-and-target pair in its real publication environment, because the answer depends on the contract, toolchain and reader context. Keep the evidence with the release record so later editors can reproduce the decision.
Can I translate a DITA topic without its map?
A standalone topic can be edited, but a publication-ready translation requires map context. Keys, profiling, navigation and reused passages can change how the reader encounters its text. A practical next step is to test the specific source-and-target pair in its real publication environment, because the answer depends on the contract, toolchain and reader context. Keep the evidence with the release record so later editors can reproduce the decision.
Is conref the same as keyref?
No. A content reference reuses content from a referenced element; a key reference resolves a key definition in map context. Both require checking final assembled output. A practical next step is to test the specific source-and-target pair in its real publication environment, because the answer depends on the contract, toolchain and reader context. Keep the evidence with the release record so later editors can reproduce the decision.
Does DITA guarantee one translation will fit every product?
No. Reuse is powerful only when the passage has stable meaning in every destination. Genuine differences need documented variants or authoring changes. A practical next step is to test the specific source-and-target pair in its real publication environment, because the answer depends on the contract, toolchain and reader context. Keep the evidence with the release record so later editors can reproduce the decision.
What is the safest way to translate commands?
Keep executable syntax unchanged, translate the explanation and test the command with controlled inputs. Make placeholders unmistakable. A practical next step is to test the specific source-and-target pair in its real publication environment, because the answer depends on the contract, toolchain and reader context. Keep the evidence with the release record so later editors can reproduce the decision.
How should translated warnings be reviewed?
Ask a qualified subject expert to confirm hazard, severity, avoidance and step placement. A language-only review cannot establish technical safety. A practical next step is to test the specific source-and-target pair in its real publication environment, because the answer depends on the contract, toolchain and reader context. Keep the evidence with the release record so later editors can reproduce the decision.
Does DITA 2.0 replace 1.3 today?
As of October 2026, DITA 1.3 remains the approved OASIS Standard while DITA 2.0 has published prerelease beta material. Follow the customer’s specified version. A practical next step is to test the specific source-and-target pair in its real publication environment, because the answer depends on the contract, toolchain and reader context. Keep the evidence with the release record so later editors can reproduce the decision.
What proves a DITA translation is complete?
Validation, map builds, link resolution, filter tests, rendered-language review, accessibility checks and documented technical approval together provide much stronger evidence than a successful file export. A practical next step is to test the specific source-and-target pair in its real publication environment, because the answer depends on the contract, toolchain and reader context. Keep the evidence with the release record so later editors can reproduce the decision.
A worked end-to-end review exercise
Suppose an editor must deliver the same topic-oriented documentation assembled from concepts, tasks and reference material rather than a single continuous book to two language audiences. The editor first chooses one authoritative source version and records the publication configuration. A language professional translates only the selected human-facing content, marking unresolved technical terms rather than replacing them by guesswork. A structured-content specialist compares references and identifiers before and after the transformation. A subject expert then reviews the actions, values and distinctions that determine real-world outcomes.
The team next builds a small but representative output in each locale. One reviewer deliberately starts from the navigation rather than from the translated source file, because that is how real users find material. Another checks the hard cases: long words, mixed scripts, nested lists, reused information, conditional requirements and links to other resources. Problems are logged as specific, reproducible failures. If the issue is a vague source instruction, the source owner resolves it; if it is an incorrect translation, the translator revises it; if it is broken markup or rendering, the responsible engineer repairs the pipeline.
The group does not declare success because every sentence has been translated. It declares success when the intended reader can locate the information, understand its meaning, act on it correctly, and distinguish authoritative facts from helpful explanation. That is a more demanding standard than superficial fluency. It is also the standard that makes international information reliable enough to reuse, maintain and update without accumulating invisible defects.
References and further reading
DITA technical committee repository
Related DocBook technical manual guide
For technical writers, translators, product documentation owners, software teams and multilingual publishing specialists, the next useful step is to select one representative file, define its protected relationships, translate it, rebuild it and record the results of both language and structural review. That measured exercise produces a more trustworthy workflow than translating hundreds of files before discovering how the publication actually works.