10 najčešćih i18n pogrešaka i kako ih izbjeci
Saznajte koje su najčešće pogreške u internacionalizaciji koje programeri prave i kako ih popraviti. Poboljšajte kvalitetu lokalizacije vaše aplikacije uz ove najbolje prakse.
Internationalizacija (i18n) djeluje jednostavno — sve dok ne shvatite da vaši njemački korisnici vide odrezane gumbe, japanski korisnici dobivaju fragmentirane rečenice, a arapsko govoreći korisnici imaju potpuno pokvaren raspored. To nisu iznimni slučajevi. To su predvidljivi učinci čestih pogrešaka koje većina razvojnih timova radi kada prvi put pristupi lokalizaciji. U ovom vodiču proći ćemo kroz 10 najčešćih i18n pogrešaka, točno objasniti zašto se događaju i korak-po-korak pokazati kako svaku ispraviti. Bilo da gradite novu aplikaciju ili nadograđujete postojeću — izbjegavanje ovih zamki uštedjet će vam tjedne debugginga.
Pogreška #1: Hardkodirani stringovi
Hardkodirani stringovi su osnovna i18n pogreška. Događa se kada programeri prvo pokušavaju uvjeriti da funkcionalnost radi, planirajući 'očistiti kasnije'. No taj trenutak nikada ne dolazi i odjednom imate tisuće stringova raspoređenih po stotinama datoteka.
['Postavite i18n okvir prije pisanja prve linije UI-koda', 'Koristite lint plugin za prepoznavanje hardkodiranih stringova u predlošcima i komponentama', 'Držite prijevodne ključeve opisne i organizirane po značajci ili stranici']
Postavite okvir i18n prije nego što napišete prvi red UI koda.
Koristite Linter dodatak kako biste prepoznali hardkodirane stringove u predlošcima i komponentama.
Držite prijevodne ključeve opisnima i organizirajte ih po znački ili stranici.
Uobičajeni scenarij
Programer piše labelu na gumbu izravno u JSX: <button>Submit Order</button>.
Aplikacija se isporučuje na engleskom i radi besprijekorno. Šest mjeseci kasnije tvrtka se proširuje na Njemačku.
Tim za lokalizaciju otkriva 2.000+ hardkodiranih stringova. Naknadna ugradnja traje 3 tjedna i uzrokuje 47 bugova.
Zašto je to problem
U zreloj bazi koda hardkodirani stringovi mogu doseći tisuće. Naknadno izdvajanje zahtijeva dodir svake datoteke, ponovno testiranje svake komponente i rizik regresija posvuda.
Hardkodirani stringovi su izravno ugrađeni u izvorni kod, predloške ili komponente. Ne mogu se izdvojiti, prevesti ili zamijeniti u vrijeme izvođenja bez promjene samog kôda.
Korisnici koji ne govore engleski vide UI elemente koji nisu prevedeni, pomiješani su s prevedenim sadržajem — kaotičan i neprofesionalan dojam.
Kako to popraviti
Premjestite sve stringove koji su vidljivi korisniku u resurse datoteke od početka.
Postavite okvir za prijevod (npr. next-intl, react-i18next, vue-i18n) prije nego što napišete prvu komponentu.
Stvori strukturu datoteka resursa (npr. messages/de.json) i referenciraj sve stringove putem ključeva prevoda kao t('checkout.submitButton').
Dodajte linting pravilo ili pre-commit hook koji označava sirove string-literal u UI komponentama.
Pogreška #10: Doslovno prevesti sve
Ne svi sadržaji bi trebali biti prevedeni. Brand imena, imena pravnih entiteta, tehnički termini i određena imena proizvoda moraju ostati na svom izvornom jeziku. Pretjerani prijevod može uzrokovati pravne probleme, nedosljednost marke i zabunu korisnika.
["Napravite 'ne prevesti' rječnik i podijelite ga sa svim prevoditeljima", "Koristite zaseban Namespace ili posebne ključ za neprevodive sadržaje", "Uvijek pružajte kontekst bilješke za višeznačne stringove kako biste spriječili pogrešne prijevode"]
Održavajte 'ne prevodi' rječnik i podijelite ga sa svim prevoditeljima.
Korištenje zaključanih segmenata ili odvojenih namespaces za pojmove marke i prava.
Uvijek pružajte kontekstualne bilješke za dvoznačne stringove kako biste spriječili pogrešne prijevode.
Uobičajeni scenarij
Datoteka prijevoda sadrži naziv tvrtke 'CloudForge Inc.' i tehnički pojam 'OAuth 2.0 Token' kao opće prevedljive stringove.
Španjolski prevoditelj preveo je 'CloudForge' kao 'ForjaNube' i 'OAuth 2.0 Token' kao 'ficha OAuth 2.0'.
Rezultat: korisnici ne pronalaze tvrtku pod njenim stvarnim imenom, a programeri koji čitaju španjolsku dokumentaciju zbunjeni su prevedenim tehničkim izrazima koji nisu poznati.
Zašto je to problem
Jedan pogrešno preveden naziv marke u pravnom dokumentu može ugovor učiniti nevažećim. Ispraviti pretjerane prijevode zahtijeva provjeru svake stringa na svakom jeziku — nekoliko tjedana.
Ako se svi stringovi šalju na prijevod bez konteksta, prevoditelji mogu prevesti nazive marki ('Apple' → 'Apfel'), pravne pojmove ('GmbH' → 'LLC') ili tehničke oznake koje moraju ostati na engleskom.
Korisnici ne pronalaze proizvode pod poznatim imenom marke, pravni dokumenti referenciraju pogrešnu tvrtku, a tehnička dokumentacija postaje nejasna ako se pojmovi poput 'API Endpoint' prevedu.
Kako to popraviti
Jasno označite sadržaje koje nije moguće prevesti i pružite prevoditeljima kontekstne napomene.
Napravite rječnik 'ne prevesti' koji navodi sve nazive marki, nazive proizvoda, pravna tijela i tehničke termine koje treba ostaviti nepromijenjene.
Koristite zaseban Namespace ili posebne ključeve za neprevedljive sadržaje. Mnogi i18n alati podržavaju 'zaključane' segmente koje prevoditelji ne mogu uređivati.
Dodajte prevoditeljima komentare/opise u vašim prijevodnimdatotekama koji objašnjavaju kontekst: 'Ovo je naziv marke — ne prevesti' ili 'Tehnički termin — ostaviti na engleskom'.
Pogreška #2: Spajanje stringova
Spajanje rečenica iz fragmenata zvuči na engleskom logično, ali na drugim jezicima ne funkcionira. Redoslijed riječi, gramatika i struktura rečenica značajno variraju među jezicima, što spojene stringove čini neprevodljivima.
['Nikada ne sastavljajte rečenice spajanjem prevedenih fragmenata', 'Koristi imenovane zamjenske znakove ('{name}') umjesto pozicijskih ({0}) radi jasnoće', 'Pružaj kontekstualne komentare prevoditeljima koji objašnjavaju što svaki zamjenski znak sadrži']
Nikada ne sastavljajte rečenice spajanjem prevedenih fragmenata.
Koristi imenovane zamjenske znakove ('{name}') umjesto pozicijskih ({0}) radi jasnoće
Pružite kontekstualne komentare prevoditeljima koji objašnjavaju što svaki zamjenski znak sadrži.
Tipičan scenarij
Programer piše: 'You have ' + count + ' items in your ' + cartType + ' cart' — funkcionira savršeno na engleskom.
Njemački prevoditelj prima tri odvojena fragmenta i ne može sastaviti gramatički ispravnu rečenicu jer se red riječi mora promijeniti.
Rezultat: Njemački korisnici vide 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — napola neuredno i nepouzdano.
Zašto je to problem
Svaka spojena string je tik-tak bomba. S 20 jezika i 50 povezanih stringova imate 1.000 potencijalnih gramatičkih pogrešaka koje se moraju ručno ispraviti.
Spajanje stringova poput 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' zahtijeva određeni raspored riječi. Prijevodi dobivaju nepovezane fragmente koje ne mogu prilagoditi.
Korisnici vide gramatički netočne rečenice. Na njemačkom je glagol često na kraju rečenice. Na arapskom je cijela struktura obrnuta. Rezultat zvuči poput besmisla.
Kako to popraviti
Koristite parametarizirane poruke s imenovanim zamjenskim mjestima kako bi prevoditelji mogli preurediti cijelu rečenicu.
Zamijeni spajanje s jednim ključem poruke s zamjenskim znakovima: 'cart.summary': 'Imate {count} artikala u vašoj '{cartType}' košarici'.
Pretvorite varijable u parametre funkcije za prijevod: t('cart.summary', { count: 5, cartType: 'Premium' }).
Prevoditelji sada mogu slobodno preurediti: 'U vašoj '{cartType}' košarici nalazi se {count} artikala' — gramatički ispravan njemački.
Pogreška #3: Ignoriranje množine
Engleski ima dva oblika množine: jednina i množina. Razvijači često pretpostavljaju da svi jezici funkcioniraju jednako. Nije tako. Poljski ima 4 oblike, arapski 6, pa čak i jezici poput francuskog drugačije tretiraju nulu nego engleski.
['Uvijek koristite ICU MessageFormat ili sličnu biblioteku za sadržaje koji se broje', 'Nikada ne pišite vlastitu logiku za množinske oblike — povjerite se pravilima CLDR', 'Testirajte množine s vrijednostima poput 0, 1, 2, 5, 21 i 100 kako biste obuhvatili sve kategorije']
Uvijek koristite ICU MessageFormat ili ekvivalentnu biblioteku za brojive sadržaje.
Nikada ne pišite vlastitu logiku množine — oslonite se na CLDR pravila.
Testirajte množinu s vrijednostima poput 0, 1, 2, 5, 21 i 100 kako biste obuhvatili sve kategorije.
Tipičan scenarij
Programer piše: count + (count === 1 ? ' Datei' : ' Dateien') — ispravno za njemački.
Poljski prevoditelj treba 4 forme: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. Jednostavan ternarni ne može izraziti ovo.
Rezultat: Poljski korisnici vide '5 pliki' (pogrešan oblik) umjesto '5 plików' (točan oblik), a aplikacija djeluje kao pokvarena.
Zašto je to problem
Svaki brojivi imenicu u tvojoj aplikaciji treba upravljanje množinom. S 50 takvih stringova i 20 jezika to su 1.000 pravila množine — nemoguće je ručno održavati.
Jednostavne provjere if/else (count === 1 ? 'Datei' : 'Dateien') rješavaju samo njemački i engleski. CLDR definira do 6 kategorija množine: zero, one, two, few, many i other. Svaki jezik koristi drugačiji podskup.
Korisnici vide gramatički netočne tekstove poput '1 Nachrichten' ili potpuno pogrešne oblika množine. U formalnim kontekstima to narušava vjerodostojnost.
Kako to popraviti
Koristite ICU MessageFormat koji iz kutije podržava CLDR pravila množine.
Definirajte poruke s ICU-sintaksom: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
Prijevoditelji pružaju sve potrebne oblike množine za svoj jezik. Poljski: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
Tvoja i18n-knjižnica pri pokretanju automatski odabire ispravan oblik temeljen na CLDR pravilima aktivne locale.
Pogreška #4: Statične širine elemenata sučelja
Dizajneri stvaraju pixeleski precizne rasporede na engleskom, a programeri ih implementiraju s fiksnim širinama. Ali prevedeni tekst može biti znatno dulji ili kraći. Njemački tekst je otprilike 30% duži od engleskog, dok kineski tekst može biti oko 50% kraći.
['Nikada nemojte koristiti fiksne px širine za elemente s prevedljivim tekstom', 'Planirajte 40% proširenje teksta kao baseline — neke jezike se još više šire', 'Koristite CSS Flexbox ili Grid za rasporede koji se prilagođavaju promjenjivim duljinama sadržaja']
Nikada nem koristite fiksne širine u pikselima za elemente s prevedivim tekstom.
Planirajte 40% proširenje teksta kao bazu — neke jezike se proširuju još više.
Korisite CSS Flexbox ili Grid za rasporede koji se prilagođavaju varijabilnoj duljini sadržaja.
Jedan tipičan scenarij
Dizajner stvara navigacijski izbornik s 5 gumba, svaki širine točno 100px — izgleda savršeno na engleskom.
Njemački prijevod: 'Settings' postaje 'Einstellungen' (13 naspram 8 znakova), 'Submit' postaje 'Absenden' (8 naspram 6). Navigacijski bar prelazi granicu.
Rezultat: na mobilnim uređajima gumbi se slažu jedan na drugi ili tekst je prekinut, što čini navigaciju za njemačke korisnike neprikladnom.
Zašto je to problem
Svaki element s fiksnom širinom predstavlja potencijalno mjesto kvara. Uobičajena aplikacija ima stotine gumba, oznaka i kartica koje sve moraju podnijeti proširenje teksta.
Kontejner širine koja je fiksna (width: 120px) i gumbi fiksne veličine se skraćuju ili izlaze iz okvira kada se tekst proširi. CSS overflow: hidden tiho skriva sadržaj, dok overflow: visible uništava raspored.
Korisnici vide odrezane oznake poput 'Einstellu...' umjesto 'Einstellungen', ili gumbi koji preklapaju susjedne elemente. Ključne akcije postaju nečitljive ili neklikabilne.
Kako to popraviti
Dizajnirajte i implementirajte fleksibilne rasporede koji se prilagođavaju dužini sadržaja svih lokalizacija.
Zamijenite fiksne širine s min-width, max-width i Flex layout-ima. Upotrijebite CSS Grid ili Flexbox za dinamičko raspoređivanje prostora.
Postavite tekstni spremnik na prelamanje: koristite overflow-wrap: break-word i izbjegavajte white-space: nowrap kod prevedivog sadržaja.
Testirajte svoj UI s pseudo-lokalizacijom koja produžuje sve nizove za 40% kako biste simulirali worst-case — prije nego što pošaljete stringove prevoditeljima.
Pogreška #5: Formatiranje datuma i brojeva
Podaci i brojevi djeluju univerzalno, ali 01/02/2025 znači 2. siječnja u SAD-u i 1. veljače u Europi. Zarez i točka mijenjaju svoje značenje u brojevima: 1,000.50 (SAD) naspram 1.000,50 (Njemačka). Pokušaj učiniti pogrešku dovodi do zbrke, pogrešaka u podacima i gubitka povjerenja.
['Koristite od početka samo logična CSS-svojstva (inline-start/end, block-start/end)', 'Testirajte svoju aplikaciju s dir='rtl' na HTML-Elementu pri svakom sprint-revisionu', 'Napravite RTL-checklistu za navigaciju, ikone, obrasce i indikatore napretka']
Nikada ručno nem formatirajte podatke ili brojeve pomoću šablona stringova — uvijek koristite Intl API-je.
Interno pohranite sve podatke u ISO 8601 i valute u najmanjoj jedinici (centi).
Testirajte s lokalima koji koriste različite decimalne znakove, različite redoslijede datuma i različite kalendarske sustave.
Jedan tipičan scenarij
Programeri formatiraju datum kao MM/DD/YYYY i cijenu kao $1,234.50 — ispravno za korisnike iz SAD-a.
Njemački prijevod: 'Settings' postaje 'Einstellungen' (13 naspram 8 znakova), 'Submit' postaje 'Absenden' (8 naspram 6). Navigacijski bar prelazi granicu.
Rezultat: Korisnik rezervira let za pogrešan datum i dovodi u pitanje format cijene. Podršbeni zahtjevi rastu na njemačkom tržištu za 15%.
Zašto je to problem
Formatiranje datuma i brojeva utječe na svaki prikaz podataka u vašoj aplikaciji: tablice, dijagrami, obrasci, računi, izvještaji. Globalno rješenje pokriva stotine instanci.
Hardkodirane Formate stringova poput toLocaleDateString('en-US') ili ručno formatiranje s Template-Literals ignoriraju stvarnu Locale korisnika. Čak i ispravna Locale ali pogrešan kalendarski sustav (Gregorian vs Hijri) uzrokuje probleme.
Korisnici čitaju podatke pogrešno i unose ih u pogrešnom formatu. Europski korisnik, koji vidi 03/04/2025, to može protumačiti kao 3. travanj umjesto 4. ožujka — propušteni termini ili pogrešne rezervacije.
Kako to popraviti
Koristite ugrađeni Intl-API ili biblioteku za formatiranje prilagođenu lokalizaciji za sve datume, vremena, brojeve i valute.
Zamijenite ručno formatiranje s Intl.DateTimeFormat(locale) za datume i Intl.NumberFormat(locale, { style: 'currency', currency }) za cijene.
Interno spremi podatke u ISO 8601 formatu (YYYY-MM-DD) i formatiraj ih samo za prikaz prema lokali korisnika.
Testirajte kritične prikaze datuma i brojeva u najmanje 5 različitih lokalizacija: en-US, de-DE, ja-JP, ar-SA i zh-CN, kako biste pokrili najvažnije varijante formatiranja.
Pogreška #6: Zaboravljeni RTL jezici
RTL-podrška utječe na svaku komponentu u vašoj aplikaciji. RTL-nakon implementacija obično zahtijeva rewrite CSS pravila i provjeru svakog ikona i rasporeda.
['Koristite od početka samo logična CSS-svojstva (inline-start/end, block-start/end)', 'Testirajte svoju aplikaciju s dir='rtl' na HTML-Elementu pri svakom sprint-revisionu', 'Napravite RTL-checklistu za navigaciju, ikone, obrasce i indikatore napretka']
Korištenje od prvog dana isključivo logičkih CSS-svojstava (inline-start/end, block-start/end).
Testirajte svoju aplikaciju s dir='rtl' na HTML elementu pri svakom sprint pregledu.
Izradite RTL popis provjera za navigaciju, ikone, obrasce i pokazatelje napretka.
Jedan tipičan scenarij
Programer koristi margin-left: 16px i text-align: left kroz cijelu aplikaciju — standardna LTR praksa.
Aplikacija se pokreće u Saudijskoj Arabiji. Povratne strelice pokazuju naprijed, bočne trake pojavljuju se na pogrešnoj strani, a numerički podaci nisu pravilno poravnati.
Rezultat: Arabci korisnici napuštaju aplikaciju nakon 30 sekundi. Timu treba 4 tjedna hitnog refaktorisanja CSS-a da riješi problem.
Zašto je to problem
RTL-podrška utječe na svaku komponentu u vašoj aplikaciji. RTL-uvođenje naknadno obično zahtijeva ponovo pisanje 30-50% CSS pravila i provjeru svakog ikona i rasporeda.
CSS-svojine poput margin-left, padding-right, text-align: left i float: left tvrdo kodiraju smjer. Ikone s određenom smjerom (strelice, indikatori napretka) pokazuju u pogrešnom smjeru. Čak i vrijednosti border-radius moraju biti reflektirane.
Arabci korisnici vide navigaciju u pogrešnom kutu, napredak teče unatrag, a tekst se sudara s UI komponentama. Aplikacija djeluje stranom i nepouzdano.
Kako to popraviti
Koristite logična CSS-svojstva i testirajte s RTL rasporedom od početka.
Zamijenite sve fizičke CSS-Properties logičkim ekvivalentima: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Postavite dir atribut na HTML-Root element prema aktivnoj Locale. Koristite CSS pseudo-klasu :dir(rtl) za RTL-prilagođene override.
Provjerite sve ikone radi smjera. Zamijenite ikone ovisne o smjeru s mirror verzijama ili koristite CSS transform: scaleX(-1) za RTL kontekste.
Pogreška #7: Slike s tekstom
Tekst u slikama — bilo u hero bannerima, gumbima, infografikama ili snimkama zaslona — noćna je mora lokalizacije. Svaka slika s tekstom mora biti izrađena za svaki jezik, što povećava dizajnerske troškove i usporava izdanje.
['Neka prevedeni tekst nikada ne bude izravno ubačen u rasterizirane slike (PNG, JPG)', 'Koristite CSS tekstualne preklopne slojeve na pozadinskim slikama za hero bannere i CTA-e', 'Automatizirajte generiranje snimaka zaslona za App Store listinge i marketinške stranice']
Nikada nem ugrađujte prevedivi tekst izravno u raster slike (PNG, JPG).
Korištenje CSS tekstne prekrivke na pozadinskim slikama za hero bannere i CTA-ove.
Automatizirajte generiranje zaslonskih snimaka za App Store listing i marketinške stranice.
Tipičan scenarij
Dizajner stvara promotivni banner s tekstom 'Start Your Free Trial' ugrađenim izravno u sliku.
Tim za lokalizaciju prevodi sve UI-tekstove, ali baner na njemačkoj stranici i dalje prikazuje engleski tekst.
Rezultat: njemačka odredišna stranica ima zbunjujući engleski banner. Izrada lokaliziranih banera za 15 jezika traje 3 dana dizajnerskog rada i odgađa lansiranje.
Zašto je to problem
Uobičajena marketinška stranica ima 5-10 slika s tekstom. Pri 15 jezika, to je 75-150 varijanti slika koje treba izraditi, održavati i ažurirati pri svakoj promjeni dizajna.
Tekst koji je ugrađen u slike (PNG, JPG, SVG s ugrađenim tekstom) ne može se izvući iz alata za prijevod. Svaka lokalizirana verzija zahtijeva ručno uređivanje izvorne datoteke, izvoz i prijenos.
Korisnici vide slike s tekstom na stranim jezicima, ili još gore, kombinaciju prevedenog korisničkog sučelja i nepregledanih/slika koje nisu prevedene. To djeluje nekonzistentno i potkopava povjerenje u marku.
Kako to popraviti
Odvojite tekst od slika korištenjem CSS Overlaya, SVG-ova s prijevodnim ključevima ili dinamičke generacije slika.
Koristite CSS za postavljanje prevedenog teksta iznad pozadinskih slika: pozicionirajte razinu teksta apsolutno iznad kontejnera slike.
Za infografike ili dijagrame koristite SVG-ove s <text>-elementima koji referenciraju ključeve prijevoda, umjesto unošenja sirovih stringova.
Za automatsko generiranje screenshota za App Store listinge i marketinške stranice.
Greška #8: Nedostaju prijevodi nisu obrađeni
Prijevodi tijekom razvoja su uvijek nepotpuni. Nove značajke dodaju stringove brže nego što ih prevoditelji mogu prevesti. Bez ispravne fallback logike, nedostajući prijevodi uzrokuju padove, prazne UI elemente ili prikaz sirovih ključeva prijevoda korisnicima.
['Uvijek konfigurirajte barem jedan fallback jezik u vašem i18n postavu', 'Zabilježite nedostajuće prijevode na vaš sustav za praćenje radi praćenja', 'Postavite minimalnu pokrivenost prijevoda prije nego što neka lokacija ide uživo']
Konfigurirajte uvijek najmanje jedan fallback-jezik u i18n-postavkama.
Zabilježite nedostajuće prijevode u vašem sustavu nadzora radi praćenja.
Postavite minimalni udio pokrivenosti prije nego što neka lokalizacija može biti aktivna.
Tipičan scenarij
Programeri dodaju novi odjeljak 'Premium Features' s 15 novih ključeva prijevoda. Engleska verzija se isporučuje odmah.
Francuski prijevodi još nisu dovršeni. Francuska stranica prikazuje sirove ključeve: 'premium.feature1.title', 'premium.feature1.description'.
Rezultat: Francuski korisnici vide pokvarenu stranicu prepune imena ključeva programera. Tim podrške dobiva desetke bug-izvještaja.
Zašto je to problem
Što se više aplikacija širi, veći je jaz između engleskih stringova i prijevoda na drugim jezicima. Aplikacija s 100 jezika i 2.000 stringova može imati 10.000+ nedostajućih prijevoda u bilo kojem trenutku.
Bez logike fallback, nedostajući ključ prijevoda vraća undefined, null ili sirovi ključ (npr. 'checkout.confirmButton'). Predlošci enginei mogu baciti greške, stranica se može srušiti ili se ništa ne renderira.
Korisnici vide neispravan UI: prazne tipke, nedostajuće oznake ili zagonetni stringovi poput 'nav.settings.title' umjesto pravog teksta. To zbunjuje i nije profesionalno.
Hogyan oldod meg ezt
Konfigurirajte robusni fallback lanac i pratite pokrivenost prijevoda u svim lokalizacijama.
Postavite robusnu fallback jezicnu lanac: nedostajući francuski ključevi (fr) automatski se vraćaju na engleski (en).
Dodajte mehanizam za rukovanje nedostajućim ključevima koji bilježi neprevedene ključeve u vašem sustavu za praćenje (npr. Sentry, Datadog) bez narušavanja korisničkog iskustva.
Izradite ploču nadzora pokrivenosti prijevoda koja prati postotak dovršenosti za svaki locale i blokira izdavanja ako pokrivenost padne ispod zadanog praga (npr. 95%).
Pogreška #9: Problem kodiranja znakova
Problemi s kodiranjem znakova tiho su ubojica lokalizacije. Sve izgleda ispravno na engleskom i europskim jezicima, ali čim dodate kineski, japanski, korejski, arapski ili emoji, pojavljuju se iskrivljeni znakovi (Mojibake). Ovi bugovi su poznati po tome što ih je teško otkriti.
['Koristite UTF-8 kodiranje posvuda — u izvorima, bazi podataka, API odgovorima i HTML meta-tagovima', 'Koristite utf8mb4 u MySQL-u (ne utf8) kako biste podržali cijeli Unicode including emoji', 'Testirajte s pravim sadržajem na CJK, arapskom i emoji kako biste rano uhvatili kodirajuće probleme']
Kövesse a UTF-8 kódolást mindenhol — forrásfájlok, adatbázis, API-válaszok és HTML-meta-tagek.
Koristite utf8mb4 u MySQL (ne utf8), kako biste podržali cijeli Unicode raspon uključujući emoji.
Testirajte s pravim sadržajem u CJK, arapskom i emojijem kako biste rano uhvatili problema s kodiranjem.
Uobičajeni scenarij
Programer postavlja MySQL bazu podataka s latin1 kolacijom (stari zadani). Kod aplikacije koristi UTF-8.
Japanski korisnici se registriraju svojim pravim imenom. Baza podataka pohranjuje '田中太郎' kao oštećene bajtove.
Rezultat: Profil korisnika prikazuje iskrivljen tekst. Šteta: pretraživanje i sortiranje ne rade za sva CJK imena, što utječe na tisuće korisnika.
Zašto je to problem
Problemi s kodiranjem šire se kroz cijeli stack. Pogrešna kolacija baze podataka može oštetiti milijune zapisa — popravak zahtijeva skupe migracije podataka.
Nekonzistentno kodiranje u cijelom stacku — UTF-8 u izvorima, Latin-1 u bazi podataka i Windows-1252 u API odgovoru — uništava multibyte znakove. Jedna pogrešno konfigurirana boja (faseta) sloja može pretvoriti '日本語' u '????' ili '日本èª'.
Korisnici vide iskrivljene tekstove, upitnike ili prazne kvadrate na mjestu gdje bi se trebala pojaviti njihov jezik. U najgorem slučaju, unos podataka u obrasce može trajno biti oštećen u bazi podataka.
Kako to riješiti
Primijenite konzistentno kodiranje UTF-8 kroz svaki sloj vašeg stacka aplikacije.
Sve izvorne datoteke postavite na UTF-8 (konfigurirajte svoj editor i .editorconfig). U HTML dodajte <meta charset='UTF-8'> i u API odgovore postavite 'Content-Type: application/json; charset=utf-8'.
Postavite vašu bazu podataka na utf8mb4 (ne samo utf8, što je 3-bytes subset u MySQL-u). Postavite konekcijsko koliranje na utf8mb4_unicode_ci.
Odaberite fontove koji pokrivaju vaš ciljani sustav pisma: Latinicu, Cyrilicu, CJK, arapski, Devanagari. Koristite sistemske font-stackove ili Google Fonts s jezičnim podskupovima za brže učitavanje.
Testirajte svoju i18n implementaciju
Test povećanja duljine
Proširite sve prevedene nizove za 30–40% kako biste simulirali proširenje teksta koje se javlja u jezicima bogatim riječju poput njemačkog, finskog ili grčkog. To pokriva kontejnere s fiksnom širinom, izrezane oznake i previše proširene gumbe prije nego što počnete s prijevodom. Mnogi alati za pseudo-lokalizaciju nude to kao ugrađenu značajku.
"Slanje" → "Ṡééééñðéñ_éxpáñðéð" (40% dulje)
Pseudo-lokalisacija
Pseudo-lokalisacija zamjenjuje svaki znak akcentiranim ekvivalentom (npr. 'a' → 'á') i obavija nizove oznakama poput [!! i !!]. Time su odmah vidljive one poruke koje su hardkodirane i one koje dolaze iz sustava za prijevod. Pokrenite pseudo-lokalisaciju kao dio CI-pipeline kako biste automatski uhvatili regresije.
Svaki tekst na zaslonu koji nije unutar oznaka [!! !!] hardkodiran je i mora biti izvan koda. Ovaj test hvata 95% neotkrivenih stringova u manje od minute.
"Pošalji poruku" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
RTL izgled test
Čak i bez prijevoda na arapski ili hebrejski, možete testirati RTL prikaz dodavanjem dir='rtl' na korijenski HTML element. To odmah otkriva CSS bugs usmjeravanja: pogrešno poravnanje ikona, marginu na pogrešnoj strani, oštećenu navigaciju i pogrešno sortiranje Flex‑stavki. Uključite to kao standardni provjeru u svakom sprint reviewu — prebacivanje traje 10 sekundi i hvata probleme koji bi inače tjednima trajali da se riješe u Production.
Kontrolna lista i18n
['Svi stringovi koje korisnik vidi premješteni su u datoteke resursa', 'Nije dopušteno spajanje stringova za stvaranje rečenica', 'Implementirana su pravila množine koristeći ICU MessageFormat ili ekvivalent', 'Formatiranje datuma, vremena i brojeva koristi locale-érzékeny API-je', 'RTL- sučelje s arapskim ili hebrejskim sadržajem testirano', 'Fleksibilno UI bez čvrstih širina za elemente sa tekstom', 'Konfiguriran je zamjenski jezik i testirano pri nedostajućim ključevima', 'UTF-8 kodiranje dosljedno u svim datotekama i bazama podataka', 'Metapodaci App Store i Play Store lokalizirani su za svako tržište', 'Skiciranje i marketinški materijali za svaki jezik ažurirani']