Copy length changes the layout

What it is

Interface copy is not a label stuck on an already-final box. It is a variable in the layout equation. Copy-length reflow is what happens when a source-language sentence is finalized or revised: character count, line breaks, and particles move, and buttons, titles, table columns, and dialog height have to move with them. If the package freezes containers to the length of one draft, the next draft is not “a few words swapped.” It is an undeclared redesign.

The variable here is an authored UI sentence, not the long and short ends of user data, and not expansion after translation. Changing “Delete” into “Permanently delete this item and you cannot undo” is already enough to shove a footer action out of the safe area.

Why it happens

Layout measures shaped glyphs. A button’s minimum width follows its label, navigation wrapping follows the item name, column width follows the header. Longer copy eats padding first, then forces a wrap, then pushes the next control down, so “we only changed the words” is a reflow. Shorter copy changes structure too: a two-character primary in a row of actions starts to look secondary; a short title makes a left-aligned header look unfinished.

Order amplifies the loss. Lock layout then swap copy, and you are cutting a door in a poured wall. Lock copy then lock boxes, and a later revision still cuts a door, but at least the box was declared variable. If the package treats one draft’s length as a geometric constant, implementation writes width: 120px on the button, and later copy can only overflow or shrink type — neither of which the writer wanted, both of which follow from length never being a variable.

Where it stops holding

Icon-only buttons and symbol toolbars have no copy length to track. Fixed-width system codes used as labels (status codes, version strings) do not move; treat them as constants. A watch face or a vehicle status strip that cannot wrap requires the writer to fit the medium’s cap, not a plea for elastic layout. Chat bubbles and social posts are mostly user text; authored copy lives in the chrome and the actions. Do not import user-text reflow habits onto those two buttons: they change less often, but when they do, hit targets and side-by-side relationships still move.

Applying it

• Mark containers for key actions, navigation, headers, and error sentences as “follows copy,” and write the allowed line cap. Lock height only where a single line is confirmed necessary.
• When copy is revised, ship a frame at the new length. Do not change the text layer and leave the old box for implementation.
• Attach two source-language, authored drafts to the package — shortest approved and longest approved — so implementation can see how the button and the dialog travel between them.
• Paste the most recently lengthened sentence from the copy table into the built UI. Check that neighboring actions stay fully hittable and that wrapping is expected. If implementation refuses to change the box and asks the sentence to shrink to the old layout, length is still not a layout input.

Related

• Same group: R2.06.1 Placeholder copy will be implemented as written · 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 · R2.06.6 Handoff must reserve space for translation length
• Adjacent: S1.01 Text Expansion and Layout Resilience · R2.05 Edge-case Completeness in Handoff
• Search terms: copy-length reflow · copy as layout input · label-driven width