Viacjazyčná webová aplikácia: čo v skutočnosti obnáša lokalizácia

Rozhodnutie „spravme to aj po anglicky" znie ako jedna položka v zozname úloh. V skutočnosti je to zásah do architektúry aplikácie, ktorý sa dotkne routingu, dátového modelu, buildu, SEO, dizajnu aj procesov v marketingovom tíme. Firmy to zvyčajne zistia až vtedy, keď je prvý jazyk hotový a druhý sa má „len doplniť".

Tento text popisuje, čo viacjazyčná webová aplikácia naozaj obnáša — nie v eurách, ale v rozhodnutiach, ktoré treba spraviť pred spustením, a v opakovaných nákladoch, ktoré po spustení nikdy neskončia. Cieľom nie je odhovoriť vás od druhého jazyka. Cieľom je, aby ste do neho išli s realistickým obrazom.

Keď si firma predstaví lokalizáciu, predstaví si tabuľku s dvoma stĺpcami: slovenský text vľavo, anglický vpravo. Tá tabuľka je reálne menšia časť práce. Väčšina úsilia je infraštruktúra okolo nej.

Kompletný rozsah typicky zahŕňa:

• routing a URL štruktúru pre každý jazyk vrátane 404 a presmerovaní,
• SEO signály: hreflang, canonical, jazykové sitemapy, štruktúrované dáta, Open Graph,
• extrakciu všetkých textov z kódu do prekladových súborov — vrátane transakčných e-mailov, PDF a faktúrových šablón, validačných hlášok, chybových stavov, prázdnych stavov a textov v notifikáciách,
• formátovanie dátumov, čísel, mien, jednotiek, adries a telefónnych čísel,
• pluralizáciu a skloňovanie,
• dizajn a komponenty, ktoré znesú výrazne dlhší text,
• obsahový model v CMS, ktorý dokáže držať jeden článok v troch verziách s vlastnými slugmi a vlastným stavom publikácie,
• proces, ktorý zabezpečí, že keď sa zajtra zmení text na homepage, zmení sa vo všetkých jazykoch.

Posledný bod podceňujú firmy najviac. Preklad je jednorazová položka v rozpočte. Synchronizácia je trvalý prevádzkový náklad, ktorý patrí do rovnakej kategórie ako údržba a rozvoj softvéru po spustení.

Lokalizácia nie je funkcia, ktorú dodáte. Je to vlastnosť systému, ktorú udržiavate.

Nasledujúci graf ukazuje kvalitatívne, ako sa úsilie zvykne rozložiť. Ide o ilustratívny príklad na vysvetlenie proporcií, nie o namerané dáta z konkrétneho projektu — v každom projekte to dopadne inak.

Prvá vec, ktorú treba rozhodnúť, je, kde jazyky žijú. Sú štyri bežné možnosti a každá má iný profil.

Pre naprostú väčšinu projektov je správna odpoveď podadresár. Dôležitejšia — a častejšie prehliadaná — je však druhá otázka: prekladajú sa aj slugy?

Preložené slugy verzus jedna cesta pre všetky jazyky

Máte dve možnosti:

• Jedna cesta pre všetky jazyky: /sk/produkty, /en/produkty, /cz/produkty. Jednoduché na implementáciu, jeden zdroj pravdy pre routing, ľahká údržba. Cena je horšia relevancia v cudzojazyčnom vyhľadávaní a URL, ktorá pre anglického návštevníka nič neznamená.
• Preložené slugy: /sk/produkty, /en/products, /cz/produkty. Lepšie pre SEO a pre dôveryhodnosť odkazu, ale routing potrebuje mapovanie slug ↔ jazyk, CMS musí slug ukladať per jazyk a redakcia musí vedieť, že zmena slugu znamená presmerovanie.

Rozhodnutie musí padnúť pred spustením, nie po ňom. Ak po roku prepnete z jednej stratégie na druhú, nejde o refaktor routingu — ide o hromadnú migráciu URL: mapovacia tabuľka pre každú stránku, trvalé presmerovania 301, aktualizácia sitemap, interných odkazov, kampaňových URL, QR kódov v tlačených materiáloch a spätných odkazov, ktoré neovládate. Vyhľadávače presmerovania zvládnu, ale prepočet trvá týždne a medzitým vidíte prepad v organickej návštevnosti. Framework tu pomôže — Next.js s vlastným routingom pre firemné weby vie preložené cesty riešiť elegantne — ale rozhodnutie samotné vám nikto neodpustí.

hreflang hovorí vyhľadávaču, že tri URL sú jazykové varianty tej istej stránky, a ktorú komu ukázať. canonical hovorí, ktorá URL je autoritatívna verzia daného obsahu. Keď sa tieto dva signály navzájom bijú, výsledok nie je „trochu horšie SEO" — je to nesprávne indexovaná stránka.

Najčastejšie chyby, ktoré vidíme pri auditoch:

• `canonical` mieri z anglickej verzie na slovenskú. Klasika pri kopírovaní šablóny. Vyhľadávač dostane pokyn, že anglická stránka je duplicitná, a prestane ju indexovať.
• Nerecipročné `hreflang`. Ak SK verzia odkazuje na EN, ale EN neodkazuje späť na SK, celý pár sa môže ignorovať. Vzťahy musia byť obojsmerné a musia obsahovať aj self-referencie.
• Chýbajúci `x-default`. Bez neho nemáte definované, čo dostane návštevník, ktorého jazyk nepokrývate.
• Nesprávne kódy jazyka a regiónu. en-UK neexistuje, správne je en-GB. cs je čeština, nie cz.
• `hreflang` na stránky, ktoré vracajú 404 alebo sú `noindex`. Signál mieri do prázdna.
• Preklad obsahu bez prekladu metadát. Titulky, popisy, alt texty a štruktúrované dáta zostanú slovenské a stránka sa v cudzojazyčnom vyhľadávaní nezobrazí zmysluplne.

Kontrolu týchto vecí zaraďte do QA pred každým nasadením, nie do jednorazového auditu po spustení.

Toto je časť, ktorú anglicky písaný kód takmer vždy urobí zle — a slovenčina s češtinou patria medzi jazyky, ktoré chybu odhalia okamžite.

Skladanie reťazcov nefunguje

Typický vzorec, ktorý vznikne v anglickom prostredí:

"Found " + count + " results"

V angličtine stačia dva tvary. V slovenčine potrebujete štyri: 0 výsledkov, 1 výsledok, 2 – 4 výsledky, 5 a viac výsledkov. A to je len číslovka. Skladanie typu "Pridať do " + folderName narazí ešte tvrdšie, lebo slovenčina vyžaduje pád: Pridať do priečinka, nie Pridať do priečinok.

Praktické pravidlo: prekladový kľúč obsahuje celú vetu, nie jej fragmenty, a pluralizáciu rieši formát, ktorý pozná viac ako dve kategórie (ICU MessageFormat je dnes de facto štandard). Ak v kóde vidíte spájanie preložených kúskov operátorom +, je to chyba, ktorá sa prejaví až v jazyku, ktorý si vývojár neprečíta.

Dátumy, čísla, meny a časové pásma

• Čísla: 1 234,56 v slovenčine, 1,234.56 v angličtine. Ak formátujete ručne, rozbijete jedno alebo druhé.
• Meny: poloha symbolu a medzera sa líšia (1 234,56 € verzus €1,234.56). Zvlášť riešte otázku, či zobrazujete jednu menu všetkým, alebo prepočítavate — prepočet znamená kurzy, zaokrúhľovanie a daňovú logiku, čo je samostatný projekt.
• Dátumy: 5. 8. 2026 verzus 8/5/2026 verzus 2026-08-05. Nikdy neformátujte dátum reťazcovou šablónou.
• Časové pásma: ak aplikácia zobrazuje časy udalostí, jazyk a pásmo sú dve nezávislé nastavenia. Slovák v Kanade chce slovenčinu a kanadský čas.

Riešením je používať štandardné Intl API prehliadača alebo ekvivalent na backende a nikdy neformátovať ručne.

Tlačidlo, do ktorého sa akurát zmestí Uložiť, sa rozbije pri nemeckom Speichern a francúzskom Enregistrer. Rovnako dopadnú navigačné položky, štítky vo formulároch, tabuľkové hlavičky a všetko, čo má pevnú šírku.

Čo s tým:

• Testujte layout s najdlhším reálnym prekladom, nie s najkratším.
• Vyhýbajte sa pevným šírkam pri prvkoch, ktoré nesú text; nechajte ich rásť.
• Počítajte s dvojriadkovým variantom tlačidiel a menu.
• Pri jazykoch písaných sprava doľava (arabčina, hebrejčina) nejde len o zarovnanie textu — obracia sa celý layout: navigácia, ikony so smerovým významom, priebehové indikátory, tabuľky. Ak RTL v pláne nemáte, nerobte preň prípravu „pre istotu"; ak ho v pláne máte, povedzte to na začiatku, lebo mení komponentovú knižnicu.

Toto je jeden z dôvodov, prečo lokalizácia predlžuje QA fázu — a jeden z faktorov, ktoré vstupujú do toho, čo ovplyvňuje dĺžku vývoja webovej aplikácie.

Technická časť sa dá dokončiť. Procesná nie — tá beží ďalej.

Rozhodnite tri veci a zapíšte ich:

1. Kto je vlastník jazyka. Konkrétny človek, nie oddelenie. Bez menovaného vlastníka sa druhý jazyk do roka rozíde s prvým.
2. Kde preklady žijú. Prekladové kľúče v repozitári (pre UI) a redakčný obsah v CMS sú dva rôzne toky s dvoma rôznymi schvaľovaniami. Ak obsah spravuje marketing, voľba medzi headless a tradičným CMS priamo určuje, ako pohodlný bude ich pracovný postup.
3. Čo sa stane pri zmene zdrojového textu. Zmena slovenskej vety musí označiť ostatné jazyky ako neaktuálne. Ak sa to nedeje automaticky, deje sa to náhodne.

Fallback pri chýbajúcom preklade

Chýbajúce preklady nastanú vždy. Otázka je len, ako sa aplikácia zachová.

Odporúčanie pre väčšinu firemných webov: fallback na zdrojový jazyk v produkcii, tvrdé zlyhanie v CI, a report chýbajúcich kľúčov, ktorý niekto reálne číta.

Najdôležitejšia veta celého článku: druhý jazyk nezdvojnásobí prácu jednorazovo, ale zdvojnásobí prácu na každej budúcej zmene.

Nová stránka znamená novú stránku krát počet jazykov. Zmena cenníka, nová funkcia v aplikácii, nový e-mail v onboardingu, úprava právneho textu — vždy krát počet jazykov. K tomu QA v každom jazyku a réžia prekladateľského toku.

Praktické dôsledky:

• Nezavádzajte jazyk, pre ktorý nemáte obchodný dôvod a rozpočet na jeho údržbu. Zanedbaný jazyk škodí viac než neexistujúci.
• Zvážte čiastočnú lokalizáciu: plná lokalizácia produktu a marketingových stránok, ale blog a dokumentácia len v jednom jazyku, jasne označené.
• Ak plánujete viac než tri jazyky, oplatí sa nasadiť prekladateľskú platformu s napojením na repozitár a CMS. Pri dvoch jazykoch je to zbytočná réžia.
• Rátajte s lokalizáciou pri plánovaní kapacity rovnako, ako rátate s rastom aplikácie — je to trvalá záťaž, nie míľnik.

Viacjazyčná webová aplikácia nie je preklad textov. Je to súbor architektonických rozhodnutí — URL stratégia, jazykové signály pre vyhľadávače, spôsob formátovania a pluralizácie, pružnosť dizajnu — plus prevádzkový proces, ktorý drží jazyky v synchrone dlho po spustení.

Tri rozhodnutia spravte pred prvým riadkom kódu: kde jazyky žijú v URL, či sa prekladajú slugy, a kto je menovaný vlastník každého jazyka. Zvyšok sa dá doladiť. Tieto tri nie.

V INTERFASE navrhujeme viacjazyčné webové aplikácie tak, aby routing, SEO signály aj prekladový tok stáli na jednom modeli od začiatku — pridanie tretieho jazyka potom nie je nový projekt. Ak zvažujete druhý jazyk a chcete si najprv prejsť dôsledky, ozvite sa nám a prejdeme si zadanie skôr, než sa rozhodnutia zafixujú v kóde.