How to Write a Multilingual SOP That Works Without Perfect English

Start from a decision about your audience

Before writing a word, answer one question: who will actually perform this task and how comfortable are they with English? A procedure for a site where most workers read at a basic level or operate in Spanish, Polish, Vietnamese or Tagalog is a different document from one written for an English-speaking office. The failure mode is writing for the engineer or the compliance officer who approves it, not for the person who must execute it.

That audience question is also a scoping question. Not every SOP deserves a full multi-language rollout. Rank procedures by how much harm or rework follows a misunderstanding, then decide which ones get full translations, which get visual-only instruction sheets, and which stay in the master language with a bilingual quick guide. Resources are limited, and clarity is strongest when it is concentrated on the highest-risk steps.

Write one master document in deliberately simple language

A multilingual program works best when there is a single master version, usually in the simplest workable English, and all local versions are derived from it. Writing the master in plain language is the single cheapest way to improve every translation that follows, because translators are generalists first and domain experts second. The plainer the source, the fewer judgment calls they must make.

Plain language is now an internationally agreed discipline rather than a personal style. ISO 24495-1:2023, the first global plain-language standard published by ISO, sets out governing principles and guidelines for documents so that readers can get, find, understand and use the information. Several governments have made plain writing a legal duty; in the United States the Plain Writing Act of 2010 requires federal agencies to use clear, concise, well-organized writing, and plainlanguage.gov distills the rules. You do not need a law to benefit from the same rules internally.

Practical rules that travel well across languages include limiting sentences to about twenty words, using the active voice so it is clear who does what, keeping verbs in the present tense, choosing everyday words over jargon, and removing redundancy. The Translators Without Borders editing guide points to active voice, short sentences, correct and consistent terminology and concise wording as the five levers of clarity, and documents that follow them are far cheaper to translate and far harder to misunderstand.

• Limit sentences to roughly 20 words and use one idea per sentence.
• Use active voice: write 'the operator closes the valve', not 'the valve shall be closed'.
• Keep verbs in present tense and step sequences in order.
• Write one term for one concept and lock it in a glossary.
• Remove idioms, metaphors, humor, and culture-bound references.

Borrow discipline from controlled-language standards

If plain English is the baseline, controlled language is the stricter ceiling that aviation and defence reached decades ago. ASD-STE100 Simplified Technical English (STE) is an international standard that restricts vocabulary, grammar and style to a small approved dictionary and clear sentence patterns, built so that maintenance instructions cannot be misread and so that translation into other languages is faster and more accurate.

You do not need to adopt STE wholesale for a warehouse, a clinic or a service desk. But its logic transfers directly to multilingual SOPs. Because STE was created partly to help non-native speakers understand technical text and to cut translation cost, its two habits matter most here: use only approved, unambiguous words, and keep sentence structure predictable. The result is text that a human or a machine can translate more reliably because there is less ambiguity to resolve.

In practice this means banning synonyms inside one document. If the step is 'remove the guard', it must always be 'remove', never later 'detach' or 'take off'. It means avoiding the passive voice and conditional hedging that hide responsibility, and it means writing each step so that a reader never has to infer intent. When a term is genuinely new, add it to the glossary once and use it identically everywhere.

Let visuals carry the procedure

The most reliable way to make an SOP survive imperfect English is to reduce how much meaning depends on words at all. Numbered photos of the real workstation, annotated diagrams, and one-point-lesson layouts that teach a single skill on one page carry the actual procedure, while the text becomes a label around them. When a worker in any language follows a sequence of numbered images, comprehension no longer hinges on grammar.

Visuals must be designed, not decorated. Use the same numbering order in every language version so that a caption, a photo and a line in the procedure always match. Standardize icons and keep their meaning constant across documents, because symbols can be culturally specific. Color can signal warnings or personal protective equipment, but never make color the only carrier of meaning, since color vision and printing differ.

Test the visuals in isolation before you invest in translation. Show a draft sheet with captions removed to a worker who reads little English and ask them to walk the procedure back to you. If they can describe the steps from the pictures alone, the visual layer is doing its job and the text only needs to confirm details.

• Use real photos of the actual workstation, not generic stock imagery.
• Keep one action per numbered step and mirror the numbering across languages.
• Standardize icons and confirm their meaning with local workers.
• Use color only to reinforce warnings, never as the sole cue.
• Show the no-text draft to a low-English reader and ask them to describe the steps.

Translate once, verify always

Translation is the point where multilingual SOPs most often fail quietly. A literal translation preserves the words of the source but may break the meaning, especially when units, date formats, tool names or local practices differ. Controlled authoring upstream is the best defence, because a source written in plain, consistent language produces a cleaner target text than dense corporate prose.

The verification loop should be built, not hoped for. Use translators who know the domain vocabulary, then have the result reviewed by a bilingual employee who actually does the work. Back-translation, where an independent person translates the target version back into the source language so both can be compared, exposes meaning drift that a fluent-sounding version can hide. Regulated sectors and auditors increasingly expect traceability: each language version should carry its own identifier and revision, and point back to the master it was derived from.

Localization goes beyond words. Review date formats, decimal separators, icons, safety-symbol conventions and examples so that a Polish, Vietnamese or Arabic reader meets familiar conventions rather than imported ones. Keep every language version in one controlled document system so that when the master changes, you know which translations are now out of date and must be refreshed before anyone trains against them.

• Use domain-aware translators rather than generic ones.
• Have a bilingual worker who performs the task review the result.
• Run a back-translation check on critical or safety SOPs.
• Localize units, dates, and icons, not only words.
• Give each language version its own identifier and link it to the master.

Prove understanding before the SOP goes live

An SOP is only finished when the people who must follow it demonstrate that they understood it. Training should run in the same language the employee works in, and comprehension should be checked in that same language rather than through an English test or a silent signature. Asking a worker to restate the critical steps in their own words, or to run a short practical demonstration, tells you more than a checkbox ever will.

Keep a short glossary alive as a living document and review it whenever a new term appears. Pair each released SOP with a lightweight verification record that names who was trained, in which language, and what they demonstrated. This is not only good operations practice; in safety-critical and regulated environments it is the evidence an auditor looks for when they ask how you know the instruction was understood.