Localization

The SDK ships localizations for German, English, Spanish, French, Irish, Italian, Lithuanian, Dutch, Polish, Portuguese, Swedish and Turkish (de, en, es, fr, ga, it, lt, nl, pl, pt, sv, tr).

By default the SDK renders in the device language and falls back to English where the device is set to a language the SDK does not ship. Two APIs let you change that: you can select the language yourself, and you can replace individual translations with your own.

Selecting the language

By default the SDK renders in the device language. setLanguage selects one of the languages the SDK ships instead, and what you select applies to:

• the text on SDK screens;
• date, number and currency formatting inside the SDK;
• the language of backend-provided content (the SDK forwards it as the request locale).

Screens are localized when they are built, so call setLanguage before starting a flow: changing the language does not re-localize a screen that is already on display.

The two platforms differ in the details, so check the one you are integrating:

	Android	iOS
Select a language	setLanguage(code), returns Boolean	setLanguage(code), no return value
Follow the device language again	resetLanguage()	setLanguage(nil)
A language the SDK does not ship	returns false, nothing changes	falls back to the device language
Remembered across app restarts	yes, until cleared	no, set it on every launch
Reading the current state	selectedLanguageCode, supportedLanguageCodes	not available

Android

Pass an ISO 639-1 code. The call returns whether that language was applied.

// Android
val success = DigidentitySDK.setLanguage("nl")   // true if "nl" is supported

• Call it after configure(), or it throws DigidentitySDKError.InvalidInput.
• A code the SDK does not ship returns false and changes nothing.
• The choice persists across app restarts until you clear it.

To go back to following the device language:

// Android
DigidentitySDK.resetLanguage()

To check the current state:

// Android
val current: String? = DigidentitySDK.selectedLanguageCode      // null if none is set
val supported: List<String> = DigidentitySDK.supportedLanguageCodes // safe to call before configure()

iOS

Pass an ISO 639-1 code, or nil to follow the device language again. A language the SDK does not ship also falls back to the device language.

// iOS
SDK.sharedInstance.setLanguage("nl")   // Dutch
SDK.sharedInstance.setLanguage(nil)    // back to the device language

The selection is not persisted, so set it on every launch, and there is no API to read it back - an app that shows the current choice in its own UI has to remember what it passed.

Overriding SDK strings

Both platforms let you replace individual SDK translations with your own, so you only provide the strings you want to change and the SDK's own translation is used for everything else. They differ in when it happens: Android overrides them while your app is built, through ordinary resources; iOS is pointed at a strings table of yours at runtime.

Ask Digidentity for the keys of the strings you want to override.

Android

Nothing SDK-specific is needed - the regular Android resource override applies. SDK strings are ordinary string resources, so declaring a resource with the same name in your app replaces the SDK's during resource merging. This is the same mechanism as overriding sdk_digidentity_links_host in the Android setup, and it is written the same way:

<!-- Android: app/src/main/res/values/strings.xml -->
<resources xmlns:tools="http://schemas.android.com/tools">
    <string name="authenticate_unlock_enter_5_digit_pin" tools:override="true">Enter your 5 digit PIN code</string>
</resources>

tools:override="true" states that replacing the library's resource is deliberate, which keeps the resource merger from failing the build over the conflict.

Localize an override by putting it in the matching values-<language> folder (values-nl/strings.xml, values-pl/strings.xml, ...); languages you do not provide keep the SDK's translations. Keep the format arguments of the string you are replacing in the same order and of the same kind (%1$s for text, %1$d for a number), and keep a plural resource a plural resource - the platform formats these, so a mismatch surfaces as a formatting error at runtime.

Because this happens while your app is built, there is no API to call and nothing to set up at runtime.

iOS

setStringsBundle points the SDK at a bundle of yours holding replacement translations. Every SDK string is looked up there first and falls back to the SDK's own translation when the key is absent.

// iOS
SDK.sharedInstance.setStringsBundle(.main)

Preparing the table

The strings table has a fixed name: DigidentitySDK. Add a string catalog called DigidentitySDK.xcstrings to your app target, and put the SDK keys you want to change in it, localized into the languages you care about. Then pass the bundle it is built into - Bundle.main for your app target - and nothing else: you never name the table yourself.

The name being the SDK's rather than yours keeps these overrides clear of your app's own Localizable strings, and gives support one file to ask about when an override does not appear.

Two things to keep in mind:

• The table must be compiled localized resources. Xcode compiles a catalog that belongs to a target into <language>.lproj/DigidentitySDK.strings (plus DigidentitySDK.stringsdict for pluralized strings), which is what the SDK reads. A .xcstrings file copied into a .bundle folder by hand is not compiled - it stays a source file that cannot be read at runtime, and the SDK will log an error saying so.
• Keep the original placeholders. Use the positional form of the placeholders of the string you are replacing, in the same order and of the same kind: %1$@ where the string takes text, %1$d where it takes a number. A translation whose placeholders the string cannot satisfy - more of them than it provides, or one of the wrong kind - is ignored and logged, because substituting it would crash rather than merely read oddly.

What is overridden, and when

• Overrides follow the language the SDK renders in - the one selected with setLanguage, or the device language. A language your table does not cover keeps the SDK's own translations, so an English-only override table leaves a Dutch session in Dutch.
• A regional folder also covers its base language: pt-BR.lproj is used when the SDK renders pt.
• A bundle that declares no languages at all (a single DigidentitySDK table at its root) is used for every language.
• A few keys the SDK reads as data rather than showing to the user cannot be overridden.
• Nothing is persisted: call setStringsBundle on every launch, before presenting any SDK flow.

The sample app demonstrates the whole setup - see the "Localization" screen and DigidentitySDK.xcstrings in the iOS sample app.