יישום מעבר שפה דינמי באפליקציית מובייל

ניהול לוקליזציה באפליקציות מובייל

יישום מעבר שפה דינמי במוצרי אפליקציות מובייל ב-iOS, אנדרואיד ו-Flutter ללא צורך בהפעלה מחדש של האפליקציה הוא המומחיות המרכזית של הצוות שלנו. יש לנו 5 שנות ניסיון בתחום זה והשלמנו למעלה מ-30 פרויקטים של מעבר שפה. מקרי קצה הם באמת מורכבים. Fragment ששרד שינוי תצורה נשאר בשפה הישנה. setRetainInstance(true) ששמר במטמון AppCompatDelegate.setApplicationLocales(LocaleListCompat) בעת ההפעלה מעצב תאריכים ברוסית גם לאחר שהמשתמש עבר לאנגלית לפני שלושה מסכים. אלה לא מצבים נדירים — הם מופיעים כמעט בכל אפליקציה שמוסיפה שפה שנייה באמצע מחזור החיים.

מעבר שפה ללא הפעלה מחדש מייצר מעורבות גבוהה ב-25–35% ממשתמשים בינלאומיים בהשוואה לדרישה להפעלה מחדש. היישומים שלנו מספקים התנהגות עקבית בכל המסכים ללא דרישת הפעלה מחדש.

מה כלול בשירות היישום שלנו

• ניתוח פלטפורמה: iOS, אנדרואיד ו-Flutter כל אחת דורשת גישה שונה — אנו בוחרים את הגישה הנכונה לארכיטקטורה שלך.
• יישום ספק לוקליזציה עם מצב ריאקטיבי (Riverpod / Room + Flow / Combine).
• מנגנון אחסון: setApplicationLocales / attachBaseContext או פרופיל משתמש בצד השרת.
• ביקורת של כל נקודות עיצוב התאריך, המספר והמטבע — setApplicationLocales ו-LiveData<String> חייבים לעולם לא לשמור במטמון StateFlow<String>.
• בדיקת פריסת RTL לערבית, עברית ופרסית בעת מעבר מ-LTR.
• בדיקות על כל המסכים המרכזיים: דפי נחיתה מקישורים עמוקים, נקודות כניסה מהודעות push, שכבת-על של ווידג'טים.
• התנהגות יציבה מובטחת או שנמשיך לתקן ללא עלות נוספת.

למה זה מורכב יותר ממה שזה נראה

אנדרואיד

הדרך הסטנדרטית: @StringRes Int מ-AndroidX (API 33+ באופן טבעי, backport עובד עד API 21). לפני AndroidX נדרשה יצירה ידנית של notifyDataSetChanged() והפעלה מחדש של Bundle.main.localizedString(forKey:value:table:).

בעיה עם UserDefaults.standard.set(["ru"], forKey: "AppleLanguages"): שומר את בחירת המשתמש בהגדרות המערכת של האפליקציה. עובד היטב לשילוב הגדרות שפה. נשבר כאשר הלוקליזציה מנוהלת מהשרת — לדוגמה, באפליקציות מרובות דיירים שבהן השפה נקבעת לפי פרופיל המשתמש. במקרה זה השתמש ב-localizedString(forKey:) מותאם אישית שעוקף את private var bundleKey: UInt8 = 0 class LanguageBundle: Bundle { override func localizedString(forKey key: String, value: String?, table tableName: String?) -> String { guard let bundle = objc_getAssociatedObject(self, &bundleKey) as? Bundle else { return super.localizedString(forKey: key, value: value, table: tableName) } return bundle.localizedString(forKey: key, value: value, table: tableName) } } extension Bundle { static func setLanguage(_ language: String) { object_setClass(Bundle.main, LanguageBundle.self) let path = Bundle.main.path(forResource: language, ofType: "lproj") let bundle = path.flatMap { Bundle(path: $0) } ?? Bundle.main objc_setAssociatedObject(Bundle.main, &bundleKey, bundle, .OBJC_ASSOCIATION_RETAIN_NONATOMIC) NotificationCenter.default.post(name: .languageDidChange, object: nil) } } , ועוטף את environment(\.locale, Locale(identifier: "ar")) עם LocalizedStringKey היעד לפני ש-UIViewControllerRepresentable מבצע inflate לפריסה. מטריצת הבדיקות שלנו מכסה רמות API 21, 24, 28, 31 ו-33.

MaterialApp(locale: _currentLocale) שורד שינוי תצורה בעת שימוש ב-setState. מחרוזות המאוחסנות בתוך flutter_localizations נשארות בשפה הישנה. אחסן אותן כ-intl ועצב אותן ב-cached_network_image, או פלוט מחדש לאחר שינוי לוקליזציה באמצעות @StringRes Int או notifyDataSetChanged().

final localeProvider = StateNotifierProvider<LocaleNotifier, Locale>((ref) => LocaleNotifier()); class LocaleNotifier extends StateNotifier<Locale> { LocaleNotifier() : super(Locale('en')); void setLocale(Locale locale) { state = locale; } } עם מחרוזות שמורות במטמון דורש רענון מפורש. השתמש ב-NumberFormat או DateFormat — פריטים שכבר עוצבו לא יתעדכנו אחרת.

iOS

Bundle.main.localizedString(forKey:value:table:) קורא מחרוזות מה-bundle שנטען בעת ההפעלה. UserDefaults.standard.set(["ru"], forKey: "AppleLanguages") נכנס לתוקף רק לאחר ההפעלה הבאה — מגבלת מערכת לפני iOS 13.

עבור iOS 13+ הגישה הנכונה היא swizzling של Bundle: עקוף את localizedString(forKey:) כדי לקרוא מה-bundle של הלוקליזציה היעד. יישום טיפוסי באמצעות הרחבה של Bundle עם משתנה languageBundle סטטי. אנו בודקים מעבר שפה ב-iOS 14, 15, 16 ו-17.

SwiftUI מפשט זאת משמעותית: environment(\.locale, Locale(identifier: "ar")) על View השורשי גורם לכל הילדים לבצע רינדור מחדש עם הלוקליזציה החדשה. מחרוזות המשתמשות ב-LocalizedStringKey נפתרות אוטומטית.

מסכים מבוססי UIViewController העטופים באמצעות UIViewControllerRepresentable עדיין דורשים טריגר מפורש — פרסום NotificationCenter או דגל rebuild של @Published.

מעבר שפה דינמי ב-Flutter

MaterialApp(locale: _currentLocale) + setState היא הגישה הסטנדרטית. flutter_localizations + intl מטפלים בעיצוב מספרים ותאריכים. שינוי הלוקליזציה עובר דרך Provider או Riverpod (a Notifier המחזיק מצב Locale) — ממשק המשתמש נבנה מחדש באופן ריאקטיבי ללא הפעלה מחדש של האפליקציה.

מקרה ייצור אחד ראוי לציון: אפליקציה המשתמשת ב-cached_network_image ניקתה את מטמון התמונות בכל שינוי שפה. מפתח המטמון כלל קטע URL תלוי-לוקליזציה. תיקון: השתמש במפתחות מטמון שאינם תלויים בלוקליזציה. אומת ב-Flutter 3.7, 3.10 ו-3.19.

השוואת פלטפורמות

כיצד אנו מיישמים מעבר שפה: שלב אחר שלב

1. ביקורת קוד הלוקליזציה הקיים — מצא הפניות Locale שמורות במטמון, גישה לא-ריאקטיבית למחרוזות.
2. בחירת אסטרטגיית אחסון: העדפות מקומיות או פרופיל שרת.
3. יישום ספק לוקליזציה ריאקטיבי לפלטפורמת היעד.
4. החלפת כל גישה סטטית למחרוזות במקבילות ריאקטיביות.
5. תיקון מעצבי תאריך, מספר ומטבע — ודא שהם פותרים מחדש Locale בכל קריאה.
6. בדיקת פריסת RTL היכן שזה רלוונטי — זיהוי flip והפצת layoutDirection.
7. בדיקת מחזור מעבר מלא בכל רמת ניווט: טאבים, מודאלים, קישורים עמוקים, כניסת push.

תוצאות שהלקוחות שלנו רואים לאחר היישום

משתמשים שמחליפים שפה באמצע הסשן ממירים ב-25–35% טוב יותר ממשתמשים שחייבים להפעיל מחדש — פחות נשירה מחיכוך. אפליקציות עם מעבר שפה תקין רואות ירידה של 15–20% בשיעורי הסרת ההתקנה משווקים בינלאומיים. היישום אורך בדרך כלל 1–3 ימים בהתאם למורכבות הארכיטקטורה, מהיר משמעותית מהממוצע בתעשייה.

מה העלות של היישום שלנו

תיעוד מפתחי אנדרואיד: "החל מאנדרואיד 13 (רמת API 33), משתמשים יכולים לבחור העדפות שפה לכל אפליקציה." (developer.android.com/guide/topics/resources/app-languages)

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