Handoff must reserve space for translation length

What it is

If a source-language screen locks boxes to the width of the current sentence, a translation has nowhere legal to go. Translation-length allowance is writing those containers, at handoff, as able to grow, wrap, or marked “this slot stays one line; translations may not exceed N” — not waiting to restyle after language packs land in the repo. It is a space budget on the shipped materials, not a study of why languages differ.

Reflow from revising the source sentence, and reflow after translation, should be booked separately. This is only the second: the box must declare, on the source frame, how much more it can still take.

Why it happens

The first geometry implementation sees is the source-language frame. A button measured to “Save,” a column measured to “Status,” a header measured to one line of the source title — those numbers become layout constants. Translations usually arrive after feature freeze, when changing constants is rework: some clients already baked the constraint, some already accepted screenshots. Allowance makes “it can still grow” part of the package — a flexible container, a permitted second line, or a side-by-side longest-translation sketch — so flexibility is coded on the first pass instead of treating source width as a contract.

The cost of no allowance is not “ugly translations.” It is harm to the translation: writers are told to shorten, terms are swapped for inaccurate short words, or a critical action loses its second half in one language. That loss lands after handoff; the fault is treating width as finished at handoff. A source frame that looks airy often looks that way because the translation was never in the budget.

Where it stops holding

Internal tools that ship one language and whose rules forbid adding more gain little from allowance, but labels still should not be baked as an uneditable pixel width. Icon-only buttons have no translated characters to reserve. Phrases locked by law or brand, which translators may neither rewrite nor wrap (a registered mark, a statutory short name), convert allowance from “make it wider” into “this slot may not grow; translations must be treated as fixed width” — still a constraint written at handoff, not an argument later. Print and a fixed-pixel TV safe area have no elasticity; allowance is a character cap on the translation, not a flexible box. When the language set is not yet chosen, reserve for the languages already committed; do not size to “the longest sentence in any language” for a locale you may never ship.

Applying it

• On the source-language frames, mark every translated slot: may wrap, may grow to how many lines, or must stay one line with a character/width cap for translations.
• For navigation, primary actions, and form errors — places where one extra line changes structure — attach a pair “source sentence + one known longer translation” so the first implementation lays out to the longer side.
• Do not set a button width equal to the source sentence. A minimum may follow the source; a maximum must follow the allowance.
• Pour an existing longer translation (or a stand-in translation) into the built UI without changing layout code. If code must change to fit it, allowance was not in the first handoff. Put flexibility back in the design source; do not ask translators to return the sentence to source length.

Related

• Same group: R2.06.1 Placeholder copy will be implemented as written · R2.06.2 Copy length changes the layout · R2.06.3 Copy and design must be reviewed in the same pass · R2.06.4 Variable ranges must ship with the copy · R2.06.5 The same concept keeps the same wording on every surface
• Adjacent: S1.01 Text Expansion and Layout Resilience · R2.05 Edge-case Completeness in Handoff
• Search terms: translation-length allowance · localization room · handoff expansion budget