10 čestih i18n grešaka i kako da ih izbegnete
Saznajte najčešće greške internacionalizacije koje programeri prave i kako da ih ispravite. Poboljšajte kvalitet lokalizacije vaše aplikacije uz ove najbolje prakse.
Internacionalizacija (i18n) izgleda jednostavno — dok ne otkrijete da nemački korisnici vide skraćene dugmiće, japanski korisnici dobijaju skraćene dijelove rečenica, a arapsko govoreći korisnici imaju potpuno pokvaren layout. Ovo nisu izuzeci. Ovo su predvidljive posledice često viđenih grešaka koje većina razvojnih timova pravi kada prvi put pristupi lokalizaciji. U ovom vodiču proći ćemo kroz 10 najčešćih i18n grešaka, tačno objasniti zašto se dešavaju i korak-po-korak pokazati kako da svaku ispravite. Bez obzira da li gradite novu aplikaciju ili nadograđujete postojeću — izbegavanje ovih zamki će vam uštedeti nedelje debugovanja i pružiti korisnicima širom sveta poliran doživljaj.
Грешка #1: Хардкодирани стрингови
Хардкодирани стрингови су основна i18n грешка. Догађа се јер програмери прво мисле да је циљ да функције раде, па планирају 'после тога очистити'. Али после тога никада не дође, и одједном имате хиљаде стрингова распоређених по стотинама фајлова.
['Podesite vaš i18n okvir pre prevođenje pre nego što napišete prvi red UI koda', 'Koristite linter dodatak da prepoznaje hardkodirane stringove u šablonama i komponentama', 'Držite prevodnički kljucevi opisnim i organizujte ih po funkciji ili stranici']
Podesite svoj i18n okvir za internacionalizaciju pre nego što napišete prvi red UI koda.
Koristi Linter dodatak kako bi prepoznao hardkodirane stringove u šablonama i komponentama
Držite ključe za prevod opisnim i organizujte ih po funkciji ili stranici.
Типичан сценарио
Развијач директно у JSX-у пише ознаку дугмета: <button>Submit Order</button>.
Aplikacija se isporučuje na engleskom i radi bez zamerki. Šest meseci kasnije kompanija se proširuje na Nemačku.
Tim za lokalizaciju otkriva više od 2.000 hardkodiranih stringova. Nadogradnja traje 3 nedelje i izaziva 47 bugova.
Zašto je to problem
У зрелој кодној бази хардкодирани стрингови могу да достигнују хиљаде. Након тога екстракција захтева измену сваког датотеке, поновно тестирање сваке компоненте i ризик од регресије на свакoм месту.
Хардкодирани стрингови су директно уткани у изворни код, шаблонe или компоненте. Непоже могу да се екстрахују, преведују или заменe за време извршавања без измене самог кода.
Korisnici u lokalizacijama koje nisu engleske vide UI elemente koji nisu prevedeni, pomešane sa prevedenim sadržajem — haotičan i neprofesionalan doživljaj.
Kako da to rešite
Premestite sve tekstove koje korisnik vidi od početka u resursne datoteke.
Postavite okvir za prevod (npr. next-intl, react-i18next, vue-i18n) pre nego što napišete vašu prvu komponentu.
Napraviite strukturu fajla resursa (npr. messages/de.json) i referencirajte sve stringove putem ključeva prevoda kao što je t('checkout.submitButton').
Dodajte pravilo lintinga ili Pre-commit-huk koji označava sirove string literale u UI komponentama.
Greška #10: Prevodi sve doslovno
Nije sav sadržaj koji treba prevesti. Nazivi brendova, imena pravnih lica, tehnički termini i neka imena proizvoda moraju ostati na originalnom jeziku. Pretjerani prijevod može izazvati pravne probleme, neusklađenost brenda i zabunu korisnika.
Napraviite glosar neprevoditi koji navodi sve nazive robnih marki, nazive proizvoda, pravna lica i stručne pojmove koji moraju ostati nepromijenjeni. Koristite odvojene prostore imena ili posebne ključeve za neprevodive sadržaje. Uvijek pružajte napomene o kontekstu kako biste izbjegli pogreške prijevoda.
Održavajte glosar 'neprevoditi' i podelite ga sa svim prevodiocima.
Koristite zaključane segmente ili odvojene namespace za brendirane i pravne termine.
Uvek obezbedite kontekstualne napomene za višeznačne stringove kako biste sprečili pogrešne prevode.
Tipičan scenario
Datoteka za prevod sadrži naziv kompanije 'CloudForge Inc.' i tehnički termin 'OAuth 2.0 Token' kao obične prevedljive nizove.
Španski prevodilac prevodi 'CloudForge' kao 'ForjaNube' i 'OAuth 2.0 Token' kao 'ficha OAuth 2.0'.
Rezultat: korisnici neće moći da nađu kompaniju pod njenim stvarnim imenom, a programeri koji čitaju špansku dokumentaciju biće zbunjeni nepoznatim prevedenim stručnim terminima.
Zašto je to problem
Jedan pogrešno preveden naziv brenda u pravnom dokumentu može učiniti ugovor nevažećim. Ispravka takvih prevoda zahteva proveru svakog stringa na svakom jeziku — nekoliko nedelja.
Kada se svi stringovi šalju na prevod bez konteksta, prevodioci mogu prevesti nazive brendova ('Apple' → 'Apfel'), pravne termine ('GmbH' → 'LLC') ili tehničke oznake koje moraju ostati na engleskom.
Korisnici neće nalaziti proizvode pod svojim poznatim brendom, pravni dokumenti referenciraće pogrešnu kompaniju, a tehnička dokumentacija postaje nerazumljiva ako se termini poput 'API Endpoint' prevedu.
Evo kako da to rešiš
Jasno označite neprevodljive elemente i obezbedite prevodiocima napomene o kontekstu.
Napravićite glosar neprevoditi koji navodi sve nazive robnih marki, nazive proizvoda, pravna lica i stručne pojmove koji moraju ostati nepromijenjeni.
Koristite odvojeni prostor imena ili posebne ključeve za neprevodljive sadržaje. Mnogi i18n alati podržavaju zaključane segmente koje prevodioci ne mogu uređivati.
Dodajte komentare za prevod koji objašnjava kontekst: Ovo je naziv brenda — ne prevoditi ili Stručni pojam — ostaviti na engleskom.
Грешка #2: Конкатенација стринга
Spajanje rečenica od fragmenata deluje na engleskom jeziku logično, ali u drugim jezicima ne funkcioniše. Poredak riječi, gramatika i rečena struktura dramatično variraju među jezicima, što povezan stringove čini neprevedljivima.
['Nikada nemoj sastavljati rečenice spajanjem prevedenih fragmenata', 'Koristi imenovane zamenjive elemente ('{name}') umesto pozicijskih ({0}) radi jasnoće', 'Obezbedi kontekstualne komentare za prevodioce koji objašnjavaju šta svaki zamenjivi element sadrži']
Nikada ne sastavljajte rečenice spajanjem prevedenih fragmenata.
Koristi imenovane zamenjive elemente ('{name}') umesto pozicijskih ({0}) radi jasnoće
Obezbedite kontekstualne komentare prevodiocima koji objašnjavaju šta sadrži svaki zamenski znak.
Tipičan scenario
Programer piše: 'You have ' + count + ' items in your ' + cartType + ' cart' — radi savršeno na engleskom.
Nemački prevodilac dobija tri odvojena fragmenta i ne može da formira gramatički tačnu rečenicu, jer red reči mora da se promeni.
Rezultat: nemački korisnici vide 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — grubo i neprofesionalno.
Zašto je to problem
Svaki spojeni niz je tikava vremenska bomba. Kod 20 jezika i 50 povezanih nizova imate 1.000 potencijalnih gramatičkih grešaka koje je potrebno ručno ispraviti.
Spajanje stringova kao 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' zahteva određeni red reči. Prevoditelji dobijaju fragmentirane kontekste koji ne mogu da ih preurede.
Korisnici vide gramatički netačne rečenice. Na nemačkom glagol se često nalazi na kraju. Na arapskom jeziku cela je struktura obrnuta. Rezultat zvuči kao besmislica.
Kako da to rešite
Koristite parametrične poruke sa imenovanim zamenjivačima, kako bi prevodioci mogli potpuno preurediti celu rečenicu.
Zameni spajanje jednim ključem poruke sa zamenjivim elementima: 'cart.summary': 'Imate {count} artikala u vašoj '{cartType}' korpi'.
Prosledite promenljive kao parametre vašoj funkciji prevoda: t('cart.summary', { count: 5, cartType: 'Premium' }).
Prevodilac sada može slobodno da preuredi: 'U vašoj '{cartType}' korpi se nalazi {count} artikala' — gramatički ispravan nemački.
Грешка #3: Ignorisanje množine
Engleski ima dve forme broja: jednine i množine. Razvojari često pretpostavljaju da svi jezici funkcionišu isto. Nisu. Poljski ima 4 forme, arapski ima 6, pa čak i jezici poput francuskog tretiraju nulu drugačije od engleskog.
['Uvek koristite ICU MessageFormat ili ekvivalentnu biblioteku za oblike množine', 'Nikada nemojte pisati sopstvenu logiku množinskog oblika — verujte CLDR pravilima', 'Testirajte oblike množine sa vrijednostima kao 0, 1, 2, 5, 21 i 100 kako biste pokrili sve kategorije']
Uvek koristite ICU MessageFormat ili ekvivalentnu biblioteku za oblike množine.
Nikada nemojte da pišete sopstvenu logiku množine — oslonite se na pravila CLDR.
Testirajte oblike množine sa vrednostima 0, 1, 2, 5, 21 i 100 kako biste obuhvatili sve kategorije.
Tipičan scenario
Programer piše: count + (count === 1 ? ' Datei' : ' Dateien') — pravilno obrađuje nemački.
Poljski prevodilac treba 4 forme: 1 plik, 2–4 pliki, 5–21 plików, 22–24 plikova. Jednostavan ternarni operator to ne može izraziti.
Rezultat: Poljaci vide '5 pliki' (neispravna forma) umesto '5 plików' (ispravna forma), a aplikacija izgleda kao da ne radi.
Zašto je to problem
Svako brojivo imenica u tvojoj aplikaciji zahteva obradu množine. Kod 50 takvih stringova i 20 jezika ima 1.000 pravila množine — nemoguće ih ručno održavati.
Jednostavna provera if/else (count === 1 ? 'Datei' : 'Dateien') pokriva samo nemački i engleski. CLDR definiše do 6 kategorija množine: zero, one, two, few, many i other. Svaki jezik koristi drugačiji skup kategorija.
Korisnici vide gramatički netačne tekstove poput '1 Nachrichten' ili potpuno netačne oblike množine. U formalnim kontekstima to narušava kredibilnost.
Kako da to rešite
Koristite ICU MessageFormat, koji podržava sva CLDR pravila množinskog broja.
Definišite poruke sa ICU-syntax: 'fileCount': '{count, plural, one {# fajl} few {# fajla} many {# fajlova} other {# fajla}}'.
Prevoditelji obezbeđuju sve potrebne oblike množine za svoj jezik. Poljski: '{count, plural, one {# plik} few {# plika} many {# plikova} other {# pliku}}'.
Vaša i18n-biblioteka tokom izvođenja automatski bira tačan oblik na osnovu CLDR pravila za aktivnu lokalizaciju.
Грешка #4: Фиксне ширине UI елемената
Dizajneri kreiraju pikselno precizne rasporede na engleskom, a programeri ih implementiraju sa fiksnim širinama. Ali prevedeni tekst može biti drastično duži ili kraći. Nemački tekst je otprilike 30% duži od engleskog, dok kineski tekst može biti 50% kraći.
['Nikada ne koristite fiksne širine u pikselima za elemente sa prevednim tekstom', 'Planirajte 40% povećanje teksta kao osnovnu referencu — neki jezici se još više šire', 'Koristite CSS Flexbox ili Grid za rasporede koji se prilagođavaju različitim dužinama teksta']
Nikada nemojte koristiti fiksne širine u pikselima za elemente sa prevedljivim tekstom.
Isplanirajte 40% povećanje teksta kao osnovu — neki jezici se još više šire.
Koristite CSS Flexbox ili Grid za rasporede koji se prilagođavaju različitim dužinama sadržaja.
Tipičan scenarij
Dizajner kreira navigacionu traku od 5 dugmića, svaki tačno 100 px širok — izgleda odlično na engleskom.
Nemački prevod: 'Settings' postaje 'Nastavenia' (13 naspram 8 znakova), 'Submit' postaje 'Odoslať' (8 naspram 6). Navigacioni panel preteče.
Rezultat: na mobilnim uređajima dugmići se slažu jedan na drugi ili se tekst seče, što navigaciju čini neupotrebljivom za nemačke korisnike.
Zašto je to problem
Svaki element sa fiksnom širinom je potencijalna tačka pucanja. Tipična aplikacija ima stotine dugmića, oznaka i kartica kojima treba da izdrže povećanje teksta.
Kontejner sa fiksnom širinom (width: 120px) i dugmići fiksne veličine se trenutno seku ili prelažu kada se tekst proširi. CSS overflow: hidden tiho sakriva sadržaj, dok overflow: visible uništava raspored.
Korisnici vide isečene oznake poput 'Einstellu...' umesto 'Einstellungen', ili dugmići preklapaju susedne elemente. Ključne akcije postaju nečitljive ili neklickabilne.
Kako to popraviti
Dizajnirajte i implementirajte fleksibilne rasporede koji se prilagođavaju dužini sadržaja svih lokalizacija.
Zamenite fiksne širine sa min-width, max-width i koristite fleksibilne rasporede. Koristite CSS Grid ili Flexbox za dinamičko raspoređivanje prostora.
Postavite prelom teksta u kontejnerima: koristite overflow-wrap: break-word i izbegavajte white-space: nowrap za prevedeni sadržaj.
Testirajte UI pomoću pseudo-lokalizacije koja produžava sve stringove za 40% kako biste simulirali worst case — pre slanja stringova prevodiocima.
Грешка #5: Формати датe и бројева
Podaci i brojevi deluju univerzalno. Ali 01/02/2025 znači 2. januar u SAD i 1. februar u Evropi. Zarezi i tačke menjaju značenje brojeva: 1,000.50 (USA) vs 1.000,50 (Srbija). Netragovo to dovodi do zabune, grešaka u podacima i gubitka poverenja.
['Nikada nemojte formatirati podatke ili brojeve ručno pomoću šablona stringova — koristite uvek Intl-API-je', 'Interno čuvajte sve podatke u ISO 8601 formatu i valutu u najmanjoj jedinici (cent) interno', 'Testirajte sa lokalima koji koriste različite decimalne zareze, različite redoslove datuma i kalendarske sisteme']
Nikada nemojte ručno formatirati podatke ili brojeve korišćenjem šablona nizova — uvek koristite Intl API.
Skladištite sve podatke u ISO 8601 i valute u najmanjoj jedinici (cent) interno.
Testirajte sa lokalama koje koriste različite decimalne zareze, redosled datuma i kalendarske sisteme.
Tipičan scenarij
Programer formatira datum kao MM/DD/YYYY i cenu kao $1,234.50 — ispravno za korisnike u SAD.
Korisnik iz Nemačke vidi datum 03/04/2025 i čita ga kao 3. april (DD/MM/YYYY konvencija). Cena $1,234.50 izgleda kao da bi trebalo biti 1.234,50.
Rezultat: korisnik rezerviše let na pogrešan datum i dovodi u pitanje format cene. Broj zahteva za podršku na nemačkom tržištu porastao je za 15%.
Zašto je to problem
Format datuma i brojeva utiče na svaki prikaz podataka u vašoj aplikaciji: tabele, dijagrami, obrasci, računi, izveštaji. Globalno rešenje pokriva stotine instanci.
Hardo kodirane format string-ove poput toLocaleDateString('en-US') ili ručno formatiranje pomoću template literala ignorišu korisničku lokalizaciju. Čak i ako je lokalizacija ispravna, pogrešan kalendarski sistem (Gregorian vs Hijri) uzrokuje probleme.
Korisnici čitaju podatke pogrešno i unose ih u pogrešanom formatu. Evropski korisnik koji vidi 03/04/2025 može protumačiti kao 3. april umesto 4. marta — propušteni termini ili pogrešne rezervacije.
Kako to ispraviš
Koristite ugrađeni API Intl ili biblioteku za formatiranje prilagođenu lokalnim podešavanjima za sve datume, vremena, brojeve i valute.
Zamenite ručno formatiranje pomoću Intl.DateTimeFormat(locale) za datume i Intl.NumberFormat(locale, { style: 'currency', currency }) za cene.
Čuvajte podatke interno u ISO 8601 formatu (YYYY-MM-DD) i formatirajte ih samo za prikaz pomoću lokalne postavke korisnika.
Testirajte kritična prikazivanja datuma i brojeva sa najmanje 5 različitih lokalizacija: en-US, de-DE, ja-JP, ar-SA i zh-CN, da biste pokrili najvažnije varijante formata.
Грешка #6: Zaborav RTL jezika
RTL jezici kao što su arapski, hebrejski i perzijski koriste se više od 500 miliona ljudi. Ipak, većina aplikacija dizajnirana je isključivo za raspored levo-desno (LTR). RTL podrška ne znači samo preokret teksta — čitav korisnički interfejs mora biti zrcaljen.
['Koristite od prvog dana isključivo logička CSS-svojstva (inline-start/end, block-start/end)', "Testirajte vašu aplikaciju sa dir='rtl' na HTML elementu na svakom sprint-review", 'Napravite RTL testnu listu za navigaciju, ikonice, forme i pokazivače napretka']
Koristite od samog početka isključivo logična CSS svojstva (inline-start/end, block-start/end).
Testirajte vašu aplikaciju sa dir='rtl' na HTML elementu pri svakom sprint pregledu.
Kreirajte RTL test spisak za navigaciju, ikone, obrasce i indikatore napretka.
Tipičan scenario
Programer koristi margin-left: 16px i text-align: left kroz celu aplikaciju — standardna LTR praksa.
Aplikacija se pokreće u Saudijskoj Arabiji. Povratna strelica pokazuje napred, bočne trake se pojavljuju na pogrešnoj strani, a numerički podaci su pogrešno poravnati.
Rezultat: arapski korisnici napuštaju aplikaciju posle 30 sekundi. Timu su potrebne 4 nedelje hitne refaktorisanja CSS-a da bi rešili problem.
Zašto je to problem
RTL podrška se tiče svake komponente u vašoj aplikaciji. Naknadno uvođenje RTL obično zahteva ponovo pisanje 30-50% svih CSS pravila i proveru svake ikone i izgleda.
CSS svojstva poput margin-left, padding-right, text-align: left i float: left fiksno određuju smer. Ikone sa oznakom pravca (strelice, indikatori napredovanja) pokazuju u pogrešnom smeru. Čak i vrednosti border-radius treba da budu ogledane.
Korisnici arapskog govora vide navigaciju u pogrešnom uglu, napredak ide unazad, a tekst se sudara sa UI elementima. Aplikacija deluje strano i neupotrebljiva.
Kako to otkloniš
Koristite logična CSS-svojstva i testirajte RTL raspored od početka.
Zamenite sva fizička CSS-svojstva logičkim ekvivalentima: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Postavite dir atribut na korenski HTML element u zavisnosti od aktivne lokalizacije. Koristite CSS pseudo-klasu :dir(rtl) za RTL-specifična prepravke.
Proverite sve ikonice na smer. Zamenite ikonice sa smerom na zrcalne verzije ili koristite CSS transform: scaleX(-1) za RTL kontekste.
Грешка #7: Слике са текстом
Tekst u slikama — bilo da u hero banerima, dugmićima, infografikama ili snimcima ekrana — predstavlja noćnu moru lokalizacije. Svaka slika sa tekstom mora biti ponovo izrađena za svaki jezik, što povećava troškove dizajna i odlaže izdanje.
['Nikada nemojte uvlačiti prevedeni tekst direktno u raster slike (PNG, JPG)', 'Koristite CSS-tekstualne preklapanja na pozadinskim slikama za hero banere i CTA', 'Automatizujte generisanje snimaka za App Store listinge i marketinške stranice']
Nikada ne ubacujte prevedljiv tekst direktno u raster slike (PNG, JPG).
Koristite CSS tekstna prekrivanja na pozadinama slika za hero banere i CTA.
Automatizujte generisanje snimaka ekrana za App Store listing-e i marketinške stranice.
Tipičan scenario
Dizajner pravi promo-banner sa tekstom 'Start Your Free Trial' ugrađenim direktno u sliku.
Tim za lokalizaciju prevede sve UI tekstove, ali baner na nemačkoj verziji i dalje prikazuje engleski tekst.
Rezultat: nemačka landing stranica ima zbunjujući engleski banner. Kreiranje lokalizovanih banera za 15 jezika traje 3 dana dizajna i odlaže pokretanje.
Zašto je to problem
Tipična marketinška stranica ima 5–10 slika sa tekstom. Kada postoji 15 jezika, to je 75–150 varijanti slika koje treba kreirati, održavati i ažurirati pri svakoj promjeni dizajna.
Tekst koji je ugrađen u slike (PNG, JPG, SVG sa ugrađenim tekstom) ne može biti izvučen iz alata za prevođenje. Svaka lokalizovana verzija zahteva da dizajner ručno uređuje izvorni fajl, eksportuje ga i učita.
Korisnici vide slike sa tekstom na stranom jeziku, ili još gore, mešavinu prevedenog korisničkog interfejsa (UI) i neprevedenih slika. To deluje nekonzistentno i narušava poverenje u brend.
Kako da to rešite
Podelite tekst od slika pomoću CSS preklapanja, SVG-a sa prevodljivim tekstualnim elementima ili dinamičkom generacijom slika.
Koristite CSS da postavite prevedeni tekst iznad pozadine: pozicionirajte tekstni sloj apsolutnim pozicioniranjem iznad kontejnera slike.
Za infografike ili dijagrame koristite SVG-ove sa <text> elementima koji referenciraju prevedene ključeve, umesto da ugradite sirove stringove.
Za screenshot-ove aplikacije u marketinškim materijalima automatizujte generisanje snimaka ekrana alatima poput Fastlane (Mobile) ili Playwright (Web), koji uzimaju snimke u svakoj lokalizaciji.
Greška broj 8: Neobrađeni ili nedovršeni prevodi
Prevodi tokom razvoja su uvek nepotpuni. Nove funkcije dodaju tekst brže nego prevodioci mogu da ih prevedu. Bez pravilne fallback logike nedostajući prevodi uzrokuju padove, prazne UI elemente ili sirove ključeve prevoda koji se prikazuju korisnicima.
['Uvek dodajte bar jedan rezervni jezik u vašem i18n podešavanju', 'Logujte nedostajuće ključeve prevoda u vaš monitoring sistem za praćenje', 'Postavite minimalni nivo pokrivenosti prevodom pre nego što lokalizacija izađe u produkciju']
Uvek konfigurišite bar jedan fallback jezik u vašem i18n okruženju.
Zabeležite nedostajuće ključeve prevoda u vaš sistem za nadzor radi praćenja.
Postavite minimalni nivo pokrivenosti prevodom pre nego što lokalizacija postane live.
Tipičan scenario
Inženjer doda novi odeljak 'Premium Features' sa 15 novih prevodnih ključeva. Engleska verzija se odmah isporučuje.
Francuska prevodi još nisu završeni. Francuska verzija prikazuje sirove ključeve: 'premium.feature1.title', 'premium.feature1.description'.
Rezultat: Francuski korisnici vide pokvarenu stranicu prepune imena ključev develperskog koda. Support tim dobija desetin bug-izveštaja.
Zašto je to problem
Što je veća vaša aplikacija, to je veća rupa između engleskih stringova i prevoda na ostale jezike. Aplikacija sa 100 jezika i 2000 stringova može u bilo kom trenutku imati više od 10.000 nedostajućih prevoda.
Bez fallback logike nedostajući prevod može da vrati undefined, null ili sirovi string (npr. 'checkout.confirmButton'). Template motori mogu da izazovu greške, stranica može da se sruši ili ništa ne renderuje.
Korisnici vide pokvareni UI: prazna dugmad, nedostaju etikete ili kryptične stringove poput 'nav.settings.title' umesto pravog teksta. To je zbunjujuće i neprofesionalno.
Kako da to rešite
Konfigurišite robusnu fallback šemu i pratite pokrivenost prevoda kroz sve lokalizacije.
Postavite fallback jezički lanac u vašoj i18n konfiguraciji: nedostajući francuski ključevi (fr) automatski će se vratiti na engleski (en).
Dodajte mehanizam za logovanje nedostajućih ključeva, koji će logovati neprevedene ključeve u vaš monitoring sistem (npr. Sentry, Datadog), bez narušavanja korisničkog iskustva.
Napravite dashboard pokrivenosti prevodima koji prati nivo završetosti za svaku lokalizaciju i blokira izdanja kada pokrivenost opadne ispod praga (npr. 95%).
Greška #9: problemi kodiranja karaktera
Problemi sa kodiranjem su tiha ubica lokalizacije. Sve izgleda u redu na engleskom i evropskim jezicima, ali kada dodate kineski, japanski, korejski, arapski ili emoji, javljaju se iskrivljeni znakovi (Mojibake). Ovi bagovi su teško otkriti.
['Uvek koristite UTF-8 kodiranje svuda — u izvorima, bazi podataka, API odgovorima i HTML meta tagovima', 'Koristite utf8mb4 u MySQL (ne utf8) da biste podržali puni Unicode opseg, uključujući emoji', 'Testirajte sa stvarnim sadržajem na CJK, arapskom i emoji kako biste ranije uhvatili probleme sa kodiranjem']
Koristite UTF-8 kodiranje svuda — izvorni fajlovi, baza podataka, API odgovori i HTML meta tagovi.
Koristite utf8mb4 u MySQL (ne utf8) kako biste podržali čitav Unicode opseg uključujući emoji.
Testirajte sa pravim sadržajem na CJK, arapskom i emoji da biste rano otkrili problema sa kodiranjem.
Tipičan scenario
Развојни он настройва базу података MySQL са latin1 сортирањем (стари стандард). Изворни код апликације користи UTF-8.
Јапански корисници се региструју својим стварним именом. База података чува '田中太郎' kao оштећене бајтове.
Резултат: кориснички профил приказује извртање текста. још горе: претраживање и сортирање се руши за сва имена ЦJK, што погађа хиљаде корисника.
Zašto je to problem
Problemi kodiranja se šire čitavim stack-om. Pogrešno konfigurisan kolacioni baze podataka može oštetiti milione zapisa — popravka zahteva skupe migracije podataka.
Nekonzistentno kodiranje čitavog steka — UTF-8 u izvorima, Latin-1 u bazi podataka i Windows-1252 u API odgovorima — uništava multibyte znakove. Jedan pogrešno konfigurisan sloj pretvara '日本語' u '????'.
Korisnici vide iskrivljene tekstove, upitnike ili prazne kvadratiće tamo gde bi trebalo da bude njihov jezik. U najgorem slučaju, podaci iz obrazaca se trajno oštete u bazi.
Kako to popraviti
Obezbedite jedinstvenu UTF-8 kodnu po svakom sloju vašeg steka aplikacija.
Postavite sve izvorne datoteke na UTF-8 (konfigurišite svoj editor i .editorconfig). U HTML dodajte <meta charset='UTF-8'> i u API odgovorima 'Content-Type: application/json; charset=utf-8'.
Podesite bazu podataka na utf8mb4 (ne samo utf8, koji u MySQL predstavlja podskup od 3 bajta). Podesite kolaciju konekcije na utf8mb4_unicode_ci.
Izaberite fontove koji pokrivaju vaše ciljne pisane sisteme: latinicu, ćirilicu, CJK, arapski i Devanagari. Koristite sistemske font-stack-ove ili Google Fonts sa jezicnim podskupovima za optimalno učitavanje.
Testirajte vašu i18n implementaciju.
Test produženja dužine
Proširite sve prevedene nizove za 30–40%, kako biste simulirali proširenje teksta koje se javlja u jezicima s bogatim vokabularom, poput nemačkog, finskog ili grčkog. Ovo obuhvata kontejnere sa čvrstim širinama, isečene oznake i preopterećene dugmiće pre nego što počnete sa prevodom. Mnogi alati za pseudo-lokalizaciju nude ovo kao ugrađenu funkciju.
"Pošalji" → "Ṡééééñðéñ_éxpáñðéð" (40 % duže)
Pseudolokalizacija
Pseudoslokalizacija zamenjuje svaki znak akcentovanim ekvivalentom (npr. 'a' → 'á') i okoluje stringove markerima poput [!! i !!]. Ovime se odmah vidi koji su stringovi hardkodirani, a koji dolaze iz sistema za prevod. Pokrenite pseudoslokalizaciju kao deo CI pipelines-a kako biste automatski uhvatili regresije.
Svi tekst na ekranu koji nije uključen u oznake [!! !!] je hardkodiran i mora biti izdvojen za prevod. Ovaj test hvata 95% previdjenih stringova za manje od minuta.
"Pošalji poruku" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
Test RTL rasporeda
Čak i bez arapskih ili hebrejskih prevoda možete da testirate RTL raspored tako što ćete dodati dir='rtl' na korenski HTML element. To odmah otkriva probleme s usmerenjem CSS-a: pogrešno poravnate ikone, margine na pogrešnoj strani, pokvarena navigacija i pogrešno sortirani flex elementi. Učinite to standardnom proverom u svakom sprint pregledu — prebacivanje traje 10 sekundi i hvata probleme koji bi inače zahtevali nedelje za popravke u produkciji.
Kontrolna lista za i18n
['Сви видљиви текстови за корисника су пребачени у ресурсне датотеке', 'Ниједно спајање стринга за формирање реченица', 'Правила за множински облик са ICU MessageFormat или еквивалент реализована', 'Форматирање датума, времена и бројева користи API-е прилагођене локализацији', 'RTL распорeд тестирани са арапским или хебрејским садржајем', 'Флексибилан UI без фиксне ширине за текстуалне елементе', 'Настројен је fallback језик и тестирано за недостајуће кључеве', 'UTF-8 кодирање конзистентно преко свих датотека и база података', 'Метаподаци App Store и Play Store локализовани за свака тржишта', 'Снимке екрана и маркетиншки материјали за сваки језик ажурирани']