המרת קירילית ללטיניות וערבית ללטיניות והמרת כתבי עזר ליישומים רב-שפתיים

האינטרנט פועל על תווי לטיניות. כתובות URL הן לטיניות. כתובות דוא"ל הן לטיניות. שמות קבצים ברוב מערכות ההפעלה מתעדים כברירת מחדל ללטיניות. מזהים בבסיסי נתונים, פרמטרים של API וקודים שנוצרו על ידי המערכת פועלים כולם בתת-קבוצה ASCII של לטיניות. לטיניוצנטריזם זה הוא חניק היסטורי שקדם להרחבה הגלובלית של האינטרנט, אך ההשלכות המעשיות שלו מתמשכות בכל מערכת שצריכה להתמודד עם טקסט מרוב מערכות הכתיבה הלא-לטיניות של העולם. שם עסק רוסי שנראה בעליל רגיל בקירילית הופך לרצף בלתי ניתן לקריאה של תווים מקודדים כאשר הוא מאולץ לתוך URL. שם של אדם ערבי שזורם באופן טבעי מימין לשמאל הופך לחידה טכנית כאשר הוא צריך להופיע בשדה בסיס נתונים מערבי. התנגשויות אלה בין הגיוון הלשוני של העולם לתשתית הלטינית של האינטרנט מתרחשות מיליוני פעמים מדי יום, וכל אחת דורשת תרגום לא של משמעות אלא של כתב.

Transliteration הוא המילה לתרגום ברמת הכתב זה, והוא שונה במהותו מתרגום לשוני. תרגום ממיר משמעות: "house" באנגלית הופך ל-"дом" ברוסית, כי שתי המילים מעניקות דבר זהה בשפות שונות. Transliteration ממיר כתב: "дом" בקירילית הופך ל-"dom" בלטיניות, כי אלו הן התווים הלטיניים המערערים את הצלילים של התווים הקירילית. המשמעות נשארת זהה. השפה נשארת זהה. רק מערכת הכתיבה משתנה, וזו הסיבה שלעיתים transliteration מתואר כ-"re-spelling" ולא "re-meaning".

ה-Transliterator API מספק המרת כתב זו כשירות תכנונית. שלח טקסט בכתב אחד, קבל אותו חזור בשנייה. קירילית ללטיניות, ערבית ללטיניות, יוונית ללטיניות, דווनגארי ללטיניות, ורשימה מקיפה של צמדי כתב אחרים המכסים את מערכות הכתיבה בהן נעשה שימוש על ידי רוב משתמשי האינטרנט בעולם. ההמרה עוקבת אחר תקנונים מסוגים של transliteration שבהם הם קיימים ומיפויים פונטיים מדויקים כאשר מערכות מתוקננות לא הוגדרו, ויוצרת פלט שהוא קריא, בר-הגיה, ומתאים להקשרים טכניים שבהם נדרשים תווים לטיניים.

URL Slugs וההבעיה של טקסט שאינו לטיני בכתובות אינטרנט

היישום המעשי המיידי ביותר של transliteration בפיתוח אינטרנט הוא הוצאת URL slugs מטקסט שאינו לטיני. פוסט בבלוג שכותרתו "Как приготовить борщ" (כיצד להכין בורשט) צריך slug ידידותי ל-URL שעובד בכל דפדפן, בכל פלטפורמת שיתוף, וכל מערכת אנליטיקה. התווים הקירילית בכותרת תקפים בשמות תחום בינלאומיים (IDNs) ומזהי משאבים בינלאומיים (IRIs), אך בפועל, רוב התשתית של אינטרנט עדיין מטפלת בהם בצורה לא אמינה. כתובות URL מקודדות קירילית הן ארוכות, מכוערות, ונשברות כאשר מעתיקים בין יישומים מסוימים. slug מתורגם כמו "kak-prigotovit-borshch" קצר, קריא, משתף, ותואם אוניברסלי.

מקרת היישום של הוצאת slug דורשת לא רק המרת כתב אלא גם עיבוד נוסף: אותיות קטנות, החלפת רווח לבן בחץ, הסרת תווים מיוחדים, והנורמליזציה של תווים מודגשים. ה-API transliteration מטפל בשלב המרת הכתב, המרת התווים הקירילית לשקולות הלטיניות שלהם, ויישום הקריאה מטפל בשלבים הנשארים. חלוקת אחריות זו שומרת את ה-API ממוקד על המשימה הקשה מבחינה לשונית (transliteration נכון) תוך הפקת המשימות הפשוטות טכנית (אותיות קטנות, הכנסת חץ) לצינור עיבוד הטקסט הקיים של המפתח.

איכות transliteration להוצאת slug משנה כי ה-slug נראה למשתמשים ותורם ל-SEO. משתמש רוסי שנתקל ב-slug "kak-prigotovit-borshch" מכיר אותו מיד כ-transliteration של הכותרת הרוסית ויכול לקרוא אותה ללא מאמץ. slug מתורגם בצורה גרועה, אחד המשתמש במיפויי אותיות שגויים או מייצר שילובי תווים בלתי בר-הגיה, נראה כמו שטויות לקוראים רוסיים ואנגלים כאחד. ה-API משתמש במיפויים פונטיים מדויקים שמייצרים פלט קריא ללא קשר לכתב המקור, מה שהופך את ה-slugs שנוצר לפונקציונלי גם כמזהים טכניים וגם כטקסט בר-קריאה אנושי.

אתרי מסחר אלקטרוני המוכרים לשווקים רב-שפתיים משתמשים ב-transliteration בהרחבה להוצאת כתובות URL של מוצרים. קטלוג של מוצרים הכולל פריטים עם שמות ברוסית, ערבית, סינית והינדית צריך URL slugs שעובדים בכל השפות. תרגום ידני בסולם זה אינו מעשי, וה-API transliteration אוטומטיות מייצר slugs עקביים ודיוקים שניתן ליצור כחלק מצינור ייבוא המוצר ללא התערבות אנושית לכל שפה.

שמות בדרכון ו-Transliteration של מסמכים רשמיים

Transliteration של דרכון הוא אחד היישומים חשובים ביותר של המרת כתב כי שגיאות ב-transliteration של שם גורמות לבעיות במציאות. שם המתורגם בצורה שונה בדרכון מאשר בבקשה לויזה יכול לעכב או להניע נסיעה בינלאומית. שם המתורגם בצורה שונה במערכת בנקאית מאשר על מסמך זיהוי יכול לחסום עסקאות פיננסיות. כשקי הם גבוהים מספיק שרוב המדינות שומרות תקנונים רשמיים של transliteration עבור שמות דרכון, וה-API מיישם תקנונים אלה עבור הכתבים שהוא תומך בהם.

שמות רוסיים להמחיש את המורכבות היטב. הרוסית מכתב "Щ" יכול להיות מתורגם כ-"shch," "sch," "sh," או "sc" בהתאם לאיזה מערכת transliteration מיושמת. התקן ICAO (International Civil Aviation Organization) בשימוש עבור דרכונים מציין "shch." מערכת BGN/PCGN בשימוש על ידי סוכנויות ממשלתיות בארה"ב ובבריטניה מציינת "shch." מערכת ISO 9 בשימוש בהקשרים אקדמיים מציינת תו יחיד עם סימן דיאקריטי. אדם בשם "Щербаков" צריך לדעת שהדרכון שלהם יקרא "Shcherbakov" וכל מסמך אחר הכרוך בשמם חייב להתאים ל-transliteration זה בדיוק. ה-API תומך בתקנונים מרובים של transliteration ומאפשר לקורא לציין איזה תקן ליישם, תוך הבטחה שהפלט תואם לדרישות ההקשר הספציפי.

Transliteration של שם ערבי מוסיף מורכבות נוספת כי כתב ערבי הוא abjad-based, כלומר תנועות לעתים קרובות מושמטות מהטקסט הכתוב ויש להסיק עבור transliteration. השם "محمد" (Muhammad) יכול להיות מתורגם בצדקה כ-Muhammad, Mohamed, Mohammed, Muhammed, או כמה גרסאות אחרות בהתאם למערכת transliteration ולהגיית אזורית. ה-API מיישם מיפויים עקביים ותואמים לתקן שמייצרים את הגרסאות הרחוקות ביותר, בזמן שהתיעוד מציין את השיבוליות החלופיות שתקנונים שונים מייצרים עבור שמות שנוצרו בדרך כלל.

מערכות הגירה וממשל המטפלות בבקשות מ מדינות מרובות יכולות מ-transliteration מתוקננת שמייצר פלט עקביות ללא קשר לאופרטור המטפל בבקשה. ללא API-based transliteration, אופרטורים בודדים מיישמים את transliteration האינטואיטיבי שלהם, מה שמייצר תוצאות לא עקביות המסבכות התאמת בסיס נתונים, אימות זהות ותיקיית רשומות. Transliteration מתוקננת דרך ה-API מבטיחה שטקסט המקור זהה תמיד מייצר פלט לטיני זהה, חיוני למערכות הסומכות על התאמת מחרוזות לאימות זהות.

חיפוש הנורמליזציה וחיפוש תוכן על פני כתבים

מערכות חיפוש מעומתות בהשגה בסיסית כאשר קורפוס החיפוש כולל תוכן בכתבים מרובים: משתמש החוקר בכתב אחד צריך למצוא תוכן המאוחסן בכתב אחר אם התוכן רלוונטי מבחינה סמנטית. משתמש רוסי החוקר "Москва" (Moscow) צריך למצוא תוכן שהוא מצטייצים "Moskva" באינדקס תסריט לטיני. משתמש אנגלי החוקר "Moscow" צריך למצוא תוכן המאוחסן עם המקור הקירילית "Москва." התאמה זו הצלבת סקריפט דורשת שכבת נורמליזציה שמתרגמת שאילתות חיפוש ותוכן מיוצר ללטיניות משותף לפני התאמה.

ה-API transliteration משמש כשכבת נורמליזציה זו. בזמן אינדקס, תוכן שאינו לטיני מתורגם ללטיניות ומאוחסן לצד הגרסה המקורית של הכתב. בזמן שאילתה, שאילתות שאינן לטיניות מתורגמות לפני התאמה כנגד המדד המנורמל לטיניות. גישה זו של דואל-אינדקס מבטיחה חיפושים בכל תסקיט תומך מוצא תוכן המאוחסן בכל כתב תומך, כי ההתאמה מתרחשת בחלל לטיני מנורמל משותף שבו הבדלי כתב פחתו.

הדיוק של transliteration משפיע ישירות על רלוונטיות חיפוש יישום זה. transliteration שגוי מייצר צורה מנורמלת שאינה תואמת את הצורה המנורמלת הנכונה של אותה מילה מ מקור שונה, מה שיוצר שליליות שקריות (תוכן רלוונטי לא נמצא). transliteration שמייצר פלט דו-משמעי, בו מילים מקור שונות ממפות לאותו מחרוזת לטיני, יוצר חיוביות שקריות (תוכן לא רלוונטי נמצא). מיפויי פונטיים מדויקים של ה-API מצמצמים את שני הסוגים של שגיאה, אם כי כמה דו-משמעיות הן אינהרנטיות לכל מערכת transliteration כי כתבים שונים מקודדים הבדלים פונטיים שונים.

פלטפורמות מוזיקה, מאגרי ספרים וקטלוגים של מדיה הם משתמשים כבדים של נורמליזציה של חיפוש מבוסס transliteration כי קטלוגים שלהם משתרעים על עשרות שפות וכתבים. אמן ששם שמאוחסן בקירילית בקטלוג רוסי, לטיניות בקטלוג בארה"ב, ויפני קטקנה בקטלוג יפני צריך להיות ניתן למצוא דרך חיפוש יחיד ללא קשר לכל כתב משתמש הקלדות. נורמליזציה של transliteration עושה חיפוש מאוחד זה אפשרי על ידי הפחתת כל גרסאות כתב לצורה לטינית משותף המשמש כמפתח התאמה.

כתבים תומכים ובהיקף של ההמרה

ה-Transliterator API תומך בהמרה מקירילית (רוסית, אוקראינית, בולגרית, סרבית וכתבים קירילית שפות אחרות), ערבית (כולל וריאנטים פרסית וראבי), יוונית, דוונגארי (הינדית, סנסקריט, מרתי), בנגלית, תאילנדית, גיאורגית, ארמנית, עברית, קוריאנית (romanization של Hangul), יפנית (romaji המרה עבור hiragana וקטקנה), וסינית (pinyin המרה עבור תווים מפוזרים וטרדיציוניים). כל זוג כתב יש כללי transliteration ספציפיים המהווים את המאפיינים הפונטיים של כתב המקור והיכולות הייצוגיות של תווים לטיניים.

כללי ההמרה אינם אחד-גודל-מתאים-הכל בשפות המשתתפות בכתב. קירילית רוסית וקירילית אוקראינית משתמשות באותה אלפבית אך עם אותיות שונות ו כללי הגיית שונים עבור אותיות משותפות. ה-API מבדיל בין קלט רוסי ואוקראיני ומיישם כללי transliteration ספציפיים לשפה המתאימים, חיוני לדיוק כי אותו תו יכול לייצג צלילים שונים בשפות קירילית שונות. מודעות שפה זו משתרעת על כתבים רב-שפתיים אחרים, מה שמבטיח transliteration משקפת את כללי ההגיה של השפה המקורית הספציפית ולא יישום מיפוי גנרי-תסקיט.

הפלט הוא טקסט לטיני טהור המשתמש בתווים ASCII כברירת מחדל, עם אפשרות לכלול סימנים דיאקריטיים עבור מערכות transliteration שהן משתמשות (כמו ISO 9 עבור קירילית או ISO 233 עבור ערבית). פלט ASCII-בלבד אידיאלי עבור יישומים טכניים כמו URL slugs, שמות קבצים, ומזהים בסיס נתונים כאשר סימנים דיאקריטיים גורמים לבעיות תאימות. הפלט דיאקריטי אידיאלי עבור יישומים שם דיוק פונטי משנה יותר מאשר תאימות אוניברסלית, כמו פרסומים אקדמיים ומאגרי נתונים לשוניים.

המרה דו-כיוונית תומכת עבור צמדי כתב שבהם ההמפה הפיכה. קירילית ללטיניות ולטיניות לקירילית שניהם עובדים, ההנעה ההמרה עם סיבוב שבו הטקסט המקורי יכול להוושג בקירוב מהטופס המתורגם. ההיפוך הוא בקירוב ולא בדיוק עבור כמה תווים כי transliteration הוא אינהרנטי אובדן כאשר כתב המקור מבדיל צלילים שהתסקיט היעד לא, אך למטרות מעשיות רובן איכות הסיבוב מספיקה להכרה אנושית.