Többnyelvű weboldal készítés: a fordítás megoldódott, az architektúra nem

Tíz éve a többnyelvű weboldal legdrágább tétele a fordítás volt. Ma ez a legolcsóbb: egy jó nyelvi modell percek alatt, meggyőző minőségben fordít le egy teljes oldalt. Amin a többnyelvű projektek 2026-ban elbuknak, az nem a szöveg — hanem a routing, a tartalommodell, a hreflang és a szerkesztői munkafolyamat. Aki sablonos megoldáson próbál többnyelvűsíteni, az a fordításon spórol, és az architektúrán bukik.

Ez nem elmélet: ezt a weboldalt is két nyelven — magyarul és angolul — visszük, headless CMS-en, és a cikk végén megírjuk a saját tanulságainkat is.

Locale a routingban: útvonal-prefix, aldomain vagy külön domain?

Az első és legnehezebben visszacsinálható döntés: hol él a nyelv az URL-ben?

• Útvonal-prefix (oldalad.hu/en/…): egy domain, egy deploy, a felépített domain-tekintély minden nyelvre dolgozik. A legtöbb cégnek ez a helyes alapértelmezés.

• Aldomain (en.oldalad.hu): technikailag különálló egységként kezelhető, de a keresők részben külön oldalként látják — ritkán éri meg a többletköltségét.

• Országdomain (oldalad.de, oldalad.fr): a legerősebb lokális jelzés, de minden domain külön karbantartás, külön tekintély-építés. Akkor való, ha adott piacon önálló márkajelenlétet építesz.

A rossz hír: ezt utólag váltani teljes átirányítás-térképet és újraindexelést jelent. Ezért ez az a döntés, amit a projekt legelején kell meghozni — nem a fordításkor.

A tartalommodell: nem minden mező fordítás

A sablonos többnyelvűsítés alapfeltevése, hogy a második nyelv az első tükörképe: ugyanazok az oldalak, ugyanazok a mezők, csak más szöveggel. A valóságban a piacok eltérnek: az angol nyelvű főoldaladon más érvek, más referenciák, akár más szekciók kellenek, mint a magyarban.

Ezért a tartalommodellben mezőnként kell eldönteni, mi lokalizált (cím, szöveg, akár az URL-slug is) és mi közös (képek, szerző, kategóriák). Egy jó headless CMS-ben ez beállítás kérdése; a nyelvenként eltérő struktúrát is elbírja, nem csak a lefordított szöveget. És külön figyelmet érdemel a fallback: ha egy tartalom nincs lefordítva, az adott nyelven vagy tudatosan az alapnyelvi változat jelenik meg, vagy egyáltalán nem — de ezt te döntsd el, ne a keretrendszer véletlene.

Hreflang helyesen: csak arra, ami tényleg létezik

A hreflang mondja meg a keresőnek, melyik nyelvi változatot mutassa melyik felhasználónak. Három szabálya van, és mindhármat rendszeresen elrontják:

• Csak létező fordításra mutasson. Ha egy cikknek nincs angol változata, ne hirdess rá angol alternatívát — a keresőt üres vagy rossz nyelvű oldalra küldeni rosszabb, mint nem hirdetni semmit.

• Kölcsönösnek kell lennie. Ha a magyar oldal hivatkozza az angolt, az angolnak vissza kell hivatkoznia a magyart, különben a kereső eldobja a jelzést.

• Legyen x-default. Ez mondja meg, mit kapjon az a látogató, akinek a nyelvére nincs változat — jellemzően az elsődleges piacod nyelvét.

És ami összeköti az egészet: a sitemap ugyanazt az igazságot mondja, mint a hreflang. Nyelvenként csak azok az URL-ek szerepeljenek benne, amik azon a nyelven tényleg léteznek.

A gépi fordítás jó — de itt kell mégis ember

A törzsszöveget nyugodtan rá lehet bízni a gépre, emberi átnézéssel. Van viszont néhány hely, ahol a szó szerinti fordítás pontosan a lényeget veszíti el:

• SEO-címek és meta leírások: a kulcsszó, amire a magyar piac keres, nem a tükörfordítása annak, amire az angol. Nyelvenként külön kulcsszó-logika kell.

• CTA-k és mikroszövegek: a gomb szövege konverziós kérdés, nem fordítási.

• Jogi szövegek: az adatkezelési tájékoztató és az ÁSZF nem fordítandó, hanem az adott jog szerint megírandó dokumentum.

Az AI-lokalizáció munkafolyamata

A kérdés ma már nem az, hogy használj-e AI-t a lokalizációra, hanem az, hogy milyen rendszerben. Ami nálunk bevált:

• Terminológia rögzítése előre: mit nem fordítunk (terméknevek, márkakifejezések), és mit fordítunk mindig ugyanúgy.

• Gépi első kör, emberi második: a teljes szöveget a gép fordítja, ember a hangnemet, a SEO-mezőket és a kritikus oldalakat nézi át.

• Verziószinkron: amikor az alapnyelvi tartalom frissül, jelölje a rendszer, hogy a fordítás elavult. E nélkül a nyelvek hónapok alatt észrevétlenül szétcsúsznak.

Ehhez az kell, hogy a tartalom strukturált adat legyen, ne oldalba ragadt szöveg — vagyis megint az architektúránál vagyunk. Arról, hogy egy ilyen rendszerben ki kezeli a tartalmat, itt írtunk: Headless CMS: ki tölti fel a tartalmat, ha nem a fejlesztő?

Így csináljuk ezen az oldalon — tanulságokkal

Az oslabs.digital magyar alapnyelvű, angol lokalizációval, headless CMS-en. Néhány dolog, amit menet közben tanultunk meg:

• A slug is lokalizált mező. Az angol cikkeink nem a magyar URL fordításán élnek, hanem saját, angolra írt slugon — a kereső és az olvasó is ezt várja.

• A hreflang csak a tényleg lefordított tartalmakra hirdet alternatívát, x-default a magyarra mutat; a sitemap nyelvenként csak a létező változatokat listázza. Ez kézzel karbantarthatatlan lenne — a CMS-ből generáljuk.

• A fallback kétélű. Szolgáltatásoldalnál elfogadható, hogy a hiányzó fordítás helyett az alapnyelv jelenik meg; blognál nem — ott a félig magyar „angol" oldal többet árt, mint a hiánya.

• Nem fordítunk le mindent. A magyar piacnak szóló, lokális témájú cikkeknek nincs angol változata — és ez így van jól. A többnyelvűség nem azt jelenti, hogy minden tartalom minden nyelven létezik.

Ha nemzetközi piacra készülsz, és nem szeretnéd az architektúrán elbukni, amit a fordításon megspóroltál: a webfejlesztés és az egyedi szoftverfejlesztés oldalunkon leírtuk, hogyan építünk ilyen rendszereket.