Our own website exists in three languages: English, Russian and Ukrainian. Not as an afterthought, not as a machine-translated layer bolted onto an English original, but as three versions we actually think about separately when we design anything new.
Most agencies treat multi-language websites the way they treat mobile responsiveness: a checkbox, a plugin, a switcher in the header. Ship the design, translate the strings, ship the translation.
That process works fine for a landing page selling one product to one market.
It falls apart the moment the languages aren't just different vocabularies for the same audience, but different audiences with different expectations, different reading habits and different relationships to the brand.
A multi-language website isn't one design translated three times.
It is a digital system designed to work across different languages, audiences, markets and ongoing content operations.
Text Length Breaks Layouts
Text Length Breaks Layouts
The first problem is the most mechanical, and the one most designs never account for.
The same sentence in English, Russian and Ukrainian is rarely the same length. German famously runs long. Russian and Ukrainian typically run 15 to 25% longer than English for the same meaning. Chinese can often be significantly more compact.
A button labeled "Book a Call" fits comfortably in English.
The Russian equivalent, "Записаться на звонок," is nearly twice the character count.
A navigation item that sits cleanly on one line in English can wrap to two lines in Russian and break the entire header's vertical rhythm.
Design a layout in English first and every other language becomes a patch job.
Buttons that were sized for English text start clipping. Navigation bars built for short labels start wrapping unpredictably.
The fix isn't a bigger font-size fallback. It's designing components with enough flexible space from the start that a significant length increase doesn't break anything, and testing every component against the longest language, not the shortest.
Typography Isn't Universal
Typography Isn't Universal
A typeface chosen for how it looks in English doesn't necessarily hold up in Cyrillic.
Some fonts have beautifully designed Latin characters and a barely-supported Cyrillic set added almost as an afterthought: uneven stroke weights, awkward letterforms, spacing never tested by someone who reads Cyrillic daily.
The same goes the other direction.
A typeface with gorgeous Cyrillic support might have a forgettable Latin alphabet.
Choosing type for a multi-language site means checking every script with equal scrutiny, not picking a font for the primary language and hoping the rest inherits its quality.
Line height, letter spacing and even punctuation conventions shift too.
Russian and Ukrainian typography have their own quotation mark conventions, their own rules for em dashes in dialogue, and their own comfortable line lengths for reading.
Importing English typographic defaults wholesale produces text that looks technically correct and reads slightly foreign to a native speaker.
Some Languages Change the Interface
Some Languages Change the Interface
English, Russian and Ukrainian can often share the same basic interface, even when typography and text length differ.
That assumption becomes much weaker when the writing system changes.
Arabic introduces right-to-left reading and interface direction.
Navigation, alignment, icons and the visual flow of a page may need to be reconsidered rather than simply translated.
Chinese creates a different set of considerations.
Text can be significantly more compact, typography behaves differently, and depending on the market and product, navigation, search, information hierarchy and interaction patterns may need to be reconsidered as well.
These are not simply translation problems.
Sometimes changing the language means changing the interface.
A multilingual design system therefore needs enough flexibility to accommodate different scripts and interaction patterns from the beginning.
Translation Isn't Transcreation
Translation Isn't Transcreation
The deepest problem isn't visual. It's that a literal translation of good English copy is rarely good copy in the target language.
English marketing writing leans on short, punchy sentence fragments, direct address and a certain rhythm that comes from the language itself.
Translate that rhythm word-for-word into Russian and it can read stiff, or worse, like it was written by someone who doesn't actually speak the language.
A translated and a transcreated sentence can say the same thing and land differently.
Transcreation means rewriting the idea in the target language's own natural rhythm, not moving words across a language boundary.
A headline that works because of English wordplay may need an entirely different headline in Russian, built around Russian wordplay rather than a translated version of the English joke that no longer lands.
This is where most agencies cut corners, because transcreation takes real fluency and real time, and a translation API doesn't.
The difference shows up immediately to a native speaker, even if it's invisible to whoever approved the draft.
AI Translates, Not Finishes
AI Translates, Not Finishes
AI has changed the economics of multilingual content.
A first translation that once took hours can now be generated in minutes.
For large websites, this makes the initial localization process dramatically faster and more practical, especially when hundreds or thousands of pages are involved.
But generated translation is not the same thing as finished content.
AI can translate the words correctly while still missing the way people in a particular market actually speak, search, compare products or understand a brand.
A service page may be grammatically perfect and still sound unnatural. A product description may preserve the meaning while losing the emotional tone.
And a luxury brand can lose much of its character if every language is treated as a literal translation of the same sentence.
The better workflow is closer to:
Create → AI Translate → Review → Adapt → Transcreate where necessary → Publish
AI is extremely useful for the first pass.
It can handle volume, consistency and repetitive work remarkably well.
But the final question should not be: "Did the AI translate this correctly?"
It should be: "Would someone who actually speaks this language and understands this market have written it this way?"
Not every piece of content needs transcreation.
A technical specification may only require accurate translation. A campaign headline or luxury brand message may need full transcreation.
AI should reduce the cost of localization.
It should not reduce the quality standard.
Formality and Culture Shift
Formality and Culture Shift
English has largely flattened the formal-informal distinction.
"You" works whether you're addressing a stranger, a client or a close friend.
Russian and Ukrainian haven't flattened that distinction at all.
Choosing between ты and вы, ти and ви isn't a translation detail.
It's a brand decision that changes how the entire site feels.
A B2B site targeting enterprise procurement teams probably wants the formal вы throughout, while a youth-oriented consumer brand might deliberately choose the informal ты.
Get this wrong and the mismatch is felt immediately by a native reader, even if they can't always articulate why the copy feels off.
English gives no signal about which choice to make because English doesn't have the choice to begin with.
This has to be a deliberate decision made once, early, and then applied consistently across every page, every button and every error message.
Imagery, metaphors and cultural references that land perfectly for an American or Western European audience sometimes land strangely, or not at all, for a different market.
A metaphor built around a culturally specific holiday, sport or historical reference needs an actual equivalent, not a literal translation of a reference nobody in the target market will recognize.
The same applies to visual content.
Photography, people, locations, examples, trust signals and even the order in which information is presented can have different meanings in different markets.
What counts as convincing social proof, acceptable directness in sales copy, or a trustworthy product all vary by market.
A global design system should therefore not mean identical content everywhere.
It should provide a consistent framework while leaving enough room for each market to feel native.
A Multilingual Content Operation
A Multilingual Content Operation
Launching another language doesn't end when the translation is uploaded.
From that point on, every language becomes another version of the website that needs to be maintained.
A new service page has to be created in every relevant language.
A new case study needs to be published and localized.
Products, prices, images and captions change. New articles get published.
Old information needs to be updated or removed.
And sometimes the content itself needs to be adapted rather than translated.
This means a multilingual website creates an ongoing operational requirement: someone has to own every language.
The business needs to know:
- who creates the original content
- who translates or adapts it
- who reviews it
- who publishes it
- who keeps versions synchronized
- who updates outdated information
- and what happens when one language intentionally has different content from another
Otherwise, the English version might have 50 articles, the second language 32 and the third 11, the newest case study existing in only one language.
Technically, all three languages are available.
Operationally, the website is telling visitors three different versions of the company's story.
A language switcher creates an expectation. The business has to be prepared to maintain what it promises behind that switcher.
For larger websites, multilingual content becomes a workflow of its own: Create → Translate → Review → Publish → Update → Archive
And that workflow needs to work across pages, services, products, case studies, blog content and other content types.
A multilingual website is therefore not only a UX/UI problem.
It is also a content management, governance and operational problem.
Multilingual SEO Isn't Translation
Multilingual SEO Isn't Translation
The language of a website also changes how people find it.
A translated page does not automatically create a localized search presence.
Different markets can use different terminology for the same product or service.
Search intent can change.
Keywords can change.
The pages that deserve to exist can change.
Even internal linking and content hierarchy may need to be reconsidered.
Then there is the technical layer: localized URLs, metadata, structured data, language signals and hreflang implementation all need to work together.
A page can therefore be perfectly translated and still perform poorly in another market because it was never actually localized for search.
This is another reason multilingual design and content strategy cannot be separated completely from SEO.
You aren't simply publishing the same information in another language, you're creating another entry point into the business.
The Cost Beyond Development
The Cost Beyond Development
The cost of a multilingual website is not only the cost of designing and developing additional language versions.
It is also the cost of building and maintaining things the business may not actually need.
Adding another language means more content to create, translate and maintain, more pages to design, more SEO work and more ongoing editorial effort.
That is why the right question isn't: "How many languages can we add?"
It's: "Which languages does the business actually need?"
A company may discover one market generates almost all its demand, while another language adds little commercial value but creates hundreds of pages and an ongoing maintenance burden.
The same applies to localization depth.
Not every page needs to exist in every language, and not every piece of content needs translating immediately or with the same depth.
The goal is not to maximize the number of languages.
The goal is to allocate the business's time and resources where they can create the most value.
Otherwise, a multilingual website can become an impressive collection of perfectly translated pages that nobody actually needs.
Build It In, Not On
Build It In, Not On
The practical answer is to treat multi-language support as a design system requirement from the first sketch, not a localization pass at the end.
Every component gets stress-tested against the longest language in the set before it's approved.
Every typeface gets checked in every script the site will actually use.
Every piece of copy gets written, not simply translated, by someone who thinks natively in that language.
The CMS needs to support the content workflow.
The technical architecture needs to support the language structure.
The SEO architecture needs to support localized search.
And the business needs to be prepared to maintain the languages it chooses to launch.
That's a slower, more expensive process than translating a finished English site.
It's also the only process that produces a site that feels native in every language it's published in, rather than a site that feels native in one language and adequately translated in the others.
We went through exactly this process building our own website in English, Russian and Ukrainian, and it shaped decisions we wouldn't have made designing for one language alone: how navigation labels are sized, how buttons handle variable text length, how formality stays consistent.
It also reinforced something we see repeatedly with international projects: localization is not something that happens after design.
It is one of the constraints that should shape the design in the first place.
It doesn't necessarily have the same number of pages, the same copy or identical imagery in every language, and it doesn't necessarily require the same interface for every market.
What should remain consistent is the underlying system:
the brand, the quality standard, the core experience and the logic that holds everything together.
Everything else should have enough flexibility to respond to the language, market and audience it serves.
Because the objective isn't to make a website that is technically available in ten languages.
The objective is to make a website that actually works in the markets the business cares about.
A multilingual website isn't one interface with different words. It is a system designed for different languages, audiences and realities.
If you're building or redesigning a website for more than one language market, the important questions should be answered before translation begins.
Which languages actually matter to the business? What needs to change in the design system? Which content needs translation, adaptation or transcreation? How will AI be used, and where does human review remain necessary? What does the underlying architecture need to support all of it?
We wrote more about choosing the right development partner in How to Choose a Web Development Company, and about the technical debt that surfaces during redesigns in The Hidden Technical Debt That Makes Website Redesigns More Expensive Than Planned.
A Strategic Session can help answer those questions before they become expensive implementation decisions.
- Share
-
-
-
-
