Višejezični sajt treba projektovati kao sistem za upravljanje različitim verzijama sadržaja, a ne kao jednu verziju sajta kojoj su naknadno dodati prevodi. Ključne odluke donose se pre unosa prvog teksta: kako će izgledati URL-ovi, koje stranice pripadaju kom tržištu, kako se povezuju jezičke verzije, gde se čuvaju prevodi i ko odobrava izmene.
Dobra arhitektura mora istovremeno da reši tri problema: korisnik treba lako da pronađe odgovarajući jezik i tržište, pretraživači treba da razumeju odnos između lokalizovanih verzija, a urednički tim treba bezbedno da objavljuje promene. Ako se ove stvari ne definišu unapred, sajt može imati duplikate, pogrešne preusmeravanja, neusklađene ponude i komplikovano održavanje.
Ovaj tekst se bavi tehničkim sub-intentom izrade višejezičnog sajta: arhitekturom, modelom sadržaja i kontrolama kvaliteta. Za širi komercijalni okvir razvoja sajta pogledajte stranicu izrada sajta, a ovde se fokusiramo na odluke koje nastaju kada jedan digitalni proizvod treba da podrži više jezika ili tržišta.
Jezik i tržište nisu uvek ista stvar
Prva važna odluka jeste razlikovanje jezika od tržišta. Jedan jezik može da se koristi u više zemalja, dok isto tržište može zahtevati više jezika. Na primer, engleska verzija za međunarodnu publiku nije nužno ista kao engleska verzija namenjena konkretnom tržištu. Razlike mogu postojati u valuti, pravnim informacijama, načinu kontakta, dostupnim proizvodima, rokovima isporuke ili terminologiji.
Zato struktura ne treba da polazi samo od pitanja „koji prevod imamo?“, već od pitanja „koju kombinaciju jezika i tržišta objavljujemo?“. Za svaki lokalizovani segment korisno je unapred definisati:
- jezik interfejsa i sadržaja;
- ciljnu zemlju ili grupu zemalja;
- valutu, jedinice mere i lokalni format datuma;
- kontakt podatke, poslovnu adresu i pravne stranice;
- ponudu, dostupnost proizvoda ili usluga;
- odgovornu osobu ili tim za uredničko odobrenje.
Ova specifikacija sprečava čestu grešku u kojoj se „prevedena verzija“ tretira kao potpuna lokalizacija. Prevod je samo jedan sloj; arhitektura mora da podrži i razlike koje nisu jezičke.
Izbor URL strukture za višejezični sajt
Najčešće opcije su poddirektorijumi, poddomeni i zasebni domeni. Nijedna opcija nije automatski najbolja. Izbor zavisi od brend arhitekture, upravljanja domenima, tržišta, pravnih zahteva i načina rada tima.
| Model | Primer | Prednosti | Rizici i obaveze |
|---|---|---|---|
| Poddirektorijum | example.com/de/ | Jednostavno upravljanje domenom i jasna organizacija URL-ova | Potrebna je dosledna lokalizacija svih relevantnih putanja i internih linkova |
| Poddomen | de.example.com | Može odgovarati odvojenim tehničkim ili organizacionim timovima | Više odvojenih okruženja i veća operativna složenost |
| Zaseban domen | example.de | Jasan lokalni identitet i nezavisna domena za tržište | Odvojena administracija, migracije, analitika i održavanje |
Poddirektorijumi su često praktičan izbor kada se jedan sajt razvija i održava iz centralnog CMS-a. Primer može izgledati ovako:
- /sr/ za srpski jezik;
- /en/ za englesku verziju;
- /de/ za nemačku verziju.
Ako se cilja konkretna zemlja, struktura može biti preciznija, na primer /en-gb/ i /en-us/. Važno je da oznake budu dosledne u URL-ovima, HTML atributima, XML sitemapama i CMS konfiguraciji. Ne treba mešati različite konvencije bez razloga, poput kombinovanja oznaka jezika, zemalja i marketinških naziva.
Kako doneti odluku
Pre izbora modela proverite da li tim može da upravlja svim domenima, DNS zapisima, sertifikatima, analitikom i redirekcijama. Zaseban domen može biti opravdan kada tržište ima snažan lokalni brend ili posebne pravne uslove, ali tada svaka promena zahteva koordinaciju na više svojstava.
Poddirektorijum ne rešava sam po sebi međunarodni SEO, kao što zaseban domen ne garantuje bolju vidljivost. URL je deo arhitekture, ne zamena za kvalitetan lokalizovan sadržaj i ispravne tehničke signale.
Model sadržaja u CMS-u
CMS treba da zna da je jedna stranica povezana sa više lokalizovanih verzija. Najjednostavniji model je da svaki jezik ima odvojenu stranicu, ali između njih postoji stabilna veza koja ne zavisi od naslova ili URL-a. Ako se prevod povezuje samo ručnim linkom u meniju, lako nastaju pogrešni parovi: engleska stranica vodi na nemačku verziju druge usluge ili jedna lokalizacija ostane bez odgovarajuće verzije.
Praktičan model može imati sledeća polja:
- jedinstveni identifikator sadržajne grupe;
- jezik i, po potrebi, ciljano tržište;
- status prevoda: nacrt, u pregledu, odobren ili objavljen;
- kanonski odnos prema drugim verzijama;
- lokalizovani naslov, meta podaci i slug;
- datum poslednje uredničke provere;
- zavisnosti, poput slika, dokumenata, formulara i CTA elemenata.
Ovakav model omogućava da se promena na izvornoj stranici označi kao zahtev za pregled prevoda. Ne znači da se svaka izmena automatski prevodi ili objavljuje. Automatizacija može ubrzati rad, ali urednik mora da proveri terminologiju, pravni kontekst i usklađenost ponude.
Modularni sadržaj i prevodivi elementi
Ako se stranice grade od komponenti, svaka komponenta treba jasno da razlikuje sadržaj koji se prevodi od konfiguracije koja ostaje ista. Naslov, opis, dugme, alt tekst slike i poruka forme obično su prevodivi. Interni identifikator komponente, analitički događaj ili tehnički ključ nisu tekst za prevod.
To je posebno važno kod globalnih komponenti: zaglavlja, podnožja, navigacije, bannera za kolačiće, formulara i sistemskih poruka. Jedna neprevedena poruka može narušiti poverenje čak i kada su glavne stranice dobro lokalizovane.
Hreflang, canonical i indeksiranje
Za lokalizovane verzije važno je da pretraživači dobiju konzistentne signale o tome koja stranica cilja koji jezik ili region. Google u svojoj dokumentaciji opisuje načine implementacije hreflang anotacija kroz HTML, HTTP zaglavlja ili sitemap. Bez obzira na metod, veze moraju biti međusobne: ako stranica A navodi stranicu B kao alternativu, B treba da potvrdi odnos ka A.
Primer koncepta izgleda ovako:
- srpska stranica navodi englesku kao alternativu za en;
- engleska stranica navodi srpsku kao alternativu za sr;
- obe verzije, ako postoji, navode odgovarajući x-default izbor;
- svaki URL je apsolutan i vraća status koji dozvoljava indeksiranje, kada je to namera.
Oznaka hreflang nije prevod stranice i nije mehanizam za prikazivanje druge verzije korisniku po svaku cenu. Ona je signal o varijantama za jezik ili region. Automatsko preusmeravanje na osnovu IP adrese ili jezika browsera može otežati pristup drugim verzijama, pa je bezbednije ponuditi jasan izbor jezika i tržišta. Detalje o međunarodnim verzijama i tehničkoj implementaciji treba proveriti u aktuelnoj Google dokumentaciji za lokalizovane verzije.
Canonical nije zamena za hreflang
Canonical govori koja je preferirana verzija među URL-ovima koji su dovoljno slični ili predstavljaju isti sadržajni skup. Hreflang povezuje lokalizovane alternative. Ako svaka jezička verzija kanonikalizuje sebe i međusobno su pravilno povezane, pretraživač dobija jasniji model. Ako sve verzije bez razloga upućuju canonical na jednu početnu verziju, lokalizovane stranice mogu izgubiti signal da su samostalno relevantne.
Ne treba koristiti canonical da bi se „rešio“ sadržaj koji je samo delimično preveden, pogrešno lokalizovan ili tehnički dupliran. Najpre treba razjasniti koju stranicu korisnik treba da vidi, a tek onda podesiti signale.
Navigacija, izbor jezika i korisnički tok
Prekidač jezika treba da bude dostupan na predvidivom mestu i da vodi na ekvivalentnu stranicu, kada ona postoji. Ako ekvivalent ne postoji, korisnik treba da dobije jasno objašnjenje ili da bude preusmeren na relevantnu lokalizovanu sekciju, a ne na nasumičnu početnu stranicu.
Oznake jezika treba pisati razumljivo korisniku. Zastavice nisu pouzdana zamena za naziv jezika, jer država i jezik nisu ista kategorija. Kod tržišnih varijanti korisno je prikazati i zemlju ili region, ali naziv treba da bude u skladu sa stvarnim sadržajem i ponudom.
Interni linkovi moraju ostati u okviru odgovarajuće lokalizacije kada je to moguće. Srpska usluga ne treba automatski da vodi na englesku kontakt stranicu samo zato što je njen URL prvi sačuvan u CMS-u. Isto važi za breadcrumbs, povezane članke, navigaciju i linkove u podnožju.
Prevod, lokalizacija i SEO sadržaja
Direktan mašinski prevod može biti koristan kao radna osnova, ali nije dovoljan za stranice koje objašnjavaju uslugu, pravne uslove ili tehničke karakteristike. Lokalizacija obuhvata terminologiju, stil obraćanja, formate datuma i brojeva, valutu, pozive na akciju i očekivanja korisnika na konkretnom tržištu.
Prevodilački proces treba definisati pre razvoja:
- napraviti inventar stranica, komponenti i sistemskih poruka;
- odrediti prioritetne šablone i termine;
- napraviti terminološki rečnik za proizvod, uslugu i brend;
- obezbediti prevod i urednički pregled;
- testirati tekst u stvarnom dizajnu;
- proveriti da li je sadržaj, metadata i navigacija objavljena u istoj verziji.
Tekst na jednom jeziku može biti duži ili kraći od izvornika. Zato komponente ne treba projektovati sa fiksnom visinom i pretpostavkom da će svi naslovi imati isti broj karaktera. Posebno proverite navigaciju, kartice, dugmad, tabele, forme i mobilni prikaz.
Tehnička organizacija obrazaca i konverzija
Formulari, potvrde i transakcioni mejlovi često se zaborave u planu lokalizacije. Za svako tržište treba proveriti naziv polja, obavezne podatke, format telefona, validaciju adrese, tekst saglasnosti i poruku nakon slanja. Ako se podaci obrađuju u različitim pravnim režimima, tehnički i pravni zahtevi treba da budu usklađeni pre objavljivanja.
Analitika takođe mora razlikovati jezik i tržište. Parametri ili svojstva događaja treba da budu stabilna, ali izveštaji treba da omoguće poređenje verzija bez mešanja podataka. Ne uvodite različita imena istog događaja u svakoj lokalizaciji ako će to otežati održavanje; lokalizujte korisnički prikaz tamo gde je potrebno, a tehničke ključeve držite doslednim.
Performanse i infrastruktura
Višejezični sajt povećava broj URL-ova, sadržajnih zapisa, slika, sitemap datoteka i potencijalnih kombinacija za testiranje. To ne znači da mora biti spor, ali zahteva kontrolu obima. Pre objave proverite keširanje, optimizaciju slika, učitavanje fontova i način generisanja stranica u svakoj lokalizaciji.
Posebnu pažnju zaslužuju:
- da li se isti resurs nepotrebno učitava više puta zbog promene jezika;
- da li CDN i keš razlikuju relevantne URL-ove;
- da li se neobjavljeni prevodi mogu dohvatiti kroz javne endpoint-e;
- da li XML sitemap sadrži samo kanonske, dostupne URL-ove;
- da li promene jezika utiču na server-side rendering ili generisanje metapodataka.
Pre produkcije uradite test na reprezentativnom skupu stranica: početna, usluga, članak, kontakt, forma i stranica sa greškom. Testirajte i najduže očekivane prevode, jer problemi sa prelomom teksta često nisu vidljivi u izvornom jeziku.
Kontrola kvaliteta pre lansiranja
QA za višejezični sajt treba organizovati po jeziku i po funkcionalnom scenariju. Nije dovoljno otvoriti nekoliko stranica i proveriti da li je tekst preveden. Potrebna je matrica koja povezuje URL, lokalizaciju, status sadržaja i tehničke kontrole.
- URL kontrola: nema pogrešnih slugova, petlji preusmeravanja ili mešanja jezika;
- SEO kontrola: title, meta opis, canonical, hreflang i sitemap odgovaraju objavljenoj verziji;
- sadržajna kontrola: nema neprevedenih elemenata, placeholdera ili pogrešnih tržišnih podataka;
- UX kontrola: izbor jezika vodi na očekivanu stranicu i radi na mobilnom uređaju;
- funkcionalna kontrola: forme, validacije, mejlovi i poruke rade na svakom jeziku;
- tehnička kontrola: statusi, keš, analitika i indeksiranje ponašaju se prema planu.
Posle lansiranja pratite greške u crawl-u, nepostojeće lokalizovane URL-ove, neobične skokove preusmeravanja i stranice koje su objavljene bez ekvivalentnih prevoda. Za planiranje prelaska sa postojeće arhitekture na novu korisno je pročitati i vodič o migraciji sajta i development planu za bezbedan prelazak.
Održavanje posle objave
Višejezični sajt uvodi stalni odnos između izvornog sadržaja i prevoda. Kada se promeni usluga, cena, kontakt, pravna napomena ili funkcionalnost, mora biti jasno koje lokalizacije zahtevaju pregled. Bez tog procesa verzije se brzo raziđu: jedna stranica obećava funkciju koja više ne postoji, dok druga sadrži staru adresu ili rok.
Support plan treba da obuhvati evidenciju promena, rok za pregled prevoda, vlasnika svakog tržišta, proveru linkova i periodični tehnički audit. Više o tome šta održavanje treba da pokriva nalazi se u tekstu održavanje sajta posle lansiranja.
Ako se tokom planiranja pokaže da svako tržište zahteva potpuno različite funkcije, korisničke naloge ili poslovne tokove, možda više nije reč samo o višejezičnom sajtu. Tada je korisno razmotriti razliku između prezentacionog sajta i aplikacije u tekstu Web sajt ili web aplikacija: gde prestaje prezentacija, a počinje softver.
Praktičan redosled arhitektonskih odluka
Najmanje rizičan proces ne počinje izborom plugina ili prevodilačkog servisa. Počinje specifikacijom:
- definišite jezike, zemlje i razlike između tržišta;
- izaberite model domena i URL pravila;
- modelujte veze između lokalizovanih zapisa u CMS-u;
- odredite pravila za canonical, hreflang, sitemap i preusmeravanja;
- popišite prevodive komponente, sistemske poruke i obrasce;
- definišite proces odobrenja i odgovorne osobe;
- napravite QA matricu i plan za održavanje.
Tek nakon toga ima smisla odlučivati o konkretnoj platformi, modulu ili načinu implementacije. Tehnologija treba da podrži ovaj model, a ne da ga nametne bez provere poslovnih i uredničkih zahteva.
Prvi koristan sledeći korak je inventar postojećih stranica i tabela sa kolonama: URL, jezik, ciljno tržište, vlasnik sadržaja, status prevoda i planirani ekvivalent. Taj dokument brzo pokazuje da li je projekat zaista višejezičan ili je potreban širi model lokalizacije. Na osnovu njega mogu se precizno proceniti struktura, CMS, migracija i obim testiranja.
