Applanga Mobile SDK Integration Overview
This article explains Applanga Mobile SDK Integration considerations for new and prospective users.
The Applanga mobile SDKs can be used to translate native, static app content into multiple languages. Applanga supports all ISO-639-1 languages and custom languages can be added on request. As long as an app is localizable, no additional development work is required to integrate Applanga into an existing app. Generally, a localizable app went through the process of internationalization, often called i18n according to the development documentation of your app development framework, All strings in scope need to be externalized in dedicated string files e.g. string XML for Android or in .string files for iOS. In other words, strings cannot be hard-coded into the app.
Applanga boasts the most native mobile integrations (SDKs) of all existing TMS which can be combined with other integration options such as the Applanga Rest API or CLI as required by the use case. The Applanga SDK integration sits above the basic localization architecture of the underlying operating system (OS) e.g. iOS or Android. For more information, please check the Applanga Integration Documentation.
Applanga currently integrates with the following SDKs:
It is important to note that each SDK may not support all Applanga integration features. Refer to the Integration Documentation for more detailed information. The features highlighted here are available for Android and iOS SDKs.
All translations that are published or set as target are live to the users of an app integrated with Applanga SDK, but every string can also have a Draft value. These Draft values can be displayed in the app via the Draft Mode. This allows translators or testers to view those Draft values of translations without publishing or even creating a new build for testing, which significantly reduces testing time.
While in debug mode or with the Draft Mode activated, Applanga automatically pushes any new, not yet uploaded strings into the dashboard across all available languages already present in the app and within the connected Applanga project.
Additionally, while the app is in Draft mode, users can access the Draft overlay to tag strings, capture and upload screenshots to the dashboard, or flag functional issues through our JIRA integration.
To find out more about the Draft mode features, visit our Draft Mode & On-Device Testing article.
The Settingsfile removes the need to manually add an API key and secret directly to the app code as part of the SDK integration. With this information, it establishes the connection between the Applanga platform, the Applanga dashboard, and the Applanga user’s integrated mobile app. Each project within the dashboard has its own Settingsfile.
In addition to the connection credentials, this file stores all translations and acts as a local database within the app. While translations can be updated over-the-air on app start, it is strongly recommended to include an updated Applanga Settingsfile with every regular app store release. Retrieving the latest version of the project Settingsfile can be automated via update script. For more information on this update script, please check the Applanga Integration Documentation.
With multiple languages and numerous strings, the Settingsfile may increase the size of the app; however, one settings file is significantly smaller than multiple string files for multiple languages which would need to be included in the app if no Applanga SDK integration existed.
While the Settingsfile may be from an earlier version of the app, the Applanga SDKs enable a mechanism called OTA (Over-the-Air) updates to keep all translations current. On app start-up, Applanga will send the translation version found locally as well as the device language to the Applanga servers. If the translations for the requested language were updated on the Applanga dashboard and the translation version is higher on the server, the SDK will download all changes made between its local version and the one on the server. This principle is called Delta Updates. It ensures the SDK does not download previously downloaded translations again and keeps the response size minimal. These downloaded updates are then cached in the app. They are available even when the app is offline and won’t be downloaded the next time the app starts.
Applanga uses a content delivery network (CDN) to accommodate for any number of update requests from around the world. This CDN resets in 10 minute intervals. That means that publishing new translations or making updates to already published translations may take up to 10 minutes until they are available via OTA updates in the app.
The Device Language, as specified in the device settings by the user, is used by the Applanga SDK to determine in which language an app should be served as well as for requesting updates. Applanga can also be integrated with an in-app language selector that would overwrite those device settings.
If only some strings of an app are available in the specified language, then those strings will appear translated while the remainder of the app will appear in the base language.
Applanga utilizes the following fallback logic to deliver the correct language to an app:
Please note the fallback logic does not work in reverse; if an app is only available in a dialect, but not the parent language, then the app will appear in the base language only. For Example, if an app is only available in Mexican Spanish (es-MX), but an app user’s device language is set to Spanish (es), then the app will appear in the base language (en).
It is possible on both android and iOS to enable the system settings fallback list which the user sets in the device settings. Additionally, the SDK supports the app configuring a custom language fallback per each language.
Please see the relevant sections for iOS and android in the readme.