Your button breaks in German: what CSS and API strategies fix it?

WHAT THIS TESTS: This question probes whether you treat copy as variable data rather than a fixed visual asset. Interviewers want to see that you understand internationalization is not a late-stage QA issue but a constraint that should shape component architecture, CSS strategy, and API design from the start. The best candidates demonstrate fluency in both layout mechanics and design-system governance.

A GOOD ANSWER COVERS: A strong response moves from CSS defenses to API controls. On the CSS side, mention intrinsic sizing so the button grows with content rather than fighting it, text-wrap balance or pretty to avoid typographic orphans, min-width to prevent collapse, and container queries to adapt layout when the button lives in narrow spaces. Discuss overflow handling such as ellipsis or fade truncation only as a last resort, because hiding text hurts accessibility. On the API side, propose props that let consumers choose behavior without overriding styles, such as a truncate boolean, a maxLength number that gates translation strings, an optional icon slot that can be hidden when space is tight, or a layout variant like stacked or icon-only. Mention design tokens for padding scales so localized buttons do not look cramped or disproportionate.

COMMON WRONG ANSWERS: A red flag is suggesting translators should just abbreviate German strings or use fixed pixel widths because the design mock uses English. Another mistake is proposing overflow hidden without ellipsis, which clips content unpredictably. Candidates who only talk about CSS and ignore the component API signal they think about styling in isolation rather than system design. Similarly, recommending JavaScript to measure text and resize buttons is usually over-engineered and prone to performance issues.

LIKELY FOLLOW-UPS: The interviewer might ask how you would handle a button inside a fixed-width card where the button cannot grow, or how you would test this without knowing every language. They may also probe accessibility, asking how truncation affects screen readers, or how you would handle right-to-left languages where icon placement and padding logic reverse.

ONE CONCRETE EXAMPLE: Imagine a primary action button with a leading icon and label. In English it reads Save and fits neatly. In German it becomes Speichern and may force the card wider. Your component API offers a layout prop with values inline, stacked, and iconOnly. At a small container size the button switches to iconOnly with an aria-label preserved. CSS sets min-width to the token space-12, uses text-wrap balance, and allows flex-wrap so the icon and label stack vertically when clamped. The translation pipeline caps strings at 24 characters when layout is inline, but allows longer copy for stacked mode. This keeps the UI intact without asking the localization team to rewrite grammar.