Vícejazyčná webová aplikace: co ve skutečnosti obnáší lokalizace

Rozhodnutí „udělejme to i anglicky" zní jako jedna položka v seznamu úkolů. Ve skutečnosti jde o zásah do architektury aplikace, který se dotkne routingu, datového modelu, buildu, SEO, designu i procesů v marketingovém týmu. Firmy to obvykle zjistí až ve chvíli, kdy je první jazyk hotový a druhý se má „jen doplnit".

Tento text popisuje, co vícejazyčná webová aplikace opravdu obnáší — ne v korunách, ale v rozhodnutích, která je třeba udělat před spuštěním, a v opakovaných nákladech, které po spuštění nikdy neskončí. Cílem není vás od druhého jazyka odradit. Cílem je, abyste do něj šli s realistickou představou.

Když si firma představí lokalizaci, představí si tabulku se dvěma sloupci: zdrojový text vlevo, anglický vpravo. Ta tabulka je reálně menší část práce. Většina úsilí je infrastruktura kolem ní.

Kompletní rozsah typicky zahrnuje:

• routing a URL strukturu pro každý jazyk včetně 404 a přesměrování,
• SEO signály: hreflang, canonical, jazykové sitemapy, strukturovaná data, Open Graph,
• extrakci všech textů z kódu do překladových souborů — včetně transakčních e-mailů, PDF a fakturačních šablon, validačních hlášek, chybových stavů, prázdných stavů a textů v notifikacích,
• formátování dat, čísel, měn, jednotek, adres a telefonních čísel,
• pluralizaci a skloňování,
• design a komponenty, které snesou výrazně delší text,
• obsahový model v CMS, který dokáže držet jeden článek ve třech verzích s vlastními slugy a vlastním stavem publikace,
• proces, který zajistí, že když se zítra změní text na homepage, změní se ve všech jazycích.

Poslední bod firmy podceňují nejvíc. Překlad je jednorázová položka v rozpočtu. Synchronizace je trvalý provozní náklad, který patří do stejné kategorie jako údržba a rozvoj softwaru po spuštění.

Lokalizace není funkce, kterou dodáte. Je to vlastnost systému, kterou udržujete.

Následující graf ukazuje kvalitativně, jak se úsilí obvykle rozloží. Jde o ilustrativní příklad pro vysvětlení proporcí, ne o naměřená data z konkrétního projektu — v každém projektu to dopadne jinak.

První věc, kterou je třeba rozhodnout, je, kde jazyky žijí. Existují čtyři běžné možnosti a každá má jiný profil.

Pro naprostou většinu projektů je správnou odpovědí podadresář. Důležitější — a častěji přehlížená — je však druhá otázka: překládají se i slugy?

Přeložené slugy versus jedna cesta pro všechny jazyky

Máte dvě možnosti:

• Jedna cesta pro všechny jazyky: /sk/produkty, /en/produkty, /cz/produkty. Jednoduché na implementaci, jeden zdroj pravdy pro routing, snadná údržba. Cenou je horší relevance v cizojazyčném vyhledávání a URL, která anglickému návštěvníkovi nic neříká.
• Přeložené slugy: /sk/produkty, /en/products, /cz/produkty. Lepší pro SEO i pro důvěryhodnost odkazu, ale routing potřebuje mapování slug ↔ jazyk, CMS musí slug ukládat per jazyk a redakce musí vědět, že změna slugu znamená přesměrování.

Rozhodnutí musí padnout před spuštěním, ne po něm. Pokud po roce přepnete z jedné strategie na druhou, nejde o refaktor routingu — jde o hromadnou migraci URL: mapovací tabulka pro každou stránku, trvalá přesměrování 301, aktualizace sitemap, interních odkazů, kampaňových URL, QR kódů v tištěných materiálech a zpětných odkazů, které neovládáte. Vyhledávače přesměrování zvládnou, ale přepočet trvá týdny a mezitím vidíte propad organické návštěvnosti. Framework tu pomůže — Next.js s vlastním routingem pro firemní weby umí přeložené cesty řešit elegantně — ale rozhodnutí samotné vám nikdo neodpustí.

hreflang říká vyhledávači, že tři URL jsou jazykové varianty téže stránky, a kterou komu ukázat. canonical říká, která URL je autoritativní verzí daného obsahu. Když se tyto dva signály navzájem perou, výsledkem není „trochu horší SEO" — je to nesprávně indexovaná stránka.

Nejčastější chyby, které vidíme při auditech:

• `canonical` míří z anglické verze na zdrojovou. Klasika při kopírování šablony. Vyhledávač dostane pokyn, že anglická stránka je duplicitní, a přestane ji indexovat.
• Nereciproční `hreflang`. Pokud SK verze odkazuje na EN, ale EN neodkazuje zpět na SK, celý pár může být ignorován. Vztahy musí být obousměrné a musí obsahovat i self-reference.
• Chybějící `x-default`. Bez něj nemáte definováno, co dostane návštěvník, jehož jazyk nepokrýváte.
• Nesprávné kódy jazyka a regionu. en-UK neexistuje, správně je en-GB. cs je čeština, ne cz.
• `hreflang` na stránky, které vracejí 404 nebo jsou `noindex`. Signál míří do prázdna.
• Překlad obsahu bez překladu metadat. Titulky, popisy, alt texty a strukturovaná data zůstanou v původním jazyce a stránka se v cizojazyčném vyhledávání nezobrazí smysluplně.

Kontrolu těchto věcí zařaďte do QA před každým nasazením, ne do jednorázového auditu po spuštění.

Tohle je část, kterou anglicky psaný kód téměř vždy udělá špatně — a čeština se slovenštinou patří mezi jazyky, které chybu odhalí okamžitě.

Skládání řetězců nefunguje

Typický vzorec, který vznikne v anglickém prostředí:

"Found " + count + " results"

V angličtině stačí dva tvary. V češtině potřebujete čtyři: 0 výsledků, 1 výsledek, 2 – 4 výsledky, 5 a více výsledků. A to je jen číslovka. Skládání typu "Přidat do " + folderName narazí ještě tvrději, protože čeština vyžaduje pád: Přidat do složky, ne Přidat do složka.

Praktické pravidlo: překladový klíč obsahuje celou větu, ne její fragmenty, a pluralizaci řeší formát, který zná víc než dvě kategorie (ICU MessageFormat je dnes de facto standard). Pokud v kódu vidíte spojování přeložených kousků operátorem +, je to chyba, která se projeví až v jazyce, který si vývojář nepřečte.

Data, čísla, měny a časová pásma

• Čísla: 1 234,56 v češtině, 1,234.56 v angličtině. Pokud formátujete ručně, rozbijete jedno nebo druhé.
• Měny: poloha symbolu a mezera se liší (1 234,56 Kč versus €1,234.56). Zvlášť řešte otázku, zda zobrazujete jednu měnu všem, nebo přepočítáváte — přepočet znamená kurzy, zaokrouhlování a daňovou logiku, což je samostatný projekt.
• Data: 5. 8. 2026 versus 8/5/2026 versus 2026-08-05. Nikdy neformátujte datum řetězcovou šablonou.
• Časová pásma: pokud aplikace zobrazuje časy událostí, jazyk a pásmo jsou dvě nezávislá nastavení. Čech v Kanadě chce češtinu a kanadský čas.

Řešením je používat standardní Intl API prohlížeče nebo ekvivalent na backendu a nikdy neformátovat ručně.

Tlačítko, do kterého se akorát vejde Uložit, se rozbije u německého Speichern a francouzského Enregistrer. Stejně dopadnou navigační položky, popisky ve formulářích, hlavičky tabulek a všechno, co má pevnou šířku.

Co s tím:

• Testujte layout s nejdelším reálným překladem, ne s nejkratším.
• Vyhýbejte se pevným šířkám u prvků, které nesou text; nechte je růst.
• Počítejte s dvouřádkovou variantou tlačítek a menu.
• U jazyků psaných zprava doleva (arabština, hebrejština) nejde jen o zarovnání textu — obrací se celý layout: navigace, ikony se směrovým významem, průběhové indikátory, tabulky. Pokud RTL v plánu nemáte, nedělejte pro něj přípravu „pro jistotu"; pokud ho v plánu máte, řekněte to na začátku, protože mění komponentovou knihovnu.

To je jeden z důvodů, proč lokalizace prodlužuje QA fázi — a jeden z faktorů, které vstupují do toho, co ovlivňuje délku vývoje webové aplikace.

Technická část se dá dokončit. Procesní ne — ta běží dál.

Rozhodněte tři věci a zapište je:

1. Kdo je vlastník jazyka. Konkrétní člověk, ne oddělení. Bez jmenovaného vlastníka se druhý jazyk do roka rozejde s prvním.
2. Kde překlady žijí. Překladové klíče v repozitáři (pro UI) a redakční obsah v CMS jsou dva různé toky se dvěma různými schvalováními. Pokud obsah spravuje marketing, volba mezi headless a tradičním CMS přímo určuje, jak pohodlný bude jejich pracovní postup.
3. Co se stane při změně zdrojového textu. Změna zdrojové věty musí označit ostatní jazyky jako neaktuální. Pokud se to neděje automaticky, děje se to náhodně.

Fallback při chybějícím překladu

Chybějící překlady nastanou vždy. Otázkou je jen to, jak se aplikace zachová.

Doporučení pro většinu firemních webů: fallback na zdrojový jazyk v produkci, tvrdé selhání v CI a report chybějících klíčů, který někdo reálně čte.

Nejdůležitější věta celého článku: druhý jazyk nezdvojnásobí práci jednorázově, ale zdvojnásobí práci na každé budoucí změně.

Nová stránka znamená novou stránku krát počet jazyků. Změna ceníku, nová funkce v aplikaci, nový e-mail v onboardingu, úprava právního textu — vždy krát počet jazyků. K tomu QA v každém jazyce a režie překladatelského toku.

Praktické důsledky:

• Nezavádějte jazyk, pro který nemáte obchodní důvod a rozpočet na jeho údržbu. Zanedbaný jazyk škodí víc než neexistující.
• Zvažte částečnou lokalizaci: plná lokalizace produktu a marketingových stránek, ale blog a dokumentace jen v jednom jazyce, jasně označené.
• Pokud plánujete víc než tři jazyky, vyplatí se nasadit překladatelskou platformu s napojením na repozitář a CMS. U dvou jazyků je to zbytečná režie.
• Počítejte s lokalizací při plánování kapacity stejně, jako počítáte s růstem aplikace — je to trvalá zátěž, ne milník.

Vícejazyčná webová aplikace není překlad textů. Je to soubor architektonických rozhodnutí — URL strategie, jazykové signály pro vyhledávače, způsob formátování a pluralizace, pružnost designu — plus provozní proces, který drží jazyky v synchronu dlouho po spuštění.

Tři rozhodnutí udělejte před prvním řádkem kódu: kde jazyky žijí v URL, zda se překládají slugy, a kdo je jmenovaným vlastníkem každého jazyka. Zbytek se dá doladit. Tyto tři ne.

V INTERFASE navrhujeme vícejazyčné webové aplikace tak, aby routing, SEO signály i překladový tok stály na jednom modelu od začátku — přidání třetího jazyka pak není nový projekt. Pokud zvažujete druhý jazyk a chcete si nejdřív projít důsledky, ozvěte se nám a projdeme si zadání dřív, než se rozhodnutí zafixují v kódu.