assuring-quality-safety-and-practice

name	assuring-quality-safety-and-practice
description	Hold documentation to legal, safety, accuracy and style-guide quality; treat warnings, brand names and EU-market translation as high-stakes; and revise, notify the client, and conduct professional practice with care.
kind	skill
status	ready
provenance	{"principles":["P001","P008","P011","P036","P048","P055","P059","P078","P081","P102","P105","P117","P119","P135","P138","P139","P141","P142","P143","P144","P145","P146"],"claims":["C00004","C00048","C00097","C00149","C00175","C00217","C00225","C00532","C00585","C00752","C00793","C00807"],"evidence":["E00003","E00041","E00086","E00135","E00158","E00199","E00207","E00498"],"source_anchors":[]}

Assuring Quality, Safety and Professional Practice

Purpose

This skill guides the translator to hold documentation to legal, safety, accuracy and style-guide quality; treat warnings, brand names and EU-market translation as high-stakes; and revise, notify the client, and conduct professional practice with care. It advises on the decision; it does not produce the final translation, override the client's brief, or sign off safety-critical or legally-mandated content — those are handed back to the translator and the commissioner.

When to use

• A translator is producing or revising technical documentation for end users.
• Translator education or professional practice targets technical texts.
• translating technical documentation.
• Readers must follow instructions without immediate feedback from the writer.
• Audience expectations affect coherence, acceptability, or quality evaluation.
• Documentation quality has legal, support, product-liability, or customer-success implications.
• Guide errors or poor documentation could damage product use, customer loyalty, or user confidence.
• Instructions affect user success, confidence, safety, or cost.
• products or documentation regulated for sale within the EU.

Procedure

1. Be a good technical writer in order to be a good technical translator — their principal stylistic goals coincide — and adopt technical writers' writing strategies and audience-analysis methods, while accepting that information design, typography, and layout are usually beyond the translator's remit. (P001)
2. Write concise, direct, audience-fit user-guide language without ambiguity, obscuring euphemism, unnecessary jargon, or unexplained acronyms. (P008)
3. Subject user documentation to legal, standards, accuracy, completeness, safety, readability, layout, and hands-on usability quality assurance. (P011)
4. Preserve user trust by making guides correct, confidence-building, and clearly oriented to customer needs. (P036)
5. Be honest, comprehensive enough, accurate, and ethically adequate at the point of need. (P048)
6. For products sold in the EU, ensure all technical documentation is translated into the country-of-sale language(s), treat the translated documentation as an original target-language document subject to target-language technical-writing regulations, and give clear, comprehensible instructions with explicit risk warnings — most stringently for regulated classes (general product safety, toys, medical devices, cosmetics). (P055)
7. Use source-external resources and technical-writing interventions whenever the source text alone is insufficient for target-user function. (P059)
8. Be able to recognize the specialized file types and software of the client's industry and be comfortable (not necessarily expert) with markup and scripting such as HTML and XML, so you can identify and translate the text without damaging the technical parts of the file — basic word processing alone is no longer enough in sci-tech domains. (P078)
9. Make safety-critical information explicit, repeated where needed, and escalated to the client when the source is deficient. (P081)
10. Comply with the client's style guide governing grammar, sentence structure, terminology, punctuation, address, headings, and product names: even a source-language style guide is useful, it may force you to change an initial choice (tense, direct speech, term), and typical rules include second-person address, present tense, positive constructions, consistent terminology, gerund rather than infinitive headings, no possessive product names, and no anthropomorphism. (P102)
11. Assume humour does not travel and gently remove jokes from technical texts (telling the client if unsure), and treat congratulatory content as potentially insincere or patronizing in some cultures; where humour must be kept because it serves a function (as in popular science), ensure it suits the audience and fulfils that function — by a non-humorous means if necessary. (P105)
12. Protect reader safety and prevent product damage before pursuing other instructional goals. (P117)
13. Treat administrator help as a guide-failure signal by directing users to the guide first and counting each escalation. (P119)
14. In update projects, ethically and commercially tell the client that only a proportion of the text needs translating, accept translation-memory matches as is because they are already client-approved and changes ripple into relay translations, translate only the new sections while replicating the existing style and tone, and flag anything downright wrong to the client — preferably before changing it. (P135)
15. When revising another translator's work, find and fix errors rather than rewrite it as your own: verify that all information is accurate, terminology is correct and consistent, style suits the text and audience, and spelling, orthography, and punctuation are correct; provide a tracked-changes copy for the translator and a clean copy for the client; distance yourself for fresh eyes; stay objective and constructive; and never impose your own style — a change must be a genuine improvement, not a preference. (P138)
16. Never use footnotes in a professional translation to flag confusion or queries — because the translation may reach the end reader unreviewed, exposing your confusion and undermining credibility (annotated footnotes are only a student aid) — and instead keep a query record with page number and source sentence, send minor queries at delivery and serious ones by email while working, and reference them in the cover email so a busy project manager does not miss them. (P139)
17. On spotting an apparent error, notify the client and choose — by the text's length, subject, deadline, and the client's preference — whether to raise queries as you go or at delivery; handle errors by type: fix simple linguistic errors quietly, refer completely incomprehensible meaning to the client, fix minor factual errors but notify the client, and even for a serious error you are certain of, still contact the client for clarification. (P141)
18. Recognize and handle program code without being a programmer: commands and arguments resemble English words, but words written entirely in uppercase and multi-word tokens joined without spaces or by underscores (e.g. MENUITEM, Style_Caption) are usually non-translatable identifiers to leave unchanged, and in localization the translatable part is the on-screen strings. (P142)
19. Respect the syntax that runtime variables impose: where a string has two identical variables (e.g. 'Click %s to update %s'), preserve their order and rework the translation around it or the substitution will be wrong; and where a language lacks a consistent plural marker, replace plural variables with a rendering covering both forms (e.g. batch(es)), consulting the client or project manager when in doubt. (P143)
20. Never modify product or brand names even when they look funny, ungrammatical, or wrong, because they are proper names central to the product's identity and to its copyright protection (based on a specific spelling); transfer a specific brand named for a reason unmodified, and transcribe an internationally recognized brand exactly as in the source. (P144)
21. For a brand unknown in the target culture, do not blindly substitute a comparable target brand, since the two products may differ in characteristics or composition with consequences for repeatability or safety (e.g. in a chemistry paper); research first, then in specialist texts reproduce the brand name plus a brief function phrase, and in general texts use a comparable product qualified with 'such as' (to avoid implying endorsement) or a generic description. (P145)
22. Translate warning and advisory information with particular care — it can be a matter of life or death and carries legal weight — and verify the notice severity hierarchy (the signal words and their ranking) against the warning-label standard governing the target market (for example ANSI Z535, ISO 3864, or IEC 82079-1 for EU instructions for use) rather than assuming any single ordering. Byrne illustrates one convention (Note; Warning for minor injury; Caution for equipment or data damage; Danger for serious or fatal injury), but this reverses the common standard ranking — where Danger and Warning denote death or serious injury, Caution denotes minor or moderate injury, and a separate Notice marks property-only risk — so do not rely on Byrne's ordering without checking, and neither understate risk (so readers do not dismiss it) nor overstate it (which dilutes the top level when truly needed). (P146)
23. Emit recommendations highest-impact first, in the format under Output, flagging where a draft or plan departs from the principles above.

Inputs

• The document or excerpt under translation (or its type) and the target-text function.
• The audience, their tasks and prior knowledge, and how the text is used and distributed.
• The translation brief, any client style guide, mandated terminology, and the constraints in force (deadline, format, space, safety/legal status).

Output

Per recommendation: name the applicable principle(s), tie the advice to the audience, brief and target-text function, state the trade-off or residual uncertainty, and end with a concrete next step. Order recommendations highest-impact first. The advisor never delivers the translation or makes the client's commercial or final linguistic decision — that is handed back to the translator and the commissioner.

References

See ../../references/technical-translation-principles-index.md for the full principle catalogue and ../../references/technical-translation-evidence-notes.md for grounding notes. For adjacent concerns, see the sibling skills: analyzing-audience-brief-and-skopos, selecting-translation-strategy-and-procedures, grounding-translation-in-reader-cognition, handling-terminology-units-and-nomenclature, applying-iconic-linkage-and-consistency, matching-document-type-and-genre, designing-document-structure-and-presentation, planning-usability-evaluations, running-and-analyzing-usability-studies.

Provenance

Derived from P001, P008, P011, P036, P048, P055, P059, P078, P081, P102, P105, P117, P119, P135, P138, P139, P141, P142, P143, P144, P145, P146, grounded in Jody Byrne's Technical Translation: Usability Strategies for Translating Technical Documentation (2006) and Scientific and Technical Translation Explained (2012) (distillation-only). The frontmatter provenance block lists the exact principle, claim, and evidence ids, which resolve into principles/principles.yaml, analysis/claims.jsonl, and evidence/evidence-records.yaml.