בניית ממשק עברי (RTL) שלא נשבר: צ׳קליסט מעשי למערכות B2B

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

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

1. כיוון המסמך הוא השורש — לא ה-div

הטעות הנפוצה ביותר היא הוספת dir="rtl" ל-div פנימי בתוך העמוד. זה משנה יישור טקסט, אבל לא משנה את סדר הפריטים בתוך פריסות flex ו-grid שהוגדרו מחוץ לאותו div, ולא משפיע על קומפוננטות שמרנדרות את עצמן ב-portal מחוץ לעץ ה-DOM המקומי — תפריטים נפתחים, דיאלוגים, טולטיפים ותפריטי הקשר.

הכיוון צריך להיקבע ברמת ה-html וה-body, ובנוסף להיות מוזרם לספריית הקומפוננטות דרך ספק כיוון ייעודי (למשל DirectionProvider ב-Radix). כשעובדים עם רינדור בצד שרת, כדאי גם לוודא בזמן ריצה שהערך אכן הוחל — עדכון סגנון מאוחר או קומפוננטה של צד שלישי עלולים לדרוס אותו.

כלל אצבע: אם פתרתם בעיית סדר פריטים באמצעות flex-row-reverse — כנראה לא פתרתם בעיה, אלא הסתרתם אותה עד לרזולוציית מסך אחרת.

2. יוטיליטיז לוגיים במקום פיזיים

מרווחים, יישור וגבולות צריכים להיכתב במונחים לוגיים (התחלה/סוף) ולא פיזיים (שמאל/ימין). ב-Tailwind זה אומר ms/me במקום ml/mr, ps/pe במקום pl/pr, ו-text-start/text-end במקום text-left/text-right. ב-CSS גולמי אלה margin-inline-start, padding-inline-end, inset-inline ו-border-inline.

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

3. איי־LTR: מתי עברית צריכה להפסיק

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

הפתרון אינו לשנות את כיוון העמוד אלא לבודד את האי: אלמנט inline עם dir="ltr" ו-unicode-bidi: isolate. בשדות קלט של טלפון ודוא"ל כדאי גם להגדיר את כיוון השדה עצמו ל-LTR, אחרת הסמן קופץ בזמן הקלדה והמשתמש מקליד לאחור.

<span dir="ltr" style="unicode-bidi: isolate">+972-52-000-0000</span>

4. טפסים: הכיוון של השגיאה חשוב כמו הכיוון של השדה

• תוויות מעל השדה ולא לצידו — חוסך התאמות כיוון ומשפר קריאות במובייל.
• הודעות שגיאה בעברית ברורה ובגובה קבוע, כדי שהטופס לא יקפוץ כשמופיעה שגיאה.
• סדר טאב חייב לעקוב אחרי הסדר החזותי; פריסת grid שמסדרת מחדש עמודות שוברת אותו בשקט.
• שדות מספריים: inputMode="numeric" בעברית מונע מקלדת עברית שמזינה תווים לא חוקיים.
• אימות בעברית צריך לקבל גם רווחים ומקפים בטלפון, ולנרמל לפני שמירה ולא לפני הצגה.

5. טבלאות, נתונים ומספרים

טבלת נתונים עברית מציגה כותרות מימין לשמאל, אבל עמודות מספריות עדיין צריכות יישור לפי סוף השורה כדי שהספרות יתיישרו אנכית. תאריכים במערכת ישראלית מוצגים בפורמט DD/MM/YYYY — ערבוב עם הפורמט האמריקאי בדוחות שונים באותה מערכת הוא מקור קבוע לטעויות תפעוליות.

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

6. אייקונים, אנימציה וכיווניות

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

7. בדיקות קבלה שאני מריץ לפני שחרור

1. מעבר על כל מסך ברוחב 360 פיקסלים ואימות שאין גלילה אופקית.
2. פתיחת כל דיאלוג ותפריט נפתח ואימות שהם נפתחים לכיוון הנכון ולא נחתכים.
3. הקלדת טלפון ודוא"ל ובדיקה שהסמן לא קופץ ושהערך נשמר כפי שהוקלד.
4. ניווט מקלדת מלא בכל טופס, כולל סגירת דיאלוג ב-Esc ושליחה ב-Enter.
5. בדיקת קורא מסך על מסך אחד קריטי לפחות, עם תוויות aria בעברית.
6. השוואת תאריכים בין המסך, הייצוא ל-Excel וה-PDF — אותו פורמט בשלושתם.

סיכום

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