How Do You Design a Page That Works in Five Languages?

How do you design a page that works in five languages?

Design for the longest version, not the English one. Most multilingual layouts break because every button, label and heading was sized to fit English, and translation makes text longer. Leave room, avoid text in images, and never hard-code a width around a word.

We get handed this problem late, usually after a design is approved and someone asks how the German version will look. By then the fixes are expensive, because the constraint was baked into the layout.

Here is what the published research says about expansion, which parts break first, and what Google needs technically.

How much does text actually grow when translated?

A lot more than designers expect, and most at the short end. The W3C's internationalisation article on text size shows the word "views" from Flickr across languages as a ratio against English at 1: Korean 0.8, Chinese 1.2, Portuguese and French both 2.6, German 2.8, and Italian 3.

The same article reproduces IBM's published expansion guidance for English into European languages, measured by source length. Strings up to 10 characters expand by 200 to 300 percent. Strings of 11 to 20 characters expand 180 to 200 percent. By the time a string is over 70 characters, average expansion is around 130 percent.

The principle is stated plainly there: the smaller the source message, the higher the likely translation length. Your body copy is fine. Your three-word button is the problem.

Which parts of a design break first?

Navigation, buttons, tabs, form labels and stat blocks. Anything where a short English phrase sits inside a fixed box. A five-item horizontal nav that just fits in English will wrap, overflow or shrink into unreadable text in German or Italian.

Card grids are the second casualty. Three cards with matching heights look designed until one language pushes one heading to two lines and the row goes ragged.

Then come the small proud details: a number with a label under it, a pill badge, a tooltip. These are usually the tightest boxes in the design and the highest expansion strings in the product.

How do you design buttons and navigation for this?

Let them size to content and give them somewhere to go. Buttons should grow with the label rather than clip it, navigation should have a defined behaviour when the row no longer fits, and nothing should rely on a specific character count to stay on one line.

A practical trick we use in design review: write the longest plausible translation into the mockup before sign-off. Pick the language you know expands most and paste real translated strings, not lorem ipsum.

Also reconsider the horizontal nav itself. Sites that will ship in five languages are often better served by fewer top-level items, because every extra item multiplies the expansion risk across every locale.

What do you do about images with text in them?

Stop making them, as a rule. Text baked into an image cannot be translated without a designer opening the source file, which in practice means it never gets translated at all, which means at least one locale ships with English words sitting in the middle of an otherwise translated page.

Put the words in HTML over the image instead. It translates automatically with the rest of the page, it is readable by screen readers, and it is searchable.

Where an image genuinely must carry text, plan the production cost per locale up front. Five languages means five exports every time the copy changes, and copy always changes.

How should the language switcher work?

Visible, honest and never automatic. Show each language name written in that language rather than a flag, because flags describe countries and languages are not countries. Keep the switcher in the header, where people already look for it, rather than hiding it in the footer.

Do not silently redirect based on location. Somebody in Germany may want the English page, and a forced redirect makes your site feel broken in a way that is hard to diagnose.

Preserve the page when switching. Sending a reader from a specific product page to the homepage of another language is the most common implementation bug we see, and it wastes the intent that made them switch. Our notes on Webflow localization cover how the switcher behaves there.

What does Google need to see technically?

Reciprocal hreflang annotations, done one of three documented ways. Google's guidance on localized versions, last updated 22 December 2025, lists HTML link tags, HTTP Link headers, and XML sitemap entries as equivalent options. Pick one method and use it consistently.

Two rules cause most failures. Each language version must list itself as well as all other language versions. And if two pages do not both point to each other, the tags will be ignored.

Use the right code standards: ISO 639-1 for language, ISO 3166-1 Alpha 2 for region, combined as language-region like en-GB. Google notes you cannot specify a country code by itself. Our hreflang guide goes through the markup in detail.

What is x-default for?

The page for everyone you did not plan for. Google's documentation describes the reserved x-default value for pages not targeted at a specific language, including language selector pages. It is the fallback when a visitor's language matches none of your versions.

Most five-language sites should have one. Without it, a visitor whose browser is set to a language you do not publish gets whichever version the search engine guesses.

Google also lists the mistakes it sees: missing reciprocal links, language codes that do not follow ISO 639-1, and region codes using reserved values such as EU, UN or UK. That last one catches teams out constantly, because UK feels correct and GB is what the standard uses.

What about right to left languages?

Treat them as a layout decision rather than a translation task. If Arabic or Hebrew is in scope, the whole interface mirrors: reading order, text alignment, icon direction, progress indicators, table column order, and the side of the screen your navigation sits on.

That is much easier if the design avoids hard-coded left and right in its spacing and alignment rules from the start. Retrofitting a mirrored layout onto a design built around left alignment is a rebuild of the stylesheet.

Some things do not mirror, like clocks, media playback controls and most numerals. Decide those case by case with someone who reads the language, rather than flipping everything and hoping.

How do you test before launch?

Put real translated strings into the real layout, on a phone, in every locale you plan to ship. Not a spreadsheet of translations, and not the English page with a language switcher wired up to it. The bugs that matter live in the rendered page at small widths.

Check five things per locale: nothing clipped, nothing overlapping, no English left behind, the switcher keeps the page, and the fonts render every character. Missing glyphs are the failure that looks most like carelessness.

Also read the page aloud with a native speaker if you can. Layout tests catch overflow, and only a reader catches the sentence that is technically translated and culturally wrong. Our piece on web typography and fonts covers the character coverage question.

What would we do first on a new multilingual build?

Choose the target languages before the design work starts, pick the one with the worst expansion, and design the key templates in that language first. Then make the English version fit the layout you built, instead of the other way round, which is how this normally goes wrong.

It feels backwards and it removes almost all of the pain later. Every other approach ends with a designer widening buttons two weeks before launch.

If you are planning a multilingual site and want help scoping it properly, we are happy to talk it through. You can see how we design and build at phoenix.studio.