A multilingual style guide is a working tool that tells translators and content creators how a brand should sound, look, and behave in every language it operates in. It sits alongside two other artefacts: language-specific style guides (per-locale linguistic rules) and the termbase (approved terms per locale). Three artefacts, three jobs.
Most brands starting to translate at scale skip the guide and discover the cost later, when the same product gets called four different things across four pages of the German site. Each translator made a defensible choice; none of them had a guide to consult.
What follows is what should go in one, what should be left out (and where it goes instead), how to build it without overengineering, and how to keep it useful as your brand and markets evolve.
TL;DRA multilingual style guide is a working tool that tells translators and content creators how your brand should sound and behave in every language you operate in. It sits alongside two other artefacts: language-specific style guides (per-locale linguistic rules) and the termbase (approved terms per locale). Three artefacts, three jobs. What goes in: voice and tone principles, writing-for-translation rules, global formatting standards, market-adaptation policy, and governance metadata. What stays out: language-specific grammar, approved-term lists, visual brand standards, and source-language writing rules. Each has a better home. Maturity isn’t binary. Most teams should aim for a level 2 operational document with a named owner and quarterly reviews; level 3 governance systems are for enterprise scale. A style guide that doesn’t sit inside the translation workflow won’t get used. Embed it in your TMS, your translator onboarding, and your QA checklist, or it gathers dust. |
What a multilingual style guide actually is
A multilingual style guide is a cross-language working document that tells translators and content creators how a brand should sound, look, and behave in every language it operates in. It defines voice, writing-for-translation rules, formatting standards, market-adaptation policy, and governance. Length isn’t the measure; usability is.
It is not a brand book (which covers visual identity, logo usage, and design system). It is not a language-specific style guide (which handles per-language grammar and idiom). It is not a termbase (which holds approved terms per locale).
All four can coexist; the multilingual style guide sits at the top, governing the cross-language principles that the other artefacts apply.
Which artefact you need depends on where you sit. Marketing translation programmes lean heaviest on the multilingual style guide because brand voice is the central variable. The next section breaks down what each artefact does.
Three artefacts, three jobs
Three artefacts work together to keep translated content consistent across languages: the multilingual style guide (cross-language principles), language-specific style guides (per-locale linguistic rules), and the termbase (approved terms per locale). Knowing which artefact owns which decision is the difference between a working system and a confused one.
One-line definitions:
- Multilingual style guide: cross-language principles. Voice, writing-for-translation rules, formatting policy, market-adaptation policy, governance.
- Language-specific style guides: per-language linguistic rules. German capitalisation, French punctuation spacing, Spanish vos vs tú, Japanese honorific usage.
- Termbase: approved and forbidden terms per locale. What to call the product, what to call the customer, what NOT to call either.
Decision matrix: which artefact owns which decision
| Decision type | Multilingual style guide | Language-specific style guide | Termbase |
|---|---|---|---|
Brand voice and tone | Yes (cross-language principles) | Yes (per-language application) | No |
| Writing-for-translation rules | Yes | No | No |
| Approved terms per locale | No (lives in termbase) | No | Yes |
| Forbidden terms per locale | No | No | Yes |
| Grammar and punctuation per language | No | Yes | No |
| Date, time, number formats (policy) | Yes (the policy) | Yes (the format detail) | No |
| Currency and unit conventions | Yes | Yes (detail) | No |
| Non-translatable elements (product names, codes) | Yes (the policy on what doesn’t translate) | No | Yes (the locked terms themselves) |
Market-adaptation policy | Yes | No | No |
The three artefacts integrate at the TMS level. The multilingual style guide gets attached to translation jobs as a reference document. The language-specific guides are loaded per market for the relevant linguist. The termbase enforces approved-term usage at the segment level, with terminology management running underneath.
Our SmartDesk hosts all three in one place; without that integration, the documents fragment and translators end up consulting whichever one they’ve seen most recently.
What to include in a multilingual style guide
Every multilingual style guide needs five sections: brand voice and tone, writing-for-translation rules, global formatting standards, market-adaptation policy, and governance metadata. Each has a specific job. Four concrete excerpts below show what entries in the first four sections look like in practice; the excerpts are adapted from public style guides and clearly labelled as illustrative.
Brand voice and tone
Define your voice in cross-language terms (warm, direct, authoritative) not in source-language tactics (“use short sentences” or “contractions OK”). Cross-language attributes travel; source-language tactics don’t.
Each attribute needs an example so the meaning is unambiguous, and a note about where local adaptation is allowed (formality register varies by language) versus where the voice has to stay consistent (the underlying attributes).
| Illustrative example: voice and tone entry Modelled on the public Mailchimp Content Style Guide pattern. Brand context fictional. Our voice: confident, plain, useful. We’re a B2B retailer. We talk to people who buy things to do their job. Confident, because we know our category and we don’t hedge. Plain, because procurement teams don’t have time for cleverness. Useful, because the next thing they read after our page is either a quote request or someone else’s page. Cross-language note: confidence and plainness travel. Usefulness travels. The exact register varies. German prefers more formal address (Sie, not du); Brazilian Portuguese permits warmer phrasing than European Portuguese. See language-specific guides for register. |
Writing for translation
Rules for writing source content in a way that translates well. Short sentences, plain language, one idea per sentence, no embedded formatting mid-sentence, no idioms or culture-specific references.
These rules help human translators and they help machine translation. The European Commission’s clear writing principles and the W3C’s internationalisation guidance are useful public references.
| Illustrative example: writing-for-translation rules Modelled on the Microsoft Writing Style Guide pattern. Brand context fictional. Keep sentences short. One idea per sentence; if you have two, write two sentences. Average 15 to 20 words; cap at 30. Active voice unless the actor is genuinely unknown. No idioms. “Hit the ground running” doesn’t translate. “Start fast” does. No embedded bold or italics inside running text. Pull emphasis onto its own line if it matters. Use the same word for the same thing. If you call it a “dashboard” on the homepage, don’t call it a “console” on the help page. |
Global formatting standards
The multilingual guide sets the policy (“use locale conventions”); the language-specific guides provide the per-locale detail. The policy belongs here; the specifics belong there.
| Illustrative example: formatting policy Modelled on the GOV.UK style guide locale pattern. Brand context fictional.
|
Market-adaptation policy
The market-adaptation section names which content gets fully translated, which gets transcreated, and which stays in source language. It’s the policy; the per-content-type detail comes from sector-specific decision matrices in our articles on e-commerce translation and transcreation.
| Illustrative example: market-adaptation policy Modelled on the European Commission English Style Guide pattern. Brand context fictional. What we localise, transcreate, or leave alone. Fully localise: marketing pages, product titles and descriptions, help-centre articles, transactional emails. Transcreate: hero headlines, slogans, campaign taglines, push notifications. The intent has to land; the literal words rarely will. Leave in source: product names (“BrandName Pro” doesn’t translate), internal English documentation, technical reference codes (SKUs, error codes), legal disclaimers with a binding single-language version. Sector-specific calls (e-commerce content types, medical regulatory content, financial reporting) live in dedicated decision matrices. |
Governance metadata
Every multilingual style guide needs a governance metadata block. Without one, the guide becomes orphaned: nobody owns it, nobody updates it, nobody resolves disputes when markets disagree.
The block should record:
- Owner (named role, not “the brand team”).
- Reviewers per market (list with named contacts).
- Update cadence (quarterly for level 2 and above; annual for level 1).
- Version control (semantic versioning: v2.1 is a tweak, v3.0 is a structural change).
- Disputes (who arbitrates when markets disagree).
- Distribution (where the guide lives, who has access).
What to leave out (and where it goes instead)
Four things often end up in multilingual style guides by mistake. Each has a better home. The guide stays useful only if these are kept out.
- Language-specific grammar rules. These belong in the language-specific style guide for each locale. The multilingual guide can reference the locale guides but shouldn’t contain their content.
- Approved-term lists. These belong in the termbase. The style guide can reference the termbase; duplicating terms in the style guide creates drift the moment one updates and the other doesn’t.
- Visual brand standards. Logo placement, colour codes, typography, design tokens. These belong in the brand book or design system, not in a translation-facing document.
- Source-language-only writing rules. “Use Oxford commas” or “never start a sentence with And.” If a rule doesn’t help translation, it belongs in the source-language style guide alone.
A maturity model for multilingual style guides
Maturity isn’t about thickness. A 10-page document that gets used beats a 100-page document nobody opens.
Three levels mark out the practical range: a working draft, an operational document, and a governed system. Most teams should aim for level 2.
Level 1: Working draft
A single document, often a Google Doc or Notion page, covering the five sections from the previous H2 in short form. The voice section is a paragraph; formatting is a small table.
One owner (the content lead or localisation manager), updated ad hoc, shared with translators on project handover.
What this looks like in practice: a 12-page Google Doc, headed by a one-paragraph voice statement, a 10-row formatting table, a list of 15 to 20 “write it this way, not that way” examples, a one-page market-adaptation rule, and a governance block at the back. The whole thing can be drafted in two weeks by one person with input from three to four translators.
Suits: 1 to 3 markets, content volume under ~200,000 words per year per language, single brand voice. Most teams start here; many should stay here longer than they think.
Level 2: Operational document
A structured document with separate sections per topic, cross-referenced to language-specific guides and the termbase. Owned by one named role with per-market reviewers, reviewed quarterly.
Hosted in the TMS alongside termbase and translation memory; linguists access it during translation jobs. Includes concrete excerpts the way the four above are written.
What this looks like in practice: a 40-page document split into the five sections, hosted in the TMS rather than a shared drive, with named market reviewers for each of the priority languages.
Translation briefs reference the guide explicitly. QA cycles check adherence on a sample of every job. Build time is typically eight to twelve weeks from audit kickoff to first published version.
Suits: 4 to 10 markets, content volume 200,000 to 2 million words per year, multi-department content production. Most growing programmes land here as the operational target.
Level 3: Governed system
The style guide itself follows a schema (structured Markdown or XML), version-controlled with semantic versioning and a change log, with per-market sub-guides that go through formal sign-off.
Integrated into TMS, termbase, QA checklist, and translator onboarding. Tied to brand-voice training for new linguists and reviewers. Disputes resolved through a named escalation path, often a localisation governance committee.
Suits: 10+ markets, regulated industries (medical, financial, legal), companies with multiple sub-brands or product lines. The operational overhead is real; only justified at scale.
Picking the right level
Pick the level by content volume, market count, and team structure, not by ambition. Moving up a level brings governance and consistency, and also brings overhead. Level 2 is the target for most growing programmes; level 3 is reserved for enterprises that can absorb the governance cost.
How to build a multilingual style guide that gets used
Four steps. Audit and gather input; draft the five sections; embed in the workflow; govern and update. The first half is upstream work; the second half is what separates style guides that get used from ones that don’t.
Step 1: Audit existing content and gather input
Pull a sample of translated content across three to five markets. List recurring inconsistencies: voice drift, terminology variation, formatting mismatches, market-specific errors.
Talk to the linguists who do the work; they know what’s missing because they guess every week. Talk to in-country reviewers about the corrections they make repeatedly.
The input pool covers brand and content (owns voice), localisation management (owns workflow), in-country reviewers (own per-market judgement), and translation partners (own day-to-day execution).
Step 2: Draft the five sections
Use the structure from H2 3 as the starting point. Keep voice and tone short, with concrete examples. Keep formatting tight, with the policy in the multilingual guide and the format detail in language-specific guides.
Reference the termbase rather than duplicating terms. Include market-adaptation policy clearly. Add governance metadata.
Aim for level 1 first. Move to level 2 once the level 1 document has been in use for six months and the recurring gaps are clear.
Step 3: Embed in the workflow
A style guide that lives in SharePoint and never gets opened might as well not exist. Four embedding points matter:
- Host the guide in our SmartDesk (or your equivalent TMS).
- Link it from translator onboarding materials.
- Reference it in every translation brief.
- Add adherence checks to the QA stage.
Without these four, the guide stays documentation. With them, it becomes infrastructure.
Step 4: Govern and update
Quarterly review cycle for level 2 and above. Annual full review for all levels. Change-management process for level 3.translation management article covers the broader workflow patterns this sits inside.
Distribute changes to linguists and reviewers via the TMS, not via email. The
Multilingual style guides in the AI and MT era
Style guides now need to work for both human translators and MTPE workflows. The same guide can serve both, but it needs explicit machine-readable rules alongside human-readable guidance. The split matters because the two audiences fail in different ways.
What MT and MTPE workflows need
Machine translation engines and MTPE editors need rules they can pattern-match against. Term-level enforcement (the termbase is the machine-readable layer). Format rules in explicit form, not “use sensible date formats” but “use locale convention per Annex B.”machine translation workflow handles enforcement at the segment level when the style guide is correctly wired into the TMS.
Voice rules in concrete examples MTPE editors can compare output against. Clear marking of which content types use MTPE and which don’t. The
A worked contrast. A vague style rule reads: “Keep dates clear and readable for the local audience.” A machine-readable version reads: “Date format: locale convention per ISO 8601 mapped to display patterns in Annex B. en-GB: D MMMM YYYY. de-DE: D.M.YYYY. ja-JP: YYYY年M月D日.”
The MT engine and the MTPE editor can both act on the second; neither can act on the first. Every rule in a multilingual style guide intended for MT workflows needs this level of specificity.
What human translators need
Human linguists need the same machine-readable rules plus the human-readable layer the machines don’t use: voice rules with adapted excerpts they can read and absorb; judgement guidance for edge cases the rules don’t cover; brand context (a paragraph or two on who the company is and who it talks to); forward-pointers to language-specific guides for per-language detail. For the broader picture on AI and translation strategy, see our take on machine translation and ChatGPT in your strategy.
How we help clients build multilingual style guides
The article’s principles are how we structure style-guide engagements. Audit-led, integrated with the termbase and translation memory, hosted in our SmartDesk, and governed with a named owner and review cadence. Not every client needs level 3; most need a well-built level 2.
Our approach in brief:
- Start from existing content. The inconsistencies tell us what’s missing.
- Involve linguists and in-country reviewers from the start.
- Build to level 1 or 2 depending on volume and market count.
- Embed the guide in the TMS so it becomes infrastructure, not a PDF.
Our SmartDesk hosts the guide alongside the termbase and translation memory; our SmartConnect feeds it into the source CMS workflow.
If you’re scoping a multilingual style guide programme, or want a second opinion on one that isn’t getting used, speak with our localisation team. We can walk through where the consistency gains live in your current setup.
Frequently asked questions
What’s the difference between a multilingual style guide and a translation style guide?
They’re typically the same thing. The two names get used interchangeably across the industry. “Multilingual” emphasises the cross-language scope of the document; “translation” emphasises the workflow that consumes it. Same artefact.
What’s the difference between a style guide and a termbase?
A style guide handles voice, grammar, formatting, and market-adaptation policy. A termbase handles approved and forbidden terms per locale. Different artefacts, different jobs. The style guide tells you how to sound; the termbase tells you what to call things. The H2 on three artefacts breaks down the boundaries.
How long should a multilingual style guide be?
Depends on the maturity level. Level 1: 10 to 20 pages. Level 2: 30 to 50 pages with cross-references to other artefacts. Level 3: a structured system rather than a flat document. Length isn’t the measure; usability is. A short guide that gets used beats a long guide that gets ignored.
Who should own the multilingual style guide?
A single named owner, usually the content lead, brand lead, or localisation manager. Multiple reviewers per market and per discipline. A guide without a named owner won’t get updated. The governance metadata block makes ownership explicit.
Can AI translation respect a style guide?
Increasingly, yes. MT engines and LLM-based translation tools can be fed style instructions and termbase entries via prompt templates, custom dictionaries, or model fine-tuning. Adherence varies by engine, content type, and how machine-readable the style guide is. The AI and MT section covers the practical pattern.
How do you know whether your style guide is working?
Two operational signals. First, the volume of mid-translation clarification questions from linguists drops. A well-used style guide reduces those questions by 30 to 50% within the first two quarters. Second, the volume of in-country reviewer corrections drops, particularly in the categories of tone consistency, terminology drift, and formatting. If neither signal moves in the first six months after launch, the guide isn’t being consulted; revisit the embedding steps before assuming the document itself is wrong.
Sources
- Microsoft Writing Style Guide (public, current version).
- Google developer documentation style guide.
- GOV.UK style guide.
- European Commission English Style Guide (current edition).
- Mailchimp Content Style Guide.
- W3C internationalisation best practices.
- ISO 17100:2015 Translation services, Requirements for translation services.
- ISO 18587:2017 Translation services, Post-editing of machine translation output, Requirements.
- AdHoc Translations ISO 17100 and ISO 18587 certifications, 2025.