Source Language and Translations#

One Source, Many Targets#

A survey’s languages are an ordered list, and the order matters: the first language is the source language. Every other language is understood as a translation of the source. The Translations page is built on this asymmetry: its source column always shows the first language, and its completion figures count how much of the source has a counterpart in the target.

Reordering the languages on the survey’s Settings page therefore changes meaning, not just presentation. Making French first declares the French text to be the original that other languages translate.

Strings, Not Documents#

Translation happens per string, not per document. Every piece of text an item carries, question text, instructions, labels, descriptions, choice labels, edit check messages, and the rest, holds its own set of language versions. The Translations page is a view over all of these strings at once; the item editors show the same strings one item at a time, one row per language. Both write to the same place, so the two views never disagree.

A translation unit exists only where the source language has text. Empty source strings have nothing to translate, so they do not appear as missing work.

Fallback#

Where a target-language string is missing, the application falls back to the best available language rather than showing nothing. The live preview uses this deliberately: previewing in a half-translated language shows the gaps in context, as source-language text among the translated strings. Exports render the chosen language with the same fallback.

Shared Items, Shared Translations#

Because code lists are shared items, a code list’s labels are translated once, no matter how many questions use the list. The Translations page shows each shared list once for the same reason. The translation travels with the item: publish a translated question to a repository, and every survey that reuses it gets the translation.