עברית ו-RTL במערכות עסקיות: הבאגים שחוזרים שוב ושוב

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

1. הבאג הנפוץ ביותר: תקין במסך, הפוך ב-PDF

זו התלונה מספר אחת, וההסבר שלה פשוט ברגע שמבינים אותו.

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

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

יש שתי גישות לפתרון, ובחירה ביניהן היא ההחלטה הארכיטקטונית האמיתית:

• לרנדר דרך דפדפן. לבנות HTML ולתת למנוע דפדפן להפיק ממנו PDF. היתרון: מקבלים את ה-bidi, את פריסת ה-CSS ואת טעינת הפונטים בחינם, בדיוק כפי שנראה במסך. החיסרון: צריך דפדפן על השרת, וזה משקל תפעולי אמיתי.
• לצייר ישירות בספריית PDF. מהיר וקל יותר לפריסה, אבל אז אתה אחראי לסידור הדו-כיווני בעצמך - צריך להעביר כל מחרוזת עברית דרך ספריית bidi שתסדר אותה מחדש לפני הציור.

שתי הגישות עובדות. מה שלא עובד הוא לצייר ישירות בלי סידור דו-כיווני ולקוות.

2. ריבועים ותווים חסרים - זו בעיית פונט

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

פונטי ברירת המחדל של ספריות PDF הם לרוב משפחות Latin-1 קלאסיות בלי כיסוי עברי כלל.

הפתרון הוא לצרף פונט עם כיסוי עברי אמיתי אל המערכת ולהצביע עליו מפורשות. שתי נקודות שקל לפספס:

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

3. פריסה: לוגי, לא פיזי

הטעות המבנית היא לבנות את הפריסה בכיוונים פיזיים - margin-left, padding-right, text-align: left - ואז לנסות "להפוך" הכול כשמגיעה עברית.

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

הגישה הנכונה היא תכונות לוגיות: margin-inline-start במקום margin-left, text-align: start במקום left. הן מתהפכות לבד לפי dir, ומה שלא אמור להתהפך פשוט נשאר בכיוונים פיזיים - בכוונה ובמפורש.

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

4. הבאג שהכי קשה לאתר: טקסט מעורב

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

דוגמאות מהחיים: חשבונית מס 2026-00123 עבור ACME בע"מ, מספר טלפון בתוך משפט עברי, מק"ט אלפאנומרי, כתובת URL בהודעת WhatsApp.

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

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

המקום שבו זה הכי מסוכן הוא טקסט שלא עובר דרך HTML בכלל - הודעת SMS, הודעת WhatsApp, שם קובץ, שורת נושא של מייל. שם אין CSS ואין dir, ורק תווי הבקרה עובדים.

מקומות שנשכחים

• שמות קבצים. קובץ PDF עם שם בעברית עלול להישבר בכותרת ההורדה, ובמערכות מסוימות להישמר פגום. שם קובץ באנגלית עם מזהה מספרי הוא הבחירה הבטוחה.
• ייצוא לאקסל. עמודה עברית תיראה תקינה, אבל עמודה מעורבת של טקסט ומספרים תסבול מאותה בעיית ניטרליות - ובנוסף, כיוון הגיליון עצמו הוא הגדרה נפרדת.
• שורת נושא במייל. נושא בעברית דורש קידוד מתאים; בלעדיו חלק מהלקוחות יציגו ג'יבריש. גוף ההודעה עשוי להיראות מצוין בזמן שהנושא שבור.
• לוגים. טקסט עברי בלוג טרמינל יוצג לפי כיווניות הטרמינל, שלרוב שגויה. זה לא באג במערכת - אבל זה יבלבל אותך בזמן ניפוי שגיאות אם לא תדע.

איך לבדוק שזה באמת עובד

הבדיקה במסך אינה מספיקה, כי המסך מקבל bidi בחינם. מה שבאמת צריך לבדוק:

1. PDF שנוצר בייצור, לא בסביבת הפיתוח - שם חסרים הפונטים.
2. רשומה עם טקסט מעורב - שם לקוח בעברית, מספר מסמך, וסכום. לא רק עברית טהורה.
3. מייל שנשלח בפועל, כולל שורת הנושא, בשני לקוחות דואר שונים.
4. הודעה שיוצאת בערוץ טקסט - SMS או WhatsApp - עם מזהה בתוך משפט עברי.
5. המקרה הריק. שדה עברי חסר לא אמור להפיל את הפריסה או להשאיר סימן פיסוק תלוי.

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