---
title: "A Multilingual Web Application: What Localization Really Involves"
description: "Translating the text is the smallest part of a multilingual application. The real cost sits in URL strategy, hreflang signals, inflection, formatting, and the process that keeps every language in sync two years later."
canonical: "https://interfase.sk/en/news/multilingual-web-application-what-localization-really-involves"
lang: "en"
last_updated: "2026-08-05"
---

# A Multilingual Web Application: What Localization Really Involves

> Translating the text is the smallest part of a multilingual application. The real cost sits in URL strategy, hreflang signals, inflection, formatting, and the process that keeps every language in sync two years later.

Published: 2026-08-05

- Translating the copy is usually a smaller part of the work than the routing, SEO signals, formatting, and maintenance process built around it.
- The URL strategy and slug translation must be decided before launch, because changing it later means mass redirects and a temporary drop in organic traffic.
- Building sentences from fragments breaks in inflected languages such as Slovak and Czech, so whole sentences belong in translation keys.
- Every additional language is a recurring cost on every future content change, not a one-off budget line.

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.

## Translation is the smallest part of the cost

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](/blog/udrzba-a-rozvoj-softveru-po-spusteni-co-vsetko-zahrna).

> 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.

:::chart bar Indicative share of effort (illustrative)
Translating copy, 15
Routing and SEO, 25
Code and formatting, 25
Design and QA, 20
Process and upkeep, 15
:::

## URL strategy: the decision you cannot cheaply undo

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

| Approach | Example | When it makes sense | Risks |
| --- | --- | --- | --- |
| Subdirectory | `company.com/en/products` | Most corporate sites and applications; one domain, one authority | A weaker geographic signal for search engines |
| Subdomain | `en.company.com` | When each market has its own team or its own infrastructure | Authority is split; extra DNS and certificate management |
| Country domain (ccTLD) | `company.de` | Strong local presence, local legal requirements | The most expensive option; each domain builds authority from zero |
| URL parameter | `company.com?lang=en` | Practically never for a public site | Poor indexing, fragile link sharing, caching problems |

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](/blog/next-js-pre-firemne-weby-preco-ho-agentury-coraz-viac-uprednostnuju) handles translated paths elegantly — but nobody will save you from the decision itself.

:::callout warning
**Caution:** Fix the URL strategy and the slug translation approach in the brief before the first line of code. It is the cheapest decision before launch and one of the most expensive after it.
:::

## hreflang and canonical: where SEO breaks most often

`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.

## Plurals, inflection, and formats

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.

## Design: text expansion and writing direction

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](/blog/co-ovplyvnuje-dlzku-vyvoja-webovej-aplikacie).

## Who owns the translations and how they stay in sync

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](/blog/headless-cms-vs-tradicny-cms-co-zvolit-pre-firemny-web) 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.

| Strategy | Behaviour | Suitable for |
| --- | --- | --- |
| Fall back to the source language | The source text is shown | Internal tools, fast rollouts |
| Show the key | `checkout.button.pay` is shown | Never in production; useful in development |
| Hide the element | The element is not rendered | Optional labels, never actions |
| Fail the build on a missing key | The deployment stops | Products where inconsistent language is unacceptable |

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.

:::callout info
**In short:** If you cannot name the person responsible for the second language a year from now, you are not ready to launch that language.
:::

## Every additional language is a recurring cost

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.

## Summary

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](/riesenia/webove-aplikacie) 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](/kontakt) before the decisions are locked into code.


---

Web version: https://interfase.sk/en/news/multilingual-web-application-what-localization-really-involves
llms.txt: https://interfase.sk/llms.txt