By Mehdi HassanHow do you design a website layout that works in multiple languages?
You design a layout that works in multiple languages by treating text length, reading direction and script as variables instead of constants. Every component is designed to stretch, wrap and mirror, then tested with real copy in your hardest languages before anything ships.
Most multilingual layout problems are created in the first week of design, when a designer sets a headline in short English and sizes everything around it. The fixes later are patches per locale, and they pile up. This guide is the design side of our multilingual website guide: what to change in Figma and in components so languages become a content task rather than a redesign.
Challenge | Languages most affected | Design response |
|---|---|---|
Text expansion | German, Finnish, French, Russian | Flexible containers, wrapping buttons, no fixed heights |
Long compound words | German, Dutch, Finnish | Hyphenation rules, wider minimum widths, careful heading sizes |
Right-to-left reading | Arabic, Hebrew, Persian, Urdu | Logical properties, mirrored layouts, direction-aware icons |
Dense scripts | Chinese, Japanese, Korean | Adjusted line height and type size, no reliance on italics |
Script coverage | Any non-Latin language | Fonts with full glyph support and planned fallbacks |
Formats | All | Locale-aware dates, numbers, currency, addresses and phone fields |
How should you design for text expansion?
Design for text expansion by assuming every string can get noticeably longer and every component has to survive it. German and Finnish are the usual stress tests, because long compound words can't wrap mid-word the way a sentence can, and translated sentences often run longer than the English original.
- No fixed heights. Buttons, cards, tabs and hero blocks should grow with their content. Fixed heights are where overflow and clipped text come from.
- Buttons that wrap or widen. Decide what a button does with a long label: grow wider up to a limit, then wrap to two lines. Never truncate a call to action.
- Navigation with room. A horizontal nav that just fits five English words will overflow in German. Leave spare width, or plan the point where it collapses into a menu.
- Headings with fallbacks. Very large display type and long compounds don't mix. Set a smaller size per breakpoint, and allow hyphenation in languages that support it.
- Equal-height grids. Card grids should handle one card with two extra lines without breaking the row.
What does RTL website design require?
RTL website design requires the whole layout to mirror for Arabic, Hebrew and other right-to-left languages: navigation, alignment, reading order, progress indicators and directional icons all flip. Done with the right CSS from the start, mirroring is mostly automatic; added later, it's a second stylesheet nobody wants to maintain.
Set the direction on the document
Each RTL page declares dir="rtl" on the html element along with its lang attribute. The browser then reverses text flow, table order and default alignment.
Build with logical properties
Use margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, and text-align: start instead of left. These follow the reading direction, so one stylesheet serves both.
Mirror directional icons only
Back and forward arrows, chevrons in carousels and breadcrumb separators flip. Logos, play and pause controls, checkmarks, and charts with a fixed time axis do not.
Handle mixed-direction text
Product names, numbers, code and URLs stay left-to-right inside RTL sentences. Test these spots, because punctuation can jump to the wrong side.
Review imagery
Photos with a strong left-to-right flow, screenshots of your English product, and illustrations with text may need RTL versions or replacements.
MDN's documentation on CSS logical properties and values is the reference we hand to developers new to this. In Tailwind, the equivalent utilities (ms-, me-, ps-, pe-, start-, end-) make the same approach easy to stick to.
How do you choose fonts for a multilingual website?
Choose fonts for a multilingual website by checking script coverage first and personality second. A beautiful display face that only covers Latin characters forces a fallback font in Greek, Cyrillic, Arabic or Japanese, and a mismatched fallback is where multilingual sites start to look cheap.
Check that your typefaces include every character for every planned language, including accented Latin characters for Central European languages. For non-Latin scripts, pair your brand font with a companion family designed for that script, matched for weight and size, rather than letting the browser pick. Chinese, Japanese and Korean fonts are large, so load them by subset and only on pages in those languages. Avoid relying on italics for emphasis, because many scripts have no italic tradition; use weight instead.
How do you build flexible components for localization?
Build flexible components by separating every piece of text from layout and letting each locale supply its own content, length and order. A component that hard-codes three logos, four features or an English-shaped headline can't adapt to a market that needs something different.
Pros
- Components driven by CMS fields let each locale reorder proof, swap examples and change list lengths
- Figma string variables with a mode per language let designers preview every locale in the same frame
- One component library serves every language, so fixes ship once
- Localized messaging needs no new design, only new content
Cons
- Flexible components take longer to design and test up front
- More states to QA: every component in every language and direction
- Designers need real or pseudo-localized copy early, not lorem ipsum
- Some layouts that look great in English have to be simplified
This matters most for proof and pricing, which almost always differ by market. Our comparison of localization vs translation explains why those sections change, and our guide to Next.js i18n shows how a CMS with locales feeds the components.
Hypothetical example: one hero section in English, German and Arabic
For example, suppose a hero has a two-line headline, a subhead, two buttons and a product screenshot on the right.
In German, the headline runs to three lines at desktop size and one compound word is too wide for mobile. The fix is a slightly smaller mobile heading size and hyphenation enabled for German, set once in the type scale. The secondary button label wraps, so the button group is allowed to stack.
In Arabic, the layout mirrors: text on the right, screenshot on the left, the arrow in the primary button pointing left. The screenshot is swapped for the Arabic version of the product. The product name stays in Latin script inside the Arabic headline, and the team checks that the punctuation lands on the correct side.
None of these changes needed a new component. They were rules in the system, applied by language.
What should you test before launching a multilingual design?
Test every template in every language and direction on real devices, with final translated copy, before launch. Screenshots of English layouts say nothing about how German or Arabic pages behave.
- Check every template at mobile, tablet and desktop widths in your longest language and in any RTL language.
- Confirm forms accept local formats for names, addresses, phone numbers and postcodes, and that validation messages are translated.
- Verify dates, numbers and currencies format per locale.
- Run accessibility checks per language: lang attributes, contrast on translated buttons, and focus order in RTL. Our guide to accessible web design covers the basics.
- Test the language switcher on every page, including pages that don't exist in every language.
What are the most common multilingual web design mistakes?
The most common multilingual design mistakes are designing only in English, baking text into images, using flags to mean languages, and building right-to-left support as an afterthought. Each one turns every new language into a design project.
The less obvious mistake is treating brand rules as English rules. A tagline set in a tight, all-caps display face may not survive translation at all. When we turn a brand identity into a website, we write the type rules so they hold for every planned language, not just the one the brand was designed in.
