Writing source text that translates well

What it is

Writing for translation means shaping the source language so that a translator, or a machine translation step, can produce a correct target text without asking the author and without the code fighting back. The GNU gettext manual (cited) lists the rules on the code side: decent English style, entire sentences, split at paragraphs, format strings instead of string concatenation, placeholders instead of embedded URLs. Its plural-forms page (cited) adds that counts must go through the plural function rather than a hand-built file%s, because languages have different numbers of plural forms; it shows languages with two, three and more forms and header rules such as nplurals=3. Google's style guidance for a global audience (cited) covers the prose side: consistent terminology and sentence structure, and omitting colloquialisms, idioms, humour and seasonal references.

Why it matters

Word order, gender, plural rules and sentence length differ between languages. A string built from fragments ("Deleted " + n + " file(s)") cannot be reordered or inflected by the translator; an English-only idiom either gets translated literally or replaced by a guess; a sentence that depends on an English pun has no target text at all. Every such case becomes a question to the author or a wrong translation in production.

How to apply

• One string per complete sentence or label; never assemble a sentence from pieces at run time.
• Use named placeholders ({count} files in {folder}) so the translator can reorder them; give translators a comment saying what each placeholder contains.
• Route every count through the plural function of the framework, including the English source ("1 file", "2 files"); do not write "file(s)".
• Keep terminology fixed: one term per concept, taken from the glossary, so the translation memory matches.
• Prefer short declarative sentences with standard word order; avoid stacked nouns and ambiguous pronouns ("it", "this") whose referent is unclear.
• Leave out idioms, humour, cultural and seasonal references, and examples that assume one country's formats; write dates, numbers and currencies through locale-aware formatting rather than in the string.
• Leave room: a translation can be longer than the source, so layouts and column widths must not assume the source length.
• Mark what must not be translated (product names, commands, code) in the source with the tool's mechanism.

Pitfalls

Reusing one string for two meanings ("Open" as a verb and as a state). Sentences split across interface elements. Screenshots with embedded English text. Changing source strings for cosmetic reasons, which invalidates every existing translation of that string.