Cyrillic to Latin a Arabic to Latin a Konverze skriptů pro vícejazykové aplikace

Internet běží na latinských znacích. Adresy URL jsou latinské. E-mailové adresy jsou latinské. Názvy souborů ve większości operačních systémů jsou ve výchozím stavu latinské. Identifikátory databází, parametry API a systémově generované kódy všechny pracují v podmnožině ASCII latinky. Tento latinský centrismus je historickým artefaktem, který předchází globální expanzi internetu, ale jeho praktické následky přetrvávají v každém systému, který musí zpracovávat text z mnoha nelatinských písemných systémů světa. Ruský obchodní název, který vypadá zcela normálně v cyrilici, se stává nečitelnou posloupností zakódovaných znaků, když je nucen do adresy URL. Jméno arabské osoby, které přirozeně teče zprava doleva, se stává technickým puzzle, když se musí objevit v poli západní databáze. Tyto srážky mezi jazykovou diverzitou světa a latinskou infrastrukturou internetu se dějí miliony krát každý den, a každá z nich vyžaduje překlad ne smyslu, ale skriptu.

Transliterace je slovo pro tento překlad na úrovni skriptu a zásadně se liší od lingvistického překladu. Překlad převádí smysl: "dům" v češtině se stává "дом" v ruštině, protože obě slova znamenají totéž v různých jazycích. Transliterace převádí skript: "дом" v cyrilici se stává "dom" v latině, protože to jsou latinské znaky, které aproximují zvuky cyrilických znaků. Smysl zůstává stejný. Jazyk zůstává stejný. Mění se pouze písemný systém, což je důvod, proč je transliterace někdy popsána jako "přepis" místo "přeznamenání".

Rozhraní Transliterator API poskytuje tuto konverzi skriptu jako programovatelnou službu. Poslat text v jednom skriptu, obdržet jej zpět v jiném. Cyrilice na latinu, arabština na latinu, řečtina na latinu, Devanagari na latinu a komprehenzivní seznam dalších párů skriptů, které pokrývají písemné systémy používané většinou uživatelů internetu světa. Konverze se řídí zavedenými standardy transliterace, kde existují, a foneticky přesnými mapováním, kde standardizované systémy nebyly definovány, a vytváří výstup, který je čitelný, vyslovitelný a vhodný pro technické kontexty, kde jsou vyžadovány latinské znaky.

Adresy URL slugy a problém nelatinských textů v internetových adresách

Nejbezprostředněji praktická aplikace transliterace ve vývoji webu je generování adres URL slugů z nelatinských textů. Příspěvek blogu s názvem "Jak připravit červenou řepu" potřebuje adresu URL slug, která je přátelská a funguje v každém prohlížeči, každé platformě pro sdílení a každém analytickém systému. Cyrilické znaky v názvu jsou platné v internacionalizovaných názvech domén (IDN) a internacionalizovaných identifikátorech prostředků (IRI), ale v praxi, većina webové infrastruktury je stále zpracovává nespolehlivě. Zakódované cyrilické adresy URL jsou dlouhé, ošklivé a přeruší se, když se kopírují mezi některými aplikacemi. Transliterovaný slug jako "jak-pripravit-cervenou-repu" je krátký, čitelný, sdílený a všeobecně kompatibilní.

Případ použití generování slugu vyžaduje nejen konverzi skriptu, ale také další zpracování: převod na malá písmena, nahrazení mezer pomlčkami, odstranění speciálních znaků a normalizaci akcentovaných znaků. Rozhraní API transliterace zpracuje krok konverze skriptu, konvertující cyrilické znaky na jejich latinské ekvivalenty, a volající aplikace zpracuje zbývající normalizační kroky. Toto dělení odpovědnosti udržuje API zaměřené na lingvisticky složitý úkol (správná transliterace), zatímco ponechává technicky jednoduché úkoly (malá písmena, vkládání pomlček) vývojářově existující kanálu zpracování textu.

Kvalita transliterace pro generování slugu je důležitá, protože je slug viditelný uživatelům a přispívá k SEO. Ruský uživatel, který se setkává se slugem "jak-pripravit-cervenou-repu", jej okamžitě rozpozná jako transliteraci ruského názvu a může jej číst bez námahy. Špatně transliterovaný slug, který používá nesprávná mapování písmen nebo vytváří nevyslovitelné kombinace znaků, vypadá jako nesmysl pro ruské i anglické čtenáře. Rozhraní API používá foneticky přesná mapování, která vytváří čitelný výstup bez ohledu na zdrojový skript, což činí výsledné slugy funkční jak jako technické identifikátory, tak jako text čitelný člověkem.

E-commerce weby prodávající na vícejazykových trzích používají transliteraci rozsáhle pro generování URL produktů. Katalog produktů, který obsahuje položky s názvy v ruštině, arabštině, čínštině a hindštině, potřebuje adresy URL slugů, které fungují ve všech jazycích. Ruční transliterace v tomto měřítku je neproveditelná a automatizovaná transliterace prostřednictvím rozhraní API vytváří konzistentní, přesné slugy, které lze vygenerovat jako součást kanálu importu produktu bez zásahu člověka pro každý jazyk.

Jména v pasech a transliterace oficiálních dokumentů

Transliterace jmen v pasech je jednou z nejdůležitějších aplikací konverze skriptu, protože chyby v transliteraci jmen způsobují skutečné problémy. Jméno transliterované jinak v pasu než v žádosti o vízum může zpomalit nebo zabránit mezinárodnímu cestování. Jméno transliterované jinak v bankovním systému než v identifikačním dokumentu může zablokovat finanční transakce. Sázky jsou dostatečně vysoké na to, že si większina zemí udržuje oficiální standardy transliterace pro jména v pasech, a rozhraní API implementuje tyto standardy pro podporované skripty.

Ruská jména ilustrují složitost dobře. Ruské písmeno "Щ" může být transliterováno jako "shch", "sch", "sh" nebo "sc" v závislosti na tom, který systém transliterace je aplikován. Standard ICAO (Mezinárodní organizace civilního letectví) používaný pro pasy určuje "shch". Systém BGN/PCGN používaný americkými a britskými vládními agenturami určuje "shch". Systém ISO 9 používaný v akademických kontextech určuje jeden znak s diakritikou. Osoba pojmenovaná "Щербаков" musí vědět, že její pas bude brát "Shcherbakov" a že každý další dokument týkající se jejího jména musí odpovídat této transliteraci přesně. Rozhraní API podporuje více standardů transliterace a umožňuje volajícímu zadat, který standard se má aplikovat, čímž zajistí, že výstup odpovídá požadavkům konkrétního kontextu.

Transliterace arabských jmen přidává dodatečnou složitost, protože arabský skript je založen na abjadu, což znamená, že samohlásky jsou často vynechány z psaného textu a musí být vyvozeny pro transliteraci. Jméno "محمد" (Muhammad) lze legitimně transliterovat jako Muhammad, Mohamed, Mohammed, Muhammed nebo několik dalších variant v závislosti na systému transliterace a regionální výslovnosti. Rozhraní API aplikuje konzistentní, standardně kompatibilní mapování, která vytváří nejčastěji rozpoznávané varianty, zatímco dokumentace poznamenává alternativní pravopisy, které různé standardy vytváří pro běžně transliterovaná jména.

Imigrační a vládní systémy, které zpracovávají žádosti z více zemí, mají prospěch ze standardizované transliterace, která vytváří konzistentní výstup bez ohledu na to, který operátor žádost zpracovává. Bez transliterace na bázi API jednotliví operátoři aplikují svou vlastní intuitivní transliteraci, která vytváří nekonzistentní výsledky, které komplikují shodu databází, ověřování identity a propojení záznamů. Standardizovaná transliterace prostřednictvím rozhraní API zajistí, že stejný zdrojový text vždy vytváří stejný latinský výstup, což je nezbytné pro systémy, které se spoléhají na porovnávání řetězců pro ověřování identity.

Normalizace vyhledávání a nalezení obsahu v rámci skriptů

Vyhledávací systémy stojí před základní výzvou, když součást vyhledávacího korpusu obsahuje obsah ve více skriptech: uživatel vyhledávající v jednom skriptu by měl být schopen najít obsah uložený v jiném skriptu, pokud je obsah sémanticky relevantní. Ruský uživatel vyhledávající "Москва" (Moskva) by měl najít obsah, který odkazuje na "Moskva" v latinském indexu. Anglický uživatel vyhledávající "Moscow" by měl najít obsah uložený s cyrilickou původní "Москва". Toto meziskripty párování vyžaduje normalizační vrstvu, která transliteruje vyhledávací dotazy a indexovaný obsah do společného skriptu před porovnáním.

Rozhraní API transliterace slouží jako tato normalizační vrstva. V čase indexování je nelatinský obsah transliterován na latinu a uložen vedle původní verze skriptu. V čase dotazu jsou nelatinské dotazy transliterovány před porovnáním s latinským normalizovaným indexem. Tento přístup s duálním indexem zajistí, že hledání v jakémkoli podporovaném skriptu najde obsah uložený v jakémkoli podporovaném skriptu, protože párování probíhá v běžném latinském normalizovaném prostoru, kde byly rozdíly mezi skripty vyřešeny.

Přesnost transliterace přímo ovlivňuje relevanci vyhledávání v této aplikaci. Nesprávná transliterace vytváří normalizovanou formu, která neodpovídá správné normalizované formě stejného slova z jiného zdroje, což vytváří falešně negativní výsledky (relevant obsah nebyl nalezen). Transliterace, která vytváří nejednoznačný výstup, kde se různá zdrojová slova mapují na stejný latinský řetězec, vytváří falešně pozitivní výsledky (nalezen nerelevantní obsah). Foneticky přesná mapování rozhraní API minimalizují oba typy chyb, i když je určitá nejednoznačnost vlastní každému systému transliterace, protože různé skripty kódují různé fonetické rozdíly.

Hudební platformy, databáze knih a katalogy médií jsou těžkými uživateli normalizace vyhledávání na bázi transliterace, protože jejich katalogy zahrnují desítky jazyků a skriptů. Umělec, jehož jméno je uloženo v cyrilici v ruském katalogu, latině v americkém katalogu a japonské katakane v japonském katalogu, musí být najditelný prostřednictvím jediného hledání bez ohledu na to, který skript uživatel napíše. Normalizace transliterace to umožňuje sjednoceným hledáním redukcí všech variantů skriptu na běžnou latinskou formu, která slouží jako klíč párování.

Podporované skripty a rozsah konverze

Rozhraní Transliterator API podporuje konverzi z cyrilice (ruština, ukrainština, bulharština, srbština a další jazyky s cyrilickým skriptem), arabštiny (včetně perské a urdské varianty), řečtiny, Devanagari (hindština, sanskrt, marathi), bengálštiny, thajštiny, gruzínštiny, arménštiny, hebrejštiny, korejštiny (romanizace hangulu), japonštiny (romaji konverze pro hiraganu a katakanu) a čínštiny (pinyin konverze pro zjednodušené a tradiční znaky). Každý pár skriptů má specifická pravidla transliterace, která berou v úvahu fonetické charakteristiky zdrojového skriptu a reprezentační schopnosti latinských znaků.

Pravidla konverze nejsou univerzální pro všechny jazyky, které sdílejí skript. Ruská cyrilice a ukrajinská cyrilice používají stejnou abecedu, ale s různými písmeny a různými výslovnostními konvencemi pro sdílená písmena. Rozhraní API rozlišuje mezi ruskou a ukrajinskou vstupem a aplikuje příslušná pravidla transliterace specifická pro jazyk, která jsou nezbytná pro přesnost, protože stejný znak může reprezentovat různé zvuky v různých jazycích s cyrilickým skriptem. Toto povědomí o jazyce se rozšiřuje na další vícejazykové skripty a zajistí, že transliterace odráží výslovnostní konvence konkrétního zdrojového jazyka místo aplikace generické mapy na úrovni skriptu.

Výstupem je čisté latinské písmo používající znaky ASCII ve výchozím stavu s možností zahrnout diakritické znamínka pro systémy transliterace, které je používají (například ISO 9 pro cyrilici nebo ISO 233 pro arabštinu). Výstup pouze ASCII je ideální pro technické aplikace jako adresy URL, názvy souborů a identifikátory databází, kde diakritické znamínka způsobují problémy s kompatibilitou. Výstup s diakritickými znamínky je ideální pro aplikace, kde má fonetická přesnost přednost před všeobecnou kompatibilitou, například akademické publikace a lingvistické databáze.

Obousměrná konverze je podporována pro páry skriptů, kde je mapování reverzibilní. Cyrilice na latinu a latinu na cyrilici fungují, což umožňuje konverzi v obou směrech, kde lze původní text přibližně obnovit z transliterované formy. Obnovení je přibližné spíše než přesné pro některé znaky, protože transliterace je přirozeně ztrátová, když zdrojový skript rozlišuje zvuky, které cílový skript ne, ale pro největší praktické účely je kvalita konverze v obou směrech dostatečná pro lidské rozpoznání.