In a component library, how should elements handle text that grows after translation, and when is truncating it acceptable?
answer
- translations are often longer
- short strings grow the most
- grow or wrap, never clip
- truncate only non-critical, repeated text
- the full text must stay reachable
basics
~20 sElements should let text grow or wrap — no fixed widths or heights on text-bearing parts — because translations are often longer. Truncate only non-critical text in constrained spots, and keep the full text reachable; never truncate actions, amounts, dates or errors.
solid answer
~50 sTranslated text is often noticeably longer than English, and short labels can grow proportionally the most, so elements must **flex**: buttons grow to fit their label, labels and headings wrap, containers use minimum rather than fixed widths, and nothing sets a fixed height on text. Icons and actions are placed so they still fit when text grows or wraps. **Truncation** is a last resort for **non-critical, repeated** text in genuinely constrained places — a long tariff name in a table cell — and the full text must stay reachable, for example on focus or activation or on a detail page. Never truncate action labels, amounts, dates, error messages or legal text. That matches WCAG 2.2's 1.4.12 Text Spacing (AA): an ellipsis is acceptable only if the truncated content remains available; clipped or overlapping text fails.
go deeper
Recall that translated text is often longer, so elements should grow or wrap, and that actions, amounts, dates and errors are never truncated.
Explain the flex rules — minimum not fixed widths, no fixed heights, wrapping, reflowing rows — and when an ellipsis with reachable full text is acceptable.
Connect expansion to WCAG 2.2's 1.4.12 and 1.4.4, audit existing elements for fixed sizes, and write truncation rules into each element's spec.
Frame length as data rather than design, and make long-string examples and the 'twice as long?' question part of how every element is reviewed.
## Why translated text grows **Text expansion** is the growth in length when a string is translated from the source language. A utility billing portal's "Download bill" becomes "Rechnung herunterladen" in German — roughly 70 percent longer. Expansion varies by language and by string, and a common rule of thumb in localization practice is that **short strings grow proportionally the most**: a four-letter label can double, while a long paragraph grows by a smaller share. Some translations are shorter, and some scripts need more vertical room rather than more width. None of these figures is a standard; they are planning margins teams use so layouts survive translation. A **component library** decides how every product copes with that growth, because the fixed widths, heights and truncation rules live in its elements. ## Designing elements to flex - **Buttons grow to fit their label**, with a minimum width for short labels rather than a fixed width for all. - **Labels, headings and helper text wrap** onto more lines instead of overflowing. - **No fixed heights on text-bearing parts**: a card whose height is fixed clips its second line. - **Icons and actions are positioned so they still fit** when a label wraps, instead of overlapping it. - **Rows can reflow into columns**: a label-and-value pair that sits side by side in English may need to stack. - **Navigation plans for overflow**: tabs or menu items that fit in English may need to scroll or collapse into an overflow menu in German. ## When truncation is acceptable | Text | Truncate? | Why | |---|---|---| | Long tariff name in a table cell | Acceptable, with the full name reachable | Repeated, non-critical, space genuinely limited | | Street address in a compact account list | Acceptable, with the full address on the detail page | The full text is one step away | | Label on the button that pays the bill | No | Users must know what the action does | | Amount due or due date | No | A truncated amount is a wrong amount | | Error message for a failed payment | No | The user needs the whole explanation to recover | | Legal or consent text | No | Hidden terms are not agreed terms | When truncation is used, the library should: 1. **Use an ellipsis**, so users can see that text is missing. 2. **Keep the full text reachable**, revealed on focus or activation, or on a linked detail page. 3. **Keep the full text available to assistive technology**, not only the visible fragment. 4. **Prefer truncating the end of a string** unless the distinguishing part is at the end, as with file names or account numbers, where middle truncation keeps both ends. ## What the accessibility standards add Two WCAG 2.2 success criteria at Level AA bear directly on this. **1.4.12 Text Spacing** requires no loss of content or functionality when users increase line height to 1.5 times the font size, paragraph spacing to 2 times, letter spacing to 0.12 times and word spacing to 0.16 times. Its Understanding document accepts an ellipsis where the truncated content remains available, and treats clipped or overlapping text as a failure. **1.4.4 Resize Text** requires text to be resizable to 200 percent without loss of content or functionality. An element that survives translation growth usually survives these too, because both demand the same thing: text that can take more space. ## Making it a library habit - **Examples with long strings** in the workshop for every text-bearing element. - **A design review question**: what happens when this label is twice as long? - **Element specs that state** which text may truncate and how the full text is revealed. The principle is that length is data, not design: an element that only works at the English length is an element with a bug waiting for its first translation.
- Why is middle truncation sometimes better than truncating the end?When the distinguishing part of a string is at its end. Two bill file names that share a long prefix and differ only in the month look identical if the end is cut off. Middle truncation keeps the start and the end visible, so users can still tell the items apart; the full text should still be reachable.
- How should a tab bar in the library cope when translated tab labels no longer fit?It should not shrink or clip the labels. Common approaches are letting the tab row scroll with visible cues that more tabs exist, or collapsing the tabs that do not fit into an overflow menu. Which one the library offers is a design decision; what matters is that every label stays readable in full.
saying these in an interview costs you the question
- Fixed-width buttons keep the design consistent, so labels must fit them.
- Truncating the amount due is fine if the full amount appears elsewhere.
- Any ellipsis on overflowing text fails WCAG, whatever else is provided.
- Translations are about the same length, so layouts need no margin.
- A fixed card height is safe as long as the English text fits.