אתמול עלה באתר של לינגנו מאמר ראשון בסדרת מאמרים על תכנות עבור תמיכה בשפות דו כיווניות (כלומר, עברית, ערבית וכדומה). המאמר הוא באנגלית, כדי לאפשר לאנשים שבאמת צריכים להבין את הנושא לקרוא אותו.
המאמר מתפרסם פה.
תגובות יתקבלו בברכה.
שחר
מאמר ראשון בסדרה – תכנות עבור תמיכה בשפות דו כיווניות
מאת
ניטפוק: הניסוח “שפות דו כיווניות” אינו נכון.
עיברית או ערבית אינן דו כיווניות. הן נכתבות רק מימין לשמאל.
באמת? מעניין אותי לראות איך אתה כותב משפט שאומר “אני אהיה בן X עוד Y חודשים”, עם X ו-Y הרלוונטים לך
שחר
יוזמה ברוכה.
הפתיח במקום, אבל אני רק רוצה להקדים את התרופה למכה ולהזכיר שמה שמפתחים רוצים בסוף אלה דוגמאות איך ליישם דברים כאלה בפועל.
למשל, בדיוק החודש קיבלתי מישהו משוגר (המערכת הגרפית של OLPC) שנתקל בעיות. הנה פוסט שלו
יש שם תגובות בנוגע לכיוון בדפי אינטרנט
למזלו הוא ידע לאן לפנות, הרוב לא יודעים
הניטפוק שלי הוא ניסוחי.
ברגע שאתה עובר לכתוב X ו־ Y אתה מחליף לשפה אחרת שבמקרה הזה הכיווניות שלה הפוכה.
זה לא משנה את העובדה שעברית (או ערבית) נכתבת אך ורק לכיוון אחד. אין כזה דבר (ככול שידוע לי) שפה דו כיוונית.
במקום לכתוב “תמיכה בשפות דו כיווניות” אני הייתי מנסח את זה כ־ “תמיכה בכתיבה דו כיוונית”
(בואנה אני קרציה….)
לא מילאת את x ואת Y בערכים שרלוונטים לך.
אני אשים את המשפט שמתאים לי, ברשותך:
אני אהיה בן 37 עוד 10 חודשים.
לא ראיתי פה שום שפה מלבד עברית.
שחר
איזה טמבל אני. שכחתי את המספרים.
התייחסתי למשפט שלך כעברית ואנגלית ולא ממש קראתי אותו.
אז עברית היא שפה דו כיוונית. זה זעזוע לא קטן בשבילי.
למעשה הספרות הן לא לגמרי עבריות. בעברית קלאסית היית כותב ‘שלושים ושבע’ או ‘כ”ז’.
ובעברית מודרנית?
שחר
תשובה נוספת לנטע היא לשלוח אותה ללמוד ערבית, שם הספרות הן יחודיות לשפה ושייכות אליה, אך עדיין נכתבות משמאל לימין.
שתי הערות לעניין המאמר עצמו:
א. כיוון בסיס של פסקה: לדעתי, צריך לסייג את הכתוב לגבי אפליקציות שמטפלות בטקסט פשוט — במיוחד אם הטקסט אמור להיות משותף עם אפליקציות אחרות (הדוגמה הקלאסית היא לקוח דואר). אפליקציות כאלה, עדיף שיממשו את אלגוריתם BiDi כלשונו, ואם הן רוצות לקבוע כיוון לפסקה, יעשו זאת בעזרת תווי הבקרה (LRM ודומיו). דוגמה שלילית בענין הזה היא ההתנהגות של KMail מאז Qt4 — בעריכה, הוא קובע את הכיוון לפי כיוון הממשק ומאפשר לך לשנות ידנית, אבל כיווני הבסיס לא נשמרים בטקסט.
ב. Shaping — אתה מזניח נושא, שלמרות שהוא לא נושא BiDi פרופר, יוצא שהוא משותף לשפות הנכתבות מימין לשמאל, וזה ניקוד (אה, כן. גם תאילנדית). אם לוקחים ניקוד בחשבון, אז גם בעברית יש בעיות של shaping.
בנוסף, הצירוף לאם־אליף בערבית הוא יוצא דופן כי שמים לב אליו גם בכתב־יד. אבל יש שם צירופים נוספים שעוברים התעללויות במחשב — למשל, לאם־מים־חא נהפך בד”כ ל־glyph אחד שבו האותיות כתובות כמעט מלמעלה למטה. כלומר, לאם־אליף לא כזה מיוחד מהבחינה הזו כשעובדים במחשב.
קבל ח”ח עצבני על היוזמה,
שי.
הי שי,
א. לא מסכים איתך. אנשים שולחים לי מיילים על סף הלא קריאים בגלל שהכיווניות לא מוגדרת בתוך הטקסט. למרבה הצער, במייל אפשר לקבוע כיווניות רק באמצעות html, ולא כל לקוחות הדואר שולחים html.
ב. ניקוד איננו shaping, למרות שבהחלט ראוי להתייחס אליו. הוא לא shaping כי הוא לא מורכב מ-glyph ייחודי, אלא פשוט מהרכבה של שני glyphs אחד על השני.
לגבי לאם-מים-חא, לא הכרתי. אני אבדוק את הנושא. בכל מקרה, מטרת המאמר הראשון היא לתת מבוא, כך שאני לא חושב שזה נורא אם לא כיסיתי הכל.
ניטפוק עצבני לנטע:
דבר ראשון, בעברית תנ”כית אתה תכתוב “שבע ושלושים”, ולא “שלושים ושבע”. “שלושים ושבע” הוא כבר עברית מודרנית. בכל מקרה, אני לא רואה מצב שבו זה יהפוך ל-כ”ז. אולי ל-ל”ז.
שחר
הי שחר,
א. כיווניות ב־plaintext אפשר לקבוע, תחת ההנחה שאין קביעה חיצונית, באמצעות תווי RLM, ואם מתעקשים, אז גם כנגד קביעה חיצונית, באמצעות RLE ו־PDF. אני טענתי שגם צריך לעשות זאת, והתלוננתי על זה ש־KMail לא עושה זאת. אני חושב שיש בינינו מעט מאד אי־הסכמה.
ב. אני מסכים שזה לא בדיוק shaping, אבל הנקודה העיקרית שהוצאת לגבי shaping היא הבדל בין מספר התווים למספר ה־glyph־ים, ובאופן מרומז, בין רוחב הטקסט לבין סכום רחבי התווים — ושם מתקבלים אותם האפקטים.
אגב, דווקא הנושא הזה של shaping אמור להיות מוכר למתכנתים בשפות לטיניות, כי הם צריכים להתמודד עם צירופים כמו ff ו־ae שמתחברים (אם כי אם הם מזניחים את זה, זה לא נורא כמו בערבית). מהבחינה הזו, הם דומים לצירופים יי ו־וו של יידיש.
וכמובן, ברור לי שאתה לא אמור לכסות הכל במבוא; אני רק מנסה להוסיף לך חומר למאמרים הבאים :-).
בוקר טוב,
אל תתנצל על חוסרי הסכמה. הכל נעשה פה ברוח טובה (תקף לגבי שי וגם לגבי נטע).
לגבי א. אני חושב שאתה נופל פה בפח מסויים. למרבה הצער לא הכנסתי אותו לרשימת ה-common pitfalls. אולי צריך. הטעות, לדעתי, שאתה עושה היא לבלבל את “מה שאתה חושב שצריך לקרות” עם “מה שפרקטי לצפות שיקרה”. חייבים מסלול הגירה בין סטנדרטים, ואני לא רואה אחד כזה.
הנושא של RLE/LRM הוא נושא מאוד מאוד כאוב. הפרקטיקה עד היום לא הצליחה להכניס אותו בצורה אמינה בשום מקום שאני מכיר. המצב עם RLO אפילו יותר גרוע. יש הרבה מאוד מנועי BiDi (כולל זה של חלונות) שיש להם באגים באיזורים הרלוונטים. התוכנות, בוודאי אלו שנכתבו ע”י אנשים שאינם דוברי השפה, לא מצליחות להסתדר עם תווים בקלט שחייבים לבוא בזוגות, ואני לא מכיר אף עורך שיודע מה לעשות איתם.
במילים אחרות, נכון להיום, ההמלצה הגורפת היא לא לגעת. מאוד מצער, אבל זה המצב.
ב. הנקודה שציינתי לגבי Shaping מדבר על מספר ה-characters שמשתנה, לא על רוחב הטקסט פיזית. בכל מקרה, מבחינת הסיפרות בכלל, ניקוד (diacritics) נחשב משהו לחלוטין שונה מאשר Shaping.
לגבי יידיש – ראיתי את התוים, עוד לא עברתי על הטבלאות של Unicode, אבל לא ראיתי מנוע שיודע להפיק ײ או װ. אני גם לא בטוח איך המנוע אמור להבדיל מתי הוא אמור לעשות את זה.
שחר
קראתי שוב את מה שכתבתי, וצריך לתקן משהו. התכוונתי ל-RLE/PDF, שצריכים לבוא בזוגות. LRM/RLM, שיכולים לבוא בפני עצמם, נתמכים סביר למדי ע”י המנועים השונים, למרות שהם בהחלט עדיין מבלבלים עורכים. עדיין, ההמלצה הגורפת שלי להזהר מ-RLE/PDF לא רלוונטית ל-RLM ול-LRM
שחר
לגבי התנצלויות: אני לא מתנצל על חוסרי הסכמה, אני רק רוצה שיהיה ברור אם הם קיימים ומה הם. ואני חוזר על הטענה הבסיסית: מי שמייצר plaintext שאמור לעבור לתוכניות אחרות, שיניח אלגוריתם BiDi בלי קביעות כיוון חיצוניות, יציג פסקאות ע”פ כיוון התו החזק הראשון, ואם צריך לסדר משהו, שיסדר עם LRM.
לגבי LRE ושות’: כן, אני מסכים שיש בעייתיות עם LRE\LRO ו-PDF, ואכן היא כמעט לא קיימת עם LRM. אם חושבים קצת על המשמעות שלהם ועל איך צריך לממש אותה, גם די ברור למה.
לגבי shaping: מספר התווים (characters) לא משתנה; מה שיכול להשתנות הוא מספרם של ligatures או presentation forms. וכאלה, יש גם בעברית (FB1D-FB4F) ובאותיות לטיניות (FB00-FB06). בערבית, כמובן, יש הרבה הרבה יותר (FB50-FDFF ובנוסף FE70-FEFF; למען ההגינות, זה כולל גם תווים משפות אחרות עם מערכת כתב דומה, אותיות שאינן קיימות בערבית עצמה).
אני פשוט לא מסכים עם הנחת הבסיס שלך. אני לא מסכים שצריך להתייחס אל אימיילים בעברית כאל plaintext. אין לי, באופן אישי, בעיה עם לטעון שמיילים בעברית חייבים להשלח כ-HTML אם רוצים שהם יגיעו קריאים.
שחר
אם כך, עליך לתקן את מערכת הבלוג שלך — היא שולחת הודעות על הערות חדשות כ-plaintext בעברית.
(רק שיהיה ברור: כמובן, אני בעד plaintext).