What running the site in several languages adds to a redesign

A site in six languages that was designed for six languages costs about the same to design as a site in one. A site in two languages where the second one arrived after the designs were approved costs a redesign of every component the longer text broke.

The reason is simple. Designing for text expansion is a constraint, like designing for mobile. Constraints are free when they are in the room at the start. They are expensive when they arrive as a correction, because a correction means redrawing work that was already approved and paid for.

So when you read a proposal, the question is not how much extra the languages cost. It is whether the studio knew about them before it drew anything. Ask which of the four buckets below each line item falls into.

These are decisions someone makes on every project anyway. The only question is whether the second language was mentioned when they made them.

German and Finnish compound words run roughly thirty percent longer than English on short strings, and worse on single words. That figure is approximate, and nav items and buttons are where it bites, because those are the elements people pin to a fixed width. A button that fits “Get started” and nothing more is not a multilingual problem. It is a button that was measured against one string.

• Components that grow with their content instead of being locked to the width of the English string.
• Nav items and buttons sized with headroom for text around a third longer.
• No text baked into images, so a translated page does not need a new export from the designer.
• A type scale and line length that still read well when the words are longer.
• Logical spacing and layout properties, so text direction can flip to right-to-left later without rewriting the stylesheet.

This is real engineering, and a quote that does not mention it has either absorbed it silently or is going to discover it later. Cost here scales with the number of locale-aware systems you need, not with the number of languages. Going from two languages to five is cheap. Adding currency formatting and locale-aware form validation to a site that had neither is not.

Language switching is the item people underestimate. Switching from the German pricing page should land you on the English pricing page, not the English homepage. Doing that properly means every page knows its equivalents in every other locale, which is a content model decision as much as a code one.

URL structure and hreflang tags belong here too. They are a day of work, done once, and worth doing so search engines serve the right market the right page.

Right-to-left support is the one item that is genuinely a separate build. If Arabic or Hebrew is on the list, say so in the brief. Mirroring layout, icons and directional spacing is a real chunk of work, not a setting.

• Language switching that keeps the user on the same page.
• URL structure per locale, plus hreflang.
• Locale-aware dates, currency, addresses, phone formats and form validation.
• Fallback rules for when a page does not exist in a market yet.
• Right-to-left layout, if any market needs it.

Every new page you publish becomes five pages if you run five markets. That is the real bill, and it lands on your team every month after launch, not on the studio once.

The failure we see is not bad translation. It is unmaintained translation. A market site launches complete, then the English pages get updated three times over eighteen months and the Spanish ones do not. Now a stale page with last year’s pricing is the one ranking in that market, and nobody noticed because nobody on the team reads Spanish.

So before you agree to a market site, name the person who will review its copy every quarter. If you cannot name them, that market should not get its own site.

This is the difference between a free constraint and a rebuild. Adding a language after designs are signed off means clipped buttons, nav that wraps onto two lines, a hero that no longer fits its headline, and a fresh round of approvals on work everyone thought was finished.

Underneath that, the CMS usually has to be remodelled. A content model built for one locale stores one title per page. Making it store one title per locale, with fallbacks and a translation status per field, touches every collection.

None of this is anyone behaving badly. It is the cost of the language question being asked at build instead of at brief. Put it in the brief and it costs you a sentence.

Three things get sold as multilingual support and are not worth your money.

An auto-translate widget or a browser-based translation overlay is not a multilingual site. Search engines cannot index what it produces, nobody on your team can review it before a customer sees it, and in regulated or legal copy it is a liability. If a proposal lists one of these as the multilingual solution, that is the whole answer you need about the proposal.

A full enterprise translation management integration on a site with four pages per market is tooling for a problem you do not have. A shared document and a human reviewer per market handles that volume. Revisit when a market has fifty pages and a weekly publishing rhythm.

Duplicating the entire site into every market is the most common overspend. Usually the pricing page, the contact details and two product pages actually differ. The rest is the same content in a different language, and some of it does not need translating at all.

If a market only needs to be reachable and credible, give it one properly translated page and a contact route. Keep the rest in English. Buyers usually overestimate how much their audience wants a fully mirrored site, especially in markets where the buying committee reads English at work every day.

This is the part that costs us money to say. A studio is paid more for building six full market sites than for talking a client down to one site plus two market pages, and the smaller build is usually the better outcome, because it is the one that still looks maintained two years later.

Concretely: a marketing site redesign with five or more pages sits in the same tier whether it serves one market or four, so the design cost does not move. What moves is your own team’s workload forever after.

Ask these of every proposal you are comparing. The answers separate studios that have built multilingual sites from studios that will learn on yours.

1. Are components sized for text expansion, and can I see one rendered with the longest language on my list in it?
2. When someone switches language on a deep page, what happens to the URL and where do they land?
3. Which locale-aware behaviours are in scope: dates, currency, forms, search?
4. Who updates market pages after launch, and what does the site show when one is missing?

Open your current site, open browser dev tools, and paste the German or Finnish translation of your longest nav item and your main call to action over the English text.

Watch what breaks. Nav wrapping to a second line, a button with its label clipped, a hero headline pushing the image off the fold. Each break is a component that was measured against English, and each one is a line item somebody will have to pay for later.

Do this before you send the brief, not after. Then write what you saw into the brief itself. That sentence is the difference between multilingual costing you nothing and multilingual costing you a rebuild.