Cirill-latin és arab-latin szkript konverzió többnyelvű alkalmazásokhoz

Az internet latin karaktereken alapul. Az URL-ek latin. Az e-mail címek latin. A legtöbb operációs rendszeren lévő fájlnevek alapértelmezés szerint latin karaktereket használnak. Az adatbázis-azonosítók, API-paraméterek és rendszer által generált kódok mind a latin ASCII-aljára működnek. Ez a latin-centrikusság egy történelmi örökség, amely az internet globális terjeszkedése előtt keletkezett, azonban gyakorlati következményei minden olyan rendszerben megmaradnak, amely a világban meglévő számos nem-latin írásrendszer szövegével foglalkozik. Az egy orosz vállalat neve, amely a cirill írásban teljesen normálisnak néz ki, olvashatatlansá válik, ha URL-be kényszerítik. Az arab ember neve, amely természetesen jobbról balra folyik, technikai rejtvénnyé válik, amikor egy nyugati adatbázis mezőben kell megjelennie. Ezek az ütközések a világ nyelvészeti sokfélesége és az internet latin infrastruktúrája között naponta milliószor történnek meg, és mindegyik egy fordítást igényel, amely nem értelmet, hanem szöveget fordít le.

A transliteráció a szöveg szintjén történő fordítás szava, és fundamentálisan eltér a nyelvészeti fordítástól. A fordítás értelmet konvertál: a „ház" angol nyelvből „дом" orosszá válik, mert mindkét szó ugyanazt jelenti különböző nyelveken. A transliteráció szöveget konvertál: a „дом" cirillből „dom" latinra válik, mert ezek a latin karakterek a cirill karakterek hangjait közelítik meg. Az értelem ugyanaz marad. A nyelv ugyanaz marad. Csak az írásrendszer változik, ezért a transliterációt néha „átírásnak" inkább, mint „átjelentésnek" nevezik.

A Transliterator API ezt a szkript konverziót egy programozható szolgáltatásként biztosítja. Küldjön szöveget az egyik szkriptben, és kapja vissza egy másikban. Cirill-latin, arab-latin, görög-latin, devanagari-latin, és átfogó lista a többi szkript párról, amely a világ internethasználóinak többsége által használt írásrendszereket fedezi le. A konverzió az establecált transliterációs szabványokat követi, ahol léteznek, és fonetikailag pontos leképezéseket használ ahol az standardizált rendszerek nem lettek definiálva, olyan kimenetet előállítva, amely olvasható, kiejthetséges és alkalmas a latin karakterek szükséges technikai kontextusokra.

URL slugok és a nem-latin szöveg problémája a webes címekben

A transliteráció legalapvetőbb gyakorlati alkalmazása a webfejlesztésben a URL slugok generálása nem-latin szövegből. Az olyan blogbejegyzés, amelynek címe „Как приготовить борщ" (Hogyan készítse el a borscst), egy URL-barát slugot igényel, amely minden böngészőben, minden megosztási platformon és minden analitikai rendszeren működik. A cím cirill karakterei érvényesek az nemzetközösített domain nevekben (IDN) és nemzetközösített erőforrás-azonosítókban (IRI), azonban a gyakorlatban a legtöbb webes infrastruktúra továbbra is megbízhatatlanul kezeli őket. A kódolt cirill URL-ek hosszúak, csúnyák, és bizonyos alkalmazások között másolásakor megromlanak. Egy transliterált slug, például „kak-prigotovit-borshch", rövid, olvasható, megosztható és egyetemesen kompatibilis.

A slug generálási felhasználási eset nem csak szkriptkonverziót, hanem további feldolgozást is igényel: kisbetűsítés, szóközök helyettesítése kötőjelekkel, speciális karakterek eltávolítása és az ékezetes karakterek normalizálása. A transliterációs API a szkriptkonverziót végzi el, a cirill karaktereket latin megfelelőikre konvertálva, az alkalmazás pedig a fennmaradó normalizálási lépéseket végzi. Ez a felelősség megosztása az API-t az nyelvtanilag összetett feladatra (helyes transliteráció) összpontosítja, miközben a technikailag egyszerű feladatokat (kisbetűsítés, kötőjel beillesztés) a fejlesztő meglévő szövegfeldolgozási csatornájára hagyja.

A transliteráció minősége a slug generálásra számít, mivel a slug látható a felhasználók számára és hozzájárul az SEO-hoz. Az orosz felhasználó, aki a „kak-prigotovit-borshch" slugot találkozik, azonnal felismeri, hogy az orosz cím transliterációja, és erőfeszítés nélkül olvasható számára. Egy rosszul transliterált slug, amely helytelen karakterleképezéseket használ vagy kiejthetetlen karakterkombinációkat hoz létre, ahhoz hasonlóan néz ki gibberishnek mind az orosz, mind az angol olvasók számára. Az API fonetikailag pontos leképezéseket használ, amely a forrászszkripttől függetlenül olvasható kimenetet termel, amely a kapott slugokat gyakorlati azonosítóként és ember által olvasható szövegként is működőképessé teszi.

Az e-kereskedelmi helyek, amelyek többnyelvű piacokra eladnak, széleskörűen alkalmazzák a transliterációt a termékkódok generálásához. Az olyan termékkatalogus, amely orosz, arab, kínai és hindi nevű cikkeket tartalmaz, URL slugokat igényel, amelyek minden nyelvben működnek. Az ilyen skálán végzett kézi transliteráció gyakorlatlan, és az API-n keresztüli automatizált transliteráció konzisztens, pontos slugokat termel, amelyeket a termékimportálási csatorna részeként lehet generálni az egyes nyelvekhez szükséges emberi beavatkozás nélkül.

Útlevél nevek és szöveges dokumentum transliteráció

Az útlevél transliteráció az egyik legfontosabb alkalmazása a szkriptkonverziónak, mivel az nevek transliterációjában elkövetett hibák valós problémákat okoznak. Egy név, amely az útlevélen máshogy van transliterálva, mint egy vízumkérvényen, késleltetheti vagy megakadályozhatja a nemzetközi utazást. Egy név, amely az egyik bankrendszerben máshogy van transliterálva, mint az azonosító dokumentumban, blokkolhatja a pénzügyi tranzakciókat. Az emiatt elég magas az a tét, hogy a legtöbb ország fenntart az útlevél nevekhez szövegtransliterációs standardokat, és az API ezeket a standardokat a támogatott szövegtípusokra implementálja.

Az orosz nevek jól illusztrálják az összetettséget. Az orosz „Щ" betű „shch", „sch", „sh" vagy „sc" lehet transliterálva az alkalmazott transliterációs rendszertől függően. Az útleveleknél alkalmazott ICAO (Nemzetközi Polgári Repülési Szervezet) standard a „shch"-t határozza meg. Az amerikai és brit kormányzati ügynökségek által alkalmazott BGN/PCGN rendszer a „shch"-t határozza meg. Az académiai kontextusban alkalmazott ISO 9 rendszer egy diakritikus jelet tartalmazó egyetlen karaktert határoz meg. Az „Щербаков" nevű embernek tudnia kell, hogy az útlevele „Shcherbakov" olvasni fog, és minden egyéb dokumentumnak, amely az ő nevét tartalmazza, pontosan egyeznie kell ezzel a transliterációval. Az API több transliterációs standardot támogat, és lehetővé teszi a felhívónak, hogy meghatározza, melyik standard alkalmazzon, biztosítva, hogy a kimenet megfelel az adott kontextus követelményeinek.

Az arab név transliteráció további összetettséget ad, mivel az arab szöveg abdzsad-alapú, vagyis az magánhangzók gyakran kimaradnak a szöveges szövegből, és a transliterációhoz meg kell inferálódni. A „محمد" (Muhammad) név legitimen Muhammad, Mohamed, Mohammed, Muhammed vagy több más variáns különbözőként lehet transliterálva a transliterációs rendszertől és a regionális kiejtéstől függően. Az API konzisztens, standardnak megfelelő leképezéseket alkalmaz, amely a legszélesebb körben elismert variánsokat termel, miközben a dokumentáció felhívja az alternatív helyesírásokat, amelyeket a különbözői standardok a gyakran transliterált nevek esetén termelnek.

Az olyan bevándorlási és kormányzati rendszerek, amelyek több ország alkalmazottainak alkalmazottainak feldolgozása jutnak, a standardizált transliterációtól profitálnak, amely konzisztens kimenetet termel, függetlenül attól, hogy az alkalmazott operátor feldolgozza. Az API-alapú transliteráció nélkül az egyes operátorok saját intuitív transliterációt alkalmaznak, amely inkonzisztens kimenetet termel, amely bonyolítja az adatbázis-illesztést, az identitás-ellenőrzést és a rekord-összekapcsolást. A standardizált transliteráció az API-on keresztül biztosítja, hogy az ugyanaz a forrásszöveg mindig ugyanaz a latin kimenetet termel, amely elengedhetetlen az olyan rendszerekhez, amelyek az identitás-ellenőrzéshez szöveges egyezésre támaszkodnak.

Keresés normalizálása és tartalom keresése a szövegekben

A keresőrendszerek fundamentális kihívással szembesülnek, amikor a keresési corpus több szövegkészletet tartalmaz: egy felhasználó, aki az egyik szövegben keres, képesnek kell lennie arra, hogy a másik szövegben tárolt tartalmat találja meg, ha a tartalom szemantikailag releváns. Az az orosz felhasználó, aki a „Москва" (Moszkva) kifejezésre keres, olyan tartalmat találjon, amely a latin-szöveg indexben a „Moskva"-ra utal. Az az angol felhasználó, aki a „Moscow" kifejezésre keres, a cirill eredeti „Москва"-val tárolt tartalmat találjon. Ez a szövegközi illesztés normalizálási réteget igényel, amely a keresési lekérdezéseket és az indexelt tartalmat egy közös szövegre transliterálja az illesztés előtt.

A transliterációs API ezt a normalizálási réteget szolgálja. Az indexelés során a nem-latin tartalom transliterálódik latinra és az eredeti szöveg verzióval együtt tárolódik. A lekérdezés során a nem-latin lekérdezések a latin-normalizált index ellen illesztés előtt transliterálódnak. Ez az kettős indexelési megközelítés biztosítja, hogy a bármely támogatott szövegben történő keresés a bármely támogatott szövegben tárolt tartalmat találja meg, mivel az illesztés egy közös latin-normalizált térben történik, ahol a szövegbeli különbségek megoldódtak.

A transliteráció pontossága közvetlenül befolyásolja a keresés relevanciáját ebben az alkalmazásban. A helytelen transliteráció egy normalizált formát termel, amely nem egyezik meg az ugyanaz szó helyes normalizált formájával egy különböző forrásból, amely hamis negatívokat hoz létre (releváns tartalom nem találva). Egy olyan transliteráció, amely kétértelmű kimenetet termel, ahol eltérő forrászszavak ugyanaz az latin stringre leképeződnek, hamis pozitívokat hoz létre (irreleváns tartalom találva). Az API fonetikailag pontos leképezése mindkét típusú hibát minimálisra csökkenti, bár valamely kétértelműség minden transliterációs rendszerben eredendő, mivel a különbözői szövegek eltérő fonetikus megkülönböztetéseket kódolnak.

A zeneplatformok, könyvadatbázisok és médiakatalógusok intenzív felhasználói az transliteráció-alapú keresési normalizálásnak, mivel a katalógusok több tucatnyi nyelvből és szövegből állnak. Az a művész, akinek a neve az orosz katalógusban cirill szövegként, az amerikai katalógusban latin szövegként, és a japán katalógusban japán katakana szövegként van tárolva, olyan módon kell, hogy megtalálható legyen egyetlen keresésből, függetlenül attól, hogy a felhasználó melyik szöveget írja be. A transliteráció normalizálása ezt az egységes keresést lehetővé teszi azáltal, hogy az összes szövegváltozatot egy közös latin formára csökkenti, amely az illesztési kulcsként szolgál.

Támogatott szövegek és a konverzió hatóköre

A Transliterator API támogatja a cirill szövegből (orosz, ukrán, bulgár, szerb és más cirill-szövegű nyelvek), arab szövegből (beleértve a perzsa és urdu variánsokat), görögből, devanagariból (hindi, szanszkrit, marathi), bengáliból, thaiból, grúzból, örménységből, héberből, koreaiból (Hangul romanizálása), japánból (romaji konverzió hiragana és katakana számára), valamint kínaiból (pinyin konverzió egyszerűsített és tradicionális karakterekhez) történő konverziót. Az egyes szöveg páros specifikus transliterációs szabályokkal rendelkezik, amelyek figyelembe veszik a forrászszöveg fonetikus jellegzetességeit és a latin karakterek reprezentációs képességeit.

A konverzió szabályok nem egyforma az összes nyelvben, amely ugyanazt a szöveget osztja. Az orosz cirill és az ukrán cirill ugyanazt az ábécét használják, azonban különböző betűkkel és a megosztott betűkre vonatkozó kiejtés konvenciókkal. Az API megkülönbözteti az orosz és az ukrán bemenetet, és az alkalmazott nyelvspecifikus transliterációs szabályokat alkalmazza, amely kritikus a pontosság szempontjából, mivel az ugyanaz karakter különbözői hangokat képviselhet a cirill-szöveges nyelvekben. Ez a nyelvtudatosság más többnyelvű szövegekre is kiterjed, biztosítva, hogy a transliteráció a forrásnyelv kiejtési konvencióit tükrözi, nem pedig egy genetikus szöveg-szintű leképezést alkalmaz.

A kimenet alapértelmezés szerint tiszta latin szöveg ASCII karakterek használatával, egy lehetőséggel a diakriitikus jeleket tartalmazó transliterációs rendszerekhez (például ISO 9 cirill szöveghez vagy ISO 233 arab szöveghez). Az ASCII-csak kimenet ideális a technikai alkalmazásokhoz, mint az URL slugok, fájlnevek és adatbázis-azonosítók, ahol a diakriitikus jelek kompatibilitási problémákat okoznak. A diakriitikus kimenet ideális az olyan alkalmazásokhoz, ahol a fonetikus pontosság fontosabb, mint az egyetemes kompatibilitás, mint az akademikus kiadványok és nyelvészeti adatbázisok.

A kétirányú konverzió támogatott azokra a szöveg párosokra, ahol a leképezés fordítható. A cirill-latin és a latin-cirill konverzió is működik, lehetővé téve a körút konverziót, ahol az eredeti szöveg az transliterált formából körülbelül helyreállítható. A reverziózás körülbelül helyreállítható az egyes karakterekhez, mivel a transliteráció tulajdonan veszteséges, amikor a forrászszöveg olyan hangokat különböztet meg, amelyeket a célszöveg nem, azonban a legtöbb gyakorlati célt a körút minősége elég az emberi felismeréshez.