i18n (lokalizace)

Angličtina potřebuje „1 item / 2 items“, čeština „1 položka / 2 položky / 5 položek“. Pravidlo je 1, potom 2–4 a od pěti dál, a platí pro ceny, počty kusů v košíku, počty dnů v odhadu doručení i pro každý badge na webu. Klasická chyba je napevno zapsané `count + " položek"`, které v košíku, kam se nikdo nepodíval, vyrobí „1 položek“.

Používejte platformu, ne řetězy if-else: `Intl.PluralRules` s lokalizací `cs` vrátí kategorii a ICU formát zpráv (i18next, FormatJS/`react-intl` nebo next-intl) nechá všechny tři tvary na překladateli. Texty patří mimo komponenty do jednoho souboru na jazyk a kontrola v CI odhalí klíče, které existují v `en.json` a chybí v `cs.json`.

Formát není překlad. Stejná hodnota z API se zobrazí jako „2. 11. 2026“, „USD 1,299.00“ nebo „1 299,00 USD“ podle lokalizace a česká pravidla jsou pořadí den-měsíc-rok a mezera mezi číslem a jednotkou u měr — u webu jde hlavně o viditelný rozdíl.

Formátujte vždy přes `Intl.DateTimeFormat` a `Intl.NumberFormat` s explicitní lokalizací, nikdy `toLocaleString()` bez argumentů — to se řídí lokalizací serveru nebo prohlížeče a na každém vývojářově stroji to vypadá jinak. A nastavte časovou zónu explicitně: server v UTC a klient v Praze se po dvaadvacáté hodině neshodnou na datu, což je klasická hydratační neshoda.

Když česká verze sedí pod `/cs/` a anglická pod `/en/`, obě potřebují vlastní `<title>`, meta popis, `hreflang` značky ukazující jedna na druhou a kanonickou URL. Web, jehož české stránky sdílejí titulek s anglickými, nerankuje v ani jedné.

Kompromis je všude stejný: každý nový text musí vzniknout ve všech jazycích a projít rodilým mluvčím, každý layout musí držet, když je němčina o 40 % delší než čeština, a každá nová stránka zdvojnásobí QA. Pro produkt, který se nikdy nebude prodávat mimo Česko, je jeden jazyk poctivý — anglická verze, kterou nikdo neudržuje, je horší než žádná.