Answer 15 of 50
Overcoming Design and Content Challenges in Multilingual Website Development
Three decisions address the problems that otherwise appear when translations arrive: size layouts for text expansion by string length, put text direction and language in the markup, and set up the translation workflow before the first page is translated. Skip them and you risk buttons that break, right-to-left pages that mirror the wrong things, the wrong glyphs for Japanese text, and translations that quietly go stale.
Why it is worth doing well
In a 2020 consumer survey by CSA Research, based on 8,709 consumers in 29 countries, 76% of online shoppers preferred to buy products with information in their native language, and 40% said they will not buy from websites in other languages. The figures come from CSA Research’s own survey, carried out with the survey firm Kantar; treat them as a starting point for deciding how far to go, not as a forecast for your market.
Text expansion depends on string length
A single average such as “German is 30% longer” breaks short labels. W3C’s article on text size in translation reproduces average expansion rates for European languages published by IBM:
| Characters in the English source | Average translated length |
|---|---|
| Up to 10 | 200% to 300% of the English |
| 11 to 20 | 180% to 200% |
| 21 to 30 | 160% to 180% |
| 31 to 50 | 140% to 160% |
| 51 to 70 | 151% to 170% |
| Over 70 | 130% |
The shortest strings, such as buttons, menu items, and form labels, grow the most. W3C’s summary: “the smaller the source message, the higher the likely translation length.” Fewer characters do not mean less width either; the same article notes that a Japanese translation with one less character “will typically take up much more horizontal space.”
What to do with that:
- Use flexible containers. Flexbox and grid layouts that let elements grow or wrap handle varying lengths better than fixed widths.
- Test with pseudolocalization early. Tools that lengthen English strings show where layouts break before real translations exist.
- Retest with real translations. Pseudolocalized text approximates length but not real word breaks.
- Truncate only as a last resort. If you must cut a label, make the full text available on keyboard focus as well as hover; WCAG 2.2 success criterion 1.4.13, Content on Hover or Focus, sets rules for content that appears that way.
Direction and language belong in the markup
Text direction is a property of the content, so declare it in HTML. W3C’s guidance on structural markup and right-to-left text says to add dir="rtl" to the html tag when the overall document direction is right-to-left, and is explicit about the alternative: “Never use CSS to apply the base direction.” CSS logical properties, such as margin-inline-start instead of margin-left, then follow the declared direction, so one stylesheet can serve both directions.
For embedded text whose direction you do not know in advance, such as a product name or a user name inside Arabic text, use the bdi element or dir="auto". MDN’s reference for the bdi element warns against doing the same thing with the CSS property unicode-bidi, “because it is not semantic and browsers are allowed to ignore CSS styling.”
Declare the language too, on every page and on every passage in another language, with the lang attribute. W3C’s article on why to use the language attribute explains that Simplified Chinese, Traditional Chinese, Japanese, and Korean text “may share the same code point for an ideographic character,” while readers of each language expect different glyph details, and that line-breaking and justification also depend on language.
What to mirror in right-to-left layouts
Mirroring is not all-or-nothing. The Wikimedia Codex bidirectionality guidelines give a practical split:
| Mirror | Do not mirror |
|---|---|
| Navigation and pagination order | Phone numbers, postal codes, URLs, and email addresses |
| Progress indicators that show steps | Elements that represent time, such as a video player's timeline |
| Directional icons such as next and back arrows | Icons containing check marks, and icons with no clear direction |
| The overall page layout | Charts where mirroring could change how data is read, and currency symbols |
Images and illustrations keep their original orientation, with captions aligned to the reading direction. Numbers always run left to right: the guidelines say “Always use LTR for numbers in Western Arabic (123) or Eastern Arabic (١٢٣).” Test every right-to-left page with native readers, because automated mirroring cannot tell which elements carry meaning in their direction.
Fonts: coverage drives cost
Font needs follow writing systems, not the number of languages. One Latin font can serve English, French, Spanish, and German; adding Russian needs Cyrillic, Japanese needs very large character sets, and Arabic needs fonts built for connected right-to-left script. Check which scripts each font license covers before counting licenses. Open-source families can help: Google describes its Noto collection as covering “more than 1,000 languages and over 150 writing systems.” Choose fonts for all your scripts together, because a carefully chosen Latin font beside a system default for Japanese looks inconsistent.
Dates, numbers, and currency
Local formats differ in ways that cause real errors. MDN’s documentation for JavaScript’s built-in formatters shows the differences: the same date appears as “12/19/2012” in US English, “19/12/2012” in British English, and “2012. 12. 19.” in Korean (Intl.DateTimeFormat), and the number 123,456.789 formatted as euros in German appears as “123.456,79 €” (Intl.NumberFormat). Use the platform’s locale-aware formatting rather than hand-building strings, and design address forms that accept the field order of each country you serve.
Content workflow
Managing content in a dozen languages needs a system, not a spreadsheet:
- Translation status: which pages are translated, in progress, or outdated because the source changed.
- Version synchronization: when the source page changes, every translation is flagged for review.
- Routing: who translates, who reviews, and who answers translators’ questions about the source.
- A content model that links translations to their source item rather than treating each one as an unrelated page; defining content types and relationships before building is covered in modeling content for a headless CMS.
- Translation memory, which reuses previously translated phrases so repeated text is not translated twice.
Machine translation with human post-editing can work for some content types; brand voice, marketing copy, and legal text call for human translation or careful review. Quality can vary by language pair, so judge each pair with native reviewers.
Cultural adaptation
Translation changes words; localization also changes examples, imagery, holidays, humor, and idioms that do not travel. Writing source content without idioms and culture-bound jokes can make localization cheaper. Visual decisions about color, symbols, and imagery are covered in how cultural differences influence color, symbol, and layout choices.
Language switcher design
- Name languages in their own language. W3C’s guidance on language and country selectors says a link to a French translation should read français rather than French, and a link to a German country site Deutschland rather than Germany.
- Avoid flags for languages. A flag stands for a country, while English and Spanish, for example, are spoken in many countries.
- Place it where people look, in the header, the footer, or both. How the footer can hold language and region selectors is covered in how footer design contributes to site usability.
- Remember the choice, and do not force a language based on location. Google’s guide to managing multi-regional and multilingual sites advises: “Avoid automatically redirecting users from one language version of a site to a different language version of a site.”
Hreflang and URL structure
Hreflang annotations help Google serve the right language or regional URL; they do not guarantee rankings. Google’s documentation on localized versions sets two rules that catch teams out: “Each language version must list itself as well as all other language versions”, and “If two pages don’t both point to each other, the tags will be ignored.” Add an x-default entry as a fallback for users whose language matches none of your versions.
Google compares URL structures this way:
| Structure | Example | Pros | Cons |
|---|---|---|---|
| Country-specific domain | example.de | Clear geotargeting; easy separation of sites | Expensive; more infrastructure; can only target a single country |
| Subdomain | de.example.com | Easy to set up; allows different server locations | Users may not recognize geotargeting from the URL alone |
| Subdirectory | example.com/de/ | Easy to set up; low maintenance on the same host | Users may not recognize geotargeting from the URL alone; harder to separate |
For similar content in the same language on different regional URLs, Google advises picking a preferred version and using the canonical element together with hreflang tags.
Testing across languages
Every form, flow, and interaction needs testing in every language: long text, encoding, and character sets can break functionality, not just layout. Screenshot comparisons catch overflow and rendering problems. Native speakers check that translations read naturally, and local reviewers catch content that is acceptable in one culture and inappropriate in another.
Questions teams ask
Does all content need to be in all languages?
No. Translate core pages and high-traffic content fully, consider fewer languages or reviewed machine translation for secondary content, and tell users clearly when a page is not available in their language, with a link to the closest alternative.
Our team doesn’t speak some of our target languages. How do we control translation quality?
Work with native speakers, in-house, through an agency, or freelance. Automated checks catch missing strings and broken formatting, but linguistic quality needs human review; budget for it at least on important pages.
Our CMS handles multiple languages badly. Rebuild or work around it?
For two or three languages, workarounds may be enough. For many languages, compare the ongoing cost of workarounds, including missed updates and manual syncing, with the cost of moving to a CMS that models translations properly.
Should we launch all languages at once or roll out gradually?
A gradual rollout lets you fix process problems on a few high-priority languages before they multiply across all of them. A simultaneous launch makes sense when markets must open on the same date, provided the workflow and testing are ready for every language.
Size components for the expansion of their shortest strings, declare direction and language in HTML, mirror only what carries direction, format dates and numbers with locale-aware tools, wire up hreflang in both directions, and build the translation workflow before the first page goes out.