A Multilingual Web Application: What Localization Really Involves

The decision "let's do it in English too" sounds like a single line on a task list. In reality it is a change to the application's architecture that touches routing, the data model, the build, SEO, design, and the marketing team's day-to-day process. Companies usually discover this only once the first language is finished and the second is supposed to be "just added on".

This article describes what a multilingual web application actually involves — not in euros, but in decisions that have to be made before launch, and in recurring costs that never end after it. The goal is not to talk you out of a second language. The goal is that you go into it with a realistic picture.

When a company pictures localization, it pictures a spreadsheet with two columns: the source text on the left, the translation on the right. That spreadsheet is genuinely the smaller part of the work. Most of the effort is the infrastructure around it.

The full scope typically includes:

• routing and URL structure for every language, including 404s and redirects,
• SEO signals: hreflang, canonical, per-language sitemaps, structured data, Open Graph,
• extracting all text out of the code into translation files — including transactional emails, PDF and invoice templates, validation messages, error states, empty states, and notification copy,
• formatting of dates, numbers, currencies, units, addresses, and phone numbers,
• pluralization and inflection,
• a design and component set that survives significantly longer text,
• a content model in the CMS that can hold one article in three versions with its own slugs and its own publication state,
• a process that ensures that when the homepage copy changes tomorrow, it changes in every language.

The last point is the one companies underestimate most. Translation is a one-off budget line. Synchronization is a permanent operating cost that belongs in the same category as software maintenance and development after launch.

Localization is not a feature you ship. It is a property of the system you maintain.

The chart below shows qualitatively how the effort tends to be distributed. It is an illustrative example meant to explain proportions, not measured data from a specific project — every project lands differently.

The first thing to decide is where the languages live. There are four common options and each has a different profile.

For the vast majority of projects the right answer is the subdirectory. More important — and more often overlooked — is the second question: are the slugs translated too?

Translated slugs versus one path for every language

You have two options:

• One path for every language: /sk/produkty, /en/produkty, /cz/produkty. Simple to implement, one source of truth for routing, easy to maintain. The price is weaker relevance in foreign-language search and a URL that means nothing to an English-speaking visitor.
• Translated slugs: /sk/produkty, /en/products, /cz/produkty. Better for SEO and for how trustworthy the link looks, but routing needs a slug ↔ language mapping, the CMS has to store the slug per language, and editors have to understand that changing a slug means a redirect.

The decision has to be made before launch, not after. If you switch from one strategy to the other a year in, this is not a routing refactor — it is a mass URL migration: a mapping table for every page, permanent 301 redirects, updated sitemaps, internal links, campaign URLs, QR codes in printed material, and backlinks you do not control. Search engines handle redirects, but the recalculation takes weeks and you see a dip in organic traffic in the meantime. The framework helps here — Next.js with custom routing for corporate sites handles translated paths elegantly — but nobody will save you from the decision itself.

hreflang tells a search engine that three URLs are language variants of the same page, and which one to show to whom. canonical tells it which URL is the authoritative version of that content. When these two signals contradict each other, the result is not "slightly worse SEO" — it is an incorrectly indexed page.

The most common mistakes we see in audits:

• `canonical` points from the English version to the source version. A classic when a template is copied. The search engine is told the English page is a duplicate and stops indexing it.
• Non-reciprocal `hreflang`. If the SK version points to EN but EN does not point back to SK, the whole pair can be ignored. The relationships must be bidirectional and must include self-references.
• Missing `x-default`. Without it you have not defined what a visitor whose language you do not cover receives.
• Wrong language and region codes. en-UK does not exist; the correct code is en-GB. cs is Czech, not cz.
• `hreflang` pointing at pages that return 404 or are `noindex`. The signal points nowhere.
• Translating content without translating metadata. Titles, descriptions, alt text, and structured data stay in the source language and the page cannot show up meaningfully in foreign-language search.

Put these checks into QA before every deployment, not into a one-off audit after launch.

This is the part that English-authored code almost always gets wrong — and Slovak and Czech are among the languages that expose the mistake immediately.

String concatenation does not work

The typical pattern that emerges in an English-language environment:

"Found " + count + " results"

English needs two forms. Slovak needs four: 0 výsledkov, 1 výsledok, 2 – 4 výsledky, 5 and more výsledkov. And that is just the numeral. Concatenation like "Add to " + folderName fails even harder, because Slovak requires a grammatical case: Pridať do priečinka, not Pridať do priečinok.

The practical rule: a translation key holds a whole sentence, not its fragments, and pluralization is handled by a format that knows more than two categories (ICU MessageFormat is the de facto standard today). If you see translated pieces joined with a + operator in the code, that is a bug that only surfaces in a language the developer never reads.

Dates, numbers, currencies, and time zones

• Numbers: 1 234,56 in Slovak, 1,234.56 in English. Format by hand and you break one or the other.
• Currencies: symbol position and spacing differ (1 234,56 € versus €1,234.56). Handle separately the question of whether you show one currency to everyone or convert — conversion means exchange rates, rounding, and tax logic, which is a project of its own.
• Dates: 5. 8. 2026 versus 8/5/2026 versus 2026-08-05. Never format a date with a string template.
• Time zones: if the application shows event times, language and time zone are two independent settings. A Slovak living in Canada wants Slovak copy and Canadian time.

The solution is to use the standard Intl API in the browser or its backend equivalent, and never to format manually.

A button that just fits Save breaks on the German Speichern and the French Enregistrer. The same happens to navigation items, form labels, table headers, and anything with a fixed width.

What to do about it:

• Test the layout with the longest realistic translation, not the shortest.
• Avoid fixed widths on elements that carry text; let them grow.
• Plan for a two-line variant of buttons and menu items.
• With right-to-left languages (Arabic, Hebrew) it is not just text alignment — the whole layout mirrors: navigation, directional icons, progress indicators, tables. If RTL is not on the roadmap, do not prepare for it "just in case"; if it is, say so at the start, because it changes the component library.

This is one of the reasons localization stretches the QA phase — and one of the factors that feed into what affects how long a web application takes to build.

The technical part can be finished. The process part cannot — it keeps running.

Decide three things and write them down:

1. Who owns each language. A specific person, not a department. Without a named owner, the second language drifts away from the first within a year.
2. Where the translations live. Translation keys in the repository (for UI) and editorial content in the CMS are two different flows with two different approval paths. If marketing owns the content, the choice between a headless and a traditional CMS directly determines how comfortable their workflow will be.
3. What happens when the source text changes. Changing the source sentence must mark the other languages as stale. If that does not happen automatically, it happens at random.

Fallback for missing translations

Missing translations will always occur. The only question is how the application behaves.

The recommendation for most corporate sites: fall back to the source language in production, fail hard in CI, and produce a missing-key report that somebody actually reads.

The most important sentence in this article: a second language does not double the work once, it doubles the work on every future change.

A new page means a new page times the number of languages. A pricing change, a new feature in the application, a new onboarding email, an edit to a legal text — always times the number of languages. On top of that comes QA in every language and the overhead of the translation flow.

Practical consequences:

• Do not introduce a language you have no business case and no maintenance budget for. A neglected language does more damage than a missing one.
• Consider partial localization: full localization of the product and marketing pages, but the blog and documentation in one language only, clearly labelled.
• If you plan more than three languages, a translation platform wired into the repository and the CMS pays off. With two languages it is needless overhead.
• Account for localization in capacity planning the same way you account for the application's growth — it is a permanent load, not a milestone.

A multilingual web application is not a translation of text. It is a set of architectural decisions — URL strategy, language signals for search engines, formatting and pluralization, design flexibility — plus an operating process that keeps the languages in sync long after launch.

Make three decisions before the first line of code: where the languages live in the URL, whether slugs are translated, and who the named owner of each language is. Everything else can be tuned later. Those three cannot.

At INTERFASE we design multilingual web applications so that routing, SEO signals, and the translation flow rest on one model from the start — adding a third language is then not a new project. If you are weighing up a second language and want to walk through the consequences first, get in touch and we will go through the brief before the decisions are locked into code.