מה צריך לדעת על תמיכת RTL בשפות באפליקציות מובייל
תארו לעצמכם: אתם נכנסים לשוק האמירויות, משיקים גרסה ערבית של האפליקציה שלכם — ומקבלים מבול של ביקורות שליליות. התפריט לא מיושר, כפתורים לא ניתנים ללחיצה, טקסט נחתך. כשמשיקים את האפליקציה בערבית, אתם עשויים לגלות שכפתור ה"חזור" מצביע ימינה, ושהשקופיות מגיעות משמאל. המשתמשים רגילים לסדר ההפוך — וזה גורם לדיסוננס קוגניטיבי. ללא תמיכת RTL נאותה, אפילו אפליקציה זהה פונקציונלית מרגישה שבורה, מה שמוביל לירידה של 30% בשימור משתמשים (נתונים מהפרויקטים שלנו). התאמנו מעל 20 פרויקטים לערבית ולעברית ואנחנו מכירים את כל המלכודות. הצוות שלנו מוכן לקחת על עצמו ביקורת מלאה ויישום RTL מלא.
שינוי ה-locale והגדרת layoutDirection = rtl הוא רק 20% מהעבודה. השאר הוא התאמה ידנית של כל רכיב: אייקונים, אנימציות, ניווט, טקסט, ואפילו מחוות (למשל, החלקות). הנה מה שבאמת נשבר:
| רכיב | iOS | Android | Flutter | React Native |
|---|---|---|---|---|
| אייקונים | SF Symbols עם גרסת RTL עובדים, אבל PNG מותאמים אישית לא | autoMirrored="true" עבור VectorDrawable, BitmapDrawable לא משקף |
Directionality לא משפיע על CustomPainter |
I18nManager.isRTL לעיבוד מותנה |
| אנימציות | UIView.animate עם קואורדינטות מוחלטות |
Animator עם translationX דורש בדיקת layoutDirection |
SlideTransition עם initialOffsetX — לוגיקה ידנית |
Animated.timing עם useNativeDriver לא משקף |
| טקסט | NSTextAlignment.natural משקף, .left לא |
textAlignment="viewStart" עבור TextView |
textDirection: TextDirection.rtl עבור Text |
textAlign: 'auto' במקום 'left' |
| ניווט | UINavigationController משקף את כפתור החזור אוטומטית |
ActionBar דורש android:supportsRtl="true" |
Navigator אוטומטית, אבל מעברים מותאמים אישית לא |
ReactNavigation דורש הגדרה ידנית |
הגישה שלנו עם טרנספורמציות היפוך מותאמות אישית מהירה פי 2 מכתיבה מחדש של כל המסכים ל-RTL מאפס ומפחיתה את זמן העבודה מחדש ב-40%. זה חוסך 30–50% מהתקציב בהשוואה לשיפוץ מלא — בדרך כלל $1,000–$3,000 לפלטפורמה. אנו משתמשים בבדיקות אוטומטיות לאימות היפוך, תופסים שגיאות מוקדם ומפחיתים עלויות QA.
למה פתרונות RTL סטנדרטיים לא מכסים את כל המקרים?
הטבלה המפורטת למעלה מראה בעיות טיפוסיות. בנוסף, ב-iOS draw() מותאם אישית ו-Core Graphics דורשים היפוך מותנה כדי לשקף תוכן. ב-Android autoMirrored עובד רק עבור VectorDrawable, לא עבור BitmapDrawable. ב-Flutter Directionality לא משפיע על CustomPainter, ולכן אנו מיישמים ידנית canvas.scale(-1, 1). ב-React Native, בדקו את הגרסה: ב-Android I18nManager.isRTL עובד רק ב-RN >=0.63; אחרת, נדרש forceRTL עם טעינה מחדש. אנו גם מטפלים בתכונות מתקדמות של אלגוריתם הדו-כיווני של Unicode כמו תווי override מפורשים ו-BidiReordering לסקריפטים מעורבים.
איך אנו מיישמים תמיכת RTL
-
ביקורת. הרצת האפליקציה ב-locale ערבי דרך
adb shell setprop persist.sys.locale ar-AE(Android) ו-Settings → General → Language & Region(סימולטור iOS). זה חושף 80% מהבעיות. לכידת artifacts על כל מסך — בדרך כלל 10–15 לאפליקציה עם 50 מסכים. -
מיון. חלוקת הבעיות ל-4 סוגים: פריסה, אייקונים, טקסט, אנימציות. לכל סוג יש מתכון תיקון ספציפי. לדוגמה, לאייקונים אנו מיישמים היפוך מותנה; לאנימציות, החלפת קואורדינטות מוחלטות ביחסיות.
-
תיקונים. ב-iOS, כתיבת
draw()מותאם אישית מחדש להיפוך מותנה, שימוש ב-UIView.appearance(whenContainedInInstancesOf:)לירושת מערכת שלsemanticContentAttribute. ב-Android, החלפתleft/rightב-start/endב-XML ופרוגרמטית דרךMarginLayoutParamsCompat. עבור Flutter, שיקוףCustomPainterדרךcanvas.scale(-1, 1). עבור React Native, בדיקתI18nManager.isRTLבכל רכיב. -
בדיקות. תמיד על מכשירים אמיתיים: Samsung עם One UI משנה את התנהגות
VectorDrawable, ובגרסאות iOS ישנות יותרUIView.appearanceעשוי לא לעבוד. הוספת בדיקות צילום מסך עם locales RTL ב-CI. הרצה על 3–4 מכשירים פיזיים כדי לכסות 95% מהמקרים.
עוד על בדיקות
שימוש ב-XCTest עם XCUIRemote כדי לדמות מחוות ולבדוק היפוך. ב-Android, Espresso עם DeviceLocale כדי להחליף locale. שילוב Firebase Test Lab לבדיקות על מכשירים אמיתיים בענן.
מה כוללת העבודה
- ביקורת קוד מלאה וזיהוי artifacts על כל המסכים
- תיקון פריסה, אייקונים, טקסט, אנימציות
- התאמת רכיבים מותאמים אישית (Canvas, Core Graphics, CustomPainter)
- הגדרת אינטגרציה עם השרת להעברת הקשר RTL
- בדיקות ידניות על 4+ מכשירים אמיתיים
- שילוב בדיקות צילום מסך אוטומטיות RTL ב-CI/CD
- תיעוד לתמיכת RTL עבור הצוות
- גישה למאגר עם דוגמאות יישום
- הדרכת צוות לעבודה עם RTL (שעתיים אונליין)
- חודש תמיכה טכנית לאחר המסירה
כמה זמן לוקחת עבודת RTL לפלטפורמה?
| פלטפורמה | ביקורת (ימים) | תיקונים (ימים) | בדיקות (ימים) | סה"כ |
|---|---|---|---|---|
| iOS | 1–2 | 2–3 | 1 | 4–6 |
| Android | 1–2 | 2–4 | 1 | 4–7 |
| Flutter | 1 | 1–2 | 0.5 | 2–3.5 |
| React Native | 1 | 2–3 | 0.5 | 3–4.5 |
טעויות נפוצות בפיתוח RTL
textAlign: 'left'מקודד קשיח ברכיבים מותאמים אישית במקום'auto'או'start'-
transform: [{scaleX: -1}]מיושם על אייקון ללא בדיקתI18nManager.isRTL— האייקון תמיד משתקף - לוקליזציה של מספרים:
١٢٣(ספרות ערביות מזרחיות) לעומת123— תלוי בהקשר התצוגה, יש להגדיר במפורשNSLocale/Locale - טקסט דו-כיווני (ערבית + שם באנגלית):
NSAttributedStringעםNSWritingDirectionAttributeNameמפורש, אחרת סדר המילים נשבר
איך לשלב RTL בשלב העיצוב
הגישה הטובה ביותר היא להשתמש ב-start/end מההתחלה במקום left/right, להימנע מקואורדינטות מוחלטות באנימציות, ולבדוק Drawable מותאם אישית עבור autoMirrored. אם הפרויקט כבר בנוי, אנו עורכים ביקורת ומתקנים את כל חוסר העקביות. המהנדסים שלנו מבטיחים פעולה תקינה בערבית ובעברית בכל המכשירים הנתמכים עם קוד נקי וניתן לתחזוקה. אנו מבטיחים תאימות לגרסאות האחרונות של iOS ו-Android, ולמומחים המוסמכים שלנו יש ניסיון של 5+ שנים בלוקליזציה.
אל תתנו למשתמשים שלכם ללכת לאיבוד במבוך משוקף — צרו קשר לייעוץ ביקורת RTL. הזמינו ייעוץ — נחשב את לוח הזמנים והעלות. ההשקעה מחזירה את עצמה תוך 2-3 חודשים לאחר הכניסה לשוק.
Apple ממליצה להשתמש ב-UIView.appearance() לירושת תכונות סמנטיות; לפרטים נוספים, ראו RTL (Right-to-Left) בוויקיפדיה.