Translation Style Guide: How to Write One for Technical Documentation
A translation style guide is the document that tells every translator, reviewer and machine translation engine how your content should read in each target language: register, how to address the user, warnings, units, dates, interface references and locale rules. DEMA Solutions builds and maintains these guides with manufacturers so that manuals, HMI text and safety content read as one voice in every language.
Do your manuals pass through more than one translation supplier?
This article is written for the people who own multilingual technical content at manufacturing companies: technical documentation managers, technical writers, localization managers and the quality or operations directors who answer for what goes out with the machine. It is also for the Italian, German or Spanish arm of an international group that receives translations from headquarters and keeps sending them back with the same corrections.
If your manuals go through more than one supplier, your subsidiaries rewrite every delivery, or you want machine translation to follow your rules rather than its own, a written translation style guide is the cheapest fix available.
What a translation style guide is, and what it is not
A translation style guide records the decisions a translator would otherwise guess. Should the German manual address the operator as “Sie” or use impersonal infinitive instructions? Is a decimal written with a comma or a point in the Swiss French edition? Does “Emergency stop” in the HMI stay in English because the label on the machine is in English? Each of these questions has a right answer for your company, and the style guide is where that answer lives, language by language.
It is easy to confuse it with two neighbouring documents, and the difference matters because each one has a different owner and a different job.
The glossary says which word; the style guide says how to write. A glossary is a list of approved term pairs with definitions and status, for example the fixed translation of “pressure relief valve” in each language. The style guide does not repeat those terms. It sets the rules around them: whether terms are capitalised, whether product names are translated, how a term is introduced on first use. Both are needed, and a style guide that tries to be a glossary becomes unreadable. Our article on keeping technical terminology consistent across translators and suppliers covers the glossary side in detail.
The corporate writing guide governs the source; the translation style guide governs the targets. Many manufacturers have a technical writing style guide for authors, sometimes based on a controlled language, covering sentence length, active voice and procedure structure. It makes translation easier but says nothing about German capitalisation, French spacing or how a Spanish warning is phrased. The translation style guide picks up where the source guide ends.
Some companies call the same document a localization style guide, especially when it also covers software and marketing content. The name matters less than the scope: one general section that applies to every language, and one section per target language and locale. Websites benefit from the same discipline, because a guide that fixes tone and terminology for each market also helps control website translation cost every time pages are updated.
Why technical content needs its own rules
Marketing style guides are mostly about tone. In technical documentation, the rules affect whether an instruction is followed correctly and a warning understood in time. A manual that switches between formal and informal address from one chapter to the next looks careless, and usually means three translators worked on three chapters. A decimal separator converted in one table and not in the next turns a tolerance of 0,5 mm into something a technician has to interpret. A button name translated in the manual but left in English on the HMI sends the operator looking for a control that does not exist on the screen. None of these are terminology errors in the narrow sense, and a glossary will not prevent them. Only an explicit rule, written down and checked, will. Tone rules of that kind matter even more in campaign copy, where transcreation rather than translation is often the only way to keep the effect of a claim.
There is also a regulatory angle. EU product legislation, including the Machinery Regulation (EU) 2023/1230 applying from 20 January 2027, expects instructions in the languages required by each Member State, written so the intended user can understand them. A style guide does not make you compliant on its own, but it makes clarity repeatable across many languages and suppliers. Our overview of what the Machinery Regulation means for translated instructions explains the wider obligations.
What to include for technical documentation
A good guide lets a translator answer a specific question in under a minute. The general section applies to every language, and each language section adds or overrides rules. The general part should cover the following.
Voice and register per document type. One register rarely fits everything you publish. Operating instructions written for machine operators, service manuals for trained technicians, spare parts catalogues, training material and sales brochures each deserve their own line in the guide. State the register for each and give a short example sentence translated well, because an example settles arguments faster than an adjective such as “formal” or “neutral”.
How to address the user. Decide, per language, whether instructions use the polite form, the informal form, an impersonal construction or the infinitive. German technical writing traditionally uses “Sie” or infinitive instructions; Italian manuals often use the infinitive or the polite imperative; Spanish may use “usted” or impersonal forms. Whatever you choose, write it down and apply it to every document type where it belongs, including the HMI, which is often translated by a different team.
Warnings and signal words. Safety messages deserve their own chapter. Record the approved translation of each signal word (DANGER, WARNING, CAUTION, NOTICE or whatever hierarchy your documentation uses), the order of the elements in a safety message (hazard, consequence, avoidance), the sentence form for each element and whether signal words appear in capitals. Many companies keep a small library of approved standard warnings in every language, and the guide should say that these are reused as they are, never retranslated.
Numbers, units and locale formats. Specify decimal and thousands separators per locale, the space between number and unit, whether imperial units are added in brackets for some markets, and the rule that values, tolerances and part numbers are never converted or rounded by the translator. If a conversion is required, it should be decided by engineering and written into the source, not improvised in translation.
Dates and times. A date such as 03/04/2026 means March in one country and April in another. Require an unambiguous format, such as 2026-04-03 or a written month, or set the local format per language, and do the same for 12-hour and 24-hour times.
Capitalisation and typography. Headings in sentence case or title case, capitalisation after a colon, quotation marks per language, how lists are punctuated, and the non-breaking spaces some languages need. French in France places a non-breaking space before colons, semicolons, question marks and exclamation marks, while Canadian French usage typically keeps it only before the colon; that single rule produces hundreds of corrections if nobody writes it down.
UI and HMI references. This is where technical manuals most often go wrong. The guide must state how interface elements are referenced in running text (bold, quotation marks or square brackets), whether the translator uses the translated HMI string or the source string, and what to do when the HMI is not yet translated. The golden rule is that the manual quotes exactly what the operator sees on the screen, which means the manual and the software must draw from the same approved strings. Keeping those strings aligned release after release is far easier when HMI and UI translation runs on the same glossary and memory as the documentation.
Abbreviations and acronyms. List which abbreviations are expanded on first use, which stay in the source language (often PLC, HMI, CE or model codes), and which have an established local equivalent. A German reader may expect “SPS” where an English reader expects “PLC”, and the guide should settle which one your documentation uses.
Names that stay in the source language. Product names, model designations, software module names, trade marks and sometimes component names printed on the machine itself are not translated. Mark them clearly, with a do-not-translate list or flags in the glossary, so that neither a translator nor a machine translation engine “helpfully” renders them.
Layout constraints. Translated text often runs longer, while labels, tables and HMI fields have fixed space. State the character limits and what translators do when text does not fit: use approved abbreviations or flag it, never cut meaning. Many of these problems are better solved before translation, which is the purpose of DTP file preparation.
For teams that want a quick translation style guide template to start from, the general section can follow this checklist:
- Scope, owner, version and date of last update
- Register and form of address per document type
- Safety messages: signal words, structure, standard warnings
- Numbers, units, dates and times per locale
- Capitalisation, punctuation, quotation marks and lists
- UI and HMI references, abbreviations, do-not-translate names
- Layout and length rules, plus who to contact with questions
Per-language sections and locale variants
The general section is where most companies stop, and it is not enough. Every target language needs its own section, written or at least approved by someone who reads that language natively and knows your products.
A language section records grammatical choices, preferred and rejected phrasing, local typography and the corrections that keep coming back from subsidiaries. If your German subsidiary always changes “Wartung durchführen” to “Wartung ausführen”, that preference belongs in the German section, so the next translator gets it right the first time.
Locale variants need explicit treatment, because a single language can serve markets with different conventions. German for Germany and German for Switzerland differ in spelling (Swiss German writing uses “ss” where Germany uses “ß”) and in some number conventions, and Austrian usage has its own vocabulary in places. French for France and French for Canada differ in punctuation spacing, in vocabulary and, for Quebec, in a stronger expectation that English loanwords are replaced. Spanish for Spain and Spanish for Latin American markets, or Portuguese for Portugal and Brazil, differ in vocabulary and forms of address. Decide whether you publish one variant per language or several, and record the decision. If you publish one, say which one, so nobody mixes them. If you publish several, give each its own subsection with the differences listed.
How to build it from approved translations you already have
The best translation style guide is not written from a blank page. Your company already has years of decisions embedded in approved translations, review comments and corrections from subsidiaries. The task is to extract them, resolve contradictions and write them down.
Start with your translation memories and the latest approved editions of key documents. A linguist comparing several manuals in one language quickly sees which choices are consistent, and can be codified, and which vary and need a decision. Each variation is a question every future translator would otherwise answer differently. If those memories sit with different suppliers, recovering them is the first step, which is one reason owning your translation memory matters so much.
Next, collect feedback: subsidiary review comments, distributor change requests and your engineers’ corrections are style rules waiting to be written. Separate genuine rules from personal taste and turn each rule into a short, testable statement with an example. “Use the infinitive for procedure steps in Italian” is testable; “write naturally” is not.
Finally, align the guide with the terminology work. Every rule that is really about a term (a preferred word, a forbidden synonym) should move to the glossary, and the guide should reference the glossary rather than duplicate it. A structured terminology management process keeps both documents consistent as they evolve.
Who approves it: headquarters or subsidiaries
In international groups, ownership decides whether the guide survives. Headquarters wants group-wide consistency; subsidiaries and distributors know the local market and are the ones asked why a manual sounds foreign.
What works is shared ownership with clear limits. Headquarters, normally the documentation or localization manager, owns the general section and the governance: version control, change requests and the final say when rules conflict. Each subsidiary nominates one reviewer per language who approves the language section, with an agreed response time and a defined scope for changes. Without this, local reviewers rewrite translations to personal preference and every delivery becomes a negotiation.
Once approved, a rule binds internal writers, every supplier and every reviewer. With several suppliers, a single approved guide is the only way to make their output comparable, which is central to managing translation across multiple vendors and markets.
How translators, reviewers and QA checks use it
A style guide that sits in a shared folder is read once, at best. To be effective, it needs to be part of the workflow at three points.
Translators should receive the current version with every project, together with the glossary and translation memory, so the brief can stay short and nobody re-explains preferences each time.
Reviewers use it as the reference for their judgement: every change should be justified by the source, the glossary or the style guide, not by taste. That one principle cuts preferential edits and makes feedback to translators actionable. It is also one of the things worth checking when you assess a supplier’s quality process before you hire them.
Many rules also become automated QA checks: number and unit formats, forbidden terms, spacing before punctuation, signal words, do-not-translate names and capitalisation can all be detected before delivery. The more precisely a rule is written, the easier it is to check, leaving reviewers more time for meaning.
Keeping it up to date
A translation style guide is never finished. New products bring new interface elements, new markets bring new locales, regulatory changes alter warning texts, and every review cycle produces a few new rules. Give the guide a version number and a change log, collect proposals continuously and publish revisions at fixed intervals, for example with major documentation releases, so translators are not chasing a moving target mid-project.
When a rule changes, decide what happens to existing translations: a corrected warning justifies updating every live document, a stylistic preference only new and revised content. Recording that decision in the change log prevents slow drift between old and new manuals.
Style guides and machine translation
Machine translation has made style guides more important, not less. A translator who has worked on your manuals for years has absorbed your preferences; an engine knows none of them unless they are supplied. Approved terminology, do-not-translate names and, depending on the setup, form of address can be enforced during machine translation. The other rules are applied in post-editing, where the style guide becomes the post-editor’s checklist and turns grammatically correct output into text that reads like your documentation. It also helps decide which content is suitable for machine translation at all, a question covered in our guide to post-editing for technical documentation.
A step-by-step approach
Broken into stages, the work is manageable, and a useful first version arrives long before the guide is complete. Begin by agreeing the scope (document types, languages, locales) and naming an owner at headquarters; without one, the rest stalls. Then gather approved translations, memories, glossaries, your source writing guide and recent review feedback.
Next, draft the general section, starting with the rules that cause the most rework today, usually address forms, warnings, numbers and HMI references. A linguist then drafts each language section with examples taken from your own documentation, so the rules look familiar to the people who approve them.
Send each language section to the nominated subsidiary reviewer with a deadline and a clear question: approve, or propose a change with a reason. Resolve conflicts centrally and publish version 1.0. From then on, distribute it with every project, ask reviewers to cite it when they make changes, turn testable rules into automated checks and collect proposals for the next version. Within a few release cycles, preferential corrections fall noticeably.
What to ask a translation supplier about style guides
Ask whether a supplier will help build the guide from your existing translations or only follow one you write, how the current version reaches every translator and reviewer, which rules they check automatically, and who owns the guide, glossary and memory if you change supplier. Those answers sit well alongside the other criteria in our guide on how to choose a technical translation company.
How DEMA Solutions builds and maintains translation style guides
A style guide works best when it is kept together with the glossary and translation memory, as one set of assets that belongs to you. We draft the general rules and the language sections from your approved translations and from the feedback your reviewers have given, then refine each section with headquarters and the subsidiaries until it is signed off; after that, every project applies it. Under our ISO 17100 certified process, the second qualified linguist who revises each translation checks it against the source, the glossary and the style guide together. In sensitive projects, sentences reused from the memory are checked again, so an older translation written before a rule changed does not slip back in. Layout and typography rules are applied by our in-house DTP team in your InDesign, FrameMaker, Word or XML files, which is part of what multilingual desktop publishing adds to translation.
The guide, glossary and memory are delivered in portable formats, TMX for memories and TBX for terminology, so the decisions you have made stay usable with any supplier, today or later.
Where TUBE fits
A style guide only pays off if its decisions are applied every time, even in the hundredth HMI update. TUBE turns them into working assets: your terminology lives in the glossary, approved sentences in the translation memory, and both control machine translation in an AI-managed process. DEMA can also align years of past translations into a first memory, so you start from your own history.
Frequently asked questions
A document that records how content is written in each target language, from register and form of address to number formats, warnings and locale rules, so translators, reviewers and machine translation all follow the same decisions.
A glossary lists approved terms and their translations. A style guide sets the writing rules around them, such as capitalisation, sentence form, how to address the user and how to format numbers. Most teams need both, and the style guide should refer to the glossary rather than repeat it.
You need one general section that applies to all languages and a dedicated section for each target language, plus subsections for locale variants such as German for Germany and Switzerland or French for France and Canada if you publish them separately.
A linguist can draft it from your approved translations and review history, but approval should come from the people responsible for the content: the headquarters documentation or localization owner for the general section and a nominated native reviewer per language, often in the local subsidiary.
Collect proposals continuously and publish new versions at planned intervals, for example with major documentation releases or when you add a market or language. Every version should carry a number, a date and a list of changes.
Yes. Terminology and do-not-translate rules can be applied during machine translation, and the remaining rules guide post-editing. Without a style guide, machine translation output may be correct but will not consistently follow your conventions.
Make your translations read as one voice
If your manuals come back from different suppliers sounding different, or your subsidiaries keep correcting the same things, ask us to review your current translations and style rules. We will show where the inconsistencies come from and propose a style guide built from the decisions you have already made.
How can we help?
Tell us what you need and we’ll get back to you with the solutions.