10 Common i18n Mistakes Developers Make | Fix Guide 2025

Medzinárodná lokalizácia (i18n) vyzerá jednoducho — dokým nezistíte, že vaši nemeckí používatelia vidia skrátené tlačidlá, vaši japonskí používatelia dostávajú zovšeobecnené fragmenty viet a váš arabský hovoriaci používateľ má úplne znehodnotený vzhľad rozloženia. Nie sú to výnimky. Sú to predvídateľné dôsledky častých chýb, ktoré väčšina vývojových tímov robí, keď po prvýkrát pristúpi k lokalizácii. V tomto sprievodcovi prejdeme 10 najčastejších chýb i18n, presne vysvetlíme, prečo sa vyskytujú, a krok za krokom ukážeme, ako každý z nich vyriešiť. Bez ohľadu na to, či staviate novú aplikáciu alebo pridávate existujúcu — vyhnutie sa týmto pascám vám ušetrí týždne ladenia a poskytnete používateľom po celom svete uhladený zážitok.

Chyba č. 1: pevné reťazce

Tvrdé zakódované texty sú základnou chybou i18n. Vzniká, pretože vývojári sa najprv sústredia na to, aby funkcie fungovali, a plánujú „upratať to neskôr“. Ale neskôr nikdy nepríde, a zrazu máte tisíce textov rozmiestnených po stovkách súborov.

['Nastavte svoje i18n rámce ešte pred napísaním prvého riadku UI kódu', 'Použite linter plugin na rozpoznanie hardkodovaných textov v šablónach a komponentoch', 'Udržujte kľúče prekladu popisné a organizované podľa funkcie alebo stránky']

Nastavte svoj i18n-Framework ešte pred písaním prvého riadku UI kódu.

Použite linter-plugin na identifikáciu hardkodovaných textov v šablónach a komponentoch.

Udržujte kľúče pre preklady popisné a organizujte ich podľa funkcie alebo stránky.

Typický scenár

Vývojár priamo v JSX napíše popis tlačidla: <button>Submit Order</button>.

Aplikácia sa vydáva v angličtine a funguje bez problémov. O šesť mesiacov neskôr spoločnosť rozšíri pôsobenie na Nemecko.

Tím pre lokalizáciu objaví viac ako 2000 hardkodovaných reťazcov. Dopĺňanie trvá 3 týždne a spôsobí 47 chýb.

Prečo je to problém

V zrelej kódovej báze môžu byť hardkodované reťazce v tisícoch. Neskoršie extrahovanie si vyžaduje zásah do každého súboru, opätovné otestovanie každej komponenty a riziko regresií na všetkých miestach.

Tvrdé zakódované reťazce sú priamo vložené do zdrojového kódu, šablón alebo komponentov. Nedajú sa extrahovať, prekladať ani vymeniť za behu bez zmeny samotného kódu.

Používatelia v lokalizáciách, ktoré nie sú anglické, vidia UI prvky, ktoré nie sú preložené, v混合 s preloženým obsahom — chaotický a neprofesionálny dojem.

Ako to vyriešiš

Presuňte všetky texty používateľa od začiatku do súborov zdrojov.

Nastavte prekladajúci rámec (napr. next-intl, react-i18next, vue-i18n), ešte predtým, než napíšete prvú komponentu.

Vytvorte štruktúru súborov zdrojov (napr. messages/de.json) a odkazujte na všetky texty cez kľúče prekladov ako t('checkout.submitButton').

Pridajte pravidlo lintu alebo pre-commit hook, ktorý flaguje surové literály reťazcov v UI komponentoch.

Chyba #10: Preložiť všetko doslovne

Nie všetok obsah by sa nemal prekladať. Značky, názvy právnických osôb, technické termíny a určité názvy výrobkov by mali zostať v pôvodnom jazyku. Nadmerný preklad môže spôsobiť právne problémy, nekonzistenciu značky a zmätenie používateľov.

Vytvorte glosár neprekladať a podeľte sa oň so všetkými prekladateľmi. Použite uzamknuté segmenty alebo samostatné priestory názvov pre značkové a právne pojmy. Vždy poskytnite poznámky k kontextu pre nejednoznačné reťazce, aby sa predišlo chybám prekladu.

Udržiavajte glosár 'neprekladať' a zdieľajte ho so všetkými prekladateľmi.

Používajte uzamknuté segmenty alebo samostatné namespace pre značkové a právne výrazy.

Vždy poskytujte kontextové poznámky k nejednoznačným reťazcom, aby ste predišli nesprávnym prekladom.

Typický scenár

Prekladový súbor obsahuje názov spoločnosti 'CloudForge Inc.' a technický termín 'OAuth 2.0 Token' ako bežne preložiteľné reťazce.

Španielsky prekladateľ prekladá 'CloudForge' ako 'ForjaNube' a 'OAuth 2.0 Token' ako 'ficha OAuth 2.0'.

Výsledok: používatelia nenájdu spoločnosť pod jej skutočným názvom a vývojári čítajúci španielsku dokumentáciu budú zmätení neznámymi preloženými odbornými termínmi.

Prečo je to problém

Jeden zle preložený názov značky v právnom dokumente môže učiniť zmluvu neplatnou. Oprava takých prekladov si vyžiada kontrolu každého reťazca v každom jazyku — niekoľko týždňov práce.

Keď sú všetky reťazce posielané na preklad bez kontextu, prekladatelia môžu preložiť názvy značiek ('Apple' → 'Apfel'), právnické skratky ('GmbH' → 'LLC') alebo technické označenia, ktoré by mali zostať v angličtine.

Používatelia nemajú nájdiť produkty pod ich známymi značkami, právne dokumenty budú odkazovať na nesprávnu spoločnosť a technická dokumentácia bude nepochopiteľná, ak budú slová ako 'API Endpoint' prekladané.

Takto to napravíš

Jasne označte neprekládateľné prvky a poskytnite prekladateľom poznámky k kontextu.

Vytvorte glosár neprekladať, ktorý zoznamuje všetky obchodné názvy, názvy produktov, právnické osoby a odborné termíny, ktoré musia zostať nezmenené.

Použite oddelený priestor názvov alebo špeciálne kľúče pre neprekládateľný obsah. Mnoho nástrojov i18n podporuje uzamknuté segmenty, ktoré prekladatelia nemôžu upravovať.

Pridajte prekladateľské komentáre/popisy k vašim prekladovým súborom, ktoré vysvetľujú kontext: Toto je názov značky — neprekladať alebo odborný pojem — ponechať v angličtine.

Chyba č. 2: Zreťazovanie reťazcov

Zlúčenie viet zo fragmentov pôsobí na angličtine logicky, no v iných jazykoch to nefunguje. Poradie slov, gramatika a vetná štruktúra sa dramaticky líšia medzi jazykmi, čo spája texty, ktoré sa nedajú preložiť.

['Nikdy neskladajte vety spájaním preložených fragmentov', 'Používajte pomenované zástupné znaky ('{name}') namiesto pozičných ({0}) pre jasnosť', 'Poskytnite kontextové komentáre pre prekladateľov, ktoré vysvetľujú, čo každý zástupný znak obsahuje']

Nikdy nekombinujte preložené fragmenty do viet spájaním.

Používajte pomenované zástupné znaky ('{name}') namiesto pozičných ({0}) pre jasnosť

Poskytnite prekladateľom kontextové komentáre, ktoré vysvetľujú, čo obsahuje každý zástupný znak.

Typický scenár

Vývojár píše: 'You have ' + count + ' items in your ' + cartType + ' cart' — funguje perfektne po anglicky.

Nemecký prekladateľ dostane tri samostatné fragmenty a nedokáže zostaviť gramaticky správnu vetu, pretože slovosled sa musí zmeniť.

Výsledok: nemeckí používatelia uvidia 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — trápne a neprofesionálne.

Prečo je to problém

Každý prepojený reťazec je tikajúca časovaná bomba. Pri 20 jazykoch a 50 prepojených reťazcoch máte 1 000 potenciálnych gramatických chýb, ktoré treba ručne opraviť.

Spájanie reťazcov ako 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' vyžaduje určitý poriadok slov. Prekladatelia dostávajú nekonzistentné fragmenty, ktoré nemôžu preusporiadať.

Používatelia vidia gramaticky nesprávne vety. V nemčine stojí sloveso často na konci. V arabčine je celá štruktúra obrátená. Výsledok znie ako nezmysel.

Ako to vyriešiť

Použite parametrické správy s pomenovanými zástupcami, aby prekladatelia mohli celú vetu preusporiadať.

Nahradte spájanie jedným kľúčom správy s zástupnými znakmi: 'cart.summary': 'Máte {count} položiek vo vašom '{cartType}' košíku'.

Predávajte premenné ako parametre do vašej prekladačskej funkcie: t('cart.summary', { count: 5, cartType: 'Premium' }).

Prekladatelia môžu teraz voľne meniť poradie: 'V vašom '{cartType}' košíku je {count} položiek' — gramaticky správna nemčina.

Chyba č. 3: Ignorovanie množného čísla

Angličtina má dve formy čísla: jednotné a množné. Vývojári často predpokladajú, že všetky jazyky fungujú rovnako. Nie sú. Poľština má 4 formy, arabčina má 6 a dokonca aj jazyky ako francúzština používajú nulovú formu inak ako angličtina.

['Vždy používajte ICU MessageFormat alebo ekvivalentnú knižnicu pre tvary množného čísla', 'Nikdy nepíšte vlastnú logiku množného čísla — spoľahnite sa na pravidlá CLDR', 'Testujte množné čísla s hodnotami ako 0, 1, 2, 5, 21 a 100, aby ste pokryli všetky kategórie']

Vždy používajte ICU MessageFormat alebo ekvivalentnú knižnicu pre tvary množného čísla.

Nikdy nepoužívajte vlastnú logiku pre množné číslo — spoľahnite sa na pravidlá CLDR.

Otestujte tvary množného čísla pri hodnotách 0, 1, 2, 5, 21 a 100, aby ste pokryli všetky kategórie.

Typický scenár

Vývojár píše: count + (count === 1 ? ' Datei' : ' Dateien') — správne ošetrenie nemčiny.

Poľský prekladateľ potrebuje 4 formy: 1 plik, 2-4 pliki, 5-21 plikov, 22-24 pliki. Jednoduchý ternárny operátor to nedokáže vyjadriť.

Výsledok: Poliaci vidia '5 pliki' (nesprávna forma) namiesto '5 plików' (správna forma), a aplikácia vyzerá zle.

Prečo je to problém

Každé počítateľné podstatné meno v tvojej aplikácii potrebuje zvládnutie množného čísla. Pri 50 takýchto reťazcoch a 20 jazykoch je to 1 000 pravidiel množného čísla — nemožné spravovať ručne.

Jednoduché overovania if/else (count === 1 ? 'Datei' : 'Dateien') pokrývajú iba nemčinu a angličtinu. CLDR definuje až 6 kategórií množného čísla: zero, one, two, few, many a other. Každý jazyk používa inú množinu kategórií.

Používatelia vidia gramaticky nesprávne texty, ako napríklad '1 Nachrichten' alebo úplne nesprávne tvary množného čísla. V formálnych kontextoch to podkopáva dôveryhodnosť.

Ako to vyriešiť

Použite ICU MessageFormat, ktorý štandardne podporuje všetky pravidlá množného čísla CLDR.

Definujte správy s ICU-syntax: 'fileCount': '{count, plural, one {# súbor} few {# súbory} many {# súborov} other {# súboru}}'.

Prekladatelia poskytnú všetky potrebné formy množného čísla pre svoj jazyk. Poľský: '{count, plural, one {# plik} few {# pliki} many {# plikov} other {# pliku}}'.

Vaša i18n knižnica počas behu automaticky vyberá správnu formu na základe pravidiel CLDR pre aktívnu lokalitu.

Chyba č. 4: pevné šírky UI prvkov

Dizajnér vytvára pixelo‑precízne rozloženia v angličtine a vývojári ich implementujú s pevnými šírkami. Ale preložený text môže byť dramaticky dlhší alebo kratší. Nemecký text je približne o 30% dlhší ako anglický, zatiaľ čo čínsky text môže byť o 50% kratší.

['Nikdy nepoužívajte pevné pixlové šírky pri prvkoch s prekladaným textom', 'Naplánujte 40% nárast textu ako základnú čiaru — niektoré jazyky sa ešte viac rozťahujú', 'Používajte CSS Flexbox alebo Grid pre rozloženia, ktoré sa prispôsobujú variabilnej dĺžke obsahu']

Nikdy nepoužívajte pevné šírky v pixeloch pri prvkoch obsahujúcich prekladaný text.

Naplánujte si baseline na 40% rozšírenie textu — niektoré jazyky sa rozšíria ešte viac.

Používajte CSS Flexbox alebo Grid pre rozloženia, ktoré sa prispôsobujú rôznej dĺžke obsahu.

Typický scenár

Dizajnér vytvára navigačný panel zo 5 tlačidiel, každé presne 100 px široké — vyzerá to skvele v angličtine.

Nemecký preklad: 'Settings' sa stane 'Nastavenia' (13 vs 8 znakov), 'Submit' sa stane 'Odoslať' (8 vs 6). Navigačný panel pretečie.

Výsledok: na mobilných zariadeniach sa tlačidlá ukladajú na seba alebo text sa orezáva, čo robí navigáciu nepoužiteľnou pre nemeckých používateľov.

Prečo je to problém

Každý prvok s pevnou šírkou je potenciálny bod zlomu. Typická aplikácia má stovky tlačidiel, štítkov a kariet, ktoré musia zvládnuť zväčšenie textu.

Kontajner s pevnou šírkou (width: 120px) a tlačidlá pevného rozmeru sa orezávajú alebo presahujú, keď sa text rozširuje. CSS overflow: hidden ticho skryje obsah, zatiaľ čo overflow: visible rozbíja rozloženie.

Používatelia vidia orezané štítky ako 'Nastavenia...' miesto 'Nastavenia', alebo tlačidlá prekrývajú susedné prvky. Kľúčové akcie sú nečitateľné alebo neklikateľné.

Ako to opraviť

Navrhujte a implementujte flexibilné rozloženia, ktoré sa prispôsobujú dĺžke obsahu vo všetkých lokalizáciách.

Nahradzujte pevné šírky min-width, max-width a používajte flexibilné rozloženia. Použite CSS Grid alebo Flexbox na dynamické rozloženie priestoru.

Nastavte prelom textu v kontajneroch: použite overflow-wrap: break-word a vyhnite sa white-space: nowrap pri prekladanom obsahu.

Otestujte UI pomocou pseudo-lokalizácie, ktorá predĺži všetky reťazce o 40% a simulujte Worst Case ešte pred zaslaním reťazcov pre preklad.

Chyba č. 5: Formátovanie dátumu a čísla

Dáta a čísla pôsobia ako univerzálne. No 01/02/2025 znamená v USA 2. január a v Európe 1. február. čiarky a bodky menia význam čísel: 1,000.50 (USA) vs 1.000,50 (Slovensko). Zle to robiť vedie k nedorozumeniam, chybám v údajoch a strate dôvery.

['Nikdy nekonvertujte údaje alebo čísla ručne pomocou reťazcových šablón — vždy používajte Intl API', 'Ukladajte všetky údaje v ISO 8601 a meny v najmenšej jednotke (cent) interne', 'Testujte s lokalitami, ktoré používajú rôzne desatinné čiarky, poradie dátumov a kalendárne systémy']

Nikdy nemanipulujte s údajmi alebo číslami ručne pomocou reťazcových šablón — vždy používajte Intl API.

Ukladajte všetky dáta v ISO 8601 a meny v najmenšej jednotke (cent) interne.

Testujte s lokalizáciami, ktoré používajú rôzne desatinné znamienka, poradie dátumov a kalendárne systémy.

Typický scenár

Vývojár naformátuje dátum ako MM/DD/YYYY a cenu ako $1,234.50 — správne pre používateľov v USA.

Používateľ zo Slovenska/Česka vidí dátum 03/04/2025 a číta ho ako 3. apríl (DD/MM/YYYY konvencia). Cena $1,234.50 vyzerá, že by mala byť 1.234,50.

Výsledok: používateľ si rezervuje let na nesprávny dátum a spochybňuje formát ceny. Počet tiketov podpory na nemeckom trhu vzrastie o 15%.

Prečo je to problém

Formát dátumu a čísel sa týka každej vizualizácie dát vo vašej aplikácii: tabuľky, grafy, formuláre, faktúry, správy. Globálne riešenie pokrýva stovky inštancií.

Tvrdý kódovaný formátovací retazec ako toLocaleDateString('en-US') alebo ručné formátovanie s použitím template literálov ignorujú skutočnú lokalizáciu používateľa. Aj keď je locale správne, ale používa sa nesprávny kalendár (gregoriánsky vs Hijri) — problém.

Používatelia čítajú údaje nesprávne a zadávajú údaje v nesprávnom formáte. Európsky používateľ, ktorý uvidí 03/04/2025, to môže interpretovať ako 3. apríl namiesto 4. marca — zmeškané termíny alebo nesprávne rezervácie.

Ako to opraviť

Použite vstavané API Intl alebo knižnicu formátovania s ohľadom na lokalitu pre všetky dátumy, časy, čísla a meny.

Nahraď ručné formátovanie pomocou Intl.DateTimeFormat(locale) pre dátumy a Intl.NumberFormat(locale, { style: 'currency', currency }) pre ceny.

Ukladajte dáta intern v ISO 8601 formáte (YYYY-MM-DD) a formátujte ich len na zobrazenie podľa lokality používateľa.

Otestujte kritické zobrazenie dátumov a čísel minimálne s 5 rôznymi lokalitami: en-US, de-DE, ja-JP, ar-SA a zh-CN, aby ste pokryli najdôležitejšie formátovacie varianty.

Chyba č. 6: Zabudnuté RTL jazyky

RTL jazyky ako arabčina, hebrejčina a perzština sú používané viac ako 500 miliónmi ľudí. Väčšina aplikácií je však navrhnutá výlučne pre rozloženie zľava doprava (LTR). Podpora RTL znamená nie len prevrátiť text — celé používateľské rozhranie musí byť zrkadlené.

['Používajte od prvého dňa výhradne logické CSS-vlastnosti (inline-start/end, block-start/end)', "Testujte vašu aplikáciu s dir='rtl' na HTML elemente na každej sprint-review", 'Vytvorte RTL testovací zoznam pre navigáciu, ikony, formuláre a ukazovatele postupu']

Používajte od prvého dňa výlučne logické CSS vlastnosti (inline-start/end, block-start/end).

Testujte svoju aplikáciu s dir='rtl' na HTML prvku pri každom sprint prehliadke.

Vytvorte RTL testovací zoznam pre navigáciu, ikony, formuláre a indikátory pokroku.

Typický scenár

Vývojár používa margin-left: 16px a text-align: left po celej aplikácii — štandardná prax LTR.

Aplikácia sa spúšťa v Saudskej Arábii. Tlačidlá späť ukazujú dopredu, bočné panely sa zobrazujú na nesprávnej strane a numerické údaje sú zle zarovnané.

Výsledok: Arabskí používatelia opúšťajú aplikáciu po 30 sekundách. Tím potrebuje 4 týždne núdzového refaktoringu CSS, aby problém vyriešil.

Prečo je to problém

Podpora RTL sa týka každej súčasti vašej aplikácie. Dodatočné zavedenie RTL zvyčajne vyžaduje prepísanie 30–50% všetkých pravidiel CSS a kontrolu každej ikony a rozloženia.

Vlastnosti CSS ako margin-left, padding-right, text-align: left a float: left pevne určujú smer. Ikony s určením smeru (šípky, indikátory postupu) ukazujú v nesprávnom smere. Dokonca aj hodnoty border-radius musia byť zrkadlené.

Arabskí používatelia vidia navigáciu v nesprávnom rohu, postupové ukazovatele idú dozadu a text sa stretáva s UI prvkami. Aplikácia pôsobí cudzo a ťažko použiteľná.

Ako to vyriešiš

Použite logické CSS-vlastnosti a otestujte RTL rozloženie od začiatku.

Nahraď ručné formátovanie pomocou logistických ekvivalentov: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.

Nastavte atribút dir na koreňový prvok HTML na základe aktuálnej lokality. Použite CSS pseudo triedu :dir(rtl) pre RTL špecifické prepisovania.

Skontrolujte všetky ikony na určenie smeru. Nahraďte ikony so smerom zobrazenia zrkadlenými verziami alebo použite CSS transform: scaleX(-1) pre RTL kontexty.

Chyba č. 7: Obrázky s textom

Vkladanie textu do obrázkov — či už v hlavných banneroch, tlačidlách, infografikách alebo snímkach obrazovky — je nočná mora lokalizácie. Každý obrázok s textom musí byť pre každý jazyk vytvorený nanovo, čo zvyšuje náklady na dizajn a zdržuje vydania.

['Nikdy nepoužívať preložený text priamo do rastrových obrázkov (PNG, JPG)', 'Používajte CSS text overlays na pozadí obrázkov pre hero bannery a CTA', 'Automatizujte generovanie snímok obrazovky pre App Store listingy a marketingové stránky']

Nikdy nevkladajte prekladaný text priamo do rastrových obrázkov (PNG, JPG).

Používajte CSS prekrytia textu na pozadie obrázkov pre hero bannery a CTA.

Automatizujte generovanie snímok obrazovky pre zoznamy App Store a marketingové stránky.

Bežný scenár

Dizajnér vytvorí promo-banner s textom 'Start Your Free Trial', vloženým priamo do obrázka.

Tím lokalizácie preloží všetky UI reťazce, ale banner na nemeckej stránke stále ukazuje anglický text.

Výsledok: nemecká vstupná stránka má rušivý anglický banner. Vytvorenie lokalizovaných bannerov pre 15 jazykov trvá 3 dni dizajnu a oneskoruje spustenie.

Prečo je to problém

Typická marketingová stránka má 5–10 obrázkov s textom. Pri 15 jazykoch to je 75–150 variant obrázkov, ktoré treba vytvárať, udržiavať a pri každej zmene dizajnu aktualizovať.

Text vložený do obrázkov (PNG, JPG, SVG s textom vo vnútri) sa nedá extrahovať prekladačnými nástrojmi. Každá lokalizovaná verzia vyžaduje, aby dizajnér ručne upravil zdrojový súbor, exportoval ho a nahral.

Používatelia vidia obrázky s textom v cudzom jazyku, alebo ešte horšie – zmiešaný preložený UI a nepreložené obrázky. Pôsobí to nekonzistentne a podkopáva dôveru v značku.

Ako to vyriešiť

Oddelte text od obrázkov pomocou CSS prekrytí, SVG s preložiteľnými textovými prvkami alebo dynamickou generáciou obrázkov.

Použite CSS na umiestnenie preloženého textu nad pozadie: umiestnite textovú vrstvu s absolútnym pozicionovaním nad kontajner obrázka.

Pre infografiky alebo diagramy používajte SVG s prvkami <text>, ktoré odkazujú na preložené kľúče, namiesto vkladania surových reťazcov.

Pre marketingové materiály na obrázkoch aplikácií automatizujte generovanie snímok obrazovky pomocou nástrojov ako Fastlane (Mobile) alebo Playwright (Web), ktoré zachytia snímky v každej locale.

Chyba č. 8: Nezachytené chýbajúce preklady

Preklady počas vývoja sú vždy neúplné. Nové funkcie pridávajú reťazce rýchlejšie, než ich prekladači dovedú preložiť. Bez správneho fallback-handlingu spôsobujú chýbajúce preklady pády aplikácie, prázdne UI prvky alebo surové kľúče prekladu, ktoré sa zobrazujú užívateľom.

['Vždy nastavte aspoň jeden záložný jazyk vo vašom i18n nastavení', 'Zaznamenávajte chýbajúce prekladové kľúče do vášho monitorovacieho systému na sledovanie', 'Nastavte minimálnu úroveň pokrytia prekladu skôr než bude lokalizácia uvedená do prevádzky']

Vždy nakonfigurujte aspoň jeden záložný jazyk vo vašom i18n nastavení.

Zaznamenávajte chýbajúce kľúče prekladu do svojho monitorovacieho systému na ich sledovanie.

Nastavte minimálnu úroveň pokrytia prekladu, než bude lokalizácia aktívna.

Bežný scenár

Vývojár pridá novú oblasť 'Premium Features' s 15 novými prekladovými kľúčmi. Anglická verzia sa okamžite dodá.

Francúzske preklady ešte nie sú hotové. Francúzska verzia zobrazuje surové kľúče: 'premium.feature1.title', 'premium.feature1.description'.

Vysledok: Francúzski používatelia vidia znehustenú stránku plnú názvov kľúčov vývojárov. Tím podpory dostáva desiatky bug-reportov.

Prečo je to problém

Čím väčšia bude tvoja aplikácia, tým väčší bude rozdiel medzi anglickými reťazcami a prekladmi do iných jazykov. Aplikácia s 100 jazykmi a 2000 reťazcami by mohla kedykoľvek mať viac ako 10 000 chýbajúcich prekladov.

Bez logiky fallback vráti chýbajúci preklad buď undefined, null alebo surový reťazec kľúča (napr. 'checkout.confirmButton'). Šablóny môžu spôsobovať chyby, zlyhanie stránky alebo nič neraenderovanie.

Používatelia vidia nefunkčné UI: prázdne tlačidlá, chýbajúce popisky alebo kryptické reťazce ako 'nav.settings.title' namiesto skutočného textu. Je to mätúce a neprofesionálne.

Ako to vyriešiť

Nastavte spoľahlivý reťazec fallback a sledujte pokrytie prekladov vo všetkých lokalizáciách.

Nastavte fallback reťazec jazykov vo vašej i18n konfigurácii: chýbajúce francúzske kľúče (fr) sa automaticky vrátia na angličtinu (en).

Pridaj mechanizmus spracovania chýb pri chýbajúcich kľúčoch, ktorý bude logovať nepreložené kľúče do tvojho monitorovacieho systému (napr. Sentry, Datadog), bez narušenia používateľského zážitku.

Vytvorte dashboard pokrytia pre preklady, ktorý sleduje úroveň dokončenia pre každú lokalizáciu a blokuje vydania, ak pokrytie klesne pod prahovú hodnotu (napr. 95%).

Chyba #9: problémy s kódovaním znakov

Problémy s kódovaním sú tichými vrahmi lokalizácie. Všetko vyzerá dobre v angličtine a európskych jazykoch, ale keď pridáte čínštinu, japončinu, kórejčinu, arabčinu alebo emodži, objavia sa skreslené znaky (Mojibake). Tieto chyby je ťažké odhaliť.

['Vždy používajte UTF-8 všade — v zdrojových súboroch, databáze, API odpovediach a HTML metatagoch', 'Použite utf8mb4 v MySQL (nie len utf8), aby ste podporili plný rozsah Unicode vrátane emoji', 'Testujte s reálnym obsahom v CJK, arabčine a emoji, aby ste včas odhalili problém s kódovaním']

Používajte kódovanie UTF-8 všade — zdrojové súbory, databáza, API odpovede a HTML meta tagy.

Používajte utf8mb4 v MySQL (nie utf8), aby ste podporili úplný rozsah Unicode vrátane emoji.

Testujte s reálnym obsahom v CJK, arabčine a emoji, aby ste včas odhalili problémy s kódovaním.

Typický scenár

Vývojár nakonfiguruje MySQL databázu s latin1 poriadkom poradia (starý štandard). Zdrojový kód aplikácie používa UTF-8.

Japonskí používatelia sa registrujú svojim skutočným menom. Databáza uloží '田中太郎' ako poškodené bajty.

Výsledok: používateľský profil zobrazuje skreslený text. Ešte horšie: vyhľadávanie a triedenie sa rozbije pre všetky mená v CJK, čo zasahuje tisíce používateľov.

Prečo je to problém

Problémy s kódovaním sa šíria cez celý stack. Nesprávne nakonfigurovaná kolácia databázy môže poškodiť milióny záznamov — oprava vyžaduje drahé migrácie dát.

Nekonzistentné kódovanie v celom stacku — UTF-8 v zdrojových súboroch, Latin-1 v databáze a Windows-1252 v API odpovediach — ničí multibyte znaky. Jeden zle nakonfigurovaný stupeň spôsobí, že '日本語' sa zmení na '????' alebo 'æ—¥æœ¬èª'.

Používatelia uvidia skreslené texty, otázniky alebo prázdne štvorčeky tam, kde by mal byť ich jazyk. V najhoršom prípade sa údaje formulárov trvalo poškodí v databáze.

Ako to opraviť

Zabezpečte jednotnú kódovanie UTF-8 na každej úrovni vášho aplikačného stacku.

Nastavte všetky zdrojové súbory na UTF-8 (skonfigurujte svoj editor a .editorconfig). Do HTML vložte <meta charset='UTF-8'> a do odpovedí API 'Content-Type: application/json; charset=utf-8'.

Nastavte databázu na utf8mb4 (nie len utf8, ktorý v MySQL predstavuje podmnožinu 3 bajtov). Nastavte spojovacie kolácie na utf8mb4_unicode_ci.

Vyberte písma, ktoré pokrývajú vaše cieľové písma: latina, cyrilika, CJK, arabčina, Devanágarí. Použite systémové font-stacky alebo Google Fonts s jazykovými podskupinami pre optimálne načítanie.

Otestujte implementáciu i18n.

Test predĺženia dĺžky

Rozšírte všetky preložené reťazce o 30–40 %, aby ste simulovali zväčšenie textu, ktoré nastáva v jazykoch s bohatým slovníkom, ako nemčina, finčina alebo grečtina. Toto zahŕňa kontajnery s pevnou šírkou, orezané popisky a preťažené tlačidlá pred samotným prekladaním. Mnohé nástroje pseudo-lokalizácie ponúkajú toto ako vstavanú funkciu.

"Odoslať" → "Ṡééééñðéñ_éxpáñðéð" (40 % dlhšie)

Pseudolokalizácia

Pseudoslokalizácia nahrádza každý znak akcentovaným ekvivalentom (napríklad 'a' → 'á') a ohraničuje reťazce značkami ako [!! a !!]. Týmto spôsobom je okamžite viditeľné, ktoré reťazce sú hardkodované a ktoré pochádzajú zo systému prekladov. Spustite pseudo-lokilizáciu ako súčasť CI pipelines, aby sa regresie automaticky zachytili.

Každý text na obrazovke, ktorý nie je uzavretý v značkách [!! !!], je hardkodovaný a musí byť presunutý do lokalizácie. Tento test zachytí 95% prehliadnutých reťazcov za menej ako minútu.

"Odoslať správu" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"

Test RTL rozloženia

Aj bez arabských alebo hebrejských prekladov môžete otestovať RTL rozloženie tak, že do koreňového elementu HTML pridáte dir='rtl'. To okamžite odhalí problémy s smerovaním CSS: nesprávne zorovnané ikony, margíny na zlej strane, pokazená navigácia a zle zoradené flex-elementy. Urobte z toho štandardnú kontrolu v každom sprintovom prehľade — prepínanie trvá 10 sekúnd a odhalí problémy, ktoré by inak trvali týždne na opravy v produkcii.

Kontrolný zoznam i18n

['Všetky texty viditeľné používateľom sú presunuté do súborov zdrojov', 'Žiadne zreťazovanie reťazcov pri vytváraní viet', 'Pravidlá pre množné číslo s ICU MessageFormat alebo ekvivalent implementované', 'Formátovanie dátumu, času a čísiel používa API, ktoré rešpektuje lokalizáciu', 'RTL rozloženie otestované s arabským alebo hebrejským obsahom', 'Flexibilné UI bez pevnej šírky pre textové prvky', 'Nastavený fallback jazyk a otestované pri chýbajúcich kľúčoch', 'Kódovanie UTF-8 konzistentné vo všetkých súboroch a databázach', 'Metadáta App Store a Play Store lokalizované pre každý trh', 'Snímky obrazovky a marketingové materiály pre každý jazyk aktualizované']