--- title: "Vícejazyčná webová aplikace: co ve skutečnosti obnáší lokalizace" description: "Překlad textů je nejmenší část vícejazyčné aplikace. Skutečné náklady leží v URL strategii, hreflang signálech, skloňování, formátech a v procesu, který drží jazyky v synchronu i o dva roky později." canonical: "https://interfase.sk/cz/novinky/vicejazycna-webova-aplikace-co-obnasi-lokalizace" lang: "cz" last_updated: "2026-08-05" --- # Vícejazyčná webová aplikace: co ve skutečnosti obnáší lokalizace > Překlad textů je nejmenší část vícejazyčné aplikace. Skutečné náklady leží v URL strategii, hreflang signálech, skloňování, formátech a v procesu, který drží jazyky v synchronu i o dva roky později. Publikováno: 2026-08-05 - Samotný překlad textů bývá menší částí práce než routing, SEO signály, formátování a proces údržby kolem nich. - URL strategii a způsob překladu slugů je nutné rozhodnout před spuštěním, protože pozdější změna znamená hromadná přesměrování a dočasný propad organické návštěvnosti. - Skládání textů z fragmentů v češtině a slovenštině nefunguje kvůli skloňování a více tvarům množného čísla, proto do překladových klíčů patří celé věty. - Každý další jazyk je opakovaný náklad na každou budoucí změnu obsahu, nikoli jednorázová položka v rozpočtu. 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. ## Překlad je nejmenší část nákladů 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í](/blog/udrzba-a-rozvoj-softveru-po-spusteni-co-vsetko-zahrna). > 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. :::chart bar Orientační podíl úsilí (ilustrativně) Překlad textů, 15 Routing a SEO, 25 Kód a formátování, 25 Design a QA, 20 Proces a údržba, 15 ::: ## URL strategie: rozhodnutí, které nejde levně vrátit 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. | Přístup | Příklad | Kdy dává smysl | Rizika | | --- | --- | --- | --- | | Podadresář | `firma.cz/en/produkty` | Většina firemních webů a aplikací; jedna doména, jedna autorita | Geograficky slabší signál pro vyhledávače | | Subdoména | `en.firma.cz` | Když má každý trh vlastní tým nebo vlastní infrastrukturu | Autorita se dělí, správa DNS a certifikátů navíc | | Národní doména (ccTLD) | `firma.de` | Silná lokální přítomnost, lokální právní požadavky | Nejdražší varianta; každá doména si buduje autoritu od nuly | | Parametr v URL | `firma.cz?lang=en` | Prakticky nikdy pro veřejný web | Špatná indexace, křehké sdílení odkazů, problémy s cache | 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](/blog/next-js-pre-firemne-weby-preco-ho-agentury-coraz-viac-uprednostnuju) umí přeložené cesty řešit elegantně — ale rozhodnutí samotné vám nikdo neodpustí. :::callout warning **Pozor:** URL strategii a způsob překladu slugů zafixujte v zadání ještě před prvním řádkem kódu. Je to nejlevnější rozhodnutí před spuštěním a jedno z nejdražších po něm. ::: ## hreflang a canonical: kde se SEO rozbije nejčastěji `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í. ## Množná čísla, skloňování a formáty 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ě. ## Design: expanze textu a směr písma 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](/blog/co-ovplyvnuje-dlzku-vyvoja-webovej-aplikacie). ## Kdo vlastní překlady a jak zůstanou v synchronu 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](/blog/headless-cms-vs-tradicny-cms-co-zvolit-pre-firemny-web) 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á. | Strategie | Chování | Vhodné pro | | --- | --- | --- | | Fallback na zdrojový jazyk | Zobrazí se zdrojový text | Interní nástroje, rychlá nasazení | | Zobrazení klíče | Zobrazí se `checkout.button.pay` | Nikdy v produkci; užitečné ve vývoji | | Skrytí prvku | Prvek se nezobrazí | Nepovinné popisky, nikdy ne akce | | Build selže při chybějícím klíči | Nasazení se zastaví | Produkty, kde je nekonzistentní jazyk nepřijatelný | 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. :::callout info **Zkratka:** Pokud neumíte jmenovat člověka, který za druhý jazyk odpovídá za rok, ještě nejste připraveni ten jazyk spustit. ::: ## Každý další jazyk je opakovaný náklad 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. ## Shrnutí 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](/riesenia/webove-aplikacie) 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í](/kontakt) dřív, než se rozhodnutí zafixují v kódu. --- Webová verze: https://interfase.sk/cz/novinky/vicejazycna-webova-aplikace-co-obnasi-lokalizace llms.txt: https://interfase.sk/llms.txt