A successful Arabic home screen does not mean localization is complete. Failures appear when a stored language is restored, an Arabic numeral reaches an API, a server returns an untranslated error, or language changes while the app is open.
Do not use forceRTL as a language switch
React Native documents I18nManager.forceRTL() as a development and testing tool. A full direction change applies on the next application start. Forcing a restart can destroy unsaved user work.
Change content language immediately where safe, then schedule any required native direction restart with a clear message and persisted state.
Normalize numbers at the boundary
Accept the formats the interface promises, then convert them before validation and API submission:
const arabicDigits = "٠١٢٣٤٥٦٧٨٩";
const persianDigits = "۰۱۲۳۴۵۶۷۸۹";
export function normalizeDigits(value: string) {
return value
.replace(/[٠-٩]/g, (digit) => String(arabicDigits.indexOf(digit)))
.replace(/[۰-۹]/g, (digit) => String(persianDigits.indexOf(digit)));
}
Reject empty, partial, or ambiguous values after normalization. Do not include the raw private input in error logs.
Treat API errors as data
Prefer stable error codes from the server and translate them in the client. Do not parse English sentences to decide what happened. Keep a safe generic message for unknown codes and log only the operational context needed for diagnosis.
Restore language before critical rendering
Load the persisted language during the app bootstrap. Avoid rendering the main navigator in one direction and immediately replacing it with another. A short controlled loading state is better than a visible layout jump.
Add a focused test matrix
Cover cold start, restored Arabic, restored English, language switching, localized numbers, mixed-direction strings, server failures, offline state, and form recovery. The most valuable tests exercise boundaries where text becomes layout or user input becomes API data.