Kyrillisen ja arabian latinalaiset muunnokset sekä kirjoitusjärjestelmien muuntaminen monikielisille sovelluksille

Internet toimii latinalaisilla merkeillä. URL-osoitteet ovat latinalaisia. Sähköpostiosoitteet ovat latinalaisia. Tiedostojen nimet useimmissa käyttöjärjestelmissä ovat oletusarvoisesti latinalaisia. Tietokantaidentifikaattorit, API-parametrit ja järjestelmän luomat koodit kaikki toimivat latinalaisen ASCII-osajoukon kanssa. Tämä latinainen keskittyneisyys on historiallinen jäänne, joka edeltää Internetin maailmanlaajuista laajentumista, mutta sen käytännölliset seuraukset jatkuvat jokaisessa järjestelmässä, joka joutuu käsittelemään tekstiä maailman monista ei-latinaisista kirjoitusjärjestelmistä. Venäläinen liiketoiminnan nimi, joka näyttää täysin normaalilta kyrillisessä muodossa, muuttuu lukukelvottomaksi koodattujen merkkien sekaksi, kun sitä pakotetaan URL-osoitteeseen. Arabialaisen henkilön nimi, joka virtaa luonnollisesti oikealta vasemmalle, tulee tekniseksi pulmaksi, kun sitä joutuu näyttämään länsimaisessa tietokantakentässä. Nämä törmäykset maailman kielellisen monimuotoisuuden ja Internetin latinalaisen infrastruktuurin välillä tapahtuvat miljoonia kertoja joka päivä, ja jokainen niistä vaatii käännöksen ei merkityksestä vaan kirjoitusjärjestelmästä.

Translitteraatio on sana tälle kirjoitusjärjestelmän tasoiselle käännökselle, ja se poikkeaa pohjimmiltaan kielellisestä käännöksestä. Käännös muuntaa merkityksen: "house" englanniksi muuttuu "домом" venäjäksi, koska molemmat sanat tarkoittavat samaa asiaa eri kielillä. Translitteraatio muuntaa kirjoitusjärjestelmää: "дом" kyrillisessä muodossa muuttuu "dom" latinalaiseksi, koska nämä ovat latinalaiset merkit, jotka lähentävät kyrillisten merkkien ääniä. Merkitys pysyy samana. Kieli pysyy samana. Vain kirjoitusjärjestelmä muuttuu, mistä johtuu, että translitteraatiota kuvataan joskus "uudelleen kirjoittamiseksi" ennemmin kuin "uudelleen merkitsemiseksi".

Translitteraatio-API tarjoaa tämän kirjoitusjärjestelmän muuntamisen ohjelmallisena palveluna. Lähetä teksti yhdessä kirjoitusjärjestelmässä ja saa se takaisin toisessa. Kyrillinen latinalaiseksi, arabia latinalaiseksi, kreikka latinalaiseksi, devanagari latinalaiseksi ja kattava luettelo muista kirjoitusjärjestelmien pareista, jotka kattavat maailman suurimman osan Internet-käyttäjistä käyttämät kirjoitusjärjestelmät. Muuntaminen noudattaa vakiintuneita translitteraation standardeja, jos niitä on olemassa, ja foneettisesti tarkkoja kartoituksia tapauksissa, joissa standardoituja järjestelmiä ei ole määritelty, mikä tuottaa tuloksia, jotka ovat luettavia, lausuttavia ja sopii teknisiin konteksteihin, joissa latinalaiset merkit vaaditaan.

URL-osoitteet ja ei-latinalaisen tekstin ongelma verkkoosoitteissa

Käytännöllisimmaksi translitteraation soveltamiseksi verkkokehityksessä on URL-osoiteosien luominen ei-latinaisesta tekstistä. Blogikirjoitus, jonka otsikko on "Как приготовить борщ" (Kuinka tehdä borssiä), tarvitsee URL-ystävällisen osoiteosan, joka toimii jokaisessa selaimessa, jokaisella jakamisalustalla ja jokaisessa analytiikkajärjestelmässä. Otsikon kyrillisiä merkkejä voidaan käyttää kansainvälisissä verkkotunnuksissa (IDN) ja kansainvälisissä resurssitunnuksissa (IRI), mutta käytännössä useimmat verkon infrastruktuurit käsittelevät niitä epäluotettavasti. Koodatut kyrillisen kielen URL-osoitteet ovat pitkiä, rumia ja rikkoutuvat, kun niitä kopioidaan tiettyjen sovellusten välillä. Translitteroitu osoiteosa, kuten "kak-prigotovit-borshch", on lyhyt, luettava, jaettava ja yleisesti yhteensopiva.

Osoiteosan luomisen käyttötapaus vaatii ei vain kirjoitusjärjestelmän muuntamista vaan myös lisäkäsittelyä: pienaakkosuuntaminen, välilyönnin korvaaminen tavuviivalla, erikoismerkkien poistaminen ja aksenttimerkkien normalisointi. Translitteraatio-API käsittelee kirjoitusjärjestelmän muuntamisen vaiheet, muuntaa kyrillisiä merkkejä niiden latinalaisiksi vastineiksi, ja kutsuvaa sovellusta käsittelee loput normalisointivaiheet. Vastuun jakaminen pitää API:n keskittyneenä kielellisesti monimutkaiseen tehtävään (oikea translitteraatio) samalla kun jättää teknisesti yksinkertaiset tehtävät (pienaakkosuuntaminen, tavuviivan lisääminen) kehittäjän olemassa olevaan tekstin käsittelyputkeen.

Translitteraation laatu osoiteosan luomiseen on tärkeä, koska osoiteosa on näkyvissä käyttäjille ja vaikuttaa hakukoneoptimoinnille. Venäläinen käyttäjä, joka kohtaa "kak-prigotovit-borshch" osoitteen, tunnistaa sen välittömästi venäläisen otsikon translitteraationa ja voi lukea sen ilman vaivaa. Huonosti translitteroitu osoiteosa, joka käyttää virheellisiä kirjainkartoituksia tai tuottaa lausumattomia merkkiyhdistelmiä, näyttää saippualta sekä venäläisille että englanninkielisille lukijoille. API käyttää foneettisesti tarkkoja kartoituksia, jotka tuottavat luettavaa tulosta riippumatta lähdekirjoitusjärjestelmästä, mikä tekee tuloksena olevista osoiteosista toimivia sekä teknisiksi tunnisteiksi että ihmisen luettavaksi tekstiksi.

Moninkertaisille markkinoille myyvät verkkokaupan sivustot käyttävät translitteraatiota laajasti tuotteen URL-osoitteille luomisessa. Tuotteluettelo, joka sisältää nimikkeitä venäläisillä, arabian, kiinalaisen ja hindikielillä, tarvitsee URL-osoiteosaa, jotka toimivat kaikilla kielillä. Manuaalinen translitteraatio tässä mittakaavassa on epäkäytännöllistä, ja automatisoitu translitteraatio API:n kautta tuottaa johdonmukaisia ja tarkkoja osoiteosaa, jotka voidaan luoda osana tuotteen tuontiputkea ilman ihmisen väliintuloa jokaiselle kielelle.

Passin nimet ja virallisen dokumentin translitteraatio

Passin translitteraatio on yksi merkittävimmistä kirjoitusjärjestelmän muuntamisen sovelluksista, koska virheet nimen translitteraatiossa aiheuttavat todellisia ongelmia. Nimi, joka on translitteroitu eri tavalla passissa kuin viisumihakemuksessa, voi hidastaa tai estää kansainvälistä matkustamista. Nimi, joka on translitteroitu eri tavalla pankkijärjestelmässä kuin henkilöntodistuksessa, voi estää rahoitustapahtumia. Panokset ovat riittävän korkeat, että useimmat maat ylläpitävät virallisia translitteraation standardeja passin nimille, ja API toteuttaa nämä standardit niille skripteille, joita se tukee.

Venäläiset nimet havainnollistavat hyvin monimutkaista. Venäläinen kirjain "Щ" voidaan translitteraada muotoon "shch", "sch", "sh" tai "sc" riippuen siitä, mitä translitteraatiotapaa sovelletaan. ICAO (International Civil Aviation Organization) standardi, jota käytetään passeissa, määrittelee "shch". BGN/PCGN-järjestelmä, jota käyttävät USA:n ja Iso-Britannian hallituksen virastot, määrittelee "shch". ISO 9 järjestelmä, jota käytetään akateemisissa konteksteissa, määrittelee yhden merkin, jossa on diakritinen merkki. "Щербакова" niminen henkilö joutuu tietämään, että hänen passissa lukee "Shcherbakov" ja että jokainen muu dokumentti, joka koskee hänen nimeään, tulee vastaamaan täsmälleen tätä translitteraatiota. API tukee useita translitteraation standardeja ja sallii kutsujalle määrittää, mitä standardia käytetään, mikä varmistaa, että tulos vastaa tietyn kontekstin vaatimuksia.

Arabian nimen translitteraatio lisää lisäkiehtoa, koska arabialaisissa kirjoitusjärjestelmissä on abjad-pohja, mikä tarkoittaa, että vokaali jätetään usein pois kirjoitetusta tekstistä ja on pääteltävä translitteraatiossa. Nimi "محمد" (Muhammad) voidaan laillisesti translitteraata muotoon Muhammad, Mohamed, Mohammed, Muhammed tai useita muita variantteja riippuen translitteraatiosysteemistä ja alueellisesta ääntämisestä. API soveltaa johdonmukaisia, standardin mukaisia kartoituksia, jotka tuottavat laajimmin tunnistetut variantit, kun taas dokumentaatio merkitsee vaihtoehtoiset oikeinkirjoitukset, joita eri standardit tuottavat yleisesti translitteroiduille nimille.

Maahanmuutto- ja hallintojärjestelmät, jotka käsittelevät hakemuksia useista maista, hyötyvät standardisoidusta translitteraatiosta, joka tuottaa johdonmukaisen tuloksen riippumatta siitä, mikä operaattori käsittelee hakemuksen. Ilman API-pohjaista translitteraatiota yksittäiset operaattorit soveltavat omaa intuitiivista translitteraatiotaan, mikä tuottaa epäjohdonmukaisia tuloksia, jotka mutkistavat tietokantasovitusta, henkilöllisyyden varmistamista ja tietueiden linkitystä. Standardoitu translitteraatio API:n kautta varmistaa, että sama lähdeteksti tuottaa aina saman latinalaisen tuloksen, mikä on välttämätöntä järjestelmille, jotka luottavat merkkijonon vastaavuuteen henkilöllisyyden varmistamisessa.

Haun normalisointi ja sisällön löytäminen eri kirjoitusjärjestelmissä

Hakujärjestelmät kohtaavat perustavanlaatuisen haasteen, kun hakusarja sisältää sisältöä useissa kirjoitusjärjestelmissä: käyttäjän, joka etsii yhdessä kirjoitusjärjestelmässä, tulisi pystyä löytämään sisältö, joka on tallennettu toiseen kirjoitusjärjestelmään, jos sisältö on semanttisesti merkityksellinen. Venäläisen käyttäjän, joka etsii "Москва" (Moskova), tulisi löytää sisältö, joka viittaa "Moskva" latinalaisen skriptin hakemistossa. Englanninkielinen käyttäjä, joka etsii "Moscow", tulisi löytää sisältö, joka on tallennettu kyrillisen originaalin "Москва" kanssa. Tämä yli-skriptinen vastaavuus edellyttää normalisointia, joka translitteroi hakukyselyt ja indeksoidun sisällön yhteiseen kirjoitusjärjestelmään ennen sovitusta.

Translitteraatio-API toimii tänä normalisointinä. Indeksointihetkellä ei-latinalainen sisältö translitteroidaan latinalaiseksi ja tallennetaan rinnakkain alkuperäisen kirjoitusjärjestelmän version kanssa. Kyselyhetkellä ei-latinalaiset kyselyt translitteroidaan ennen vertaamista latinalaisen normalisoidun hakemistoon. Tämä kaksinkertainen indeksi lähestymistapa varmistaa, että haut missä tahansa tuetulla kirjoitusjärjestelmällä löytävät sisällön, joka on tallennettu mihin tahansa tuettuun kirjoitusjärjestelmään, koska sovitus tapahtuu yhteisessä latinalaisessa normalisoidussa tilassa, jossa kirjoitusjärjestelmän erot on ratkaistu.

Translitteraation tarkkuus vaikuttaa suoraan haun merkityksellisyyteen tässä sovelluksessa. Virheellinen translitteraatio tuottaa normalisoidun muodon, joka ei vastaa saman sanan oikeaa normalisoitua muotoa eri lähteestä, mikä luo vääriä negatiivisia tuloksia (asiaa ei löydy). Translitteraatio, joka tuottaa epäselvää tulosta, jossa eri lähdesanat kartoitetaan samaan latinalaisen merkkijonoon, luo vääriä positiivisia tuloksia (löydettiin asiaa). API:n foneettisesti tarkat kartoitukset minimoivat molemmat virhetyypit, vaikka jokin epäselvyys on luontaista missä tahansa translitteraatiosysteemissä, koska eri kirjoitusjärjestelmät koodaavat eri foneettisia erotteluja.

Musiikkialustat, kirjan tietokannaksi ja medialuettelot ovat painavat käyttäjät translitteraation perusteella hakujen normalisoinnista, koska heidän luettelonsa kattavat kymmenien kielten ja kirjoitusjärjestelmät. Artisti, jonka nimi on tallennettu kyrillisella venäläisessä luettelossa, latinalaisella USA:n luettelossa ja japanilaisella katakana japanilaisessa luettelossa, tulee löytää yhdellä haulla riippumatta siitä, mitä kirjoitusjärjestelmää käyttäjä kirjoittaa. Translitteraation normalisoiminen tekee tämän yhtenäisen haun mahdolliseksi vähentämällä kaikki kirjoitusjärjestelmän variantit yhteiseen latinalaisen muotoon, joka toimii vastaavuusavaimena.

Tuetut kirjoitusjärjestelmät ja muuntamisen laajuus

Translitteraatio-API tukee muuntamista kyrillisestä (venäläinen, ukraina, bulgaria, serbia ja muut kyrillisen kielen kielet), arabia (mukaan lukien persia ja urdu variantit), kreikka, devanagari (hindi, sanskrit, marathi), bengali, thai, georgian, armenian, hebrea, korealainen (romanisaatio hangul), japani (romaji muuntaminen hiragana ja katakana), ja kiinalainen (pinyin muuntaminen yksinkertaiselle ja perinteiselle merkeille). Jokaisella kirjoitusjärjestelmien parilla on erityiset translitteraation säännöt, jotka ottavat huomioon lähdekirjoitusjärjestelmän fonetiiset ominaisuudet ja latinalaisista merkeistä saatavat kyvyt.

Muuntamissäännöt eivät ole samanlaisia kaikille kielille, jotka jakavat kirjoitusjärjestelmän. Venäläinen kyrillinen ja ukraina kyrillinen käyttävät samaa aakkosta, mutta eri kirjainten ja eri ääntämisen sopimuksella jaetuille kirjaimille. API erottaa venäläisen ja ukraina tuloksen ja soveltaa asianmukaisia kielikohtaisia translitteraation sääntöjä, mikä on välttämätöntä tarkkuudelle, koska sama merkki voi edustaa eri ääniä eri kyrillisen kielen kielissä. Tämä kielitietoisuus ulottuu muihin monikielisiin kirjoitusjärjestelmiin, varmistaen, että translitteraatio heijastaa erityisen lähdeäänimen ääntämisen sopimuksia sen sijaan, että soveltaisiin yleistä kirjoitusjärjestelmän tasolla olevaa kartoitusta.

Tuotos on oletusarvoisesti puhdas latinalainen teksti ASCII-merkeillä, ja valinnainen diakritisten merkkien sisällyttäminen translitteraation järjestelmille, jotka käyttävät niitä (kuten ISO 9 kyrilliselle tai ISO 233 arabialaiselle). ASCII-vain tuotos on ihanteellinen teknisille sovelluksille, kuten URL-osoitteille, tiedostoille ja tietokantaidentifikaattoreille, joissa diakritisten merkkien aiheuttavat yhteensopivuusongelmia. Diakritinen tuotos on ihanteellinen sovelluksille, joissa foneettinen tarkkuus on tärkeämpää kuin yleinen yhteensopivuus, kuten akateemiset julkaisut ja kielentutkimuksen tietokannat.

Kaksisuuntainen muuntaminen on tuettu kirjoitusjärjestelmien pareille, joissa kartoitus on käännettävä. Kyrillinen latinalaiseksi ja latinalainen kyrilliseksi molemmat toimivat, mikä mahdollistaa kierrosta muuntamisen, jossa alkuperäinen teksti voidaan approksimaatiovaisesti palauttaa translitteroidusta muodosta. Reverssoiminen on approksimaativaa ennemmin kuin tarkkaa joihinkin merkkeihin, koska translitteraatio on luontaisesti häviöllista, kun lähde-skripti tekee erotuksia, joita kohde-skripti ei tee, mutta useimmissa käytännöllisissa tarkoituksissa kierrosta laatu on riittävä ihmisen tunnistamiseen.