כשכיוון הטקסט הופך לסיכון קליני: למה ⁨RTL⁩ אינו פרט עיצובי

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

מה קורה בפועל

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

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

המקרה של סימני ההשוואה מסוכן במיוחד

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

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

למה צילומי מסך לא תופסים את זה

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

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

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

למה זה קורה כמעט בכל מערכת מתורגמת

כי התמיכה בכיוון הפוך נבנית בדרך כלל בדיעבד, כשכבת תיקונים מעל עיצוב שנבנה לאנגלית. במערכת קוד פתוח ותיקה ומוכרת בתחום, מדידה של גיליון הסגנונות מראה שרק כ‑⁨5%⁩ מכללי העיצוב משתנים בין המצב הרגיל למצב ימין לשמאל, ושהממשק בעברית מתורגם בכ‑⁨61%⁩ לפי ספירת מחרוזות. מספרים כאלה מייצרים מסכים היברידיים: חלק מיושר נכון, חלק לא, וכפתורים שנשארו במקום הלא נכון.

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

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

איך פותרים את זה נכון

הפתרון אינו רשימת תיקונים למסכים אלא שלוש החלטות תשתית:

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

מה לשאול ספק

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

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

חזרה לבלוג