Преобразуване между Кирилица и Латиница и Арабица в Латиница за многоезични приложения

Интернетът работи с латински знаци. URL адресите са латински. Имейл адресите са латински. Имената на файловете в повечето операционни системи по подразбиране са латински. Идентификаторите на база данни, параметрите на API и системно генериране кодовете работят с ASCII подмножество на латиницата. Този латински централизъм е исторически артефакт, който предшества глобалното разширяване на интернета, но практическите му последствия остават в стойност във всяка система, която трябва да обработва текст от световете много писмени системи, които не са латински. Русско бизнес име, което изглежда абсолютно нормално на кирилица, става нечетима последователност на кодирани знаци, когато е принудено в URL адрес. Арабско име, което протича естествено отдясно наляво, става технически пъзел, когато трябва да се появи в западно поле на база данни. Тези сблъсъци между езиковото многообразие на света и латинската инфраструктура на интернета се случват милиони пъти всеки ден и всеки един изисква превод не на смисъл, а на писмена система.

Транслитерацията е думата за превод на ниво писмена система и е фундаментално различна от лингвистичния превод. Преводът преобразува смисъла: "къща" на английски става "дом" на руски, защото и двете думи означават едно и също нещо на различни езици. Транслитерацията преобразува писмена система: "дом" на кирилица става "dom" на латиница, защото това са латинските знаци, които приблизително представляват звуците на кирилските знаци. Смисълът остава същия. Езикът остава същия. Само писмената система се променя, което е причината транслитерацията понякога се описва като "преписване" по-скоро, отколкото "преосмисляне".

API-то на Transliterator предоставя тази преобразуване на писмена система като програмируема услуга. Изпратете текст в една писмена система, получете го обратно в друга. Кирилица в латиница, арабица в латиница, гръцки в латиница, деванагари в латиница и всеобхватен списък на други двойки писмени системи, които покриват писмените системи, използвани от мнозинството на световите потребители на интернета. Преобразуването следва установени стандарти за транслитерация, когато съществуват, и фонетично точни съответствия, когато стандартизирани системи не са определени, произвеждайки резултат, който е четлив, произносим и подходящ за технически контексти, където са необходими латински знаци.

URL маршрути и проблемът с текст без латиница в уеб адреси

Най-практичното приложение на транслитерацията в уеб разработката е генериране на URL маршрути от текст без латиница. Публикация в блог озаглавена "Как приготовить борщ" (Как да направим борш) нуждае се от URL-приложен маршрут, който работи във всеки браузър, всяка платформа за споделяне и всяка система за анализ. Кирилските знаци в заглавието са валидни в интернационализирани доменни имена (IDN) и интернационализирани идентификатори на ресурси (IRI), но на практика повечето уеб инфраструктура все още ги обработва неправилно. Кодирани кирилски URL адреси са дълги, грозни и счупват се, когато се копирайт между определени приложения. Транслитериран маршрут като "kak-prigotovit-borshch" е кратък, четлив, споделяем и универсално съместим.

Генериране маршрута изисква не просто преобразуване на писмена система, но и допълнителна обработка: съчетаване, замяна на празни места с хифени, отстраняване на специални знаци и нормализиране на акцентирани знаци. API-то за транслитерация обработва етапа на преобразуване на писмена система, преобразувайки кирилските знаци в техните латински еквиваленти, а извиква приложението обработва останалите етапи на нормализиране. Това разделение на отговорност держи API-то фокусирано на лингвистично сложна задача (правилна транслитерация), докато оставя технически простите задачи (съчетаване, вмъкване хифен) на разработчика съществува обработка на текст конвейер.

Качеството на транслитерацията за генериране на маршрути има значение, защото маршрутът е видим за потребителите и допринася към SEO. Руски потребител, който среща маршрута "kak-prigotovit-borshch", го признава незабавно като транслитерацията на руския заглавието и може да го прочете без усилие. Лошо транслитериран маршрут, един, който използва неправилни съответствия на букви или произвежда непроизносими комбинации от знаци, изглежда като бълнуване както на руския, така и на английския читатели. API-то използва фонетично точни съответствия, които произвеждат четлив резултат, независимо от писмената система източник, което прави резултатните маршрути функционални както като технически идентификатори, така и като човешки четлив текст.

Електронни търговия сайтове, които продават на многоезични пазари, използват транслитерацията широко за генериране на URL продукта. Каталог на продукти, който включва елементи с имена на руски, арабски, китайски и хинди, нуждае се от URL маршрути, които работят на всички езици. Ръчна транслитерация при този мащаб е непрактична, и автоматизирана транслитерация чрез API-то произвежда последователни, точни маршрути, които могат да бъдат генерирани като част на конвейера на внос на продукта без човешко вмешаватне за всеки език.

Паспортни имена и официална документация за транслитерация

Паспортната транслитерация е одно от най-значимите приложения на преобразуване на писмена система, защото грешките в транслитерацията на имена причиняват реални проблеми. Име, транслитерирано по различен начин в паспорта, отколкото в заявката за виза, може да отложи или предотврати международното пътуване. Име, транслитерирано по различен начин в банкова система, отколкото в документ за идентификация, може да блокира финансови трансакции. Залозите са достатъчно високи, че повечето страни имат официални стандарти за транслитерация за паспортни имена, и API-то внедрява тези стандарти за писмените системи, които поддържа.

Русците имена илюстрира сложността добре. Руската буква "Щ" може да бъде транслитерирана като "shch", "sch", "sh" или "sc" в зависимост от това кой систем за транслитерация е приложен. Стандартът ICAO (Международна организация на гражданската авиация), използван за паспорти, указва "shch". Системата BGN/PCGN, използвана от американските и британските правителствени агенции, указва "shch". Системата ISO 9, използвана в академични контексти, указва един знак с диакритична мярка. Лице със име "Щербаков" трябва да знае, че техния паспорт ще чете "Shcherbakov" и че всеки друг документ, включващ техното име, трябва да съответства на тази транслитерация точно. API-то поддържа множество стандарти за транслитерация и позволява на извиквача да определи кой стандарт да прилага, осигурявайки, че резултата съответства на изискванията на конкретния контекст.

Арабската транслитерация на имена добавя допълнителна сложност, защото арабската писмена система е съоснова, което означава, че гласните често се пропускат от написания текст и трябва да се внушат за транслитерация. Името "محمد" (Muhammad) може да бъде легитимно транслитерирано като Muhammad, Mohamed, Mohammed, Muhammed, или няколко други варианта в зависимост от системата за транслитерация и регионалния произнос. API-то прилага последователни, мотивирани от стандарти съответствия, които произвеждат най-широко признаваните варианти, докато документацията отбелязва алтернативните правописи, които различни стандарти произвеждат за често транслитерирани имена.

Имиграционните и държавни системи, които обработват приложения от множество страни, благодарят на стандартизирана транслитерация, която произвежда последователни резултата, независимо от това кой оператор обработва приложението. Без API-основана транслитерация, отделни оператори прилагат своята собствена интуитивна транслитерация, която произвежда непоследователни резултата, които компликура съответствието на база данни, проверката на идентичност и свързването на записи. Стандартизирана транслитерация чрез API-то осигурява, че същия текст източник винаги произвежда същия латински резултата, което е съществено за системите, които разчитат на съответствието на низове за проверка на идентичност.

Нормализиране на търсенето и намиране на съдържание между писмени системи

Системите за търсене са преправени да се сблъскват с фундаментално предизвикателство, когато корпусът за търсене съдържа съдържание в множество писмени системи: потребител, който търси в една писмена система, трябва да бъде в състояние да намери съдържание, съхранено в друга писмена система, ако съдържанието е семантично релевантно. Руски потребител, който търси "Москва" (Москва), трябва да намери съдържание, което реферира "Moskva" в латински индекс. Англиски потребител, който търси "Moscow", трябва да намери съдържание, съхранено с кирилския оригинал "Москва". Този кросс-писмен мач изисква слой на нормализиране, който транслитерира заявки за търсене и индексирано съдържание в обща писмена система преди съответствие.

API-то за транслитерация служи като този слой на нормализиране. В индекс време, не-латинското съдържание е транслитерирано в латиница и съхранено наред с оригиналната версия на писмена система. В време на заявка, не-латински заявки са транслитерирани преди да бъдат съответствани срещу латински нормализиран индекс. Този двойния индекс подход осигурява, че търсенията на всяка поддържана писмена система намират съдържание, съхранено на всяка поддържана писмена система, защото съответствието се случва на обща латински нормализирана пространство, където разликите в писмената система са разрешени.

Точността на транслитерацията преки влияе на релевантност на търсенето в това приложение. Неправилна транслитерация произвежда нормализирана форма, която не съответства на правилната нормализирана форма на същата дума от различен източник, което създава лошо отрицание (релевантно съдържание не е намерено). Транслитерация, която произвежда двусмислен резултата, където различните думи източник съответстват на същи латински низ, създава лошо положително (нерелевантно съдържание намерено). Точни съответствия на API-то фонетично минимизира и двата вида грешка, въпреки че някаква двусмисленост е присъща в всяка система за транслитерация, защото различни писмени системи кодират различни фонетични различия.

Музикални платформи, базови данни на книги и каталози на медия са тежки потребители на нормализиране на търсене на основата на транслитерация, защото техните каталози обхващат десетки езици и писмени системи. Артист, чието име е съхранено на кирилица в руския каталог, на латиница в американския каталог и японския катакана в японския каталог, трябва да бъде намираемо чрез един поиск, независимо от това коя писмена система потребителят пише. Нормализиране на търсене на основата на транслитерация прави този унифициран поиск възможен чрез намаляване на всички вариант на писмена система на обща латинска форма, която служи като съответствие ключ.

Поддържани писмени системи и обхватът на преобразуване

API-то на Transliterator поддържа преобразуване от кирилица (руски, украински, български, сръбски и други езици със кирилски писмена система), арабица (включително персийски и урду вариант), гръцки, деванагари (хинди, санскрит, маратхи), бенгалски, тайландски, грузински, армански, иврит, корейски (романизиране на Hangul), японски (ромаджи преобразуване за хирагана и катакана) и китайски (pinyin преобразуване за опростена и традиционна символика). Всяка двойка писмени системи има специфични правила за транслитерация, които отчитат фонетичните характеристики на писмената система източник и представителните способности на латинските знаци.

Правилата за преобразуване не са еднакви за всички езици, които имат писмена система. Руската кирилица и украинската кирилица използват една и съща азбука, но с различни букви и различни произнос конвенции за общите букви. API-то разграничава между русинския и украинския входа и прилага подходящите правила за транслитерация, специфични за езика, което е съществено за точност, защото същия знак може да представи различни звуци на различни кирилични езици. Това осъзнаване на езика разширява до други многоезични писмени системи, осигурявайки, че транслитерацията отразява произносът конвенции на конкретния език източник, по-скоро отколкото прилага универсално съответствие на ниво писмена система.

Резултата е чист латински текст с използване на ASCII знаци по подразбиране, с опция да включва диакритични знаци за системи за транслитерация, които ги използват (такива като ISO 9 за кирилица или ISO 233 за арабица). ASCII-само резултата е идеален за технически приложения, като URL маршрути, имена на файлове и идентификатори на база данни, където диакритични знаци причиняват проблеми със съвместимостта. Диакритичен резултата е идеален за приложения, където фонетична точност има значение повече от универсална съвместимост, такива като академични публикации и лингвистични базови данни.

Двупосочна преобразуване се поддържа за двойки писмени системи, където съответствието е обратимо. Кирилица в латиница и латиница в кирилица и двете работят, позволявайки обратна преобразуване, където оригиналният текст може да бъде приблизително възстановен от транслитерирана форма. Обръщането е приблизително вместо точно за някои знаци, защото транслитерацията по своята същност е без загуба, когато писмената система източник разграничи звуци, които писмената система целева не разграничи, но за повечето практически цели обратна качество е достатъчна за човешко признаване.