Flutter Localisation

Overview

The iProov SDK automatically adapts to the host app's language. By default, this matches the device's system language — for example, if the device is set to Spanish and the app supports Spanish, the app (and therefore the iProov SDK) will display in Spanish.

If an app wants to let the user override this and pick a different language than the device default, that should be done through the platform's own per-app language preference mechanism, not through any manual language switch inside the SDK itself.

note

A manual "change language" option built directly into the iProov SDK is not supported. Language must be driven by the app/OS layer, and the SDK will follow it.

In summary:

• The SDK reacts to in-app locale changes.
• Those changes must be made using the platform-native per-app language preferences approach (as defined by Android, and the equivalent on iOS).
• The SDK itself does not expose a language switcher.

Adding Support for a New Language

If a customer needs a language that the SDK doesn't natively support yet, they can add it themselves by supplying the translation strings for the iProov SDK's text.

• Reference material on currently supported languages is available.
• An example strings file is provided as a template — on Android this is a strings.xml containing every string key the SDK needs translated.
• The same concept applies on iOS, using a Localizable.strings file as the reference/template.

Supporting In-App Language Change in Flutter

Since Flutter apps run on top of native Android/iOS platforms, and the per-app language preference mechanism lives at the native layer, Flutter needs a way to reach down into native code to trigger it. This is done using Flutter's Platform Channels (specifically a MethodChannel).

Android

Step	Detail
1	In-app language change is supported using the per-app language preferences approach.
2	To trigger this from Flutter/Dart code, use a MethodChannel to call into the native Android side.
3	To add a new language, create a strings.xml for that language, using the provided example as a reference.

Why a MethodChannel is needed

Flutter cannot change Android's locale by itself — the locale change must happen in native Android code. Flutter sends a message across a MethodChannel (a simple, well-understood bridge between Dart and native code), and the native Android side implements the actual locale-change logic, exactly as it would in a native Android app.

Flutter (Dart) side

import 'package:flutter/services.dart';

const _channel = MethodChannel('app/locale');

Future<void> setNativeLanguage(String code) async {
  await _channel.invokeMethod('setLocale', {'code': code});
}

Android (Kotlin) side

class MainActivity : FlutterActivity() {
    override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)

        MethodChannel(flutterEngine.dartExecutor.binaryMessenger, "app/locale")
            .setMethodCallHandler { call, result ->
                if (call.method == "setLocale") {
                    val code = call.argument<String>("code") ?: "en"
                    setLocale(code)
                    result.success(true)
                } else {
                    result.notImplemented()
                }
            }
    }

    private fun setLocale(code: String) {
        val locale = Locale(code)
        Locale.setDefault(locale)
        val config = resources.configuration
        config.setLocale(locale)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
            createConfigurationContext(config)
        }
        @Suppress("DEPRECATION")
        resources.updateConfiguration(config, resources.displayMetrics)
    }
}

Calling it from the Flutter app

await setNativeLanguage('es'); // Spanish

iOS

Step	Detail
1	In-app language change is supported using Apple's Localization approach.
2	To add a new language, create a Localizable.strings file for that language, using the provided reference.

Bridging Flutter to native iOS

The same MethodChannel concept applies on iOS. The native AppDelegate listens for the "app/locale" channel and responds by updating the AppleLanguages preference:

import Flutter

@UIApplicationMain
@objc class AppDelegate: FlutterAppDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    let controller = window?.rootViewController as! FlutterViewController
    let channel = FlutterMethodChannel(
      name: "app/locale",
      binaryMessenger: controller.binaryMessenger
    )

    channel.setMethodCallHandler { call, result in
      if call.method == "setLocale" {
        let args = call.arguments as? [String: Any]
        let code = args?["code"] as? String ?? "en"
        UserDefaults.standard.set([code], forKey: "AppleLanguages")
        result(true)
      } else {
        result(FlutterMethodNotImplemented)
      }
    }

    GeneratedPluginRegistrant.register(with: self)
    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }
}

The same Dart-side setNativeLanguage('es') call works here too, since it targets the same channel name ("app/locale") — only the native handler differs per platform.

Key Takeaways

The iProov SDK never provides its own language switcher. It always follows the host app's locale.

1. To change the app's language at runtime, use each platform's native mechanism:
   • Android → per-app language preferences
   • iOS → native Localization / AppleLanguages
2. Flutter apps need a bridge (a MethodChannel) to invoke these native mechanisms from Dart, since Flutter cannot change the OS-level locale directly. This is a standard Flutter pattern, not something iProov-specific.
3. Adding a new language to the SDK itself just requires supplying the missing translation file:
   • Android → strings.xml
   • iOS → Localizable.strings
4. The Android and iOS native MethodChannel handlers shown above are working examples the customer's own developers would implement and adapt — iProov provides the SDK bridge, but the app-level locale-switching bridge is built by the customer as they would for any native platform feature.