Practice writing technical content that is easy to translate and localise: avoiding idioms, culturally neutral language, and internationalisation-friendly writing.
0 / 8 completed
1 / 8
Why should technical writers avoid idioms and colloquialisms in documentation?
Idioms create translation problems: 'kill two birds with one stone' translates literally and absurdly. They also confuse non-native English readers before translation. Use plain literal language: 'solve two problems at once' is clear in any language.
2 / 8
What is 'culturally neutral' language in technical writing?
Culturally neutral technical writing avoids: US-centric date formats, dollar signs, local phone number formats, sports analogies (American football), and legal references that differ by country. This reduces localization effort and avoids misleading content.
3 / 8
What does 'text expansion' mean and how should writers plan for it?
German runs 30-40% longer than English; French 15-25% longer. Tight English UI labels ('OK', 'Submit', 'Settings') may overflow in translated UIs. Technical writers and UI designers should account for expansion from the start.
4 / 8
Why should technical writers avoid passive voice when writing for translation?
Passive voice removes the actor, which creates ambiguity that translators must resolve. Active voice is clearer and translates more accurately. 'The system processes your data' is unambiguous; 'data is processed' requires inference.
5 / 8
What is a 'do-not-translate' (DNT) term and why is it important?
DNT terms prevent mistranslation of product names and technical terms. 'GitHub Actions', 'Kubernetes', 'API key' should stay in English in translated documentation. A translation glossary defines DNT terms so translators do not accidentally translate them.
6 / 8
What is a 'translation memory' (TM) and how does it benefit technical writers?
TMs make translation more consistent and less expensive. Repeated phrases (like UI labels, warning messages) are translated once and reused. Writers can leverage TMs by reusing phrasing consistently — slight variations force re-translation of similar content.
7 / 8
What does 'string externalization' mean in software localisation?
String externalization is a key l10n best practice. Hardcoded strings in code cannot be translated. By moving them to .json, .po, or .properties files, teams can replace strings per locale without touching the code.
8 / 8
What are 'embedded strings' and why are they a localisation problem?
Screenshots with text are a localization nightmare: each locale needs a separate screenshot. Best practice: use text overlays or callouts instead of screenshots with embedded text, or provide separate localized versions. Diagrams with embedded labels have the same problem.