עיצוב RTL הוא בניית אתר או אפליקציה כך שהם עובדים נכון כשקוראים אותם מימין לשמאל — כמו שקוראים עברית וערבית — ולא רק הופכים אותם ויזואלית כדי שייראו כך. רוב האתרים שפונים לקהל דובר עברית מתחילים כעיצוב שנבנה מלכתחילה משמאל לימין ואז 'מתורגם', והתרגום לבדו לא נוגע במבנה עצמו: אייקונים ממשיכים להצביע לכיוון הלא נכון, הפריסה לא מתהפכת בעקביות בין המסכים, תאריכים ומספרי טלפון נשברים באמצע המשפט, והפונט מעולם לא תוכנן לשפה שהוא מציג. כשעושים את זה נכון, RTL הוא החלטה מבנית ולא רק תרגום — וזה ההבדל בין אתר שמרגיש 'בית' לגולש דובר עברית לבין אתר שמרגיש כמו תוספת בדיעבד.
למה "רק לתרגם" לא מספיק
מחליפים את הטקסט לעברית ומשאירים את אותו קובץ CSS, ומקבלים אתר שנקרא מימין לשמאל אבל עדיין מתנהג מבפנים כאילו הוא משמאל לימין. תיבות תוכן ממשיכות לצוף לכיוון המקורי, מרווחים שנכתבו כ-margin-left או padding-right נשארים בדיוק במקום שהיו, ואלמנטים אינטראקטיביים — כפתורי חזרה, שדות טופס, breadcrumbs, סיידברים — נשארים מעוגנים למקום המקורי שלהם בזמן שהטקסט סביבם התהפך. התוצאה היא תהליך תשלום שבו כפתור 'המשך' מצביע ויזואלית אחורה, שדה חיפוש שבו האייקון בקצה הלא נכון, ו-breadcrumbs שנקראים בסדר שאף גולש דובר עברית לא היה מצפה לו. שום דבר מזה הוא לא בעיית תרגום — זו בעיית פריסה שתרגום אף פעם לא נוגע בה.
אייקונים, חצים ואנימציות שמצביעים לכיוון הלא נכון
כל אייקון שנושא משמעות כיוונית צריך להתהפך יחד עם הטקסט: חצי חזרה וקדימה, חצי דפדוף בין עמודים, כפתורי 'הבא' בתהליכי הרשמה, ואנימציות של תפריטים ומחוונים (sliders) שנכנסים מהצד. חץ חזרה שממשיך להצביע שמאלה בממשק עברי אומר לגולש ללכת לכיוון הלא נכון. אבל לא הכל צריך להתהפך — אייקונים של דברים עם כיוון קבוע במציאות (שעון, מצלמה, כפתור נגן, רוב הלוגואים) צריכים להישאר בדיוק כמו שהם; הפיכה שלהם נראית כמו באג, לא כמו תיקון. לקבל את ההבחנה הזו נכון דורש מעבר מכוון על כל אייקון ומעבר במוצר, לא רק היפוך CSS גורף.
- צריך להתהפך: חצי חזרה/קדימה, breadcrumbs, פסי התקדמות, אנימציות של קרוסלה ותפריט נגלל, זנב בועת צ'אט.
- לא צריך להתהפך: שעונים, מצלמות, כפתורי הפעלה/עצירה, רוב הלוגואים, אייקונים של חפצים מהעולם האמיתי.
מספרים, תאריכים וטקסט דו-כיווני
טקסט בעברית מציג בדרך כלל ספרות משמאל לימין גם בתוך משפט שנקרא מימין לשמאל, מה שאומר שמספר טלפון, מחיר או תאריך שמוטמעים בתוך פסקה יכולים 'להתפרק' ויזואלית אם לא אומרים לדפדפן איך לבודד אותם מהכיוון שסביבם. תאריכים צריכים לעקוב אחרי סדר הקריאה והמוסכמות של השפה, לא רק להחליף את סדר הספרות. וכל תוכן שמערבב כיוונים — שם מותג באנגלית בתוך משפט עברי, כתובת מייל, מק"ט מוצר — צריך טיפול כיווני מפורש (בידוד יוניקוד דו-כיווני, או תכונת ה-CSS בשם unicode-bidi), אחרת סימני פיסוק וספרות מסתדרים בסדר הפוך על המסך למרות שהטקסט הבסיסי תקין.
פונטים: למה לא כל גופן מתאים לעברית (ולערבית)
להשתמש באותו פונט לטיני במשקל 'תואם' זה הקיצור הכי נפוץ, וגם הטעות הכי בולטת לעין. לעברית יש מטריקות משלה: גובה שורה טבעי שונה, אין מקבילה ל-italic, וצורות אותיות שנקראות פחות טוב באותו גודל שבו פונט לטיני היה נראה מצוין. אצל ערבית המצב עוד יותר קיצוני — זהו כתב מחובר וקונטקסטואלי, שבו כל אות משנה צורה לפי מיקומה במילה, ורוב הפונטים הלטיניים בכלל לא תומכים בו, או מציגים אותו עם ריווח דחוס ותמיכה חלשה בסימני ניקוד. בחירת גופנים שתוכננו בפועל לכתב הרלוונטי — עם משקלים מאוזנים מול הלטינית שלצידם — משנה את התחושה של העמוד יותר מכל תיקון פריסה.
הפתרון שמחזיק מעמד: תכונות CSS לוגיות במקום ימין/שמאל קבועים
הפתרון שנשאר לאורך זמן הוא לא גיליון עיצוב RTL מקביל שמתוחזק ידנית — הגישה הזו נשברת ברגע שרכיב חדש עולה לאוויר ואף אחד לא זוכר להפוך אותו. הפתרון הוא לכתוב את הפריסה עם תכונות CSS לוגיות מלכתחילה: margin-inline-start במקום margin-left, padding-inline-end במקום padding-right, text-align: start במקום text-align: left. כשכותבים כך, הדפדפן הופך את הפריסה אוטומטית ברגע שמוגדר dir="rtl" על העמוד, וכל רכיב חדש יורש התנהגות נכונה כברירת מחדל, בלי צורך במעבר ידני על RTL.
הרגל אחד שמחזיר את עצמו
אסרו left/right קבועים בכל CSS חדש, ואכפו תכונות לוגיות בבדיקת קוד. זה לא עולה כלום במוצר שעובד רק באנגלית, וחוסך בנייה מחדש שלמה ביום שבו מוסיפים עברית או ערבית.
למה זה משנה מבחינה עסקית בשוק דו-לשוני או תלת-לשוני
בשוק שבו הקהל שלכם קורא עברית או ערבית לצד אנגלית, אנשים שמים לב תוך שניות אם האתר נבנה בשבילם או רק תורגם אליהם. אייקון הפוך בטעות, תאריך מבולגן, או פונט שנראה דחוס וזר — כל אלה נקראים כחוסר מקצועיות, גם אצל משתמשים דו-לשוניים שיכולים פשוט לעבור לאנגלית במקום. באיקומרס זה מתבטא ישירות בהשלמת רכישות; ב-B2B זה מתבטא בכמה ברצינות ליד פוטנציאלי מתייחס למוצר שלכם. תמיכת RTL אמיתית היא לא עוד פיצ'ר נגישות — היא סימן ברור לכמה החברה השקיעה בפועל בקהל הזה, ורוב המתחרים עדיין לא עשו את זה כמו שצריך.
שאלות נפוצות
האם עיצוב RTL זה רק להפוך את הפריסה?
לא. כיוון הטקסט הוא רק החלק הנראה. RTL אמיתי נוגע גם בכיוון האייקונים, כיוון האנימציות, פורמט המספרים והתאריכים, ובחירת הפונט. היפוך פריסה בלבד בלי כל אלה עדיין נקרא כשבור לדובר עברית ילידי.
האם עברית וערבית צריכות אותו טיפול RTL?
שתיהן נקראות מימין לשמאל, אבל אלה שני כתבים שונים לגמרי מבחינת דרישות טיפוגרפיות — ערבית היא כתב מחובר וקונטקסטואלי שדורש פונטים ייעודיים וריווח מיוחד, בעוד עברית היא כתב עם אותיות נפרדות ומטריקות משלו. אתר שפונה לשני הקהלים צריך בדיקה נפרדת לכל אחד, לא 'מצב RTL' אחד שמתאים לשניהם.
מה הטעות הכי גדולה שעסקים עושים ב-RTL?
קידוד left/right קבוע ב-CSS במקום תכונות לוגיות. זה עובד בגרסה הראשונה, ואז נשבר בשקט בכל פעם שרכיב או עמוד חדש עולה ואף אחד לא זוכר להפוך אותו ידנית.
איך אני יודע אם האתר שלי באמת מוכן ל-RTL?
העבירו אותו לעברית או לערבית ובדקו חמישה דברים: האם האייקונים והחצים מצביעים לכיוון הנכון, האם מספרים ותאריכים נקראים נכון בתוך משפט, האם הפריסה מתהפכת בעקביות בכל העמודים ולא רק בדף הבית, האם הפונט קריא ונראה טבעי, והאם משהו גולש או נחתך כשאורך הטקסט הממוצע שונה מאנגלית.