10 nejčastějších i18n chyb a jak se jich vyhnout
Vyvarujte se nákladných chyb internacionalizace. Naučte se nejčastější i18n chyby, které vývojáři dělají, a jak je ve své iOS-, Android- či webové apps zabránit.
Mezinárodní lokalizace (i18n) působí jednoduše — dokud nezjistíte, že vaši němečtí uživatelé vidí zkrácené tlačítka, japonští uživatelé dostávají roztrhané fragmenty vět a arabsky mluvící uživatelé čelí úplně rozbitým rozvržením. To nejsou okrajové případy. Jsou to očekávané důsledky častých chyb, které dělí většina vývojových týmů při prvním řešení lokalizace. V tomto průvodci projdeme 10 nejčastějších i18n chyb, přesně vysvětlíme, proč k nim dochází, a krok za krokem ukážeme, jak každou vyřešit. Ať už stavíte novou aplikaci nebo modernizujete existující, vyvarování se těchto nástrah vám ušetří týdny ladění.
Chyba č. 1: pevně zakódované řetězce
Hardkodování řetězců je nejzákladnější chybou i18n. Děje se to proto, že vývojáři nejprve zaměřují na to, aby funkce běžely, a plánují „později to uklidím“. Ale později už nikdy nepřijde a najednou máš tisíce řetězců rozmístěných po stovkách souborů.
['Nastavte i18n-framework ještě před napsáním prvního řádku UI kódu', 'Používejte linter plugin pro detekci hardkodovaných řetězců v šablonách a komponentách', 'Udržujte překladové klíče popisné a uspořádané podle funkce nebo stránky']
Nastavte i18n-framework ještě před napsáním prvního řádku UI-kódu.
Používejte nástroj lintu, který identifikuje hardkodované řetězce v šablonách a komponentách.
Udržujte překladové klíče popisné a organizované podle funkce nebo stránky.
Typický scénář
Jeden vývojář napíše štítky tlačítek přímo v JSX: <button>Submit Order</button>.
Aplikace bude dodána v angličtině a funguje bez problémů. O šest měsíců později se společnost rozšiřuje do Německa.
Tým lokalizace objeví 2 000+ hardkodovaných řetězců. Dolaďování trvá 3 týdny a způsobí 47 chyb.
Proč je to problém
Ve stávající kódové základně mohou hardkodované řetězce dosáhnout tisíců. Jejich pozdější extrakce vyžaduje zasahování do každého souboru, opětovné testování každé komponenty a riziko regresí na všech místech.
Hardkodované řetězce jsou přímo vloženy do zdrojového kódu, šablon nebo komponent. Nelze je extrahovat, přeložit nebo za běhu vyměnit bez změny samotného kódu.
Uživatelé v lokalizacích jiných než anglických vidí nestránkové UI prvky smíšené s přeloženým obsahem — chaotický a neprofesionální dojem.
Takto to opravíte
Uložte všechny uživatelsky viditelné řetězce od začátku do zdrojových souborů.
Nainstalujte překladat framework (např. next-intl, react-i18next, vue-i18n) ještě dříve než napíšete první komponentu.
Vytvořte strukturu souborů zdrojů (např. messages/de.json) a všechny řetězce odkažte pomocí překladových klíčů jako t('checkout.submitButton').
Přidejte pravidlo lintování nebo pre-commit hook, který označí tvrdě zakódované řetězce v komponentách UI.
Chyba č. 10: Překládat vše doslovně.
Ne všechno by mělo být překládáno. Značky, názvy právnických osob, technické termíny a určité názvy produktů by měly zůstat v originálním jazyce. Přílišný překlad může vyvolat právní problémy, nekonzistenci značky a zmatení uživatelů.
["Udržujte 'Nepřeložit' slovník a sdílejte ho se všemi překladateli", 'Používejte uzamčené segmenty nebo samostatné jmenné prostory pro značky a právnické termíny', 'Vždy poskytujte poznámky k kontextu pro nejednoznačné řetězce, aby se zabránilo chybám v překladu']
Udržujte slovník 'Nepřekládat' a sdílejte jej se všemi překladateli.
Používejte uzamčené segmenty nebo samostatné názvové prostory pro značkové a právní termíny.
Poskytněte vždy kontextové poznámky pro víceznačné řetězce, abyste zabránili chybným překladům.
Typický scénář
Soubor s překlady obsahuje název společnosti 'CloudForge Inc.' a technický pojem 'OAuth 2.0 Token' jako běžně přeložitelné řetězce.
Španělský překladatel překládá 'CloudForge' jako 'ForjaNube' a 'OAuth 2.0 Token' jako 'token OAuth 2.0'.
Výsledek: uživatelé nenajdou společnost pod jejím skutečným názvem a vývojáři, kteří čtou španělskou dokumentaci, jsou zmatení neznámými překládanými technickými výrazy.
Proč je to problém
Jeden špatně přeložený název značky v právním dokumentu může smlouvy učinit neplatnými. Oprava nadměrných překladů vyžaduje prověření každého řetězce v každém jazyce — úkol na několik týdnů.
Když jsou všechny řetězce posílány bez kontextu k překladu, překladatelé mohou překládat názvy značek ('Apple' → 'Apfel'), právní termíny ('GmbH' → 'LLC') nebo technické výrazy, které musí zůstat v angličtině.
Uživatelé nenacházejí produkty pod svým známým názvem značky, právní dokumenty odkazují na špatnou společnost a technická dokumentace je nejasná, pokud se termíny jako 'API Endpoint' překládají.
Tak to opravíš
Jasně označte nepřeložitelné obsahy a připravte překladatelům kontextové poznámky.
Vytvořte slovník 'Ne překládat', který vyjmenuje všechny značkové názvy, názvy produktů, právnické osoby a odborné termíny, které musí zůstat nezměněné.
Použijte samostatný jmenný prostor nebo speciální klíče pro ne–přeložitelný obsah. Mnoho nástrojů pro i18n podporuje blokované segmenty, které překladatelé nemohou upravovat.
Přidejte překladatelské komentáře/popisy do vašich souborů s překlady, které vysvětlují kontext: 'To je název značky — nepřekládej' nebo 'Odborný termín — ponechte anglicky'.
Chyba č. 2: řetězcové spojování
Věty složené z fragmentů působí v angličtině logicky, ale v jiných jazycích se slovosled, gramatika a struktura vět výrazně liší, což dělá složené řetězce nepřeložitelnými.
['Nikdy nesestavujte věty spojením přeložených fragmentů', 'Používejte pojmenované zástupce ('{name}') místo pozičních ({0}) pro jasnost', 'Poskytněte překladatelům kontextové komentáře vysvětlující obsah každého zástupce']
Nebuďte vytvářeny věty spojením přeložených fragmentů.
Používejte pojmenované zástupce ('{name}') místo pozičních ({0}) pro jasnost
Poskytněte kontextové komentáře pro překladatele, které vysvětlují, co obsahuje každý zástupný znak
Typická situace
Vývojář píše: 'You have ' + count + ' items in your ' + cartType + ' cart' — funguje perfektně v angličtině.
Německý překladatel obdrží tři samostatné fragmenty a nemůže vytvořit gramaticky správnou větu, protože slovosled musí být změněn.
Výsledek: Němčtí uživatelé uvidí 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — zní to stroze a neprofesionálně.
Proč je to problém
Každý řetězec propojený dohromady je tikající časovaná bomba. Při 20 jazycích a 50 propojených řetězcích máte 1 000 potenciálních grammatikálních chyb, které je třeba ručně opravit.
Řetězcové spojování jako 'Vítejte ' + userName + ', máte ' + count + ' nových zpráv' vyžaduje konkrétní uspořádání slov. Překladatelé dostávají nesouvislé fragmenty bez kontextu, který by bylo možné přeuspořádat.
Uživatelé vidí gramaticky nesprávné věty. V němčině bývá sloveso často na konci. V arabštině je celá struktura obrácená. Výsledek působí jako nesmysl.
Jak to vyřešit
Použijte parametrizované zprávy s pojmenovanými zástupci, aby překladatelé mohli celou větu přeuspořádat.
Nahraďte spojování jedním klíčem zprávy s zástupci: 'cart.summary': 'Máte {count} položek ve vašem '{cartType}' košíku'.
Předávejte proměnné jako parametry funkci pro překlad: t('cart.summary', { count: 5, cartType: 'Premium' }).
Překladatelé nyní mohou volně měnit pořadí: 'V vašem '{cartType}' košíku je {count} položek' — gramaticky správná němčina.
Chyba č. 3: ignorování množného čísla
Angličtina má dvě formy množného čísla: singulár a plurál. Vývojáři často předpokládají, že všechny jazyky fungují stejně. Není tomu tak. Polština má 4 formy, arabština má 6 a dokonce jazyky jako francouzština zachází s nulou jinak než angličtina.
['Vždy používejte ICU MessageFormat nebo ekvivalentní knihovnu pro množitelné obsahy', 'Nikdy nepíšte vlastní logiku pro množiny — důvěřujte pravidlům CLDR', 'Otestujte množiny s hodnotami jako 0, 1, 2, 5, 21 a 100, abyste pokryli všechny kategorie']
Vždy používejte ICU MessageFormat nebo ekvivalentní knihovnu pro obsahy, které lze počítat
Nikdy nepoužívej vlastní logiku pro plurál — důvěřuj pravidlům CLDR.
Otestujte množné číslo s hodnotami jako 0, 1, 2, 5, 21 a 100, abyste pokryli všechny kategorie.
Typický scénář
Vývojář píše: count + (count === 1 ? ' Datei' : ' Dateien') — správně řeší němčinu.
Polský překladatel potřebuje 4 tvary: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliků. Jednoduchý ternár to nedokáže vyjádřit.
Výsledek: Polští uživatelé vidí '5 pliki' (špatná forma) namísto '5 plików' (správná forma), a aplikace působí, že nefunguje.
Proč je to problém?
Každý početně vyjádřitelný podstatný jmén ve vaší aplikaci potřebuje řešení pro množné číslo. Při 50 takových řetězcích a 20 jazycích je 1 000 pravidel množného čísla — nemožné ruční správy.
Jednoduché if/else kontroly (count === 1 ? 'Datei' : 'Dateien') řeší jen němčinu/angličtinu. CLDR definuje až 6 kategorií množného čísla: zero, one, two, few, many a other. Každý jazyk používá jinou podmnožinu.
Uživatelé vidí gramaticky nesprávné texty jako '1 Nachricht' nebo zcela nesprávné tvary množného čísla. Ve formálních kontextech to poškozuje důvěryhodnost.
Jak to vyřešit
Použijte ICU MessageFormat, který podporuje všechna pravidla množného čísla CLDR od začátku.
Definujte zprávy s ICU-syntaxí: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
Překladatelé poskytnou všechny potřebné tvary množného čísla pro svůj jazyk. Polština: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
Tvá i18n knihovna vybere za běhu správnou formu na základě pravidel CLDR pro aktuální locale.
Chyba č. 4: pevné šířky UI prvků
Designéři vytvářejí pixel-perfect rozvržení v angličtině a vývojáři je implementují s pevnými šířkami. Ale přeložený text může být dramaticky delší nebo kratší. Německý text je zhruba o 30 % delší než anglický, zatímco čínský text může být až o 50 % kratší.
['Nikdy nepoužívejte pevné pixely šířky u prvků s přeložitelným textem', 'Naplánujte 40% rozšíření textu jako výchozí hranici — některé jazyky se ještě více rozšíří', 'Používejte CSS Flexbox nebo Grid pro rozvržení, která se přizpůsobí proměnlivé délce obsahu']
Nikdy nepoužívejte pevné šířky v pixelech u prvků s přeložitelným textem.
Naplánujte 40% nárůst textu jako základnu — některé jazyky se dále rozšiřují.
Použijte CSS Flexbox nebo Grid pro rozvržení, které se přizpůsobují proměnlivé délce obsahu.
Typický scénář
Designér vytvoří navigační lištu se 5 tlačítky, každé přesně široké 100 px — v angličtině vypadá skvěle.
Německý překlad: 'Settings' se změní na 'Einstellungen' (13 vs 8 znaků), 'Submit' se změní na 'Absenden' (8 vs 6 znaků). Navigační lišta se přeteče.
Výsledek: Na mobilních zařízeních se tlačítka překrývají nebo je text ořezaný, což pro německé uživatele navigaci znemožňuje.
Proč je to problém
Každý prvek s pevnou šířkou je potenciálním bodem zlomu. Běžná aplikace má stovky tlačítek, štítků a karet, které musí unést rozšíření textu.
Kontejnery s pevnou šířkou (width: 120px) a tlačítka pevné velikosti se oříznou nebo přetékají, když se text rozšiřuje. CSS overflow: hidden tiše skryje obsah, zatímco overflow: visible rozbije rozvržení.
Uživatelé vidí ořezané popisky jako 'Einstellu...' místo 'Einstellungen', nebo tlačítka překrývají sousední prvky. Kritické akce jsou nečitelná nebo nejdou na ně kliknout.
Jak to vyřešit
Navrhujte a implementujte flexibilní rozvržení, která se přizpůsobí délkám obsahu ve všech lokalizacích.
Nahraďte pevné šířky minimální šířkou (min-width), maximální šířkou (max-width) a flexibilními rozvrženími. Používejte CSS Grid nebo Flexbox pro dynamické rozdělení místa.
Nastavte zalomení textu: použijte overflow-wrap: break-word a vyhněte se white-space: nowrap u přeloženého obsahu.
Otestujte UI pomocí pseudo lokalizace, která prodlouží všechny řetězce o 40 % a simulujte nejhorší případ — ještě před odesláním řetězců překladatelům.
Chyba č. 5: formátování data a čísel.
Formátování dat a čísel působí dojmem, že jsou univerzální. Ale 01/02/2025 znamená v USA 2. ledna a v Evropě 1. února. Čárky a tečky u čísel mění význam: 1,000.50 (USA) vs 1.000,50 (Německo). Dělat to špatně vede k záměně, chybám v datech a ztrátě důvěry.
['Nikdy nevytvářej ruční formátování dat či čísel pomocí string templates — vždy používej Intl-API', 'Ulož všechna data v ISO 8601 a měny interně v nejmenší jednotce (centy)', 'Otestuj s locale, které používají různé desetinné oddělovače, pořadí data a kalendářní systémy']
Nikdy neformátujte data ani čísla ručně pomocí šablon řetězců — vždy používejte Intl API.
Ukládejte všechna data v ISO 8601 a měny v interní nejmenší jednotce (cent).
Otestujte s locale, které používají odlišné desetinné oddělovače, pořadí dat a kalendářní systémy.
Typický scénář
Vývojář formátuje datum jako MM/DD/YYYY a cenu jako $1,234.50 — správně pro uživatele z USA.
Uživatel z Německa vidí datum 03/04/2025 a přečte si ho jako 3. duben (konvence DD/MM/RRRR). Cena $1,234.50 vypadá, že by měla být 1.234,50.
Výsledek: Uživatel zarezervuje let na nesprávné datum a zpochybní formát ceny. Počet podpůrných tiketů na německém trhu vzroste o 15%.
Proč je to problém
Formátování data a čísel zasahuje do každé vizualizace dat ve vaší aplikaci: tabulek, grafů, formulářů, faktur, zpráv. Globální oprava pokrývá stovky instancí.
Hardcodované formátovací řetězce, jako toLocaleDateString('en-US'), nebo ruční formátování šablonami ignorují skutečnou locale uživatele. I když je locale správná, ale kalendářní systém (gregoriánský vs. hijri) způsobuje problémy.
Uživatelé čtou data nesprávně a zadávají data ve špatném formátu. Evropan, který uvidí 03/04/2025, to může vyložit jako 3. duben místo 4. března — zmeškané termíny nebo špatné rezervace.
Takto to vyřešíš
Používej vestavěné API Intl nebo knihovnu pro formátování s lokalizovanou podporou pro všechna data, časy, čísla a měny.
Nahraď ruční formátování Intl.DateTimeFormat(locale) pro data a časy a Intl.NumberFormat(locale, { style: 'currency', currency }) pro ceny.
Ukládej data interně v formátu ISO 8601 (YYYY-MM-DD) a formátuj je jen pro zobrazení podle locale uživatele.
Otestujte klíčová zobrazení dat a čísel s minimálně 5 různými lokalitami: en-US, de-DE, ja-JP, ar-SA a zh-CN, abyste pokryli nejdůležitější varianty formátování.
Chyba č. 6: Zapomenuté RTL jazyky
RTL jazyky jako arabština, hebrejština a perština používají více než 500 milionů lidí. Přesto je většina aplikací navržena výhradně pro rozvržení zleva doprava (LTR). Podpora RTL není jen otočení textu — celé uživatelské rozhraní musí být zrcadleno.
['Od první chvíle používej pouze logické CSS-props (inline-start/end, block-start/end)', "Otestuj svou aplikaci s dir='rtl' na HTML-Elementu při každém sprintovém review", 'Vytvoř RTL-checklistu pro navigaci, ikony, formuláře a ukazatele průběhu']
Používejte od prvního dne výhradně logické CSS vlastnosti (inline-start/end, block-start/end)
Otestujte svou aplikaci s dir='rtl' na HTML prvku při každém sprint review.
Vytvořte RTL testovací checklistu pro navigaci, ikony, formuláře a ukazatele průběhu.
Typický scénář
Vývojář používá margin-left: 16px a text-align: left po celé aplikaci — standardní praxe LTR.
Aplikace se spustí v Saúdské Arábii. Zpětné šipky ukazují dopředu, postranní panely se objevují na špatné straně a číselná data jsou špatně zarovnána.
Výsledek: Arabští uživatelé opustí aplikaci po 30 sekundách. Tým potřebuje 4 týdny nouzového CSS-refaktoringu, aby problém vyřešil.
Proč je to problém?
Podpora RTL zasahuje do každé komponenty ve tvé aplikaci. Dodatečné zavedení RTL obvykle vyžaduje přepracování 30–50 % všech pravidel CSS a kontrolu každé ikony a rozložení.
CSS-vlastnosti jako margin-left, padding-right, text-align: left a float: left pevně zakódují směr. Ikony s orientací (šipky, ukazatele průběhu) ukazují na špatný směr. Dokonce i hodnoty border-radius musí být zrcadleny.
Arabští uživatelé vidí navigaci ve špatném rohu, ukazatele průběhu běží vzad a text naráží do UI prvků. Aplikace působí zvláštně a je nepoužitelná.
Takto to vyřešíš
Používej logické CSS-vlastnosti a otestuj RTL-rozvržení od začátku.
Nahrad všechny fyzické CSS-vlastnosti logickými ekvivalenty: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Nastav dir-attribut na kořenovém HTML prvku podle aktivní locale. Použij CSS pseudo-třídu :dir(rtl) pro RTL-specifické overrides.
Zkontroluj všechna ikon na určení směru. Nahraď orientované ikony zrcadlenými verzemi nebo použij CSS transform: scaleX(-1) pro RTL kontexty.
Chyba č. 7: Obrázky s textem
Text vložený do obrázků — ať už v hero bannerech, tlačítkách, infografikách či snímcích — je noční můrou lokalizace. Každý obrázek s textem musí být pro každou jazyk nově vytvořen, což zvyšuje náklady na design a zpožďuje vydání.
['Lepší, nikdy nepřidávat překládaný text přímo do rastrových obrázků (PNG, JPG)', 'Použij CSS překryvy textu na pozadí obrázků pro hero bannery a CTA', 'Automatizuj generování snímků obrazovek pro App Store listingy a marketingové stránky']
Nikdy nepřidávejte překládaný text přímo do rastrových obrázků (PNG, JPG).
Používejte CSS textové překryvy na pozadí pro hero bannery a CTA.
Automatizujte generování snímků obrazovky pro App Store listingy a marketingové stránky.
Typický scénář
Designér vytvoří promo banner s textem 'Start Your Free Trial' vloženým přímo do obrázku.
Tým pro lokalizaci překládá veškeré texty UI, ale banner na německé stránce stále zobrazuje anglický text.
Výsledek: Německá vstupní stránka má iritující anglický banner. Vytvoření lokalizovaných bannerů pro 15 jazyků trvá 3 dny návrhu a zpozdí spuštění.
Proč je to problém?
Typická marketingová stránka má 5–10 obrázků s textem. Při 15 jazycích je to 75–150 variant obrázků, které je třeba vytvořit, udržovat a aktualizovat při každé změně designu.
Text vložený do obrázků (PNG, JPG, SVG s vloženým textem) nelze extrahovat z překladových nástrojů. Každá lokalizovaná verze vyžaduje, aby návrhář ručně upravil zdrojový soubor, exportoval ho a nahrál.
Uživatelé vidí obrázky s textem ve cizím jazyce, nebo ještě hůř, směs překládaného UI a nepřeložených obrázků. Vypadá to nekonzistentně a podrývá to důvěru ve značku.
Jak to vyřešit
Oddělte text od obrázků pomocí CSS překryvů, SVG s textovými prvky, na které lze překládat, nebo dynamickou generací obrázků.
Použijte CSS k umístění překládaného textu nad pozadím obrázků: nastavte textovou vrstvu na absolutní polohu nad kontejnerem s obrázkem.
Pro infografiky nebo diagramy použijte SVG s elementy <text>, které odkazují na překladové klíče, místo vkládání surových řetězců.
Pro snímky obrazovky aplikací v marketingových materiálech automatizujte generování snímků pomocí nástrojů jako Fastlane (mobilní) nebo Playwright (web), které vytvářejí snímky pro každou lokalizaci.
Chyba č. 8: Neřešené chybějící překlady
Překlady jsou během vývoje vždy neúplné. Nové funkce přidávají řetězce rychleji, než je mohou překládat překladatelé. Bez správné logiky fallback způsobují chybějící překlady pády, prázdné UI prvky nebo surové klíče překladů, které se zobrazují uživatelům.
['Nastavte vždy alespoň jeden fallback jazyk ve svém i18n nastavení', 'Logujte chybějící klíče překladů do vašeho monitorovacího systému pro sledování', 'Nastavte minimální míru pokrytí překladů, než daná lokalizace půjde do produkce']
Nastavte vždy alespoň jeden fallback jazyk ve vašem i18n nastavení.
Zaznamenejte chybějící překladové klíče do monitorovacího systému pro sledování.
Nastavte minimální pokrytí překladů, než locale půjde do produkce.
Typický scénář
Vývojář přidá novou sekci 'Premium Features' s 15 novými překladovými klíči. Anglická verze je doručována okamžitě.
Překlady do francouzštiny ještě nejsou hotové. Francouzská stránka zobrazuje surové klíče: 'premium.feature1.title', 'premium.feature1.description'.
Výsledek: Francouzští uživatelé vidí rozbitou stránku plnou názvů klíčů na straně vývojáře. Podpora obdrží desítky bug-reportů.
Proč je to problém?
Čím větší je vaše aplikace, tím větší je rozdíl mezi anglickými řetězci a překlady v ostatních jazycích. Aplikace se 100 jazyky a 2 000 řetězci by mohla mít kdykoli více než 10 000 chybějících překladů.
Bez logiky fallbacku vrací chybějící klíč překladů undefined, null nebo surový text klíče (např. 'checkout.confirmButton'). Šablonové engine mohou vyvolat chyby, stránka se může zhroutit nebo nic se nevykreslí.
Uživatelé vidí rozbité UI: prázdná tlačítka, chybějící popisky nebo kryptické řetězce jako 'nav.settings.title' místo skutečného textu. To je matoucí a neprofesionální.
Jak to vyřešit
Nastavte robustní fallback řetězec a sledujte pokrytí překladů ve všech lokalizacích.
Nastavte v rámci vaší i18n konfigurace robustní fallback řetězec: chybějící klíče ve francouzštině (fr) se automaticky vrátí na angličtinu (en).
Přidej obslužný modul pro chybějící klíče (Missing-Key-Handler), který bude logovat nelokalizované klíče do tvého monitorovacího systému (např. Sentry, Datadog) a nepřeruší uživatelskou zkušenost.
Vytvoř dashboard pokrytí překladů, který sleduje míru dokončení pro jednotlivé locale a brání vydání, pokud pokrytí klesne pod prahovou hodnotu (např. 95%).
Chyba č. 9: Problémy s kódováním znaků
Problémy s kódováním znaků jsou tichými zabijáky lokalizace. Všechno vypadá správně na angličtině a evropských jazycích, ale když přidáš čínštinu, japonštinu, korejštinu, arabštinu nebo emoji, objeví se zkreslené znaky (mojibake). Tyto chyby bývají notoricky těžko odhalitelné.
['Používejte UTF-8 kódování všude — zdrojové soubory, databáze, odpovědi API a HTML meta tagy', 'Používejte utf8mb4 v MySQL (ne UTF-8), abyste podpořili plný Unicode včetně emoji', 'Testujte s reálným obsahem v CJK, arabštině a emoji, abyste chyby kódování zachytili včas']
Používejte UTF-8 kódování všude – zdrojové soubory, databáze, odpovědi API a HTML meta tagy.
Používejte utf8mb4 v MySQL (ne utf8) pro plné pokrytí Unicode včetně Emoji.
Otestujte skutečný obsah v CJK, arabštině a Emoji, abyste zachytili problémy s kódováním co nejdříve.
Typický scénář
Vývojář nastaví databázi MySQL s latin1 kolací (starý standard). Zdrojový kód aplikace používá UTF-8.
Japonští uživatelé se registrují svým skutečným jménem. Databáze ukládá '田中太郎' jako poškozené bajty.
Výsledek: uživatelský profil zobrazuje zkreslený text. Ještě hůře: vyhledávání a třídění selhává pro všechna jména CJK, což postihuje tisíce uživatelů.
Proč je to problém
Problémy s kódováním se šíří napříč vaším stackem. Špatně nakonfigurovaná kolace databáze může poškodit miliony záznamů — oprava vyžaduje nákladné migrace dat.
Nekonzistentní kódování napříč stackem — UTF-8 ve zdrojových souborech, Latin-1 v databázi a Windows-1252 v odpovědi API — ničí multibyte znaky. Jedna špatně nakonfigurovaná vrstva změní '日本語' na '????' nebo '日本èª'.
Uživatelé uvidí rozmazané texty, otázky nebo prázdná políčka, kde by měl být jejich jazyk. V nejhorším případě budou formulářová pole trvale poškozena v databázi.
Takto to vyřešíš
Vynucujte jednotné kódování UTF-8 napříč každou vrstvou vaší aplikační stack.
Nastavte všechny zdrojové soubory na UTF-8 (nastavte editor a .editorconfig). Vložte <meta charset='UTF-8'> do HTML a 'Content-Type: application/json; charset=utf-8' do odpovědí API.
Nastavte databázi na utf8mb4 (ne jen utf8, což je 3-bytesový podmnožina). Nastavte spojovací kolaci na utf8mb4_unicode_ci.
Vyberte písma, která pokrývají vaše cílové psací systémy: latinku, cyrilici, CJK, arabštinu a devanágari. Používejte systémové font-stacks nebo Google Fonts s jazykovými podmnožinami pro optimální načítání.
Otestujte svou i18n implementaci.
Test délky rozšíření
Rozšiřte všechny přeložené řetězce o 30–40 %, abyste simulovali prodloužení textu, které nastává v bohatě vyjádřených jazycích, jako je němčina, finština nebo řečtina. To pokrývá kontejnery s pevnou šířkou, zkrácené popisky a tlačítka, která překročí šířku, ještě před začátkem překladů. Mnoho nástrojů pro pseudo-lokalizaci to nabízí jako vestavěnou funkci.
"Odeslat zprávu" → "Ṡééééñðéñ_éxpáñðéð" (40% delší)
Pseudo-lokalizace
Pseudo-localizace nahrazuje každý znak akcentovaným ekvivalentem (např. 'a' → 'á') a obklopí řetězce značkami jako [!! a !!]. Tím se okamžitě ukáže, které řetězce jsou hardcodované a které pocházejí ze systému překladů. Proveďte pseudo-lokalizaci jako součást CI pipeline, aby byly regresní chyby automaticky zachycené.
Každý text na obrazovce, který není uzavřen v [!! !!]-značkách, je hardcodovaný a musí být externizován. Tento test zachytí 95 % přehlédnutých řetězců během méně než minuty.
"Odeslat zprávu" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
Test rozvržení RTL
I bez arabských ani hebrejských překladů můžeš otestovat RTL rozvržení, když do kořene HTML přidáš dir='rtl'. To ihned odhalí CSS problémy s orientací: špatně zarovnané ikony, okraje na špatné straně, nefunkční navigace a špatně řazené prvky flex. Udělej z toho standardní kontrolu v každém sprint review — trvá 10 sekund a odhalí problémy, které by jinak trvaly týdny v produkci.
i18n – kontrolní seznam
['Všechny uživatelsky viditelné řetězce jsou externě uloženy v souborech zdrojů', 'Žádné spojování řetězců pro tvorbu vět', 'Pravidla množného čísla implementována pomocí ICU MessageFormat nebo ekvivalentu', 'Formátování dat, času a čísel používá API citlivá na locale', 'RTL rozvržení testováno s obsahem v arabštině nebo hebrejštině', 'Flexibilní UI bez pevných šířek pro prvky s textem', 'Záložní jazyk nakonfigurován a testován při chybějících klíčích', 'Kódování UTF-8 konzistentní napříč všemi soubory a databázemi', 'Metadat App Store a Play Store lokalizována pro každý trh', 'Snímky obrazovky a marketingové aktiva pro každý jazyk aktualizována']